zk proof for state transition function in lean consensus

[DimitriosMitsios]

Describe the feature

Introduction

Current issue introduces the reasoning and structure of a prototype meant to generate a zk proof of the state transition function in collaboration with @unnawut and @x-senpai-x. The implementation of this feature should not interfere with the rest of the codebase and will be initialized with a cli flag. Draft PR #835 hosts the development branch of the present issue and issue #13 provides useful guidelines. The choice of risc0 as a zkVM is temporary and is due to our previous experience with it and useful documentation. We plan to abstract the interface so that the user chooses among various zkVM options. This interface abstraction has been implemented for beacon chain https://github.com/x-senpai-x/Ream-ZKVM-Benchmarks with integration for: SP1, RiscZero, Zisk, Pico, Jolt, (OpenVM is coming soon).

Proof generation

1. Cli flag risc0 enabled as --features risc0.
2. ValidatorService sends a message to lean chain service
   LeanChainServiceMessage::ProduceBlockProof{ slot, sender, need_gossip }
3. For gossiping, we introduce a new p2p request variant
   LeanP2PRequest::GossipBlockProof(slot)

Proof verification

1. The proof is verified using LeanChainServiceMessage::ProcessBlockProof { proof_block, is_trusted: false, need_gossip: true }

2. Voting based on block proofs could also be implemented but only after we complete all the above

Metrics

• elapsed (wall-clock) time for proving and verification

Logs

At the beginning, we will include logs for:

• success/failure
• latest block proven, to track the progress of the client
• (time metrics as well?)

Additional context

No response

[unnawut]

Thanks for this @DimitriosMitsios! I think we can remove the meta: prefix from this issue so that this issue is solely for this first prototype.

I was thinking below would be useful to other new contributors and I tend to write long stuff so forgive me for this...

While the PR description lists the changes to the codebase (which you already did ♥️), the issue description should describe what you're trying to achieve with this feature in terms of usage/outcome. This is so that all team members and open contributors can get up to the same page as us by just reading the Github issue and the PR review process more solid :)

E.g. we should summarize into the issue from our chat discussions that...

1. User enables this feature by passing a CLI flag
2. When enabled, once the validator service produces a block, the block is fed into the zkvm to produce a proof of valid state transition.
   • The proof should commit to pre_state, block_root, slot, post_state
   • The proving process happens in parallel to the main flow of signing and gossiping the native SignedBlock
3. New gossip topic for gossiping the proof
4. Client instances will register to this new topic, receives and verifies the proof, what will we compare it with, logs the result
5. Maybe new custom metrics to show the last zk-verified slot, proving time, verification time, etc.
6. etc. etc.

It should also list the design decisions we reached so that others have context and can feedback on e.g.

1. Why we go with risc0
2. How often the proving will happen and how we arrived with this number

The question about processing LeanChainServiceMessage::ProduceProofBlock can go in the PR discussion

[DimitriosMitsios]

@unnawut Thank you very much for your feedback, I will update the issue with all the info in a few hours.