Goal of the project

We will add a feature that allows the block proposer to generate a proof of the state transition function. The proof will also be gossiped to the network so that other validators verify the proof. For the moment, proof generation requires several minutes (I think) which is much longer than the duration of a slot (4 secs). As a consequence we hope to prove one block every 100 or 200 slots and skip the rest of the blocks.

We spent more than a week trying to understand the structure of the Ream lean consensus client. The main concept that we need to grasp is that of services. During each segment, called tick, of a slot the validator or the block proposer initializes a service. At tick 0 and 1 it is the ValidatorService that handles block production, signing of the block, sending a message to update the lean chain and voting. At ticks 2 and 3 LeanChainService updates the lean chain and accepts new votes.

Draft Pull Request

We created a draft PR https://github.com/ReamLabs/ream/pull/835#.

Work done so far includes

  • Creating a cli flag proof_gen that initializes proof generation
  • Add an extra argument to run_lean_node for proof generation
  • Create a new variant ProduceProofBlock at LeanChainServiceMessage
  • Add new field proof: bool to struct ValidatorService

There is a technical issue that we face about sending LeanChainServiceMessage::ProduceProofBlock, as seen here https://github.com/DimitriosMitsios/ream/blob/99062abb34f142d88db520371c651d86ae164c58/crates/common/validator/lean/src/service.rs#L83-L88. We don’t know how to properly implement it in such a way that the response could happen anytime in the future. We will create an issue in the Ream client for that.

We are still missing:

  • Set up guest environment and generate a proof. There is a ring dependency that needs to be fixed first. Varun is on it, the issue will be resolved in a few days.
  • Gossip and validate the proof