Thanks to Kevaundray Wedderburn, Alex Stokes, Tim Beiko, Mary Maller, Alexander Hicks, George Kadianakis, Dankrad Feist, and Justin Drake for feedback and review.
Ethereum is going all in on ZK. Eventually we expect to migrate to using ZK proofs at all levels of the stack, from consensus layer signature aggregation to onchain privacy with client side proving, and upgrade the protocol to be simpler and more zk-friendly. But the first step will be an L1 zkEVM.
How we can ship an L1 zkEVM in less than a year
The fastest and safest way to ship an L1 zkEVM is to start by giving validators the option to run clients that, rather than re-executing execution payloads, statelessly verify multiple (let’s say three) proofs generated by different zkVMs each proving different EVM implementations. Because proof verification is so fast and proof size so succinct, downloading and verifying multiple proofs is very reasonable and allows us to apply the same defense in depth as existing client diversity to zkVMs.
For this plan to initially verify execution proofs offchain, all we need from the protocol is some form of pipelining in Glamsterdam to allow for more proving time.
Initially, we expect few validators to run ZK clients. Over time, their security will be demonstrated in production. With the EF also putting resources into formal verification, specification writing, audits, and bug bounties; we expect adoption will slowly increase.
When a supermajority of stake is comfortable running ZK clients, we can increase the gas limit to a level that would require validators running reasonable hardware to verify proofs instead of re-executing blocks. Once all validators are verifying execution proofs, the same proofs can also be used by an EXECUTE precompile for native zk-rollups.
Defining realtime proving for the L1
Our greatest advantage in executing this plan is the ability to harness the entire zkVM industry towards making Ethereum by far the largest ZK application in the world. Many zkVMs are already proving Ethereum blocks and performance breakthroughs are being announced on a weekly basis.
In order to maintain the security, liveness, and censorship-resistance properties of the L1 the Ethereum Foundation is proposing a standardized definition of realtime proving for zkVM teams to work towards.
On the proof system side, zkVMs targeting realtime proving should aim for 128 bits of security, which we consider the right long-term target for Ethereum L1. However, we are willing to accept a minimum of 100 bits of security in the initial months of deployment, to accommodate short-term engineering challenges in reaching 128 bits. Proof size should remain under 300KiB and must not rely on recursive wrappers that use trusted setups. We expect proof systems to move to 128-bit security by the time ZK clients are in production and to further tighten security requirements (e.g. regarding conjectures) as proving time decreases.
With the current slot time of 12 seconds and maximum time to propagate data across the network of ~1.5 seconds, realtime means 10 seconds or less. We expect zkVMs to be able to prove at least 99% of mainnet blocks in this window, with the tail end (as well as synthetic DOS vectors) mitigated in future hard forks.
In order to maintain the highest levels of liveness and censorship resistance, our definition of realtime proving aims to enable “home proving” with the idea that some of the solo stakers who currently run validators from home will opt-in to proving. Even though we expect to harden censorship resistance through enforced transaction inclusion before verifying ZK proofs is made mandatory, home proving is an important final safeguard.
Since proving in the cloud is already quite cheap with multi-GPU spot instances, the focus for zkVM teams targeting realtime proving will largely be optimizing for running provers on-prem where the specs are much more constrained. On-prem realtime proving should require a maximum capital expenditure of 100k USD (at time of writing it requires ~$80k in stake to run a validator). We expect this to come down over time even as the gas limit is increased.
More than hardware cost, the most significant constraint for home proving using GPUs is energy usage. Most residential homes have at least 10kW entering from the street and some will have circuits intended for electric appliances or charging electric vehicles with 10kW capacity. Therefore, realtime proving must be possible on hardware running at 10kW or less.
This brings us to our working definition of realtime proving:
- Latency: <= 10s for P99 of mainnet blocks
- On-prem CAPEX: <= 100k USD
- On-prem power: <= 10kW
- Code: Fully open source
- Security: >= 128 bits
- Proof size: <= 300KiB with no trusted setups
The race to realtime
Between now and Devconnect Argentina, we hope to see zkVM teams continue innovating towards realtime home proving, and for the leading zkVMs to become future core infrastructure for Ethereum.