Nixifies #61

See #40 (review).

Motivation

In order to integration test our L2 request handlers once we implement the interaction with the L1, we will need to establish connections to the L1 using casper-client-rs's library.
These tests will potentially be executed in parallel, thus we have to be able to spawn multiple networks in isolation, such that each test-case has access to a clean state network.

Steps towards a working harness

We will implement a cctl network hook that launches a network. To ensure proper functioning of this hook, we will need a basic test doing the following steps:

• launch network via cctl
• await network launch
• establish node connection via casper-client-rs
• execute a deploy transfering funds
• await transaction settlement

Since we wanted contract to be no_std (smaller WASM), panic handler and global allocator has to be implemented additionally. We just relied on no-std-helpers features from casper_contract, which unnecessarily enforced use to use nightly toolchain.

I would like to build contracts with stable Rust.

Both public key and signature types are defined as String:

This is clearly wrong, as those are arbitrary bytes, not necessarily valid UTF-8 data.

• report code coverage
• report number of tests i.e. visualize cargo test results
• report benchmarks for critical functions/ parts of the system

Nix defines unstable toolchain for building prover:

I would like to investigate why (or rather if) we need nigthly toolchain here.

As discussed during the latest Smart Contract deep dive, we should include details of L2 transaction in deposit event:

• payload - SigningPayload from kairos-tx,
• public key,
• signature.

Furthermore, smart contract must check that given transaction details are correct, i.e.:

• Given public key is matching with contract caller (depositor).
• Signature is valid for payload.
• Payload details are matching with deposit amount.

That would allow to us to fully trust deposit events, without additional interactions with L1.

We need 3 basic commands: deposit / transfer / withdraw.

Use https://github.com/rkyv/rkyv for inner messages that appear in a ZK context.
Json is quite expensive should we should use a more efficient format like rkyv's archive or flatbuffers. We only need this on inner messages we can wrap it in JSON for communicating with the server, and base64 the payload.

There is some security risk in using a rkyv since it's devs may have made a mistake and it uses unsafe extensively. Hence we may only want to use it where needed or use the more mature flatbuffers.

https://github.com/paritytech/trie/tree/master/trie-db

The CLI and any future SDKs should use a Rust library to identify L2 endpoints and construct/sign payloads.
The library should be WASM compatible for use in TypeScript and Python SDKs.

This logic needs live in Rust to allow the use of efficient formats like rkyv in the signed payload that needs to be checked in ZK.

The following PR's implement the kairos-cli deposit integration. The PR's can be reviewed in any order but merged in the following order:

• 1. #89 is needed for the kairos-test-utils to achieve a more congruent configuration with the actual CLI binary. All of the logic is now in kairos_server::run
• 2. #90 then uses the kairos_server::run instead of the binary-cli to solve a chicken and egg-problem.
• 3. #91 implements the integration with the kairos-server. kairos-test-utils is then used in an integration test to verify that submitting to the kairos-server works
• 4. #94 submit the deposit deploy to L1
• 5. update end-to-end to await deposit deploy, after it was submitted through the CLI
  • 5.1 NEEDS_REVIEW: #110
  • 5.2 NEXT: create a mock data availability layer, circumvent the batch submission and verification, and query whether the deposit was added correctly

• add the kairos-cli to a client node
• use the kairos-cli to make a deposit, transfer, withdraw call to the kairos server

Currently we are using anyhow we should switch to thiserror.

See #73 (comment).

Nix's e2e tests relying on curl SHOULD be already broken at least twice - for example the following PRs successfully passed CI checks, even they changed request body in incompatible way:

• #32
• #53

For deposits routed through Kairos, we should subscribe for Casper's DeployProcessed server-side event in order to get notification once deployment was processed. Relevant design part:

Notably there is no Rust client/SDK available for Casper's SSE.

Verify signatures where I have TODOs on transactions.
Favor RustCrypto k256 so we can match the use of the risc0 accelerated patch in the guest.
https://github.com/risc0/risc0/tree/release-0.19/examples/ecdsa

Besides CLI for users, we want to provide set of SDKs for developers.

Since server is accessible via REST API, we can leverage OpenAPI spec to autogenerate clients (a.k.a. SDKs).

Reported by @xcthulhu and @jonas089 during Kairos - Tx Format deep dive call.

Btw. no_std is NOT requirement for Casper contracts, but it is beneficial for creating smaller binaries.

• Build Rust library for working with Casper Event Standard - https://github.com/koxu1996/casper-event-toolkit.
• Implement simple SSE client - #40.
• Integrate kairos-tx with smart contract events - #73. <- This will be discussed post-MVP.
• Integrate CES library with Kairos server - #96.
• Integrate SSE trigger - WIP ⚙️ .

See #74 (review).

Broken e2e tests was detected after CI was fixed:

Exception: command `curl --fail-with-body -X POST http://kairos/api/v1/deposit -H 'Content-Type: application/json' -d '{"public_key": "publickey", "amount": 10}'` failed (exit code 22)

See #74 (comment).