# EPF Cohort 6 Final Update

## tldr
* [Project Proposal](https://)
* [My work on Benchmarking ZKVMs on Ream's Beacon Chain](https://github.com/x-senpai-x/Ream-ZKVM-Benchmarks/)
* [My work on Ream's Lean Chain](https://github.com/DimitriosMitsios/ream/commit/0ea819ab4c0351a329bbb95b3b7fa19c22f85859)

## Abstract

Ream is a Lean Consensus Client being written in Rust. The Lean consensus is beacon chain 2.0, its goal is to transition quickly and safely from the Beacon Chain to a consensus layer design much closer to the final design of Ethereum.
Currently, the Ethereum Beacon Chain achieves consensus by having validators “re-execute” every block to verify that the resulting state root is correct. This re-execution process introduces inefficiencies and acts as a barrier to lowering the hardware requirements for validators.
Lean Chain aims to replace this re-execution process with “verification” using ZK, significantly lowering the hardware requirements for validators and enabling anyone to run an Ethereum node from anywhere.

During my time at Etherum Protocol Fellowship, me and my partner Dimitris worked on two subprojects correlated with each other under Ream Client in the mentorship of Unnawut.
The first goal of the project was to benchmark the State Transition Function of Beacon State inside ZkVMs, the aim here being that we find the possible bottlenecks inside the state transition function of Beacon State and get to know how each zkVm performs with respect to Ethereum's state transitions.
The second goal was to integrate zkVM proof service inside Ream's Lean Consensus Chain which would work in parallel with the existing Lean Chain service and instead of just producing blocks it would generate proof of the correct execution as well so that other validators do not need to re-execute the STF again and can just verify the proof generated by the Lean Prove Service.

## Benchmarking zkSTF on Beacon Chain
For the first half of the fellowship we focused on the Beacon Chain and came up with a unified benchmarking framework for 5 different zkVMs, i.e [Ream-ZkVm-Benchmarks](https://github.com/x-senpai-x/Ream-ZKVM-Benchmarks/) servces as a repository in which there's a single host file through which we can invoke guest programmes of any of RiscZero, SP1, Pico, Zisk or Jolt. From the user perspective all of the orchestration takes place through the Makefile. This repository also serves as a guide for zkVMs describing each of the zkVMs I worked with in detail.
The Beacon Chain's State Transition Function can be splitted this way:

state_transition(state: &mut BeaconState, block: &SignedBeaconBlock) - A wrapper of process_slots(), verify_block_signature() and process_block()

process_slots(state: &mut BeaconState, slot: block.slot) - A wrapper of process_slot() and process_epoch()

process_slot(state: &mut BeaconState, slot: Slot) - Updates the state for a specific slot, including validator updates and committee assignments

fn process_epoch(state: &mut BeaconState) -> anyhow::Result<()> {
    process_justification_and_finalization(state)?;
    process_inactivity_updates(state)?;
    process_rewards_and_penalties(state)?;
    process_registry_updates(state)?;
    process_slashings(state)?;
    process_eth1_data_reset(state)?;
    process_pending_deposits(state)?;
    process_pending_consolidations(state)?;
    process_effective_balance_updates(state)?;
    process_slashings_reset(state)?;
    process_randao_mixes_reset(state)?;
    process_historical_summaries_update(state)?;
    process_participation_flag_updates(state)?;
    process_sync_committee_updatestates()
}

fn process_block(state: &mut BeaconState, block: &SignedBeaconBlock) {
    process_block_header(state, block);
    process_withdrawals(state, block.body.execution_payload);
    process_execution_payload(state, block.body,execution_engine);
    process_randao(state, block.body);
    process_eth1_data(state, block.body);
    process_proposer_slashings(state, block.body.proposer_slashings);
    process_attester_slashings(state, block.body.attester_slashings);
    process_attestations(state, block.body.attestations);
    process_deposits(state, block.body.deposits);
    process_voluntary_exits(state, block.body.voluntary_exits);
    process_bls_to_execution_change(state, block.body.bls_to_execution_change);
    process_deposit_request(state, block.body.execution_requests.deposits);
    process_withdrawal_requests(state, block.body.execution_requests.withdrawals);
    process_consolidation_requests(state, block.body.execution_requests.consolidations);
    process_sync_aggregate(state, block.body.sync_aggregate);
}

Therefore over the course of the fellowship we benchmarked operations contained in process_block and process_epoch inside different zkVMs and the results for can be found [here](https://github.com/x-senpai-x/Ream-ZKVM-Benchmarks/tree/main/Beacon-Harness/host/summaries).

## Benchmarking zkSTF on Lean Chain
The second half of the fellowship period was spent on the Lean Chain itself, particularly the one implemented right now by Ream, which is called the pqdevnet0, the goal here was to execute the state_transition function which is part of ```handle_produce_block``` to be executed inside a zkVM. For this we created a ```LeanProverService```, which executed the STF inside RiscZero zkVM and then produces a proof of valid execution, this proof is then gossiped across the P2P network and every validator recieves this block proof, the validators then verify it on their devices whether the proof itself is correct or not, thus allowing the validators to just verify the zkProof instead of re-executing the entire STF again. The work done can be found [here](https://github.com/dimitriosMitsios/ream/tree/leanprover).
Apart from creating a prover service from scratch we also had to modify the p2p network and created a new gossip topic for the gossiping of the new Lean Proof.

## Reflections
The goal of this project was to provide essential data to Ream's team for making informed zkVM choices in Lean Chain development and to prepare ourself to snarkify the Lean Chain specs. By not only benchmarking the Beacon State but rather also benchmarking the Lean State as well we exceeded the goals for the project and it has prepared us for the Lean Chain specs

## What's Next
Lean Chain is progressing at a steady pace and with this we need to keep our benchmarks updated as the updates keep on coming. Right now only zkVM supported for Ream's LeanProverService is RiscZero, this needs to be eventually replaced by a cli argument through which prover can choose the zkVM he wants to use for proving. Also gossiping proof is still a WIP and requires multiple Ream Nodes to be connected with each other. I'll be continuing this project and complete the final deliverables for our DraftPR to be merged into [Ream](https://github.com/ReamLabs/ream/pull/835).

## Thanks
I really want to thank Mario and Josh for conducting this amazing cohort, and also special thanks to our mentor Unnawut, who helped us during the entire period of fellowship and was responsive to our doubts at all the times. Additionally I really enjoyed working with my colleague Dimitris throughout this project.