zk proof for state transition function in lean consensus

[DimitriosMitsios]

Describe the feature

The goal of draft PR #835 is to allow the block proposer to generate a zk proof of the state transition function. The proof will be gossiped and other validators will be able to verify it. We will use risc0 zkVM for start.

Question
How should we implement sending and receiving of LeanChainServiceMessage::ProduceProofBlock. Receiving the proof will not happen at the given slot but a few minutes later.
Our current implementation is probably wrong: https://github.com/DimitriosMitsios/ream/blob/99062abb34f142d88db520371c651d86ae164c58/crates/common/validator/lean/src/service.rs#L83-L88

Future work
Acceptance criteria and Justin's comments found in issue #13 will be considered later on, once we get a working prototype.

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.