Native rollups—superpowers from L1 execution

[thegaram33]

@JustinDrake

a rollup which uses EXECUTE to verify EVM state transitions for batches of user transactions. One can think of native rollups as “programmable execution shards” that wrap the precompile within a derivation function to handle extra-EVM system logic

There is some uncertainty whether Ethereum’s state transition could be applied to rollups with no modification:

• State transition function divergence (mentioned by @edfelten).
• EVM validity rules. E.g. for Ethereum a block that contains a transaction with incorrect nonce or insufficient balance is itself invalid. For rollups, it’s often beneficial to treat all blocks as valid (which may result in no-op state transition).

Also, the term EVM state transition misses a few steps that are today part of a most rollups’ execution, and it’s unclear how those steps could be combined with this precompile:

• Chain derivation: There are multiple steps to how most rollups derive the L2 chain from the blob data. At the least they have a decompression step, but the chain derivation pipeline could be much more complex.

@JustinDrake

trace is a well-formatted execution trace (e.g. a list of L2 transactions and corresponding state access proofs)

EVM execution also depends on the block context (block number, timestamp, etc.), these would also need to be passed to the precompile.

@JustinDrake

The trace must point to available Ethereum data from calldata, blobs, state, or memory.
…
Validators must hold an explicit copy of trace for re-execution, preventing the use of pointers to blob data which are sampled

Aren’t these two sentences in conflict? Could you provide an example (few lines of Solidity) showing how a native rollup would pass traces to the precompile?

@JustinDrake

From now on we assume one-slot delayed execution where invalid blocks (or invalid transactions) are treated as no-ops

I think EIP-7862 (and related discussion) only proposes delayed state root computation, not delayed execution. Most nodes are still expected to execute blocks in the same slot.

@JustinDrake

To reiterate, we suggest that zkEL EXECUTE proofs not go onchain and instead be shared offchain.

The decoupling of execution from proving is nice and I can certainly see the benefits. Are there any guarantees/expectation of long-term availability for these proofs? If I spin up a new node I want to avoid reexecuting each precompile call and verify proofs instead.

@JustinDrake

Having a market of zkEL verifier clients allows for the consensus layer to not pick technology winners

I can see that the block proposer can use whichever proving vendor they want to use. But doesn’t this mean that all EL clients need to be able to verify all possible types of proofs? If I receive a block with a proof, but I don’t know how to verify this specific proof type, then I have to re-execute the traces and I’ll fall behind.

@JustinDrake

With one-slot delayed state root the proving latency underlying the native execution precompile can be relaxed to one full slot.

How does this enable synchronous composability, could you elaborate?