<section style="font-size: 0.75em; text-align: left;">
# zkVM Benchmarking on Ream's STF
**Utsav Sharma** — EPF Cohort 6
Project lead: **Unnawut**
Focus: Beacon Chain STF in zkVMs for Beam Chain
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## Motivation
Modular chains (like Beam) require proving consensus logic inside zkVMs.
The **Beacon Chain State Transition Function (STF)** is:
- Critical to Ethereum’s consensus
- Complex, multi-layered, and data-heavy
- Not designed with SNARK-friendliness in mind
We aim to benchmark zkVMs to answer:
> How viable is SNARKing consensus code for real-time L2s?
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## What is the STF?
The **State Transition Function** (STF) for the Beacon Chain:
- Inputs: `BeaconState`, `SignedBeaconBlock`
- Processes:
- Slot advancement, proposer duties
- Attestations, sync committees
- Rewards, penalties, slashings
- Output: Updated `BeaconState`
Defined in [ethereum/consensus-specs](https://github.com/ethereum/consensus-specs)
Implemented in Rust by [Ream](https://github.com/unnawut/ream)
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## zkVMs in Scope
**zkVMs = General-purpose proving VMs**
We benchmark Beacon STF inside:
- 🔹 **SP1**: Rust-based VM with STARKs, native Rust support
- 🔹 **RISC Zero**: RISC-V emulation, SHA-based ZK-STARKs
- 🔹 **Jolt**: Polynomial IOPs over RISC-V, optimized IR
- 🔹 **Zisk**, **Valida**, **Brevis Pico**, **OpenVM** (planned)
Key differences:
- Instruction sets (custom vs RISC-V)
- Precompiles, memory model, I/O constraints
- Witness size, proof time, recursion support
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## Current Benchmark Setup
- Rust STF code from `ream-consensus`
- Input SSZ data (compressed `BeaconState`, `SignedBlock`)
- Benchmarks run inside zkVM entrypoint
- Outputs verified post-execution
Metrics collected:
- Guest execution time
- Proving time / memory
- Instruction cycle counts
- Throughput limits
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## Design Goals
- 🧩 **Modularity**: Swap zkVMs with minimal code change
- 🧪 **Isolation**: Test STF subfunctions independently (`process_attestation`, `process_block`)
- 🧮 **Metric Logging**: Consistent measurements across backends
- 🛠️ **Snark-Friendly Prep**: Transform code with minimal I/O/memory footprint
Benchmarking serves dual purpose:
- Short-term: guide Beam zkVM selection
- Long-term: snarkify next-gen L1 consensus logic
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## STF Execution in zkVMs: Bottlenecks
Early benchmarks highlight:
- 🚧 Heavy Merkle tree operations (state roots, committee caches)
- 📦 SSZ encoding/decoding costs
- 🧠 High memory footprint for `BeaconState` mutations
- 🔁 Nested loops in attestation and slashing logic
- 🔄 Random accesses to validator registry, committee assignments
SP1 and RISC Zero show divergent behavior due to:
- ISA efficiency
- Precompile availability
- Trace size overhead
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## Work Plan
### ✅ Done
- SP1 + RISC Zero integration
- Benchmarks for `process_block`, `process_attestation`
- Test input pipeline with mainnet data
- Logging cycle counts, constraints
### 🧭 In Progress
- Port to **Jolt**, **Valida**, **OpenVM**
- Minimize state mutation footprint
- Add proof verification stats
### 🛣️ Coming Up
- Generalize for Beam Chain STF
- Automate regressions / profiling
- Publish zkVM comparison report
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## Example: SP1 Benchmark Logs
- STF run: `process_block`
- Cycles: 8.1M
- Trace size: 12MB
- Memory used: 18MB
- Proving time: ~40s
Bottlenecks:
- `get_beacon_committee()`: heavy indexing + hashing
- Sync committee updates: large Merkle recalculations
- Rewards loop: variable-length loops
</section>
---
<section style="font-size: 0.75em; text-align: left;">
## Long-Term Impact
This project enables:
- 💡 Data-driven zkVM choices for Beam Chain
- 🧱 Foundation for SNARK-friendly consensus clients
- 🔬 Benchmarking culture for STF implementations
- 🔗 Closer alignment of zk infrastructure with Ethereum’s modular roadmap
> STF snarkification is a crucial step toward fully trustless light clients and verifiable execution chains.
</section>
---
<section style="font-size: 0.75em; text-align: left;">
# 🔚 Summary
✅ Beacon STF is complex and non-trivial to prove
✅ Early benchmarks on SP1 and RISC Zero are promising
✅ Modular benchmarking framework is live
✅ Integration with more zkVMs is next
✅ We aim to support Beam Chain’s zk future with real data
---
## 🔗 Links
- 🔸 [Ream GitHub](https://github.com/unnawut/ream)
- 🔸 [EPF Wiki](https://github.com/ethereum/ethereum-org-website/wiki/EPF)
- 🔸 [Consensus Specs](https://github.com/ethereum/consensus-specs)
- 🔸 [SP1 Docs](https://docs.succinct.xyz/sp1)
- 🔸 [RISC Zero](https://www.risczero.com/)
</section>
{"title":"Project Proposal Presentation","description":"Ethereum Protocol Fellowship - Cohort 6","contributors":"[{\"id\":\"0b089b2a-a200-45d0-86ee-9248ab0cc97a\",\"add\":5312,\"del\":0,\"latestUpdatedAt\":1752002338531}]"}