Risc0 circuit

[Avi-D-coder]

This is the risc0 circuit that me and @jonas089 worked on, the branch is based on @marijanp's nixified risc0 toolchain.

TODO (not necessarily before merge):

• groth16 wrapping from jonas089's branch.
• ~tests.~
• Switch to bincode2.0rc3 from json.
• Merge the logic in the server with the logic in kairos-circuit-logic. The logic in the server does a bunch of prechecks that are important in that setting.
• get asn1 compiling in risc0-guest for signature verification.
• ~use patched sha256 crate from risc0~

[jonas089]

I personally liked my initial structure a lot better. It was much easier to work with and easier to read. kairos-prover-server is an unnecessary crate and all of this should happen inside the kairos-server.

It also doesn't look like there are any tests for the proving process. If I just overlooked them please point them out.

[Avi-D-coder]

No tests yet. kairos-prover-server is needed, it could be a CLI instead as marijanp has suggested.

But they compile with different toolchains so some separation is required. I made it a microservice because I expect proving would occur on machines with GPUs.

The bare minimum logic is in the risc0 workspace since that workspace is still broken for RA.

[jonas089]

Also how am I supposed to construct a Snapshot when there are no tests?

[jonas089]

No tests yet. kairos-prover-server is needed, it could be a CLI instead as marijanp has suggested.

But they compile with different toolchains so some separation is required. I made it a microservice because I expect proving would occur on machines with GPUs.

The bare minimum logic is in the risc0 workspace since that workspace is still broken for RA.

Proving a Batch should not be an API endpoint. It should happen automatically on the kairos-server every n seconds / era / transactions.

[Avi-D-coder]

Also how am I supposed to construct a Snapshot when there are not tests?

fine grained tests will come soon, snapshot is constructed by existing code in the server (batch manager) if you want to take a crack at constructing one take a look at that, and or the property tests i have in the trie. We need a good property test generator like i have in the ops trie tests.

with that being said if you look at the signature of the trait I introduced in the prover server and implement in the prover, that is what you should build the contract end point around.

it should provide snapshot, ProofInputs and handle the output.

[jonas089]

Also how am I supposed to construct a Snapshot when there are not tests?

fine grained tests will come soon, snapshot is constructed by existing code in the server (batch manager) if you want to take a crack at constructing one take a look at that, and or the property tests i have in the trie. We need a good property test generator like i have in the ops trie tests.

with that being said if you look at the signature of the trait I introduced in the prover server and implement in the prover, that is what you should build the contract end point around.

it should provide snapshot, ProofInputs and handle the output.

I can't begin to write the contract entry point before this PR has been merged and this PR can't be merged without tests. The entry point will depend on types exposed by this PR so therefore we need to merge it first and it must be obvious how a proof is constructed and we must know for sure that the circuit code works as is.

[Avi-D-coder]

i'd suggest pulling this branch into a branch based on the refactored deposit contract and following the types from there.

alternatively just copy the ProofInputs/Outputs types directly into your file and don't worry about the function that turns one to the other. just make the body todo and make the logic all type check and lint.

I can write an initial prop test later today or tomorrow.

but don't let that block you the proof Inputs and Outputs types are fixed. if you write the logic around those types it will work.

[jonas089]

i'd suggest pulling this branch into a branch based on the refactored deposit contract and following the types from there.

alternatively just copy the ProofInputs/Outputs types directly into your file and don't worry about the function that turns one to the other. just make the body todo and make the logic all type check and lint.

I can write an initial prop test later today or tomorrow.

but don't let that block you the proof Inputs and Outputs types are fixed. if you write the logic around those types it will work.

i'd suggest pulling this branch into a branch based on the refactored deposit contract and following the types from there.

alternatively just copy the ProofInputs/Outputs types directly into your file and don't worry about the function that turns one to the other. just make the body todo and make the logic all type check and lint.

I can write an initial prop test later today or tomorrow.

but don't let that block you the proof Inputs and Outputs types are fixed. if you write the logic around those types it will work.

This workflow is incredibly messy, we already have too many branches and I'm sure that most of us have lost track of what's happening on them. Merging all of this will be a huge pain since Marijan is also currently trying to merge something from his deposit contract into my deposit contract.

[Avi-D-coder]

This workflow is incredibly messy

it is indeed, maybe one day pijul or stacked diffs will save us, but until then we have to live with the trade offs. complete features in a single pr are going to result in branches that live a while. on the other hand merging incomplete code results in churn and quality issues.

copying two types is about the minimum amount of coupling between branches you could do. but yes it's always a mess, until the rebase.

[github-actions[bot]]

File	Coverage
All files	43%	:x:
kairos-server/src/state/transactions/batch_state.rs	42%	:x:
kairos-test-utils/src/cctl.rs	87%	:white_check_mark:
kairos-crypto/src/implementations/casper.rs	6%	:x:
kairos-prover-server/src/lib.rs	0%	:x:
kairos-server/src/config.rs	0%	:x:
kairos-server/src/errors.rs	12%	:x:
kairos-server/src/lib.rs	95%	:white_check_mark:
kairos-server/src/state.rs	90%	:white_check_mark:
kairos-server/src/utils.rs	22%	:x:
kairos-circuit-logic/src/account_trie.rs	0%	:x:
kairos-tx/src/asn.rs	51%	:x:
kairos-tx/src/error.rs	0%	:x:
kairos-test-utils/src/cctl/parsers.rs	66%	:white_check_mark:
kairos-server/src/state/trie.rs	35%	:x:
kairos-server/src/routes/deposit.rs	88%	:white_check_mark:
kairos-server/src/routes/transfer.rs	90%	:white_check_mark:
kairos-server/tests/transactions.rs	85%	:white_check_mark:

Minimum allowed coverage is 60%

Generated by :monkey: cobertura-action against 3bcc3684da51dca3f30c198ef42a5859ce83a09f

[koxu1996]

I noticed that kairos-tx was moved to the prover directory. It should not be there, as it is a common module used by other root modules (cli, crypto, server) and it's not specifically related to the prover itself.

As clarified with @marijanp, this change was implemented to resolve an issue with Nix sourcing. I am really unhappy about such changes. Nix should be an extra feature, not something that compromises the quality of our codebase.

---

Update: fixed in https://github.com/cspr-rad/kairos/pull/112.

[koxu1996]

TODO (not necessarily before merge):

• ...
• get asn1 compiling in risc0-guest for signature verification.

If we want (I think we should) to verify signatures inside ZK VM, then I am not sure why we have duplicate types, e.g. KairosTransaction and Transaction, but we can resolve this post PR.