Thanks to Kev for extensive discussion, as well as George, Marius and Thomas for feedback
***
One of the key recent conversations in the Ethereum community revolves around a fundamental challenge: how do we scale the network without sacrificing the core principles of decentralization and permissionless verification? This has led to a rethinking of the validator's role, potentially splitting the duties of today's staking nodes into more specialized tasks like attesting, including, building and proving.
At the heart of Ethereum's future roadmap are two technological north stars: zero-knowledge (ZK) proofs and data availability sampling (DAS). With the push towards an L1-zkEVM, it's time to look at how these technologies will reshape the validator experience.
This post will explore what a ZK-powered future may look like for a validator specifically. We will focus on one of the most immediate use cases: the role of an attester.
Without clear goals for what our network should provide, we end up optimising for our means rather than for our ends. In this talk, I'll discuss the goals of our network - scale, hardness, verifiability and censorship-resistance - and how some of the means ("local building", "solo staking") should be re-evaluated in light of their contributions to these goals, given advances in protocol research.
Leveraging ZK proofs enables Ethereum to massively scale its transaction throughput while drastically lowering the hardware requirements for running a staking node, allowing for a more heterogeneous, uncorrelated validator set.
In a traditional setup, a staking node must maintain the complete Ethereum state—hundreds of gigabytes and growing—and re-execute every transaction in every block to verify its validity. This requires significant CPU power, RAM, and fast disk storage.
A ZK staking node flips this model on its head. Instead of re-executing anything, it simply verifies a ZK proof. Here’s why that’s a game-changer:
Minimal computation & bandwidth regardless of the block size: Verifying ZK proofs is computationally inexpensive and consistently fast, irrespective of the number of transactions within a block. This effectively standardizes the cost of block processing, independent of the block size.
Statelessness: Since the ZK proof cryptographically guarantees the block's validity, the node no longer needs to store the Ethereum state to check it. Consequently, disk space and RAM requirements drop significantly.
This efficiency allows for much higher gas limits on the L1 while making it feasible for almost anyone to run a verifying node.
A staking node’s job will shift from a "trust but verify by re-doing" model to a "verify a cryptographic guarantee" model.
Today, the Consensus Layer (CL) client downloads a new beacon block, which includes an execution payload that is then passed to the Execution Layer (EL) client. The EL client then re-executes all the transactions to confirm the new state is valid.
With a ZK staking node, a client will download a beacon block and listen for a corresponding ZK proof on the network. This proof provides a cryptographic guarantee that the transactions were executed correctly and the state transition is valid. The node simply verifies this proof without needing the state or the overhead of re-execution.
The proof itself is generated by a specialized entity known as a prover, which does require significant resources and access to the full state (unless the proof is provided by a builder; more on this below).
The practical benefits of running a ZK staking node for home stakers are significant. Running resource-intensive Execution Layer (EL) clients is no longer necessary. This translates to:
Lower Hardware Costs - No need for terabytes of expensive NVMe storage for the EL state. That kind of storage is only required for the CL state (on the order of gigabytes), as the CL state is not yet ZK-proven. This means attesters still need to maintain the CL state for consensus, though future upgrades like lean consensus (formerly known as beam chain) aim to address this.
Reduced CPU Load - The node’s processor will experience a significantly reduced burden as it will not be re-executing hundreds (or later thousands) of transactions per block.
Faster Sync Times - Syncing a new node will require minutes, rather than hours or days, as the necessity to download the entire state history has been eliminated.
This makes running a home node far more accessible and affordable, potentially very soon on a device like an Orange Pi 5 with a small SSD, eventually on an even more lightweight device on the order of a smart watch. Dramatically improving home node operator competitiveness will moreover become increasingly relevant in the context of reducing needlessly excessive issuance while maintaining a decentralised attester set.
A Little History - For some of the early stakers, this might feel familiar. Before the Merge, from 2020 to 2022, the Beacon Chain operated in parallel with the Execution Layer chain, just reaching consensus on itself. Validators could stake using only a CL client, outsourcing EL queries to RPC services like Infura (for tracking deposits). For some stakers, including the author of these lines, a $10/month VPS proved to be sufficient to host a staking node. The Merge, however, introduced the Engine API, which forced validators to run their own local EL client, increasing hardware costs significantly. In some sense, a ZK staking node brings us back to those leaner, more accessible roots.
Today, the CL client communicates with the EL client through the Engine API for a few key tasks:
engine_newPayload: Asking the EL to verify that a received block is valid.
engine_forkChoiceUpdated: Telling the EL what the current head of the chain is.
engine_getPayload: Asking the EL for a block with transactions for proposing.
In a ZK staking node design, this relationship changes entirely.
The plan is to create an integrated CL/EL client that handles both consensus and execution verification in a single binary. The EF’s zkEVM team together with existing client teams are already building prototypes for this, following an initial draft specification.
Here’s how it would work:
When the CL client receives a new beacon block, instead of calling newPayload, it will listen on a peer-to-peer gossip topic for ZK proofs corresponding to that block. Once received, it verifies the proof(s) itself.
Since the node is stateless, it has no EL state to update. Therefore, forkChoiceUpdated calls are no longer necessary.
Likewise, a stateless attester does not have to maintain a transaction pool to build a block from, so it won't be calling getPayload. (Notably, stateless attester nodes cannot locally build blocks because they do not hold EL state; block production will be handled by other specialized nodes such as builders).
Of note but tangential to ZK attesting: Research is ongoing into how partial statelessness designs can contribute to foster censorship resistance guarantees, eg. by verifying inclusion lists.
Consequently, instead of referring to the term "embedded EL" in this context, it seems more accurate to say the EL's verification function is replaced by a ZK proof verifier directly within the CL client.
It appears worth pointing out that even with a ZK staking node, the current requirement of a minimum effective balance of 32 ETH for attesters who also propose blocks remains unchanged. This requirement is separate from the L1-zkEVM initiative. However, it may be addressed in the future as part of the lean consensus roadmap, particularly within the context of rainbow staking and attester-proposer separation.
If attesters become super lightweight, who does the heavy work?
Currently, generating ZK proofs in real-time (i.e. within a slot; 12 seconds) is a resource-intensive process, demanding significant GPU power, and has so far not yet consistently been achieved. The high barrier to entry means that proving is primarily handled by specialized entities or prover networks. But the cost of proving is expected to continually decrease. We will likely see better hardware (potentially specialized ZK ASICs) and better software going forward. The idea is that in a not so distant future, home provers or small proving pools can create ZK proofs for Ethereum blocks in real-time to ensure highest levels of network liveness and censorship resistance.
Isn’t it concerning for Ethereum to rely on sophisticated proving entities?
No, because in the context of proving Ethereum will only depend on a "1-of-N" honest minority assumption. This means the network only needs at least one honest and capable prover on the planet to generate and broadcast a valid proof for each block.
By contrast, blockchains assume “N/2 of N” honest consensus participants (= 51% quorum), and thus an honest majority in order to function properly.
Provers in that sense are somewhat similar to how slashers operate today. Running a slasher has higher hardware requirements than a regular full node and no direct incentive, yet the network relies on at least one altruistic actor to detect slashable offenses.
A ZK proof only guarantees that the execution followed the rules of its specific zkEVM program; it doesn't guarantee the program itself is bug-free.
To guard against a bug in a single zkEVM implementation, the plan is for the network to adopt a multi-proof model. A ZK staking node won't just accept the first proof it sees. Instead, it will require k valid proofs from n different zkEVM implementations before considering a block valid (e.g., 3 proofs from 5 different clients).
This means a ZK staking node might need to download multiple proofs for each block, adding some bandwidth overhead. However, it provides a powerful, built-in defense against a bug in any single EL client or its corresponding zkVM, effectively creating client-side cross-validation similar to Vouch or Vero.
What are the key dependencies, and how could a rollout on mainnet look like?
The transition to ZK staking nodes can happen gradually and does not require a single, sweeping hard fork. The current proposals involve a phased rollout:
Phase 0 - Opt-in ZK attestation: Initially, early-adopting validators could run a ZK staking node as soon as prototypes are solidified and client teams declare them production-ready – potentially on a short-term time scale.
It is important to note that prematurely migrating to a ZK staking node before consistent proof timeliness more likely than not is economically irrational for the average staker, and thus not recommended as it comes with drawbacks. This is because proof generation delays exceeding the 4-second attestation deadline will forfeit timeliness rewards for attestations and sync committee participation. For overall network health and due to security considerations around the nascent zkVM technology, it is initially desirable to have less than 33% of validators opt-in.
Phase 1 - ZK attesting with delayed proofs: The Glamsterdam upgrade scheduled for 2026 will likely introduce block pipelining as part of ePBS, decoupling the execution payload from the block - overcoming one of the main dependencies for zkEVM proofs.
Attesters then just vote on the availability and validity of the consensus block. This would give provers almost a full slot worth of proving time, while attesters don't have to wait for the proof to arrive within the attestation deadline, and thus mitigate incurring timeliness penalties. Notably, EIP-7886 (delayed execution) would allow for the same unlock.
Phase 2 - Proofs become mandatory: Further in the future, the consensus mechanism may be changed such that timely proofs become relevant for fork choice.
Share Dialog
Ladislaus
