Exploring Attacks in the Modular Rollup World - Censorship.wtf

The Motivation

Nashqueue (the speaker) is a research engineer at Celestial Labs and a contributor to Rollkit

The talk is about to discuss how rollups have evolved to rely on specialized protocols for transaction inclusion, proof verification, and ordering rather than just Ethereum's censorship resistance.

Rollups are now using decentralized data availability layers, shared sequencers, and provermarkets. This allows rollups to inherit the censorship resistance of these specialized protocols.

But there are potential attacks which illustrate how rollups' reliance on other protocols affects their censorship resistance.

What is a rollup ? (1:15)

How things go :

1. A user submits a transaction to a sequencer, which batches transactions.
2. Rollup full nodes see the batch
3. Light nodes rely on the header with a cryptographic commitment/guarantee for finality.

Rollup Block = Rollup Data + Rollup Header. Rollup blocks consist of rollup data (batch of transactions or state differences) and rollup headers (metadata about the block including a commitment to the transactions).

Rollups delegate different steps :

• Data availability is delegated
• Inclusion : what transactions are in the block
• Ordering : order of transactions
• Execution : state root after executing transactions
• Proving : cryptographic proofs validating metadata

There is flexibility in how rollups divide up these responsibilities :

• The sequencer does inclusion and ordering by batching transactions.
• The header producer can do execution and proving.

Attack #1 (3:15)

In the most basic rollup, transactions are posted directly to the data availability (DA) layer, and Rollup full nodes can read transactions from the DA layer.

This means the DA layer gets all the MEV (maximum extractable value). The DA layer can reorder, censor, etc.

Instead of the base layer, MEV could be leaked to a shared sequencer : the shared sequencer can provide soft confirmations for faster block times, but finality still comes from the DA layer and rollup full nodes.

So the shared sequencer is also incentivized to extract MEV and get bribes.

Attack #2 (4:15)

If the shared sequencer does not provide soft confirmations, rollup nodes read from the DA layer to force posting :

• The DA layer and sequencer can collude and censor - the sequencer blocks batches so rollup nodes can't get the canonical chain.
• The DA layer is not reordering transactions, since they are not posted yet. There is delayed finality.

Attack #1+#2 (5:15)

If there are two schemes - shared sequencer and base layer - there can be an "escape hatch" prioritizing the shared sequencer batch.

But having a fallback sequencing mechanism is not sufficient, as the data layer can still selectively delay batches to game the fallback.

Ultimately, the data layer has control over transaction ordering and censoring before finality, enabling MEV extraction.

The Execution Layer (06:15)

About execution :

• Rollups have full nodes that execute all transactions to verify validity (pessimistic rollups).
• Light nodes do not execute transactions. They rely on header producers to provide transaction batch summaries.

A centralized header producer can reorder transactions in a batch to get MEV for themselves before committing the header.

To prevent a single header producer extracting all the value, there can be competition through permissionless header production.

Different header producers can apply different objective functions to reorder transactions, such as maximizing MEV extraction, gas burn, user welfare, or community rewards.

Fork-choice rules determine which header chain is canonically accepted. Rules could favor headers maximizing different objectives.

Header producers control transaction ordering before batch commitment, enabling MEV extraction unless ordering is enforced on the data layer.

Attack #3 (07:50)

If there are multiple header producers per rollup height, MEV is leaked to the DA layer again via profitable censorship.

Header producers can bribe the DA layer to censor other headers when theirs has the highest MEV extraction, creating a "highest bribe" foxtrous rule.

Attack #5 (08:45)

For Validity Rollups, there is a decentralized prover market to incentivize creating proofs for the DA layer.

• The DA layer still does ordering and inclusion.
• The header producer does execution

There would be an attack which censors proof propagation to delay finality for user light nodes.

This can be mitigated with incentives and P2P propagation. But the real issue is on-chain light clients needed for cross-chain bridges.

Transactions initializing a bridge must include ZK proofs. These transactions go through the pipeline of the bridged chain.

This allows the bridged chain's data layer to reorder and censor bridge transactions before execution and finality.

So even with a decentralized prover market, the data layer and header producer of the bridged chain can extract MEV from bridge transactions by controlling order and inclusion.

Attack #6 (10:50)

With optimistic rollup bridges, the censorship resistance depends on the fraud proof window (the time allowed to submit fraud proofs)

The bridged chain's data layer and header producer can control transaction ordering and inclusion for bridge transactions. This allows them to extract MEV, e.g. by censoring a transaction to unlock collateral and cause a liquidation.

The fraud proof window needs to be set long enough to account for potential censorship of bridge transactions.

But more protocols and steps involved makes calculating the window harder. If set too short, censorship could prevent fraud proofs.

There needs to be more research on how to properly set fraud proof windows to ensure censorship resistance when bridging between chains.

Combining everything together (12:45)

In a modular blockchain system with shared sequencers, data availability layers, header producers, ZK proofs, and bridges, there are many potential attack vectors for transaction censorship and MEV extraction.

The data availability layer is critical. it must have strong censorship resistance to prevent systemic MEV extraction on transactions before finality.

Methods to improve data availability censorship resistance include :

• Threshold encryption so proposers don't know transaction contents
• Multiple proposers per block to split censorship risk
• Prioritizing shared sequencer batches over base layer sequencer batches

Overall, researching and ensuring censorship resistant data availability is key to preventing MEV extraction across rollups, validiums, ZK proofs, and bridges in a modular blockchain.

Recommended talks for more details :

• Profitable Censorship MEV
• Exploring MEV Capture in Modular Systems