Gratitude is extended to Kevaundray Wedderburn, Alex Stokes, Tim Beiko, Mary Maller, Alexander Hicks, George Kadianakis, Dankrad Feist, and Justin Drake for their insights and evaluation.
Ethereum is fully committing to ZK. Ultimately, we foresee a transition to the use of ZK proofs at every level of the architecture, spanning from consensus layer signature aggregation to onchain privacy with client-side verification, and simplifying and enhancing the protocol to be more zk-adaptive. However, the initial step will be the development of an L1 zkEVM.
How we can deliver an L1 zkEVM in under a year
The quickest and most secure avenue to deliver an L1 zkEVM is to begin by providing validators the choice to operate clients that, instead of re-executing execution payloads, verify multiple (say three) proofs created by various zkVMs, each validating different EVM implementations, in a stateless manner. Given the rapidity of proof verification and the concise nature of proof size, downloading and validating multiple proofs is quite feasible and enables us to maintain the same layered defense as current client diversity applied to zkVMs.
For this strategy to initially validate execution proofs offchain, all we require from the protocol is some form of pipelining in Glamsterdam to permit additional proving time.
At this stage, we anticipate a limited number of validators will operate ZK clients. Gradually, their security will be established in production. With the EF also allocating resources towards formal verification, specification drafting, audits, and bug bounties, we predict that adoption will incrementally grow.
Once a substantial majority of stake feels at ease running ZK clients, we can elevate the gas limit to a threshold that would necessitate validators to utilize appropriate hardware for proof verification instead of block re-execution. After all validators are affirming execution proofs, the same proofs can be utilized by an EXECUTE precompile for native zk-rollups.
Defining realtime proofing for the L1
Our primary benefit in executing this strategy is the capacity to leverage the entire zkVM sector to establish Ethereum as the preeminent ZK application on the globe. Numerous zkVMs are already validating Ethereum blocks, and performance advancements are being revealed weekly.
To uphold the security, continuity, and censorship-resistance characteristics of the L1, the Ethereum Foundation proposes a standardized definition of realtime proving for zkVM groups to aspire to.
Regarding the proof mechanism, zkVMs focusing on realtime proving should strive for 128 bits of security, which we identify as the appropriate long-term goal for Ethereum L1. Nonetheless, we are prepared to accept a baseline of 100 bits of security during the initial deployment months to address short-term engineering hurdles in achieving 128 bits. Proof size should remain under 300KiB and must not depend on recursive wrappers that engage trusted setups. We anticipate proof systems to reach 128-bit security by the time ZK clients are in operation and to tighten security prerequisites (e.g., concerning conjectures) as proving time diminishes.
With the current slot duration of 12 seconds and the maximum time to transmit data across the network of approximately 1.5 seconds, realtime defining means 10 seconds or fewer. We expect zkVMs to prove a minimum of 99% of mainnet blocks within this window, with the tail end (as well as artificial DOS vectors) addressed in forthcoming hard forks.
To ensure optimal levels of liveness and censorship resistance, our definition of realtime proving aims to facilitate “home proving,” suggesting that some solo stakers who currently operate validators from home will choose to engage in proving. Even though we anticipate reinforcing censorship resistance through mandated transaction inclusion prior to making ZK proof verification compulsory, home proving remains a vital final safeguard.
Since cloud-based proving is already quite economical with multi-GPU spot instances, the focal point for zkVM teams pursuing realtime proving will mainly be optimizing for deploying provers on-site where the specifications are significantly more limited. On-premises realtime proving should require a maximum capital investment of 100k USD (currently it requires around $80k in stake to operate a validator). We expect this expense to decrease over time even as the gas limit is raised.
More significant than hardware costs, the foremost limitation for home proving utilizing GPUs is energy consumption. Most residential properties have at least 10kW supplied from the street, and some will have circuits designated for electric appliances or charging electric vehicles with 10kW capacity. Thus, realtime proving must be feasible on hardware functioning at 10kW or less.
This leads us to our working definition of realtime proving:
- Latency:
- On-prem CAPEX:
- On-prem power:
- Code: Fully open source
- Security: >= 128 bits
- Proof size:
The race to realtime
In the period leading up to Devconnect Argentina, we hope to see zkVM teams persist in their innovations towards realtime home proving, and for leading zkVMs to evolve into vital infrastructure for Ethereum.
