Native rollups: rollups verified directly by L1
Strawmap L* (2029~30) · native rollups
Instead of each rollup building its own proving machinery, Ethereum L1 directly verifies the results of the rollup's transaction execution. The rollup inherits L1's security and the EVM as they are.
Why it is needed
Today each rollup builds its own machinery to prove that transaction execution is correct. These are fraud proofs, which reverse an incorrect result, or validity proofs, which produce a mathematical proof that the result is correct. This machinery is complex and can have bugs. For that reason many rollups give a small group of operators, called a security council, the authority to make emergency fixes. There is also the burden that when Ethereum L1's EVM changes, rollups must update their proving machinery to follow. Native rollups are a concept that hands this job to L1. As with the EXECUTE precompile that Ethereum Foundation researcher Justin Drake proposed on ethresear.ch, if L1 has a feature that directly verifies EVM execution results, a rollup can submit its state changes to L1 and have them checked. The rollup then gets the same security as L1, and when the EVM is upgraded it follows along as is, with no separate work. In the Strawmap it appears as a headliner in the L* fork column around 2029 to 2030, but this is only an expectation, not a confirmed schedule.
How it works
- The rollup submits its result The rollup submits the batch of transactions it processed, along with the states before and after, to an L1 contract. It does not go through its own proving machinery.
- L1 verifies the execution L1 uses its EVM execution verification feature to check that executing those transactions produces the submitted result. Ethereum itself, not the rollup, acts as the verifier.
- The state is finalized Only results that pass verification are accepted as the rollup's new state. The rollup inherits L1's security as is, without a separate security council.