Ethereum Researcher: Native rollups – Superpowers from L1 execution

Author: Ethereum researcher Justin Drake, ethresearch; compiled by Tao Zhu, bitchain vision

The credit for this article is due to the wider Ethereum R&D community.Key contributions stemmed from 2017, with significant incremental unlocks in design over the years.Recent breakthroughs in zkVM engineering have triggered a thorough exploration of design space.This article is just trying its best to piece together a coherent design for a big idea that may finally come.

summary

We propose an elegant and powerful EXECUTE precompilation that exposes native L1 EVM execution engine to the application layer.Native Execution Summary (“Native Summary”) is a summary of EVM state transitions using EXECUTE to verify batch user transactions.Native summary can be considered as “programmable execution shards”, and precompiled in derived functions to handle system logic outside the EVM, such as sorting, bridging, forced inclusion, governance.

Since EXECUTE precompilation is performed directly by the validator, it enjoys (zk)EL client diversity and provides EVM equivalents that are constructively error-free and are upgraded to EVM via L1 hard forkPrevious compatibility.For EVM equivalent summary that wishes to fully inherit Ethereum security, EVM introspection forms like EXECUTE precompilation is necessary.We call the summary of fully inheriting Ethereum security a “trustless summary”.

EXECUTE precompilation greatly simplifies the development of EVM equivalent summary because EVM simulation and maintenance is performed without complex infrastructure such as fraud prevention games, SNARK circuits, Safety Boards.With EXECUTE, a few lines of Solidity code can be used to deploy minimal native and roll-based summaries using simple derived functions, eliminating the need for special treatment of sorting, forced inclusion, or governance.

Most importantly,Native aggregation can enjoy real-time settlement without worrying about real-time proofing, greatly simplifying synchronous composability.

This article is divided into two parts, first introducing the proposed precompilation and finally discussing native summary.

Part 1 — EXECUTE Precompiled

structure

EXECUTE Precompilation accepts inputs pre_state_root, post_state_root, trace, and gas_used.It returns true if and only if the following conditions are met:

trace is a well-formed execution tracking (e.g., L2 transaction list and corresponding status access proof)
The stateless execution of trace starts with pre_state_root and ends with post_state_root
The stateless execution of trace just consumes gas_used gas

There is an EIP-1559-style mechanism for measuring and pricing the accumulated gas consumed by all EXECUTE calls in the L1 block.Specifically, there is an accumulated gas limit EXECUTE_CUMULATIVE_GAS_LIMIT, and an accumulated gas target EXECUTE_CUMULATIVE_GAS_TARGET.(When L1 EVM can be executed statelessly by the verifier, the cumulative limits and targets can be merged with the L1 EIP-1559 mechanism.)

Calling precompilation requires a fixed number of L1 gas, EXECUTE_GAS_COST, plus gas_used * gas_price, where gas_price (price in ETH/gas) is set by the EIP-1559-style mechanism.The full prepayment will be withdrawn even if precompilation returns false.

Tracking must point to available Ethereum data from the call data, blob, state, or memory.

Re-execute

If EXECUTE_CUMULATIVE_GAS_LIMIT is small enough, the validator can simply re-execute the trace to enforce the correctness of the EXECUTE call.The initial deployment based on reexecution precompilation can serve as a stepping stone, similar to the simple re-download of the original danksharding to the full danksharding.Note that simple re-execution does not bring state growth or bandwidth overhead to the validator, and any execution overhead can be parallelized between CPU cores.

The validator must hold an explicit copy of the trace for re-execution, thus preventing the use of pointers to blob data sampled (rather than downloaded) through DAS.Note that optimistic native summaries may still publish aggregated data in the form of blobs, falling back to the call data only in fraud proof games.It is also important to note that optimistic native aggregation can have gas limits that far exceed EXECUTE_CUMULATIVE_GAS_LIMIT, because EXECUTE precompilation only requires a single call on a small EVM segment to resolve the fraud proof challenge.

As a historical record, in 2017, Vitalik proposed a similar “EVM inside EVM” precompilation called EXECTX.

Execute via SNARK

To unlock the larger EXECUTE_CUMULATIVE_GAS_LIMIT, it will naturally allow the verifier to selectively verify the SNARK proof.From now on, we assume that a time slot delays execution, where an invalid block (or invalid transaction) is considered to be an operation without operation.(For more information on delayed execution, see this ethresearch post, this EIP, and this design for Francesco.) A slot delayed execution results in seconds (the entire slot) for proof.They also avoid incentivizing MEV-driven proof competitions, which will introduce centralized vectors.

Note that even if EXECUTE is enforced by SNARK, there is no clear proof that the system or circuit is incorporated into the consensus.(Note that EXECUTE precompilation does not take any explicit proof as input.) Instead, each staking operator is free to choose their favorite zkEL validator client, similar to how today’s approach to selecting an EL client subjectively.The next section “Off-chain Proof” will explain the benefits of this design decision.

From now on, we assume that the execution proposer is mature in the context of prove-proposer separation (APS) with alternating execution and consensus slots.To motivate rational execution proposers to generate proofs in a timely manner (within 1 time slot), we require that the proofs prove execution block n+1 only when the proof of execution block n is available.(We recommend bundling block n+1 with EXECUTE proof of block n at the p2p layer.) Execution proposers who skip proofs may miss their time slots, resulting in missed fees and MEVs.We further impose a fixed penalty on the missed execution slots, setting it high enough (e.g. 1 ETH) to always exceed the cost of the proof.

Note that in the context of APS, the generation of consensus blocks is not blocked by missed execution slots.However, timely generation of proofs is important for light clients so that they can read state easily on the chain side without stateless re-execution.To ensure timely proof generation for light clients, we rely on the altruistic minority proof assumption even in the special case where the next execution proposer misses its time slot.A single altruistic prover is sufficient to generate a proof in 1 time slot.To avoid unnecessary redundant proofs, most altruistic proofs can wait on standby and initiate only when no proof arrives within 1 slot, thus acting as a fail-safe measure for delays of up to 2 slots.

Note that EXECUTE_CUMULATIVE_GAS_LIMIT needs to be set low enough to make the altruistic minority prover assumptions trustworthy (and to make the execution proposal unrealistically complicate).A conservative strategy could be to set EXECUTE_CUMULATIVE_GAS_LIMIT so that laptops such as high-end MacBook Pro can access single-slot proofs.A more pragmatic and positive policy may be to target a small percentage of GPUs, and once they are fully commoditized, it may eventually target the SNARK ASIC proof.

Off-chain proof

To reiterate, we recommend not putting the zkEL EXECUTE proof on the chain, but sharing it off-chain.Not saving proof is a good idea, first proposed by Vitalik, and it has several advantages:

Diversity:Verifiers are free to select proof validators (including proof systems and circuits) from the development team they trust, similar to how validators choose EL clients they trust.This provides robustness through diversity.The zkEL validator client (and some of the underlying zkVMs of clients) are complex encryption software.Errors in either client should not cause Ethereum to crash.
Neutrality:Having the zkEL validator client market allows the consensus layer to not select the technology winner.For example, the zkVM market is highly competitive and choosing a winning supplier (such as Risc0, Succinct, or many other suppliers) may not be considered neutral.
Simplicity:The consensus layer does not need to include a specific SNARK validator, which greatly simplifies the specification of the consensus layer.Just include the format of the state access proof, not the specific proof validator implementation details.
flexibility:If errors or optimizations are found, affected validators can update their clients without hard forks.

Having off-chain proof does bring about some controllable complexities:

Prove load and p2p fragmentation:Since there is no single specification proof, multiple proofs need to be generated (at least one per zkEL client).Each zkEL client customization (for example, swapping one RISC-V zkVM for another) requires a different proof.Similarly, each zkEL version upgrade requires a different proof.This will result in increased proof load.If each proof type has a separate gossip channel, it will further fragment the p2p network.
A few zkEL:It is difficult to motivate a few zkEL to generate proofs.Rational execution proposers may only generate enough proofs to reach the vast majority of proofs without missing out on their time period.To solve this problem, staked operators can be encouraged from the society to run multiple zkEL clients in parallel, similar to today’s Vouch operators.Running the k-of-n setup also has the added benefit of improving security, especially preventing sanitary vulnerabilities that allow attackers to create proofs for arbitrary EXECUTE calls (this case is not for traditional EL clients.common).

Off-chain proof will also reduce the efficiency of real-time settlement L2:

No substitute DA:Since the tracking input of EXECUTE needs to be provided to the L1 validator, the L2 that settles in real time (the L2 that updates its specification status root immediately) must consume L1 DA, i.e., summary.Note that there is no such limit on the optimistic L2 of the game’s delayed settlement by fraud, i.e. it can be a valid value.
Status access overhead:Since the trace must be stateless executable, it must include state trie leaves that are read or written, which introduces a small amount of DA overhead than a typical L2 block.Note that optimistic L2 does not have this limitation because the state trie leaves are only needed in fraud proof challenges, and the challenger can recalculate the trie leaves.
No state difference:Since the proof should be permissionless, the summary status difference cannot be done because of a given tracking.However, if the corresponding specialized proof is incorporated into the consensus, the stateless access proof or EVM transaction signature can be compressed.

RISC-V native execution

Given today’s actual convergence to RISC-V zkVM, there may be an opportunity to locally expose RISC-V state transitions to EVMs (similar to WASMs in Arbitrum Stylus environments) and maintain SNARK-friendly.

Part 2 — Native Rollup

name

Let’s first discuss the naming of native Rollup to solve several confusing problems:

Alternative name:Native summary was previously known as enshrined summary.(The term “canonical summary” was also briefly used in Polynya 12.) The term “enshrined” was later abandoned and replaced with “native” to indicate that existing EVM equivalent summary can be optionally upgraded to native.The name “native” was independently proposed by Dan Robinson and a Lido contributor who wanted to remain anonymous in November 2022.
Based on summary:Based on summary and native summaries are always orthogonal concepts: “Based” is related to L1 sorting, while “Native” is related to L1 execution.At the same time, based on and native summary is whimsical called “superonic summary”.
Execute sharding:Execution sharding (i.e., the enshrined copy of the L1 EVM chain) is a different but related concept related to native summaries, several years before native summaries.(The execution of sharding was before the “Phase 2” of the Ethereum 2.0 roadmap.) Unlike native rollup, sharding is not programmable, that is, there are no options such as custom governance, custom sorting, and custom gas tokens.Execution shards are also usually instantiated in a fixed number (e.g. 64 or 1,024 shards).Unfortunately, Martin Köppelmann used the term “native L2” 7 in his 2024 Devcon’s speech on executing shards.

benefit

Native Rollups have several benefits, which we will cover in detail below:

Simplicity:Most of the complexity of a native rollup VM can be encapsulated by precompilation.Today, optimism and zk-rollup, comparable to EVM, have thousands of lines of code for their fraud proof games or SNARK validators that can be compressed into one line of code.Native rollups also do not require auxiliary infrastructure such as proof networks, watchtowers and security committees.
Security:Building an error-free EVM fraud proof game or SNARK validator is a very difficult engineering task that may require in-depth form validation.Today, every optimism and zk EVM rollup is likely to have a serious vulnerability in its EVM state transition function.To prevent vulnerabilities, centralized sorting is often used as a crutch to control adversarial block production.Native execution of precompilation allows secure deployment of permissionless sorting.Trustless rollups that fully inherit L1 security also fully inherit L1 asset interchangeability.
EVM Equivalence:Today, the only way rollup keeps synchronized with L1 EVM rules is to have governance (usually security committees and/or governance tokens) mirror L1 EVM upgrades.(EVM updates are still regularly performed with hard forks about once a year.) Governance is not only an attack vector, it strictly deviates from L1 EVM and prevents any rollup from achieving true long-term EVM equivalence.On the other hand, native rollup can be upgraded synchronously with L1 without governance.
SNARK gas cost:Verifying SNARK on-chain is expensive.Therefore, many zk-rollups settle rarely to minimize costs.Since SNARK is not validated on-chain, EXECUTE precompilation can be used to reduce verification costs.If you use SNARK to recursively batch EXECUTE proofs for multiple calls in a block, EXECUTE_GAS_COST can be set relatively low.
Synchronous Composability:Today, synchronous composability with L1 requires real-time proof of the same slot.Implementing ultra-low latency proofs (e.g. around 100 milliseconds) is a particularly challenging engineering task for zk rollups.Using a single slot delay state root, you can relax the proof delay of the native performing precompiled to a full slot.