Rollups: how they expand network capacity

If you have read layer 1 and layer 2: how blockchains scale, you already know the essentials: a rollup executes transactions off the main network, groups them into batches and publishes the result on it. This article opens the box. It shows who does each step, where the data lives, how the proofs work and why a withdrawal can take a week.

The focus is Ethereum, where rollups are the main path to scalability. The information was checked on October 8, 2026.

A transaction’s path through a rollup

Think of a transfer made on a layer 2 network. It goes through four stages.

1. Ordering. The transaction reaches the sequencer, the operator that decides the order of transactions and assembles the batches. Many rollups have a single sequencer (ethereum.org, optimistic rollups).
2. Execution. The sequencer executes the transactions and computes the network’s new state: balances, contracts, everything. This state is summarized in a state root, a short code that changes if any detail changes.
3. Publication. The compressed batch goes to Ethereum. Along with it go the old and new state roots, recorded in a rollup contract on layer 1 (ethereum.org, optimistic rollups).
4. Verification. A proof system ensures the new root is correct. Here rollups split into optimistic and zero-knowledge, as you will see below.

In our newsroom’s reading, the practical point is this: the fast confirmation your wallet shows comes from the sequencer. Ethereum’s guarantee only exists once the batch is on layer 1 and, for optimistic rollups, once the challenge period ends.

The sequencer: speed with a control point

A single sequencer is simple and fast, but it concentrates power. According to ethereum.org, centralized operators can influence transaction ordering and can censor users by going offline or refusing transactions (ethereum.org, optimistic rollups).

What limits this power is forced exit. In several rollups, you can send your transaction directly to the rollup contract on Ethereum. If the sequencer does not include it within the defined maximum period, it gets in anyway. In some designs, every block must include messages sent from layer 1, and the sequencer cannot delay them (ethereum.org, optimistic rollups). Zero-knowledge rollups have a similar mechanism to force an exit without the operator’s permission (ethereum.org, ZK-rollups).

The detail that changes everything: this feature varies from network to network. A rollup without a working forced exit depends on the goodwill of whoever runs the sequencer.

Data availability: why the rollup publishes everything

Data availability is the assurance that the data needed to verify a block is actually accessible to anyone who wants to check it (ethereum.org, data availability).

For a rollup, this is vital. Without the transaction data, no one can check whether the published state root is correct. In an optimistic rollup, no one can build a fraud proof. In a zero-knowledge rollup, the proof still guarantees the state is valid, but if the operator withholds the data, you can neither know your balance nor move it (ethereum.org, data availability).

That is why a rollup publishes its data on Ethereum itself. Networks that keep data off it, such as validiums, depend on a data availability committee, a group that stores the information and attests that it exists. The guarantee then becomes that group’s honesty, not Ethereum’s.

From calldata to blobs

Until 2024, rollups published their data as calldata, a field in ordinary transactions, which is expensive because it competes for space with every other operation on the network.

EIP-4844 created blobs, data packages attached to blocks. The proposal’s numbers: each blob is about 128 KB, and the original target was 3 blobs per block, with a maximum of 6. Blobs have their own fee market, independent of regular gas, and nodes only need to keep them for 4,096 epochs, about 18 days (EIP-4844). The change went live in March 2024 with the Dencun upgrade (ethereum.org, danksharding).

The 18 days are not an oversight. The data only needs to exist long enough for honest participants to reconstruct the state and challenge errors. After that, keeping the history becomes the job of other participants in the ecosystem (ethereum.org, data availability).

PeerDAS: more blobs without demanding more from each node

Increasing the number of blobs runs into the usual limit: each node would have to download more data. EIP-7594, called PeerDAS, solves this with data availability sampling. Blob data is extended with error-correcting codes and split into columns. Each node stores only some columns and checks samples with its peers; with half the columns, everything can be reconstructed (EIP-7594).

According to the proposal, each node now downloads a fixed fraction of 1/8 of blob data, which allows capacity to grow without increasing bandwidth and storage requirements (EIP-7594). PeerDAS arrived with the Fusaka upgrade in December 2025 (ethereum.org, layer 2). The next step on the roadmap, full danksharding, envisions up to 64 blobs per block and is described by ethereum.org as still “several years” away (ethereum.org, danksharding).

Proofs: how Ethereum knows the batch is right

Fraud proofs, round by round

In optimistic rollups, the batch is accepted up front and can be challenged. Early versions re-executed the entire disputed transaction on Ethereum. Current designs use multi-round interactive proofs: the party that published the batch and the challenger split the execution in half, over and over, until a single disputed step is isolated. Only that step is executed on layer 1 (ethereum.org, optimistic rollups).

The incentive comes from bonds, amounts deposited by those who publish batches. If the challenge succeeds, part of the bond goes to the challenger and the rest is burned, which discourages collusion between the parties. The contract can also delete invalid state roots and return the rollup to the correct state (ethereum.org, optimistic rollups).

Validity proofs

In zero-knowledge rollups, each batch comes with a cryptographic proof. A verifier contract on Ethereum checks the proof, the previous root and the new one before accepting the batch (ethereum.org, ZK-rollups).

There are two families of proofs. SNARKs produce small proofs that are cheap to verify, but they depend on a trusted initial setup. STARKs dispense with that setup and are considered resistant to quantum computing, but they produce larger proofs that cost more to verify. Verifying a proof on Ethereum costs about 500,000 gas, and generating one requires heavy computation, sometimes specialized hardware, which can concentrate the operation (ethereum.org, ZK-rollups).

Withdrawal periods: where the difference shows up for you

Bringing assets back to Ethereum shows, in practice, how each rollup protects itself.

• Optimistic rollup. The withdrawal request goes into the next batch and must wait for the end of the challenge period, about seven days (ethereum.org, optimistic rollups).
• Fast withdrawal. A liquidity provider takes over your pending withdrawal and pays you on Ethereum immediately, for a fee. It can verify the withdrawal by running the network itself before paying (ethereum.org, optimistic rollups). You trade waiting for an intermediary.
• ZK-rollup. The withdrawal is executed as soon as the contract verifies the validity proof, with no challenge period (ethereum.org, ZK-rollups).

Moving assets between networks by other routes involves bridges, which carry their own risks. The topic has a dedicated article: blockchain bridges.

Stages: how much a rollup still depends on people

Many rollups started with “training wheels”: administrators able to upgrade contracts, pause the system or fix errors. To measure how far each network has moved past this, the independent site L2BEAT uses a three-stage classification (L2BEAT, stages). It is not an official Ethereum standard, but it has become a market reference.

• Stage 0. The proof system must exist and work: in ZK-rollups, accept the proposed state root; in optimistic rollups, allow invalid roots to be rejected.
• Stage 1. Blocking or forging withdrawal messages requires compromising at least 75% of the security council, the group with emergency powers. Upgrades made by other parties must give users at least 7 days to exit.
• Stage 2. Anyone can submit fraud proofs, users have at least 30 days to exit in the face of an unwanted upgrade and the council can only act on bugs provable on the blockchain itself.

ethereum.org takes the same line, saying a layer 2’s security depends on the technology, the security of its contracts and the network’s maturity, and recommends starting with small amounts (ethereum.org, layer 2).

Questions to ask before using a rollup

• Does transaction data go to Ethereum or stay with an external committee?
• Is the proof system active, and who can submit proofs?
• Is there a forced exit through layer 1 if the sequencer stalls or censors?
• Who can upgrade the contracts, and with how many days’ notice?
• What is the withdrawal period through the official route?

No answer eliminates the risks of bugs, poorly written contracts or tokens losing value. Transactions generally cannot be reversed. If the network is used for financial applications, it is also worth reviewing what DeFi is.

Key takeaways

• A rollup gains capacity because it executes off Ethereum and publishes there only compressed data and state roots; security comes from the data being available and from there being a proof.
• Blobs (EIP-4844) and PeerDAS (EIP-7594) made space for this data cheaper and larger, with retention of about 18 days.
• A single sequencer, no forced exit, contracts that can be upgraded without notice and proofs restricted to a few participants are signs that a rollup still depends on trust in people.