Add cctl module and extend e2e test to use it

[marijanp]

• added a binary which uses the kairos-test-utils to launch a cctl network
• added a nixos module definition for cctl
• added the module to the e2e-tests server configuration, and created an assertion that queries one of the casper-nodes using casper-client-rs

[xcthulhu]

Why not just do it now?

[marijanp]

Because CCTL does not offer a way to do that yet. Mark is aware of it and working on it.

[Rom3dius]

Small question, looks all good to me and I think I'm good to approve.

How flexible are such nix modules? During the testing that @jonas089 did, he often had to modify the chainspec files in casper-node to allow them to accept the large proofs generated by the zk-rollup. Hopefully this won't be an issue with the trie, and if it is then wrapper proofs might be a solution anyway, but during this phase of prototyping such changes to the casper-node are practical.

Also, shouldn't we be waiting at least for the genesis block before we start testing?
kairos.succeed("casper-client get-node-status --node-address http://localhost:11101")
Is it feasible to instead check that genesis or the first block has been processed before running tests?

[marijanp]

Small question, looks all good to me and I think I'm good to approve.

How flexible are such nix modules? During the testing that @jonas089 did, he often had to modify the chainspec files in casper-node to allow them to accept the large proofs generated by the zk-rollup. Hopefully this won't be an issue with the trie, and if it is then wrapper proofs might be a solution anyway, but during this phase of prototyping such changes to the casper-node are practical.

For different chainspec configurations you would extend the module with an according option.
You then implement this option, analogous to what I did with cctl enable or port. I assume given a chainspec option you create the respective updated chainspec and cctl is called with this chainspec.

Also, shouldn't we be waiting at least for the genesis block before we start testing? kairos.succeed("casper-client get-node-status --node-address http://localhost:11101") Is it feasible to instead check that genesis or the first block has been processed before running tests?

The cctl rust-wrapper waits for that. So here we just wait for the service to start as expected

[github-actions]

File	Coverage
All files	63%	✅
kairos-crypto/src/implementations/casper.rs	3%	❌
kairos-server/tests/transactions.rs	83%	✅
kairos-test-utils/src/cctl.rs	87%	✅
kairos-test-utils/src/cctl/parsers.rs	66%	✅
kairos-tx/src/asn.rs	66%	✅
kairos-server/src/routes/deposit.rs	86%	✅
kairos-server/src/routes/transfer.rs	73%	✅
kairos-server/src/routes/withdraw.rs	91%	✅
kairos-server/src/config.rs	0%	❌
kairos-server/src/errors.rs	16%	❌
kairos-server/src/utils.rs	22%	❌

Minimum allowed coverage is 60%

Generated by 🐒 cobertura-action against a0d71e8

[Rom3dius]

Approved, but I don't think changing chainspec or other files will be easy using nix, since (as I understood from your last message) it seems mostly capable of flexibility in CLI arguments, but not in changing files (CCTL has no CLI argument for chainspec)

[marijanp]

@Rom3dius the option I meant in my explanation is a module option. How you implement a module option can differ. It can be whatever you want. So I could modify a file, set an env-var, pass an argument, run a binary, etc. it doesn't matter.

Files are the smallest deployment units as far as nix is concerned

[Avi-D-coder]

LGTM

[koxu1996]

@Rom3dius Agree, this might be blocker for us when we start integrating Risc0. However, we should think about workarounds to avoid chainspec customization, as this prevents us from using official L1 infrastructure.