Original author | Taiko Labs
Compiled by | Odaily Planet Daily ( @OdailyChina )
Translator | Dingdang ( @XiaMiPP )
Editors note: Do you remember the excitement of Sharding? At that time, it was the traffic password in the blockchain industry. As a result, Ethereum calmed down and gave up this hot potato. Today, local Rollup has made a comeback. By executing precompiled contracts (EXECUTE Precompile) and optimizing the Ethereum block processing structure, it not only makes Rollup safer and more flexible, but also expands the horizontal capacity of Ethereum L1, paving the way for future real-time proofs.
The following is the original content published by Taiko Lab, translated by Odaily Planet Daily. Due to the high technical content of this article, Odaily has made appropriate deletions to ensure the readability of the article and present it as clearly and understandably as possible.
introduction
Sharding was a hot topic between 2017 and 2020. At the time, different teams such as Harmony, Zilliqa, and Elrond implemented sharding technology in their blockchains. This technology essentially divides the network into multiple smaller, parallel-running chains (called shards) that can process transactions simultaneously as a straightforward way to scale distributed systems.
Sharding was also a topic that was seriously discussed by the community in the Ethereum 2.0 era. However, Ethereum ultimately decided not to adopt the sharding solution, mainly based on the following four challenges:
1. Mindset Differentiations
In this sharding model, the protocol itself enforces the exact number of shards from top to bottom. These shards are single chains that run according to a predefined template, lack programmability, and are essentially just multiple identical copies of the L1 (first layer blockchain).
2. Optimistic Security
At that time, in order to ensure the honesty of the shards, optimistic proofs were needed, and zero-knowledge (ZK) technology was not yet mature. This meant that the fraud proof logic had to be systematically managed on the chain.
3. Complexity
Implementing sharding at the L1 layer significantly increases the complexity of the protocol, especially in managing the fast preconfirmation and slower final confirmation system, and coordinating shards with different security levels.
4. Overload Consensus
Pursuing higher scalability at the L1 layer may increase centralization risk. If sharding is implemented at the base layer, this risk may affect the entire protocol, rather than being limited to a single L2 (second layer scaling solution) as it is now.
Native Rollups can essentially be seen as a return to sharding, but this time it’s different. We’ve learned our lessons and have better technology and experience.
What is Local Rollup?
Remember that Rollup consists of data, sequencing, and execution modules. Local Rollup directly uses Ethereums own execution environment as its execution module. We can call it L1s programmable execution shards .
It can be a bit complicated to understand how to use the L1 execution environment as a Rollup. In order to consume the L1 execution environment in a Rollup, we need to be able to execute another EVM inside an EVM. Therefore, L1 needs to be able to sense the state transition of the local Rollup in each block. To achieve this, we need a <precompile contract> to provide support.
EXECUTE precompiled contract
EXECUTE precompiled contracts provide a mechanism that enables one EVM context to verify the execution results of another EVM context while maintaining the same execution rules and state transition logic.
The precompiled contract accepts three input parameters:
pre_state: 32-byte state root before execution
post_state: 32-byte state root after execution
witness_trace: execution trace, including transaction and state access proof
The core of the precompiled contract is the assertion : it verifies whether the trace executed from pre_state can get post_state. If the state transition function is valid, the precompiled contract will return true.
The execution trace needs to be available to all validators (in the form of blobs or calldata) so that the validators can re-execute the computation and verify the correctness of the state transition. It is worth noting that the precompiled contract does not take proofs as input. This means that the protocol itself does not enforce any specific proof system, but rather propagates different types of proofs through the Gossip channel of the p2p network.
Gas Billing Model
Ethereums computing resources are limited, so the Gas mechanism is used to manage these resources. The EXECUTE precompiled contract implements a Gas billing model to manage computing resources:
Base Cost : The precompiled contract will charge a fixed Gas fee EXECUTE_GAS_COST , plus the Gas used by the execution trajectory multiplied by the current Gas price.
Cumulative Gas Limit : Similar to the EIP-1559 mechanism, it manages and prices the total Gas consumption of all EXECUTE calls in an L1 block:
EXECUTE_CUMULATIVE_GAS_LIMIT: The maximum Gas limit for all EXECUTE calls in a block.
EXECUTE_CUMULATIVE_GAS_TARGET: Target Gas usage for efficient pricing.
This model is similar to the data availability (DA) pricing mechanism in blobs.
It is important to remember that local Rollup and SNARKifying the L1 are often confused. SNARKing L1 is a vertical scaling method that improves L1 performance by eliminating Gas limitations through SNARKing execution (such as zkEVM) and consensus (such as Beam). Local Rollup is horizontal scaling L1, which creates any number of EVM copies in a programmable way to achieve higher scalability.
Why is local Rollup more advantageous?
1. Security
The current Rollup design requires Security Councils to update the chain to deal with potential vulnerabilities. Local Rollup relies on Ethereums <Social Consensus> for governance. Operators do not need to worry about vulnerabilities because the Ethereum community will be responsible for maintenance and repairs.
2. Simplify L1 Synchronous Composability
L1-based Rollup is close to achieving synchronous composability, but requires that L1 and L2 blocks be built simultaneously by the same builder. A local Rollup can directly verify the status of another local Rollup through the EXECUTE precompiled contract without additional trust assumptions.
3. Forward Compatibility
As L1 EVM evolves, the local Rollup will automatically inherit all improvements without the need for separate adaptation, thus achieving long-term compatibility with Ethereums development path.
Initial implementation: Re-execution
In the context of local Rollup, re-execution is considered as the initial implementation. Re-execution means that the validator directly executes the transaction trace to verify whether the state transition of the local Rollup is valid, instead of relying on SNARK proof. If EXECUTE_CUMULATIVE_GAS_LIMIT is kept within a small range, this re-execution is still manageable for the validator.
Optimizing execution: Real-Time Proving
In re-execution mode, validators must process all transactions themselves, and their throughput is limited by the EXECUTE_CUMULATIVE_GAS_LIMIT parameter. Real-time Proofs can significantly increase this limit, because validators only need to verify proofs without re-executing all transactions.
As the industry rapidly moves towards real-time proofs, we need to take steps to expand the proof window of local Rollup . In order to gain more proof time, the current Ethereum block processing structure needs to be adjusted.
How to extend the certification window?
Current Ethereum block processing flow
Under the current structure, all of the following steps must be completed within 12 seconds (one stage every 4 seconds) before entering the next block:
Block N Proposed Transaction
Before a block can be verified/confirmed, it must be completed:
Execute all trades
Computing state changes
Compute state root (stateRoot)
Calculate transaction receipts and logs
Only after all the above steps are completed can the block be verified and confirmed.
According to the current process, if synchronous composability with L1 is to be achieved, the proof must be completed within 4 seconds. However, ZK technology is not yet mature and cannot generate proofs for Ethereum blocks within 4 seconds, so we need to introduce greater flexibility in the proof process.
In order to buy more proof time for the local Rollup, we need to adjust Ethereum’s current block processing structure. For example:
Delaying state_root calculation: Remove state_root calculation from the critical path and make it calculated during validator idle time.
Delayed Execution: Separates block verification from transaction execution, optimizing consensus efficiency while providing more time for proof generation.
FAQ
What type of proof will Taiko use?
There will not be a single type of proof. We want diversity in both provers and clients. Verifiers can subjectively decide which proof to use based on their own choice.
See EthProofs for a variety of different proof types.
Who generates the proof?
Anyone can generate a proof. Even if there is only one prover, the chain can still function normally. There is still an open question: how to incentivize provers at the protocol level.
Will there be consensus among the proofs?
No. Proofs are not consensus-generated on-chain, but propagated off-chain. The network only needs to reach consensus that a valid proof exists somewhere.
