# Grandine: zkVMs for Beacon Chain Snarkification

Mentor - *Saulius Grigaitis*
Interested Permissioned Fellow - [Harsh Pratap Singh](https://harsh-ps-2003.bearblog.dev/)

### Background and Motivation

Recent breakthroughs in zkVMs have positioned SNARK-based verification as a viable path toward scaling Ethereum's Beacon Chain. Initial implementations using SP1 Hypercube and RISC Zero zkVM demonstrate the feasibility of real-time proving for networks with 10,000–50,000 validators, achieving sub-12-second proof generation times. However, expanding this capability to support 500,000+ validators—a requirement for Ethereum’s long-term decentralization goals—demands architectural innovations in parallelism, cryptographic primitives, and proof continuity mechanisms. Emerging solutions like [OpenVM’s modular zkVM](https://blog.axiom.xyz/openvm/) and Zisk’s low-latency for real-time proof generation aim to address these challenges while maintaining compatibility with Ethereum’s evolving consensus-layer roadmap.

Initial zkVM Architectures for Beacon Chain State Transition Function Prooving :

**SP1 Hypercube: Real-Time Proving for Stateless Execution** :

[Succinct Labs’ SP1 Hypercube represents a paradigm shift in zkVM design, leveraging multilinear polynomials and GPU-accelerated parallelization to prove 93% of Ethereum mainnet blocks in under 12 seconds as an average case performance.](https://blog.succinct.xyz/sp1-hypercube/)

Its architecture addresses three critical bottlenecks in Beacon Chain verification:

* *Attestation Aggregation Overhead*: By [implementing specialized precompiles for BLS12-381 curve operations, SP1 reduces the cycle count for signature aggregation by 20× compared to generic RISC-V emulation](https://blog.succinct.xyz/succinctshipsprecompiles/)
* *State Transition Parallelism*: By departing from traditional univariate polynomial-based STARKs and instead utilizing multilinear polynomials, SP1 Hypercube enables more efficient packing of computation. This shift is described as unlocking "powerful new capabilities" for zkVMs, including improved parallelism and efficiency in handling complex state transitions like those found in Ethereum’s Beacon Chain. The system's optimized prover stack and parallel execution capabilities, along with the Jagged Polynomial Commitment Scheme and highly optimized LogUp GKR protocol (both tailored for multilinear-friendly, parallelizable computation), allow the prover to distribute computational effort efficiently across available hardware resources. This inherent design for parallelism is what enables the system to achieve high throughput, such as proving over 93% of mainnet blocks in under 12 seconds with a cluster of 160-200 GPUs. The reduction of recursive proof overhead by 40% overhead through a new cross-table lookup system further enhances efficiency in the recursive aggregation of proofs, which is crucial for handling parallelized state verification at Ethereum scale.
* *Witness Optimization*: SP1’s stateless execution model excludes Merkle proof retrieval times from its benchmarks, focusing solely on computational verification—a design choice that aligns with Ethereum’s post-Dencun statelessness roadmap

**RISC Zero zkVM: A General-Purpose Proving Infrastructure**

[RISC Zero’s production-ready zkVM](https://risczero.com/blog/beating-moores-law-with-zkvm-1-0) introduces a complementary approach, enabling Rust-based STF implementations with three key advantages:

* *Cost-Effective Proofs*: By compressing multiple validator attestations into a single SNARK, it [supports proof composition](https://risczero.com/blog/proof-composition) and parallalization, allowing multiple proofs (such as validator attestations) to be aggregated into a single succinct proof for on-chain verification it achieves dramatic reductions in gas fees and proof verification costs (e.g., "8x cheaper attestation verification" for TEEs, "up to a 5x cost reduction" for batch validity proofs)
* *Cross-Chain Compatibility*: Unlike SP1’s Ethereum-focused optimizations, RISC Zero’s generic RISC-V runtime supports multi-chain environments, critical for cross-shard communication in Ethereum’s future sharded architecture
* *Deterministic Execution*: The zkVM enforces strict computational reproducibility, mitigating consensus bugs caused by nondeterministic floating-point operations—a recurrent issue in early Beacon Chain clients

[Risc Zero is cooking up even more performant zkVM with Binus and hardware accleration.](https://risczero.com/blog/introducing-R0VM-2.0)

Current zkVM implementations face fundamental limitations when scaling beyond 100,000 validators:

| Parameter | SP1 Hypercube (50k Validators) | RISC Zero zkVM (Comparable Workload) | Target (500k Validators) |
| :------------------ | :----------------------------- | :----------------------------------- | :----------------------- |
| Proving Time | 10.3 seconds | 9.7–16.6 seconds (see notes) | <5 seconds |
| Hardware Cost | $100,000 (GPU cluster) | Consumer-grade cloud GPU/PC; 7x–60x cheaper than SP1 | $5,000 (Consumer GPUs) |
| Energy Consumption | 8.2 kWh/proof | Not directly reported, but lower due to consumer hardware | 0.4 kWh/proof |
| On-Chain Verification | 350k gas | Not explicitly reported; similar or lower due to smaller proof size | <50k gas |

> Notes on Proving Time:
* RISC Zero zkVM achieves proof times of 9.7 seconds and 16.6 seconds (Stage 2) in independent zkVM benchmarks, outperforming SP1 in comparable tasks.
* RISC Zero’s own benchmarks confirm that on consumer hardware (e.g., Nvidia 4090), it is the fastest zkVM tested, and in the cloud, it is at least 7x less expensive than SP1 for equivalent workloads.

> Notes on Hardware Cost:
* RISC Zero zkVM is designed to run efficiently on consumer-grade GPUs and PCs, with cost benchmarks showing it is 7x–60x less expensive than SP1 for similar workloads in cloud.
* SP1’s reported $100,000 cluster is for high-throughput, large-scale proving.

> Notes on On-Chain Verification:
* RISC Zero zkVM produces much smaller proofs (e.g., 217 KB vs. SP1’s 3 MB), which suggests lower on-chain verification costs, though exact gas numbers are not specified in the available sources.

A more detailed [exploration](https://vac.dev/rlog/zkVM-explorations) and [comparion](https://vac.dev/rlog/zkVM-testing#summary-table) on available zkVMs was done by Vac Research team.

### Continuation Support

[Continuation support](https://risczero.com/blog/continuations) is necessary for the Beacon Chain and its state transition functions (STF) when using zkVMs :

* The Beacon Chain STF, especially with large validator sets, can involve computations that exceed the practical limits of a single proof circuit or require more memory and compute than available in a single proving session. Continuation support allows these large, monolithic computations to be split into smaller, manageable segments (sub-proofs), each of which can be proven independently and then aggregated or recursively composed into a final proof. This is essential for scaling proof generation to real-world validator set sizes
* By breaking the STF into smaller pieces, continuation support enables horizontal scaling: multiple provers (or servers) can work on different segments of the computation in parallel, dramatically reducing overall proving time. This modular approach is a core innovation in modern zkVMs like OpenVM, which are designed for extensibility and parallel execution. For the Beacon Chain, where state transitions can be computationally intensive (especially during peak network activity), this parallelism is crucial for timely finality.
* With continuation support, zkVMs can produce unbounded program proofs that are still efficiently verifiable on-chain. Each sub-proof can be recursively aggregated into a single succinct proof, minimizing on-chain verification costs and supporting Ethereum’s statelessness and scalability goals post-Dencun

### Next-Generation zkVMs: OpenVM, Zisk, and adopting Continuation Paradigms

**OpenVM: Sharded Proving for Horizontal Scaling**

The proposed [OpenVM](https://blog.openvm.dev/v1) architecture introduces a [modular and extensible](https://www.youtube.com/watch?v=Q5yS-38ji4k) zkVM model that supports:

It intends to be a general-purpose zkVM for a wide range of applications, and does not provide out-of-the-box support for specific blockchain consensus rules or sharding; such features must be implemented by developers as custom extensions. It emphasizes flexibility and modularity over specialized performance optimizations. Performance depends on the underlying proof system and hardware chosen by the developer. It supports custom VM extensions and modular ISA design, allowing developers to tailor the zkVM for specific use cases. Importantly, it supports parallelism in proof generation and recursion and continuation for bounded program execution, enabling segmented proofs that can be aggregated recursively.

**Zisk: Low-Latency Proof Generation**

Zisk is a high-performance zkVM designed to make ZK proof integration simple for scalable, private, and secure applications.

It focuses on leveraging [new cryptographic primitives - Binus](https://polygon.technology/blog/polygon-labs-x-irreducible-a-binius-based-zkvm), plonky3, zk-STARK/SNARK hybrids and hardware acceleration (FPGA clusters for proof speeds) for order-of-magnitude improvements in proof generation time and cost. This is prioritised even if it means sacrificing a little bit of cost, as the computational cost of proving is already considered relatively low. The goal is to generate proofs in seconds or milliseconds, which is crucial for applications like cross-chain transactions within layers.

* *Rust-Native Circuit Development*: In this new generation of proving systems, circuits are built directly in Rust. Developers take Rust code, compile it, and build proofs in Rust, eliminating the need for a special language for circuits
* *Emulation of RISC-V 64-bit*: Zisk specifically emulates a 64-bit RISC-V virtual machine. The system proves that a given program, written in Rust and compiled to RISC-V, runs correctly with specific inputs to produce correct outputs. It can also potentially emulate WASM
* *Pill2 Framework*: Zisk is built upon the Pill2 framework, which is an extensible arithmetization language. This framework moves beyond older, gate-based circuits (like those using Circom or R1CS), which become prohibitively large for complex operations like VM emulation. Instead, it uses polynomials to represent state transitions and constraints, working in parallel with many values.
* *Modular Architecture, the Bus and Proof Recursion*: A core innovation is the ability to split large, monolithic proofs into smaller sub-proofs or pieces, a concept sometimes referred to as vIBCops. These sub-proofs, often representing different state machines (e.g., for arithmetic, memory, binary operations, or co-processors like Keccak or elliptic curves), communicate via a mechanism called a bus. State machines can assume operations (adding to the bus) or prove operations (subtracting from the bus), with the overall constraint that the bus must sum to zero, ensuring consistency across all assumed and proven operations. This modularity allows for horizontal scaling and parallelization of proof generation across multiple servers. This is inspired by Polygon’s zkEVM and Plonky3. The system incorporates a recursor that allows different proofs or split sub-proofs to be aggregated together into a single final proof

| Feature | Zisk (Polygon Labs) | OpenVM |
| :---------------------- | :---------------------------------------------------- | :---------------------------------------------------- |
| Primary Focus | High-performance, scalable ZK computation for Polygon/AggLayer | Modular, extensible zkVM for general use |
| Cryptographic Innovation | Binius (binary fields), Plonky3, zk-STARK/SNARK hybrid | No specific cryptographic innovations |
| Hardware Optimization | FPGA acceleration, focus on proof speed | Hardware-agnostic, depends on configuration |
| Language Support | Rust (primary), more planned | Modular, language-agnostic |
| Consensus/Protocol Integration | Designed for Polygon’s ZK rollup and AggLayer ecosystem | No native protocol/consensus integration |
| Sharding/Parallelism | Designed for interoperability and cross-chain use | Modular; sharding/parallelism up to developer |
| Developer Experience | Abstracts ZK complexity, developer-friendly | Highly modular, requires more customization |
| Target Users | Polygon/AggLayer, EVM and non-EVM chains | Any developer needing a zkVM |

## Integrating zkVM with Grandine

We can benchmark the zkVM's against Grandine's consensus layer client, track performance, identify bottlenecks, and understand how different zkVMs behave. To integrate zkVMs, following points should be kept in mind :

* We should Isolate the STF (ideally a seperate crate) and minimize dependencies
* Use stateless reads and writes (the full consensus state should never be loaded in memory for snarkification — use Merkle proofs for state access)
* [zkVMs doesn't support asynchronous behavior and are fundamentally single-threaded synchronous environments.](https://dev.risczero.com/api/zkvm/zkvm-specification#the-zkvm-execution-model)
* No async routines, locking, or atomic operations - attempting to use these inside a zkVM will not improve performance and may actually make programs slower.
* No multi-threading or pipelining - the zkVM executes one instruction at a time, in the order determined by the compiler, without instruction-level parallelism. In the current Ethereum consensus architecture, the Beacon Chain client must call the connected execution client via the Engine API to process the Execution Payload. However, since zkVMs cannot perform asynchronous calls or interact with external systems during proof generation, the entire state transition function (STF) must be modeled as a pure, deterministic computation within the zkVM. Any data required from the execution client (e.g., execution payload results) must be provided as part of the input "witness" to the zkVM, not fetched dynamically during execution.

# Conclusion

Scaling zkVMs for half-million-validator networks demands coordinated advances across cryptography, hardware, and protocol design. While SP1 and RISC Zero have proven the base-case feasibility, achieving Ethereum’s targets requires more - OpenVM’s sharded parallelism, Zisk’s algebraic optimizations, and continuation-based proving workflows. Early implementations suggest these architectures could enable sub-3-second finality by 2027, provided the community addresses remaining challenges in hardware decentralization and quantum resistance. As the Beam Chain initiative progresses, zkVM innovations will likely form the backbone of Ethereum’s consensus layer.