Author: imToken
Editor's note: Ethereum is moving towards a new era of scalability with 10,000 TPS, and zero-knowledge proof (ZK) technology is becoming a key driving force. This article is the second part of our compilation on the 'Ethereum 10,000 TPS Roadmap', focusing on the technical challenges of real-time proving, the participation logic of Provers, security challenges during the L1 transition, and how 'native Rollup' will become the ultimate form of ZK scalability.
If ZK transformation is the starting point for the technological reconstruction of Ethereum, then 'real-time proving' and 'native Rollup' are the core landing phases of this scalability revolution.
In this article, we will continue to explore how to achieve 12-second level ZK real-time proving on the Ethereum mainnet, the hardware thresholds and incentive mechanisms for becoming a Prover, and how native Rollup will rewrite the landscape of Ethereum L2.
01. Real-time proving: the key puzzle piece in Ethereum's scalability
In Ethereum's roadmap toward 10,000 TPS, there is an indispensable technological breakthrough point: real-time proving.
Uma Roy, co-founder of Succinct, explained: 'Real-time proving refers to the ability to complete the generation of a ZK proof for a block on the Ethereum mainnet in less than 12 seconds.'
What does this mean? Once real-time proving is achieved, Ethereum will be able to incorporate its block verification logic into the protocol itself and raise the gas limit 'arbitrarily' without sacrificing verifiability, thus achieving large-scale scalability for L1 (editor's note: the generation time for each block on the Ethereum mainnet is 12 seconds, so 'real-time' refers to completing the proof within each block cycle).
However, to achieve real-time proving, relying solely on zkVM technology is not enough; changes to the Ethereum protocol layer are also required.
Ladislaus from the Ethereum Foundation indicated that a key mechanism is expected to be introduced in next year's Glamsterdam upgrade—'decoupling block verification and immediate execution', which will provide Provers with more time to generate zkEVM proofs within a complete slot, thus achieving true real-time processing.
In terms of technical implementation, Succinct has released its latest SP1 Hypercube zkVM, which can generate proofs in real-time for 93% of the 10,000 mainnet blocks under a cluster of 200 GPUs.
Roy stated that they are confident of raising the success rate to 99% by the end of this year. Although some difficult-to-handle blocks may still result in a few blocks being unable to generate proofs in time, the protocol design has considered fault-tolerance mechanisms, such as allowing the skipping of that block and proceeding to the next block.
Furthermore, Ethereum is also considering reducing the block time from 12 seconds to 6 seconds (as another potential proposal for Glamsterdam), which would significantly enhance user experience and transaction confirmation speed. However, this also adds extra pressure on ZK Provers—the difficulty of the task has doubled.
However, Roy is not worried; after all, ZK technology can improve its performance by tenfold each year, and even if block times are halved, it can still cope.
In June, Linea also announced that it can achieve 100% on-chain activity covered by ZK proofs on its network. Although Linea's current TPS is only 2, this is not a performance limitation but rather constrained by usage demand.
Notably, the Linea block interval is only 2 seconds, with ZK proofs uploaded to Ethereum L1 for verification via smart contracts. This model may be a precursor to the future 'ZK transformation' of the mainnet.
02. Is the hardware threshold for Ethereum ZK Provers high?
To generate ZK proofs in real-time, powerful computing resources are essential.
The initial technical goal set by the Ethereum Foundation for Provers is to keep hardware costs under $100,000 and power consumption below 10 kilowatts, which is roughly equivalent to the power consumption level of a Tesla Powerwall home battery.
This number does not sound 'lightweight'; Ethereum critic Justin Bons (founder of Cyber Capital) called it 'mad hardware requirements far exceeding those of Solana's validation nodes', but this actually confuses two completely different roles.
Ladislaus from the Ethereum Foundation's protocol coordination team points out that the roles of Prover and Validator are different and should not be confused—Validators run nodes and participate in consensus, while Provers generate ZK proofs. Once a ZK proof for a transaction is correctly generated, the network only needs to verify whether that proof is correct, without needing to re-execute the transaction.
Because of this, Ladislaus expressed optimism, stating, 'As long as we can find an honest Prover that meets the hardware conditions, Ethereum can continue to operate safely. We intentionally set the threshold below that of data centers, and even individuals with technical capabilities can run Provers at home, even if they are not large institutions or data centers.'
Currently, this $100,000 hardware configuration is just an initial target. Ethereum Foundation researcher Sophia Gold expects that by November this year, ahead of the Devconnect developer conference in Argentina, mainstream Provers will likely meet this target.
Roy, co-founder of Succinct, expects that by early next year, GPU demand can be reduced to about 16 graphics cards, with total costs controlled between $10,000 to $30,000.
At the same time, Succinct has already built a decentralized network composed of 'hundreds of Provers' on the testnet, generating millions of proofs cumulatively.
The core logic of this system is competitive proving, meaning all Provers participate in bidding to select a winner for each round to execute zk proofs, aiming for participants with shorter times and lower costs to win, forming a computational bidding mechanism.
This means that in the ZK-driven future of Ethereum, the miner spirit will reappear in another form—only the role has changed from computing blocks to computing proofs.
03. Transitioning the mainnet to ZK architecture: a highly challenging system migration
The Ethereum L1 mainnet will switch to a zero-knowledge proof (ZK) architecture, which is another technological challenge of a similar level following the transition from proof of work (PoW) to proof of stake (PoS) in 2022. The entire process not only requires the reconstruction of the protocol layer but also must carefully consider various potential edge scenarios and security risks to prevent network interruptions.
At the EthProofs conference in July this year, researcher Justin Drake mentioned several possible risk hazards. For example, malicious attackers might insert so-called 'prover killers' into the block, leading to a failure of the entire network verification mechanism; or if network activity suddenly drops, the transaction fee income generated may not be sufficient to cover the costs of generating ZK proofs, affecting the sustainability of the network.
Ladislaus from the Ethereum Foundation's protocol coordination team indicated that the entire transition process could take several years, especially focusing on security risks. The ZK virtual machine (zkVM), as a complex technology still in its early stages, is likely to have various vulnerabilities. However, as the ecosystem matures, we can gradually enhance its feasibility and robustness on Ethereum L1 through the introduction of diverse proof systems (proof diversity), improvements in incentive mechanisms, and formal verification.
Meanwhile, Ethereum is also planning a fundamental architectural reconstruction of its consensus layer, specifically constructing a new structure named 'Beam Chain', aiming to be ZK-optimized right from the design phase. Drake even mentioned that in the future, the entire data validation work of Ethereum could be completed on a regular laptop's CPU.
04. Mainnet 'Snarkification': Native Rollup is coming
Alongside the integration of zkEVM on the Ethereum mainnet, another long-term vision is gradually emerging: native Rollup.
Current Rollups (whether Optimistic or ZK type) use independent proof systems, with their security relying on their own validator or sequencer mechanisms, which involves some trust assumptions with the Ethereum mainnet.
The vision for 'native Rollup' is completely different—it aims to integrate zkEVM into the mainnet, allowing Ethereum L1 validators to directly verify the state transition proofs of the Rollup, thus achieving true L2 verification and security guaranteed by the mainnet.
This requires adding a critical piece of code, 'execute precompile', in the Ethereum L1 client, allowing validators to directly verify ZK state transition proofs generated by L2. As Ladislaus, the Ethereum Foundation protocol coordinator, said, 'L1 validators will consume these execution proofs from Rollups and verify their correctness.'
In other words, if native Rollup comes to fruition, then in the future, whether a transaction occurs on L1 or on a native Rollup, its final settlement and security will be guaranteed by the same group of Ethereum validators, with an equivalent level of trust.
This means that depositing $10 million on a native Rollup will have the same level of security as directly depositing on the Ethereum mainnet.
Declan Fox, the project lead of Linea, stated that their long-term goal is to become a native Rollup. He believes this is an 'upgraded version' of the ETH 2.0 sharding plan—not merely running 64 structurally identical shard chains but constructing heterogeneous Rollup systems in a highly programmable and customizable manner to serve different scenarios and user needs.
Unlike the homogeneous sharding architecture of ETH 2.0 in the past, native Rollups can be heterogeneous, providing end users with a more diverse and differentiated application experience.
Although native Rollup has not yet been formally written into the Ethereum roadmap, the official launch of zkEVM and the gradual reconstruction of the L1 architecture, along with setting predetermined interfaces and precompiled logic, have clearly become foreseeable technical trends.
Ladislaus summarized that 'there is a high degree of technical synergy in integrating EVM Snark (i.e., incorporating ZK proof capabilities) and advancing native Rollups, as both share the underlying ZK technology stack.' Of course, this process still needs to go through Ethereum community governance to form EIPs (Ethereum Improvement Proposals) and ultimately be deployed in a hard fork.
Optimistically, if everything goes smoothly, relevant EIPs might be submitted by the end of the year and go live in the fork after the Glamsterdam upgrade.
However, this timeline still carries a high degree of uncertainty and should be viewed with caution.
