Hybrid Rollup

Current Standard for Rollups
OPTIMISTIC
Transactions are assumed to be valid
unless challenged with fraud proofs
Lower transaction fees
Cost-efficient in gas usage and off-chain computation, with cheaper withdrawals
Lower complexity
Intuitive security with the straightforward challenge window
Compatibility
EVM-compatible with a simpler implementation
ZK
All transactions must
have validity proofs to be posted
Fast Finality
Instant finality and withdrawals are reduced from days to hours.
Robust Security
ZK properties provide strong cryptographic guarantees
Fast Withdrawals
No challenge period required
Valid Transactions Only
Every transaction must have a posted validity proof
How Optimistic Rollup works
All transaction batches are assumed to be valid unless challenged with a fraud proof during the challenge period (e.g., 7 days). Transactions have instant confirmation with withheld finality.
1
The user submits a transaction to an L2 Node.
2
The transaction is forwarded to the L2 Sequencer who executes the transactions, aggregates to produce batches, computes the new state root and submits to the L1.
3
The transaction batch is submitted to the L1 Bridge Contract. The L1 Bridge Contract publishes the batch on the L1 and the status is updated to “submitted”.
4
The Challenger will recompute a new state root and scrutinize the transaction blocks.
5
If the transaction block is challenged: the L1 Arbitrator Contract is run and parties may be rewarded or punished as a result. If a transaction is found to be indeed fraudulent: the entire batch of fraudulent transactions will be rolled back and the fraudster will be slashed. The status is updated to “invalid”.
6
If the transaction block is not challenged: the transaction batches are considered to be correctly computed. After the challenge period, the batch is validated and actions such as withdrawals are allowed. The status is updated to “valid”.
How ZK Rollup works
All transaction batches must have a validity proof to be posted onto L1. Transactions with validity proofs have instant finality.
1
The user submits a transaction to an L2 Node.
2
The transaction is forwarded to the L2 Sequencer who executes the transactions, aggregates to produce batches, computes the new state root and submits to the L1.
3
The transaction batch is submitted to the L1 Bridge Contract. The L1 Bridge Contract publishes the batch on the L1 and the status is updated to “submitted”.
4
The Prover zkVM produces a succinct proof that proves the correctness of the batch.
5
The Prover sends the proof and the new state root to the L1 Verifier Contract.
6
The L1 Verifier Contract checks the proof, stores the state root and updates the status of the batch from “submitted” to “validated”.
Why Hybrid?
Each rollup flavor has its own challenges
Present Trust Assumptions
Transactions are considered valid until proven otherwise
Reliance on Challengers
Requires available challengers to identify and prove invalid transactions
Delayed finality
Waiting period consists of a 7-day challenge window before transactions are finalized
Difficult implementation
ZK-secured EVMs are difficult to build
Higher Complexity
Greater complexity due to cryptographic principles in ZK proofs
More Computationally Expensive
Involves more hardware requirements and higher costs for proving
Higher transaction fees
Tends to incur higher gas costs and more expensive withdrawals
Our existing rollups alone are not sufficient
How Hybrid Rollup works
A ZK Rollup is placed inside an Optimistic Rollup for a single cohesive protocol. Users can choose between the Optimistic and ZK phases depending on their needs.
1
The user submits a transaction to an L2 node.
2
The transaction is forwarded to the L2 sequencer who executes the transactions, aggregates to produce batches, computes the new state root and submits to the L1.
3
The transaction batch is submitted to the L1 bridge contract. The L1 bridge contract publishes the batch on the L1 and the status is updated to “submitted”.
4
If the user wants to bypass the fraud challenge window (for faster finality), the transaction batch will be processed using a validity proof in Steps 4-6 in “How ZK Rollup Works”.
5
Transactions that fail the validity check will be processed through the optimistic fraud challenge phase in Steps 4-6 in “How Optimistic Rollup Works”. Note: Hybrid Rollups can also create a longer fraud challenge window if preferred by the user.
Leveraging zkMIPS, we can integrate

with any L2 to construct Hybrid Rollup
zkMIPS offers seamless integration with existing L2 solutions to enable the implementation of Hybrid Rollups. L2s can leverage zkMIPS which enables support for ZK rollups by generating succinct proofs.
1
The user submits a transaction to the Sequencer.
2
The Sequencer upon receiving L2 transactions, composes a new L2 block and submits the validated block to the L1 Rollup Smart Contract as a transaction batch.
3
The Batch Monitor reads the new batch from the L1 Rollup Smart Contract.
4
The Batch Monitor sends the batch to the State Monitor.
5
The State Monitor retrieves the L2 state (from the L2 node) to validate the batch.
6
The State Monitor passes the retrieved state and batch to the MIPS VM.
7
The MIPS VM executes the program compiled MIPS and generates an execution trace. The Prover uses the execution trace to generate a ZK Proof.
8
The ZK Proof is sent to an on-chain Proof Verifier. If the proof is valid, a state transition is triggered and actions such as withdrawals are allowed.

Metis is implementing zkMIPS to build the first Hybrid Rollup.

LEARN MORE
Home
Team
whitepapers
BLOG
docs
EVENTS
CONTACT
Brand Guideline
Brand Assets
Terms and Conditions
Privacy Policy for ZKM