If you've been in the blockchain space, you've probably heard of "rollups" - they're Layer 2 (L2) solutions that help Ethereum scale by processing transactions off the main chain. But there's always been a tradeoff: these rollups often rely on things like multisig wallets (where multiple people hold keys) or security councils to ensure everything works properly. These are essentially centralized points of failure in an otherwise decentralized system. Ethereum researcher Drake Justin published a proposal for what he called "native rollups". The aim is to solve this problem by allowing rollups to inherit the full security of Ethereum's Layer 1 (L1) blockchain. Let me break this down in simpler terms. proposal proposal The Problem With Current Rollups Currently, rollups that want to provide an Ethereum-like experience face several challenges: Security Councils: Many rollups rely on trusted groups to oversee operations.
Complex Fraud Proofs: Optimistic rollups need complicated systems to catch bad behavior
Expensive SNARK Verification: Zero-knowledge rollups spend a lot of gas verifying their proofs
Keeping Up With Ethereum: When Ethereum upgrades its rules, rollups need to manually update too Security Councils: Many rollups rely on trusted groups to oversee operations. Security Councils: Complex Fraud Proofs: Optimistic rollups need complicated systems to catch bad behavior Complex Fraud Proofs: Expensive SNARK Verification: Zero-knowledge rollups spend a lot of gas verifying their proofs Expensive SNARK Verification: Keeping Up With Ethereum: When Ethereum upgrades its rules, rollups need to manually update too Keeping Up With Ethereum: These are all basically "trust points" that prevent rollups from being as secure as the Ethereum L1 itself. The Solution: EXECUTE Precompile The proposal introduces something called an "EXECUTE precompile". Think of a precompile as a highly efficient, special smart contract that's part of the Ethereum protocol itself, verified directly by all Ethereum validators. Other precompiles exist for things like cryptographic operations that are too complex or slow to do efficiently in a regular smart contract. Here's what the EXECUTE precompile does: EXECUTE EXECUTE(pre_state_root, post_state_root, trace, gas_used) EXECUTE(pre_state_root, post_state_root, trace, gas_used) It checks if: The trace (list of transactions and state changes) is valid
Starting from the pre_state_root and applying the trace gets you to the post_state_root
The execution uses exactly gas_used amount of gas The trace (list of transactions and state changes) is valid trace Starting from the pre_state_root and applying the trace gets you to the post_state_root pre_state_root trace post_state_root The execution uses exactly gas_used amount of gas gas_used In simpler terms: Ethereum's validators themselves verify that rollup transactions are correct, rather than relying on separate security mechanisms. How Would This Work? There are two main ways this could be implemented: Re-Execution Approach
Ethereum validators would simply re-execute the rollup transactions to verify they're correct. This is simple but has limitations on how much processing can be done.


SNARK-Based Approach
This uses zero-knowledge proofs (like super-efficient cryptographic receipts) to verify execution without redoing all the work. The cool part is that the proposal doesn't pick one specific SNARK system - validators could choose which verification clients they want to use, providing diversity and resilience. Re-Execution Approach
Ethereum validators would simply re-execute the rollup transactions to verify they're correct. This is simple but has limitations on how much processing can be done. Re-Execution Approach Re-Execution Approach Ethereum validators would simply re-execute the rollup transactions to verify they're correct. This is simple but has limitations on how much processing can be done. SNARK-Based Approach
This uses zero-knowledge proofs (like super-efficient cryptographic receipts) to verify execution without redoing all the work. The cool part is that the proposal doesn't pick one specific SNARK system - validators could choose which verification clients they want to use, providing diversity and resilience. SNARK-Based Approach SNARK-Based Approach This uses zero-knowledge proofs (like super-efficient cryptographic receipts) to verify execution without redoing all the work. The cool part is that the proposal doesn't pick one specific SNARK system - validators could choose which verification clients they want to use, providing diversity and resilience. In summary: In summary: Deploy EXECUTE with a low initial gas cap—validators just re-execute.
Rollups switch their state-transition verification to call EXECUTE(...).
Validators optionally run zk-verifier clients off-chain for bigger batches.
Users enjoy instant finality, simpler bridges, and fully trustless L2s. Deploy EXECUTE with a low initial gas cap—validators just re-execute. EXECUTE Rollups switch their state-transition verification to call EXECUTE(...). EXECUTE(...) Validators optionally run zk-verifier clients off-chain for bigger batches. Users enjoy instant finality, simpler bridges, and fully trustless L2s. Benefits of Native Rollups Benefit

Today’s Rollups

With Native EXECUTE



Code complexity

Thousands of lines of fraud-proof or SNARK logic

Single-line Solidity precompile call



Security risk

Multisig councils or custom verifiers

Inherits L1 validator security directly



EVM equivalence

Governance needed for each hard fork

Automatically stays in sync



Real-time settlement

Hard for ZK (needs 100 ms proofs)

One-slot delay—easy to hit



Gas costs

High on-chain SNARK verification cost

Metered like any other precompile Benefit

Today’s Rollups

With Native EXECUTE



Code complexity

Thousands of lines of fraud-proof or SNARK logic

Single-line Solidity precompile call



Security risk

Multisig councils or custom verifiers

Inherits L1 validator security directly



EVM equivalence

Governance needed for each hard fork

Automatically stays in sync



Real-time settlement

Hard for ZK (needs 100 ms proofs)

One-slot delay—easy to hit



Gas costs

High on-chain SNARK verification cost

Metered like any other precompile Benefit

Today’s Rollups

With Native EXECUTE Benefit Benefit Today’s Rollups Today’s Rollups With Native EXECUTE With Native EXECUTE EXECUTE Code complexity

Thousands of lines of fraud-proof or SNARK logic

Single-line Solidity precompile call Code complexity Code complexity Thousands of lines of fraud-proof or SNARK logic Thousands of lines of fraud-proof or SNARK logic Single-line Solidity precompile call Single-line Solidity precompile call Security risk

Multisig councils or custom verifiers

Inherits L1 validator security directly Security risk Security risk Multisig councils or custom verifiers Multisig councils or custom verifiers Inherits L1 validator security directly Inherits L1 validator security directly EVM equivalence

Governance needed for each hard fork

Automatically stays in sync EVM equivalence EVM equivalence Governance needed for each hard fork Governance needed for each hard fork Automatically stays in sync Automatically stays in sync Real-time settlement

Hard for ZK (needs 100 ms proofs)

One-slot delay—easy to hit Real-time settlement Real-time settlement Hard for ZK (needs 100 ms proofs) Hard for ZK (needs 100 ms proofs) One-slot delay—easy to hit One-slot delay—easy to hit Gas costs

High on-chain SNARK verification cost

Metered like any other precompile Gas costs Gas costs High on-chain SNARK verification cost High on-chain SNARK verification cost Metered like any other precompile Metered like any other precompile For Users True Security: Your assets on L2s become as secure as on Ethereum L1 itself
No More Trusted Operators: No need to worry about security councils going rogue
Synchronous Composability: L2s could interact with L1 contracts in real-time True Security: Your assets on L2s become as secure as on Ethereum L1 itself True Security: No More Trusted Operators: No need to worry about security councils going rogue No More Trusted Operators: Synchronous Composability: L2s could interact with L1 contracts in real-time Synchronous Composability: For Developers Simplicity: Building a rollup becomes dramatically simpler
Automatic Updates: When Ethereum upgrades, your rollup automatically stays compatible
Lower Costs: Verification becomes more efficient Simplicity: Building a rollup becomes dramatically simpler Simplicity Automatic Updates: When Ethereum upgrades, your rollup automatically stays compatible Automatic Updates: Lower Costs: Verification becomes more efficient Lower Costs: For Ethereum More Fee Revenue: Since rollups would use Ethereum for data availability
Increased ETH Value: Greater utility and demand for the network
Forward Compatibility: Existing L2s have a clear path to upgrade More Fee Revenue: Since rollups would use Ethereum for data availability More Fee Revenue: Increased ETH Value: Greater utility and demand for the network Increased ETH Value: Forward Compatibility: Existing L2s have a clear path to upgrade Forward Compatibility: What About "Based Rollups"? What About "Based Rollups"? Most L2s today handle sequencing themselves using a dedicated server or a small set of servers, often run by the team that built the rollup. This gives them a lot of control (which can be good for user experience, like instant confirmations), but it also introduces centralization risks. The sequencer has significant power over transaction ordering and inclusion. The idea behind a Based Rollup is to decentralize and secure the L2’s sequencing layer by tying it directly to Ethereum's L1 block production. In a Based Rollup, instead of the rollup having its own independent sequencer(s), the right to order and propose the next batch of rollup transactions is given to the current L1 block proposer. This means that the rollup inherits the L1's censorship resistance and MEV protection. In my next article, I will be comparing the Based and Native rollups for a clearer understanding of both rollup architecture and design. Watch this space 😉. What This Means For You What This Means For You If you're using rollups today, the idea of Native rollups represents a future where you don't have to worry about the rollup's security model being different from Ethereum's. Your assets would have the same security guarantees regardless of which layer they're on. For L2 projects, this offers a path to enhance their security without rebuilding from scratch, potentially eliminating their most significant vulnerability (centralized components). For Ethereum, this strengthens its position as the security hub of the ecosystem, capturing more value and making the whole system more robust. The Bottom Line The Bottom Line Native rollups represent a straightforward but powerful idea: let Ethereum itself verify rollup execution. This eliminates the need for security councils, complex fraud proof systems, and other centralized components while maintaining all the performance benefits of rollups. As Eigenlayer's founder Sreeram Kannan put it: “This is a slam dunk idea by @drakefjustin—extend L1 security to any rollup without random multisigs. Ethereum earns more fees, rollups get strong security, and everyone wins.” “This is a slam dunk idea by @drakefjustin—extend L1 security to any rollup without random multisigs. Ethereum earns more fees, rollups get strong security, and everyone wins.” This is a "slam dunk idea" that creates a win-win situation for both Ethereum and its L2 ecosystem. It expands Ethereum's security offering to solve a real pain point while increasing fee revenue and ETH value.

A New Ethereum Upgrade Could Solve Rollups’ Biggest Security Flaw

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Beginner's Guide to Reading and Writing Smart Contracts on Explorers

06/09/2018: Biggest Stories in the Cryptosphere

07/09/2018: Biggest Stories in the Cryptosphere

0x Protocol, Waves, and EtherDelta: Solutions and Limitations of Distrust

03/09/2018: Biggest Stories in the Cryptosphere

108 Stories To Learn About Blockchain Adoption

A Beginner's Guide to Reading and Writing Smart Contracts on Explorers

06/09/2018: Biggest Stories in the Cryptosphere

07/09/2018: Biggest Stories in the Cryptosphere

0x Protocol, Waves, and EtherDelta: Solutions and Limitations of Distrust

03/09/2018: Biggest Stories in the Cryptosphere

108 Stories To Learn About Blockchain Adoption

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps