Date: 2025-05-09 By: Jun Song Few weeks ago, O wrote a well-organized note about the Partial State, and I've been investigating how we can design the partial state upon existing code. Any feedback is welcome. Background Merkle Multiproof image For illustration, let's assume there are only 8 fields in the BeaconState. I intentionally omitted most of the fields and left only a few. (FYI: from Electra, there are a total of 37 fields.) The complex fields like validators, fork will have their subtree, but for simplicity, I just labeld them as "Root". Generalized index is denoted as a blue number that indicates the index of the node in the tree.

Existing Toolchain Currently, there are two widely used tools for generating and managing validator keys: staking-deposit-cli Validator management modules integrated within various consensus clients Both staking-deposit-cli and these modules support generating BLS keys and exporting them in the JSON format specified by EIP-2335. New Tools?

Date: 2025-04-24 By: Unnawut L. TLDR This post is my attempt at getting RISC Zero to work with >32-bit lists, with a mix zkVM program optimizations along the way. Details To recap, I was able to run process_block_header() on RISC Zero by reducing BeaconState properties that are 2^40^-sized to be under 32-bit. The benchmark is below. Standard write() and read() from earlier benchmark

Date: 2025-04-28 By: Jun Song Yesterday, Justin provided some updates on zkVMs, along with a few implementation tips. Here's the list: a) isolate your STF (e.g. in a separate module/library/crate/repo) b) minimise STF dependencies (e.g. avoid loading heavy libraries) c) use stateless reads and writes (the full consensus state should never be loaded in memory for snarkification—use Merkle proofs for state access) d) kick the tyres of various zkVMs

Date: 2025-04-18 By: Unnawut TLDR Details It started with this suggestion by Justin after our primitive zkSTF benchmarks showed that committing to the beacon state requires 200M cycles. Loading the full state is suboptimal. State reads and write are better to be done statelessly.

Date: 2025-04-11 By: unnawut TLDR Similar to @junsong 's work on SP1, I've integrated and benchmarked ReamLabs' implementation of beacon chain state transition functions within RISC Zero zkVM. Similarly, I explored 2 questions: Can zkVM successfully run STFs (state transition functions)? How many cycles are needed for each operation?

As Ream has fully implemented state transition functions(STFs) for Ethereum consensus, I started to integrate the STFs with my project, consensp1us. As consensus-specs provides some test suites with pre/post state and input, I thought it would be a great chance to check two things: How many cycles are needed for each operation?Also, does patched crate for BLS significantly affect to the result? Can zkVM successfully run STFs? Run benchmark git clone git@github.com:ReamLabs/consensp1us.git cd script make download

TLDR I'm now able to pass a BeaconState and a BeaconBlock into risc0 zkVM to perform BeaconState::process_block_header() within the guest VM. The program was able to prove this specific operation in 15 minutes. 15 minutes per a subset transition function is far from ideal Out of the 3 operations: 1) reading the state, 2) reading the block, 3) processing the block header, reading the state took over 92.5% of the cycle count. Loading the state into the guest VM seems to be the biggest bottleneck. Still not able to output the result into the receipt journal. See the work at https://github.com/ReamLabs/consenzero/pull/1/ Details Thanks to @junsong's headwork on process_* skeleton and Varun's process_block_header() implementation, I'm now able to drop this into risc0 zkVM with only slight hacking, i.e. removing ssz_types::serde_utils::quoted_u64_var_list::deserialize() from the BeaconState I benchmarked 3 points in the guest program. This is the result which is consistent across multiple runs.​​​​read_pre_state: 47791528

I had tackled into SP1 and Lighthouse in the past, and found that we have to manage our own beacon chain implementation for PoC. (Past Dev Log) As O nicely worked on Risc0, I also tried same approach with him. I pruned the RPC module to fetch from Mekong because 1) Ream is based on deneb state, and 2) EF tests already provide nicely compressed snappy files for state transition. https://github.com/ReamLabs/consensp1us/tree/945dacfc47c53721ef924bb9dbdb933c0c9da664 Bumped SP1 version from v3.x.x to v4.0.0. Removed Lighthouse depencency and imported Ream.Special thanks to Kolby and Varun who implemented all those beacon types and transitions. Checked cycles on SP1 zkVM to inspect potential bottlenecks.

TLDR Able to construct a full BeaconState from consensus-spec-tests yaml files. Able to pass a BeamState constructed with a subset of BeaconState fields, pass it into the guest zkVM, and journaled back to the host machine. See the work at https://github.com/unnawut/consenzero/pull/1/ Details After being stuck trying to construct a BeaconState from scratch, I was finally able to escape by constructing it from consensus-spec-tests test data instead. Thanks to Jun's suggestion and Kolby's code in ream/testing/ef-tests that made this straightforward. Initially I tried passing the full BeaconState into the guest VM but the guest threw this error back:​​​​thread 'main' panicked at /Users/unnawut/.cargo/registry/src/index.crates.io-6f17d22bba15001f/risc0-zkvm-1.2.1/src/guest/env/read.rs:78:54: ​​​​called `Result::unwrap()` on an `Err` value: NotSupported

Progress [Feature] Worked mainly on consenzero, or more specifically tried to fetch the beacon head slot number (done), then fetch the beacon state at that particular slot number (in progress). See my draft PR for the work in progress. [Chore] Internal organization - Spent some time on external coordinations and coming up with rationales for: 1.1) Why Ethereum needs another consensus client 1.2) Why Ream client development should start now Details I've been trying to generate mock BeaconState from scratch, in hope that I can use it to prepare the data for experimentation with zk state transitioning. It's been straight hard labor since the BeaconState contains over 20+ attributes, each with its own complex types that need to be prepared. After a hint from Jun Song that the consensus-spec-tests contain SSZ-serialized data for testing purposes, I gave up generating the state from scratch and tried to construct the state from pre-existing SSZs instead.Kolby has this code in ream repo that's a pretty neat example of how to deserialize the SSZ for usage in Rust

https://github.com/ReamLabs/consensp1us(My etude for PoC) I've been working on a PoC (Proof-of-Concept) project that "snarkifies" the current Ethereum beacon chain processor. Since SP1 offers an excellent developer experience, I began by exploring SP1. Succinct Labs also recommends using Precompiles for common operations (e.g., hash functions, arithmetic on elliptic curves) including bls12_381. I thought leveraging these with Lighthouse would be a great way to deepen my understanding of zkVM's core concepts. This article documents my short journey hacking with SP1 and Lighthouse. Adding a new backend: bls12_381 https://github.com/syjn99/lighthouse/pull/1 Lighthouse supports adding new "backends" for BLS (crypto/bls/src/lib.rs). My first step was implementing a new backend using zkcrypto/bls12_381. As bls12_381 provides a more raw API, I first had to study the basic concepts of BLS12-381.