Author: Ethereum researcher Justin Drake, ethresearch; Compiler: Tao Zhu, Golden Finance

The credit for this article goes to the broader Ethereum R&D community. Key contributions date from 2017, with significant incremental unlocking of the design over the years. Recent zkVM engineering breakthroughs have led to radical design space exploration. This article is just my best attempt at piecing together a coherent design for a big idea that might finally be here.

Abstract

We propose an elegant and powerful EXECUTE precompilation that exposes the native L1 EVM execution engine to the application layer. A native execution rollup ("native rollup" for short) is a rollup that uses EXECUTE to validate EVM state transitions for batches of user transactions. Native rollup can be thought of as "programmable execution sharding", wrapping precompilation in derived functions to handle system logic outside the EVM, such as sorting, bridging, forced inclusion, governance.

Because EXECUTE precompilation is performed directly by the verifier, it enjoys (zk)EL client diversity and provides EVM equivalence that is bug-free in construction and consistent with Forked EVM upgrades are forward compatible. For EVM equivalent rollups that wish to fully inherit the security of Ethereum, a form of EVM introspection like EXECUTE precompilation is necessary. We call rollups that fully inherit the security of Ethereum "trustless rollups."

EXECUTE precompilation greatly simplifies the development of EVM equivalent summaries, as no complex infrastructure (e.g. fraud prevention games, SNARK circuits, safety committees) is required for EVM simulation and maintenance. With EXECUTE, minimal native aggregation and aggregation-based aggregation can be deployed with just a few lines of Solidity code using simple derived functions, eliminating the need for special handling of sorting, forced inclusion, or governance.

Most importantly, native rollups can enjoy real-time settlement without worrying about real-time proofs, greatly simplifying synchronous composability.

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

Part 1 - EXECUTE Precompilation Structure

The EXECUTE precompilation accepts as 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 trace (such as a list of L2 transactions and corresponding proof of state access)

None of trace State execution starts from pre_state_root and ends at post_state_root

tracThe stateless execution of e consumes exactly gas_used gas

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

Invoking precompilation costs a fixed amount of L1 gas, EXECUTE_GAS_COST, plus gas_used * gas_price, where gas_price (priced in ETH/gas) is set by an EIP-1559-style mechanism. Even if precompile returns false, the full advance will be taken.

Traces must point to available Ethereum data from call data, blobs, state, or memory.

Re-execution

If EXECUTE_CUMULATIVE_GAS_LIMIT is small enough, the verifier can simply re-execute the trace to enforce correctness of the EXECUTE call. An initial deployment based on a re-execution of the precompilation can serve as a stepping stone, similar to a simple re-download blob to a full danksharding similar to the original danksharding. Note that simple re-execution imposes no state growth or bandwidth overhead on the validator, and any execution overhead can be parallelized across 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 via DAS (rather than downloaded). Note that optimistic native aggregation may still publish aggregate data as blobs, falling back to call data only in fraud proof games. Also note that optimistic native aggregation can have a gas limit well in excess of EXECUTE_CUMULATIVE_GAS_LIMIT since EXECUTE precompilation only needs to be called once on a small EVM segment to solve the fraud proof challenge.

For a historical note, in 2017 Vitalik proposed a similar "EVM inside EVM" precompilation called EXECTX.

Execution via SNARK

To unlock the larger EXECUTE_CUMULATIVE_GAS_LIMIT, it is natural for the verifier to selectively verify the SNARK proof. From now on, we assume a slot-delayed execution in which invalid blocks (or invalidTransaction) is considered a no-op. (For more information on delayed execution, see this ethresearch post , this EIP , and this design by Francesco .) A slot delayed execution yields a few seconds (the entire slot) for the proof. They also avoid incentivizing MEV-driven proof competitions, which would introduce centralized vectors.

Note that even if EXECUTE is enforced by a SNARK, there is no explicit proof system or circuit being incorporated into the consensus. (Note that EXECUTE precompilation does not take any explicit proofs as input.) Instead, each staking operator is free to choose their favorite zkEL validator client, similar to how EL clients are subjectively chosen today. The next section, “Off-chain Proofs,” explains the benefits of this design decision.

From now on, we assume that execution proposers are mature in the context of prover-proposer separation (APS) with alternating execution and consensus slots. To incentivize rational execution proposers to generate proofs in a timely manner (within 1 slot), we require the prover to only certify execution block n+1 if a proof for execution block n is available. (We recommend bundling block n+1 with the EXECUTE proof of block n at the p2p layer.) Execution proposers who skip the proof may miss their slots, resulting in missed fees and MEV. We further impose a fixed penalty on 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, it is important for light clients to generate proofs in a timely manner so that they can easily read the state on the chain side without the need for stateless re-execution. To ensure timely generation of proofs for light clients, even in the special case where the next executing proposer misses its slot, we rely on the altruistic minority prover assumption. A single altruistic prover is enough to generate a proof in 1 slot. To avoid unnecessary redundant proofs, most altruistic provers can wait on standby and only start when no proofs arrive within 1 slot, thus acting as a failsafe for delays of up to 2 slots.

Note that EXECUTE_CUMULATIVE_GAS_LIMIT needs to be set low enough so that the altruistic minority prover assumption is credible (and so that executing the proposal is not unrealistically complicated). A conservative strategy could be to set EXECUTE_CUMULATIVE_GAS_LIMIT so that laptops (such as high-end MacBook Pros) can access single-slot proofs. A more pragmatic and aggressive one might be to target a small subset of GPUs, and possibly eventually SNARK ASIC provers once they are sufficiently commoditized.

Off-chain proof

RestatementWe recommend not placing zkEL EXECUTE proofs on-chain but sharing them off-chain. Not saving proofs is a good idea, first proposed by Vitalik, and it has several advantages:

Diversity: validators are free to choose proof validators from development teams they trust (including proof systems and circuit), similar to how validators select which EL clients they trust. This provides robustness through diversity. The zkEL validator client (and the underlying zkVM for some clients) is complex cryptographic software. A bug in any one client should not cause Ethereum to crash.

Neutrality: Having a zkEL validator client market allows the consensus layer to not choose a technical winner. For example, the zkVM market is highly competitive, and selecting a winning vendor (such as Risc0, Succinct, or many others) may not be considered neutral.

Simplicity: The consensus layer does not need to contain a specific SNARK validator, thus greatly simplifying the specification of the consensus layer. Only the format of the state access proof needs to be included, not specific proof validator implementation details.

Flexibility: If a bug or optimization is discovered, affected validators can update their clients without the need for a hard fork.

Having off-chain proofs does come with some manageable complications:

Proof load and p2p fragmentation: Since there is no single canonical proof, multiple proofs need to be generated ( At least one per zkEL client). Each zkEL client customization (such as exchanging one RISC-V zkVM for another) requires a different certification. Likewise, each zkEL version upgrade requires a different certification. This will result in increased proof load. It would also further fragment the p2p network if there were separate gossip channels for each proof type.

Minority of zkEL: It is difficult to incentivize a small number of zkELs to generate proofs. Rationally executing proposers may only generate enough proofs to reach a supermajority of provers without missing their slot. To solve this problem, staking operators could be socially encouraged to run multiple zkEL clients in parallel, similar to today's Vouch operators. Running a k-of-n setup has the added benefit of improving security, specifically preventing sanity vulnerabilities that would allow an attacker to craft proofs for arbitrary EXECUTE calls (a situation that is not possible with traditional EL clients). common).

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

No replacement DA: Since the tracking input of EXECUTE needs to be provided to the L1 verifier, the L2 of real-time settlement (i.e. immediately An L2) that updates its canonical state root must consume L1 DA, the aggregation. Note that the optimistic L2 that proved the game was delayed by fraud did notSubject to this restriction, it can be a valid value.

State access overhead: Since the trace must be stateless executable, it must include state trie leaves for reading or writing, which introduces a small amount of DA overhead than a typical L2 block. Note that optimistic L2 does not have this restriction, since the state trie leaves are only required in fraud-proof challenges, and the challenger can recompute the trie leaves.

Stateless Difference: Since the attestation should be permissionless given the trace, aggregation of state differences is not possible. However, stateless access proofs or EVM transaction signatures can be compressed if the corresponding specialized proofs are incorporated into the consensus.

RISC-V native execution

Given today's de facto convergence to RISC-V zkVM, there may be an opportunity to natively expose RISC-V state transitions to the EVM (similar to WASM in the Arbitrum Stylus environment) and maintain SNARKs Friendliness.

Part 2 - Native Rollup Naming

We first discuss native rollup naming to resolve several confusing issues:

Alternative names: Native rollups were formerly called enshrined rollups . (The term "canonical rollup" was also briefly used in Polynya 12.) The term "enshrined" was later abandoned in favor of "native" to indicate that existing EVM equivalent rollups could optionally be upgraded to native. The name "Native" was independently proposed in November 2022 by Dan Robinson and a Lido contributor who wished to remain anonymous.

Aggregation-based: Aggregation-based and native aggregation are orthogonal concepts: "based" relates to L1 ordering, while "native" relates to L1 execution. Both based and native rollups are whimsically called "supersonic rollups."

Execution sharding: Execution sharding (i.e. enshrined copies of an L1 EVM chain) is a different but related concept to native rollup, predating native rollup by a few years. (Execution sharding was previously “Phase 2” of the Ethereum 2.0 roadmap.) Unlike native rollups, execution sharding is not programmable, i.e. there are no options for custom governance, custom ordering, custom gas tokens, etc. Execution shards are also typically instantiated in a fixed number (such as 64 or 1,024 shards). Unfortunately, Martin Köppelmann used the term "native L2" in his talk on executing sharding at Devcon 2024 7 .

Benefits

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

Simplicity: Most of the complexity of a native rollup VMAll can be packaged through precompilation. Today's EVM equivalents, optimism and zk-rollup, have thousands of lines of code for their fraud proof games or SNARK verifiers that can be compressed into a single line of code. Native rollups also do not require supporting infrastructure such as proof networks, watchtowers, and security committees.

Security: Building a bug-free EVM fraud-proof game or SNARK verifier is a very difficult engineering task that may require deep formal verification. Today, every optimism and zk EVM rollup is likely to have a critical vulnerability in its EVM state transition function. To guard against vulnerabilities, centralized ordering is often used as a crutch to control adversarial block production. Native execution of precompilation allows safe deployment of permissionless sorting. Trustless rollups that fully inherit L1 security also fully inherit L1 asset fungibility.

EVM equivalence: Today, the only way for rollups to keep up with L1 EVM rules is to have governance (usually the security committee and/or governance token) mirror L1 EVM upgrades. (EVM updates still occur regularly via hard forks about once a year.) Not only is governance an attack vector, it strictly speaking deviates from L1 EVM and prevents any rollups from achieving true long-term EVM equivalence. On the other hand, native rollup can be upgraded simultaneously with L1 without the need for governance.

SNARK gas cost: Verifying SNARKs on-chain is expensive. Therefore, many zk-rollups settle rarely to minimize costs. Since SNARKs are not verified on-chain, EXECUTE precompilation can be used to reduce verification costs. If you are using SNARK recursion to 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 same-slot real-time proofs. Achieving ultra-low latency proofs (e.g. around 100 milliseconds) is a particularly challenging engineering task for zk rollups. Using a single-slot delayed state root, the proof latency of native execution precompilation can be relaxed to a full slot.