Chapter 01

Execution is separate from data availability and settlement

Layer-2 rollups scale Ethereum by unbundling the core responsibilities of a blockchain: execution, consensus, data availability, and settlement. On Layer 1, every validator executes every smart contract instruction and stores the resulting state. A rollup processes transactions off-chain in its own execution environment, allowing thousands of transactions to occur rapidly without congesting the mainnet.

However, off-chain execution cannot be self-authenticating. For a rollup to inherit Ethereum's base-layer security, it must do two things on Layer 1: guarantee data availability and verify settlement. Data availability means that anyone running a node can obtain all the raw transaction data necessary to reconstruct the current state of the rollup. Settlement means that the rollup's state transitions are irreversibly anchored to Ethereum consensus, backed either by mathematical validity proofs or economic fraud dispute windows.

Chapter 02

How EIP-4844 blobs lowered data availability costs

Historically, rollups posted compressed transaction data to Ethereum Layer 1 using smart contract calldata. Because calldata is stored permanently by all Ethereum nodes, it competed directly with ordinary mainnet transactions for execution gas, making Layer-2 fees volatile and expensive during peak periods.

The activation of EIP-4844 (Proto-Danksharding) introduced "data blobs"—ephemeral data packets attached to consensus blocks rather than execution payloads. Blobs carry roughly 128 kilobytes of data each and are automatically pruned by consensus clients after approximately eighteen days (4,096 epochs). This window provides sufficient time for rollup observers and fraud provers to download the batch, verify state transitions, and raise challenges without permanently burdening Ethereum full node storage. EIP-4844 also established an independent blob gas market, decoupling rollup data availability costs from mainnet DeFi congestion.

Chapter 03

Fraud proofs versus validity proofs: the two settlement paradigms

Rollups employ two fundamentally different cryptographic architectures to enforce state validity on Ethereum:

  • Optimistic Rollups: These operate under an optimistic assumption: state root commitments posted to Ethereum are presumed valid unless challenged. Anyone can challenge an invalid state transition by executing an interactive fraud proof within a predefined dispute period (typically seven days). Because of this challenge window, native bridge withdrawals from an optimistic rollup back to Ethereum L1 require a seven-day delay, unless bridged through liquidity providers who take on the inventory risk.
  • Zero-Knowledge (Validity) Rollups: ZK-rollups post cryptographic validity proofs (such as SNARKs or STARKs) alongside each transaction batch. A smart contract on Ethereum Layer 1 mathematically verifies the proof before accepting the new state root. If the proof verifies, the state is immediately valid and final on L1; there is no dispute period, and funds can be withdrawn immediately once the proof is included.

Chapter 04

The sequencer trust model and stage maturity

In their current production states, most rollups rely on centralized sequencers operated by the protocol's development entity. The sequencer orders user transactions, produces immediate soft confirmations, and packages batches for L1 submission. While this provides instant user feedback and low latency, it introduces central failure points: a sequencer can censor specific transactions, extract maximum extractable value (MEV), or temporarily go offline.

To evaluate rollup decentralization, researchers rely on frameworks such as L2Beat's Stage system: - Stage 0 (Full Training Wheels): Centralized operator controls state updates; an emergency multisig can override any transaction without a delay. - Stage 1 (Limited Governance): A functioning proof system is deployed on-chain; an independent security council can only intervene in documented bug emergencies, subject to timelocks. - Stage 2 (No Training Wheels): The proof system is fully autonomous; if bugs occur, multiple distinct proof implementations govern consensus, and user escape hatches allow trustless fund exits directly on Layer 1.

Chapter 05

What users and developers should inspect before bridging

Before committing significant capital to an Ethereum Layer 2, evaluate the following operational realities:

1. Escape Hatches: If the sequencer shuts down, does the rollup have a functioning mechanism to force transaction inclusion directly through the L1 bridge contract? 2. Upgrade Timelocks: Can the rollup contracts be modified instantly by an admin multisig, or is there a multi-day timelock that allows users to exit before code changes take effect? 3. Proof System Status: Is the fraud or validity proof system active on mainnet, or are withdrawals currently authorized by trusted attestations?

Review our parent Ethereum news desk and self-custody wallet guide to track network scaling milestones and security verifications.

Chapter 06

EIP-4844 Blob gas mechanics and Layer 2 fee amortization

The activation of EIP-4844 (Proto-Danksharding) introduced a dedicated transaction type (Type 3) and an independent fee market for ephemeral cryptographic blobs. Instead of posting execution batches as permanent calldata on Ethereum Layer 1, Layer 2 rollups now attach up to six 128-kilobyte data blobs per block.

The blob fee adjustment rule operates according to an exponential pricing model: Blob Base Fee(t) = Blob Base Fee(t-1) * (1 + (Target Blobs - Actual Blobs) / Adjustment Factor)

Blobs are not accessible to the Ethereum Virtual Machine (EVM) execution environment; instead, nodes store blob data on the consensus layer for approximately 4,096 epochs (roughly 18 days), after which the raw data is pruned from validator storage. Point evaluation precompiles allow Layer 1 smart contracts to verify that rollup state commitments match the underlying blob content without processing the full dataset. This architecture reduced rollup operational expenses by over 90%, allowing optimistic and zero-knowledge rollups to amortize execution fees across millions of transactions.

Chapter 07

Escape hatches, forced transaction inclusion, and sequencing failure

A primary security consideration when evaluating Layer 2 networks is whether the rollup implements decentralized escape hatch mechanisms. Most commercial rollups operate centralized sequencers to achieve sub-second transaction confirmations and instant UI updates. However, centralized sequencing introduces transaction censorship and denial-of-service risks.

The forced transaction lifecycle operates as follows: User submits L1 transaction -> Enters L1 Delay Queue -> Sequencer must process within N blocks If Sequencer fails -> Rollup enters emergency mode -> User executes state withdrawal via L1

To maintain trust-minimized security, rollup smart contracts on Layer 1 must provide a forced inclusion queue. If a centralized sequencer refuses to process a user's transaction or goes offline due to infrastructure outages, the user can submit the transaction directly to the Layer 1 bridge contract. If the sequencer does not include the forced transaction within a predefined time window (typically between 24 and 72 hours), the rollup enters emergency state, allowing users to withdraw their assets directly to Layer 1 using Merkle proof verification without sequencer authorization. Rollups lacking these escape hatches should be classified as centralized sidechains rather than true Layer 2 scaling solutions.