Ethereum Layer 2s Explained: Scaling, Rollups, Transactions, Blobs and Bridges

Disclaimer: This article is for informational and educational purposes only and simplifies underlying technical concepts for clarity. It is not financial, investment, or security advice.

Sending USDC on a Layer 2 looks just like sending it on Ethereum: choose a network, enter an address, approve and send. The transfer confirms in moments and costs a fraction of what it would on Ethereum itself.

But beneath that simple experience sits a chain of separate systems. A sequencer orders your transaction, an execution engine processes it, a batch poster publishes the data to Ethereum, and a proof system establishes that the result is valid.

Let us follow how these pieces fit together, from the reason Layer 2s exist to how a business should choose between them.

1. Why Does Ethereum Need Layer 2s?

Ethereum is a blockchain that allows users to transfer assets and interact with smart contracts. Every transaction executed directly on Ethereum competes for limited block space and consumes computational resources.

Consider the activity happening on Ethereum simultaneously:

• A user transfers USDC to another wallet.
• A trader swaps ETH for another token on a decentralised exchange.
• An investor deposits collateral into a lending protocol.
• A business issues tokenised securities.
• Another user mints an NFT.

Ethereum must process these transactions according to its execution rules and include them in blocks. When demand exceeds the available capacity, users compete for block space, and transaction fees can increase.

CryptoKitties: The Cats That Clogged Ethereum

In late November 2017, a game called CryptoKitties launched on Ethereum. Players could buy, collect and breed digital cats, each represented by a unique NFT.

Every purchase, sale and breeding action required an Ethereum transaction. The game's popularity generated enough activity to contribute significantly to network congestion. Transactions queued up, fees increased, and users performing unrelated activities also faced delays.

The problem returned on a larger scale during the 2020–2021 DeFi and NFT boom. At peak times, token swaps could cost tens of dollars, and popular NFT mints could cost hundreds of dollars or more.

Ethereum's problem was not that it could not execute these transactions. It was that its limited capacity could not accommodate everyone cheaply during periods of high demand.

Why Not Simply Make Ethereum Bigger?

Ethereum produces blocks at intervals of roughly 12 seconds, and each block has a limited capacity for computation and data.

Every full node must independently verify the blockchain's execution. This repetition helps make Ethereum trustworthy, but it also creates a scaling constraint: if the resource requirements become too demanding, fewer people can afford to run nodes.

Increasing block capacity substantially could improve throughput, but it could also increase hardware, bandwidth and storage requirements. That could make it harder for ordinary participants to operate nodes and weaken decentralisation.

This trade-off is often described through the blockchain scaling trilemma.

The trilemma is a useful design framework, not a mathematical law that every blockchain must satisfy in exactly the same way.

Ethereum's Rollup-Centric Roadmap

Ethereum has pursued scaling through a combination of improvements to the main network and the growth of Layer 2s.

Rather than requiring Ethereum L1 to execute every transaction directly, the rollup-centric approach moves much of the execution to separate networks while retaining Ethereum as an important settlement and data-availability layer.

Ethereum itself continues to evolve, including through upgrades that increase data availability and improve transaction efficiency. However, much of the intended growth in application activity takes place on Layer 2s.

2. What Is a Layer 2?

A Layer 2 (L2) is a network built on top of an underlying blockchain, such as Ethereum, to process transactions more efficiently.

Ethereum is called Layer 1 (L1). An Ethereum rollup executes transactions in its own environment and uses Ethereum for functions such as data availability, settlement and enforcement of its security rules.

Examples of Ethereum L2 networks include Arbitrum, Base, OP Mainnet, ZKsync Era, Starknet, Linea and Scroll.

An L2 has its own transaction history, blocks and execution state. It is therefore similar to a separate blockchain operating alongside Ethereum, but it is not necessarily an independent blockchain with the same security model.

A rollup can inherit important security properties from Ethereum, but its practical security also depends on its proof system, data availability, bridge, upgrade permissions and operational design.

The Highway Analogy

Imagine Ethereum's main network as a heavily guarded highway into a city. It is secure, but it can carry only a limited amount of traffic.

Layer 2s are express lanes alongside the main highway. Vehicles travel along the express lanes, and many of them are grouped into buses. Instead of every vehicle entering the main highway separately, the buses carry information representing many transactions.

The main highway processes fewer individual transaction submissions, while many more users can transact through the express lanes.

3. How Does an L2 Transaction Work?

Let's follow a simple example: you have 100 USDC on an L2 and want to send 20 USDC to a friend.

Your balance should decrease to 80 USDC, while your friend's balance should increase by 20 USDC. The simplified flow is:

Rollup settlement and Ethereum finality are distinct milestones and do not always complete in the order shown; see Steps 9 and 10. Let us break this down step by step.

Step 1: Your Wallet Constructs and Signs the Transaction

You select the L2 network, enter your friend's address, and specify 20 USDC.

Your wallet constructs a transaction calling the USDC smart contract's transfer function. It includes the L2 chain ID, your account nonce, the contract address, encoded instructions and fee parameters.

Your wallet signs the transaction using your private key. The private key is never sent to the network.

Step 2: The Wallet Submits the Transaction Through an RPC Provider

The signed transaction is sent to an RPC endpoint for the L2.

An RPC provider connects your wallet to blockchain infrastructure. It can retrieve balances, estimate gas, submit transactions and return receipts. It relays your transaction but does not decide the final outcome.

Step 3: The Sequencer Receives and Orders Transactions

The sequencer receives transactions and determines their processing order according to the rollup's rules. For example:

1. You transfer 20 USDC to your friend.
2. Another user swaps ETH for USDC.
3. A third user deposits collateral into a lending protocol.

Ordering matters because each transaction may change the state encountered by subsequent transactions.

Step 4: The L2 Execution Engine Processes Transactions

The L2 execution software processes the ordered transactions according to the network's execution rules.

For your transfer, the USDC smart contract checks the relevant conditions and updates its storage:

• Your USDC balance decreases by 20.
• Your friend's USDC balance increases by 20.

The execution produces a new L2 state. The sequencer determines transaction ordering, while the execution software determines the outcome. The same infrastructure may perform both roles.

Step 5: Transactions Are Organised Into L2 Blocks

The sequencer organises transactions into L2 blocks, preserving their processing order. Each block contains an ordered set of transactions processed against the state resulting from earlier transactions.

L2 blocks are distinct from Ethereum L1 blocks. Multiple L2 blocks can be produced before their associated transaction data is published to Ethereum.

Step 6: The L2 Provides a Quick Confirmation

The sequencer may acknowledge your transaction once it has been accepted and processed. This often happens before Ethereum has received the transaction data or finalised the corresponding rollup state.

Step 7: The Batch Poster Publishes L2 Data to Ethereum

A batch poster collects L2 transaction data and submits it to Ethereum through an L1 transaction. Depending on the rollup, data may be published as calldata or blobs.

This is where Ethereum becomes directly involved in the rollup's settlement process. The L1 transaction is processed by Ethereum, and the published data or commitment becomes part of Ethereum's record.

The batch poster is a separate role from the sequencer, although the same organisation may operate both.

Step 8: Ethereum's Execution and Consensus Clients Process the L1 Transaction

Ethereum's execution clients process the batch poster's transaction. Depending on how the rollup publishes its data, Ethereum records the data or its associated commitment and updates the relevant Ethereum smart contract state. If the batch uses blobs, the blob data itself is propagated and stored by Ethereum's consensus clients, while the execution layer sees only the versioned hashes that commit to it.

Ethereum's role is to record the data needed by the rollup and provide the on-chain mechanisms for settling its state. Ethereum does not normally execute each individual L2 transaction, such as your 20 USDC transfer, as a separate Ethereum transaction. That transfer is executed on the L2.

Step 9: The Rollup's Settlement Mechanism Completes

What happens next depends on the rollup type.

• Optimistic rollup: The rollup may publish a claim about the resulting L2 state. Eligible participants can challenge an invalid claim during the challenge period using the rollup's dispute mechanism. If no successful challenge occurs, the claim can be accepted under the protocol's rules.
• ZK rollup: The rollup submits a validity proof, which its Ethereum verification contract checks. If the proof is valid and the required L1 transaction is accepted, the state update can be accepted without an optimistic challenge period.

The precise order and implementation of data publication, state claims and proof verification vary by rollup.

Step 10: Ethereum Reaches Consensus Finality

Ethereum validators attest to blocks, and the consensus protocol finalises the chain under its proof-of-stake rules.

Ethereum finality helps establish that the relevant L1 records are part of the finalised chain.

4. What Do RPC Providers, Execution Clients and Consensus Clients Do?

The transaction lifecycle above relies on several pieces of software. Some sit between the user and the network, while others run the network itself.

RPC Providers

An RPC (remote procedure call) endpoint is the interface that wallets and applications use to communicate with a blockchain node. Through it, a wallet can read balances, estimate fees, simulate transactions, submit signed transactions and retrieve receipts.

Most wallets and applications do not run their own nodes. They rely on RPC providers such as Infura, Alchemy or QuickNode, or on public endpoints published by an L2 team. An RPC provider cannot alter a signed transaction, but it can fail to relay it, return outdated or incorrect information, or observe which addresses and transactions a user is interested in. Businesses with significant volume often use more than one provider or run their own nodes.

Execution Clients

An Ethereum execution client, such as Geth, Nethermind, Besu, Erigon or Reth, executes the transactions in each L1 block, runs smart contract code and maintains Ethereum's state, including account balances and contract storage.

When a batch poster submits a rollup transaction, execution clients run the rollup's L1 contracts and update their state.

Consensus Clients

A consensus client, such as Prysm, Lighthouse, Teku, Nimbus or Lodestar, follows Ethereum's proof-of-stake protocol. It tracks which blocks form the canonical chain, processes validator attestations and determines when blocks are finalised.

Consensus clients are also responsible for blob data. Blobs travel alongside blocks as separate "sidecars" that consensus clients receive, store and later prune, while the execution layer sees only the versioned hashes that commit to them. This is why rollup nodes need access to a consensus (beacon) endpoint to retrieve blob data.

Validator Clients

A validator client is used by stakers who have deposited ETH. Working with a consensus client, it proposes blocks when selected and signs attestations. Validators earn rewards for performing these duties correctly and can be penalised for being offline or acting dishonestly.

5. How Do Optimistic Rollups Work?

Optimistic rollups generally operate on the assumption that a proposed state transition is valid unless it is successfully challenged through the protocol's fraud-proof mechanism.

This does not mean an operator can arbitrarily change balances. The execution rules and dispute mechanisms are designed to identify and reject invalid state claims.

Arbitrum One, OP Mainnet and Base are examples of optimistic rollups.

The terminology in this section follows Arbitrum. In the OP Stack, which OP Mainnet and Base use, the equivalent roles are usually called proposers, who post claims about the L2 state, and challengers, who dispute invalid claims.

The Optimistic Rollup Transaction Lifecycle

Step 1: Transactions are submitted and ordered. Users send signed transactions to the L2. The sequencer establishes their order and coordinates execution.

Step 2: The L2 executes transactions. The execution environment processes the ordered transactions and updates account balances and contract storage.

Step 3: The batch poster publishes transaction data. The batch poster collects and compresses the relevant transaction data and submits it to Ethereum through the rollup's data-inbox mechanism.

Step 4: A validator proposes an assertion. An assertion is a claim about the result of executing a portion of the L2 transaction history.

Conceptually, the assertion claims that starting from the previously accepted state, executing the relevant transactions according to the rollup's rules produces the claimed new state and outputs.

Step 5: The assertion can be challenged. An eligible participant who believes an assertion is incorrect can initiate the protocol's dispute process.

In Arbitrum's fraud-proof design, participants use an interactive dispute game to narrow the disagreement down to the relevant execution step. An on-chain verifier can then determine the outcome according to the protocol's rules.

An ordinary customer does not usually challenge an assertion through a normal wallet transaction. Challenging assertions requires the appropriate technical infrastructure and eligibility under the rollup's protocol.

Step 6: The assertion is confirmed or rejected. If the assertion survives the applicable dispute process and satisfies the protocol's requirements, it can be confirmed. If it is invalid, the protocol applies the prescribed consequences.

What Happens to Withdrawals?

Suppose you want to withdraw USDC from Arbitrum to Ethereum.

You initiate the withdrawal on the L2. The withdrawal becomes part of the L2 transaction history and must satisfy the rollup's confirmation requirements.

The relevant state claim must be sufficiently established before the L1 bridge releases the corresponding assets.

Standard optimistic-rollup withdrawals therefore include a challenge-related delay, commonly around seven days for major systems, although exact timing and protocol requirements vary.

This delay applies to the standard withdrawal process, not every ordinary L2 transaction. You can generally continue using funds within the L2 without waiting for the entire challenge period.

6. How Do Zero-Knowledge Rollups Work?

Zero-knowledge (ZK) rollups also execute transactions separately from Ethereum, but they use cryptographic validity proofs to establish that the claimed state transition follows the rollup's rules.

ZKsync Era, Starknet, Linea and Scroll are examples of ZK or validity-proof-based rollup systems, though their architectures and maturity differ.

The ZK Rollup Transaction Lifecycle

Step 1: The wallet submits a transaction. The user signs a transaction and sends it to the rollup.

Step 2: The sequencer orders transactions. The sequencer establishes the processing order and coordinates transaction execution.

Step 3: The L2 executes the transactions. The execution environment processes the transactions and calculates the resulting state.

Step 4: Transaction data is grouped into batches. The rollup prepares the transaction information required by its data-availability design.

Step 5: A prover generates a validity proof. A prover generates a cryptographic proof demonstrating that the relevant state transition follows the rollup's execution rules.

Conceptually, the proof establishes that the claimed computation is valid given the specified inputs, previous state and execution rules.

Proof generation can require substantial computation. It is often handled by specialised proving infrastructure and does not necessarily happen inside the sequencer itself.

Step 6: Data and proof information are submitted to Ethereum. The rollup publishes the required transaction data and submits the validity proof and associated state commitments through Ethereum transactions. These are separate operations and may happen at different times.

Step 7: Ethereum verifies the proof. A verifier contract checks the proof according to the rollup's cryptographic verification rules. If the proof is valid and the other protocol requirements are satisfied, the state transition can be accepted.

However, a ZK rollup does not necessarily provide instant finality. Proof generation, submission, Ethereum inclusion and other protocol requirements still take time.

Does Zero-Knowledge Mean Transactions Are Private?

Not necessarily.

The term describes the cryptographic proof system. Many ZK rollups use validity proofs to establish computational correctness while making transaction data available publicly.

Privacy depends on the specific design, not merely on the use of a zero-knowledge proof.

Optimistic vs ZK Rollups

Both designs rely on more than their core verification mechanism. Data availability, upgrade controls, bridge security and operational arrangements also matter.

7. Why Are L2s Faster and Cheaper?

L2s can process transactions independently of Ethereum's ordinary transaction execution capacity and provide quick confirmations through their own transaction-processing systems.

Three mechanisms explain much of the improvement.

1. Separate Execution Capacity

An L2 executes transactions in its own environment. Those transactions do not each need to compete for Ethereum L1 execution capacity.

2. Transaction Batching

Many L2 transactions can share the cost of publishing data and settlement information to Ethereum.

Instead of requiring a separate L1 transaction for every L2 transfer, a rollup can publish compressed data representing many transactions.

3. Different Confirmation Mechanisms

The sequencer can provide a quick confirmation before the relevant batch or state claim completes its L1 settlement process.

This improves the user experience, but a quick confirmation is not necessarily the same as full settlement finality.

How Are L2 Fees Calculated?

A user generally pays for L2 execution, while the rollup also incurs costs associated with publishing data to Ethereum. Depending on the network, fees can include:

• L2 execution costs.
• Priority fees or other ordering-related charges.
• A contribution toward the cost of publishing transaction data to Ethereum.

The exact fee model varies by L2. A priority fee can influence transaction ordering on networks that use such a mechanism, but it is not necessarily retained entirely by the sequencer.

A USDC transfer fee is generally based on computational and data costs, not the dollar amount being transferred. Sending 10,000 USDC does not ordinarily cost ten times as much as sending 1,000 USDC when both involve the same standard transfer operation.

The Dencun Upgrade and Blobs

In March 2024, Ethereum's Dencun upgrade introduced blob-carrying transactions through EIP-4844, also known as proto-danksharding.

Before this upgrade, rollups often relied on calldata to publish transaction data. Blobs provided a separate, generally cheaper data-publication mechanism designed for rollups.

Because the cost of publishing rollup data is a significant component of L2 fees, cheaper blob space helped reduce fees on many L2s.

There is also an economic consequence for Ethereum itself. Ethereum burns the base fees associated with certain transaction activity, and blob fees have their own separate fee market, whose base fee is also burned. When rollups pay less for data publication, the amount of ETH burned through those payments can fall.

8. What Are Ethereum Blobs?

Rollups need to publish transaction data to Ethereum so that the data can be retrieved and used to reconstruct or verify the L2's state. Ethereum supports different ways of publishing this data, including calldata and blobs.

What Are Calldata and Blobs?

Calldata is data included directly in an Ethereum transaction. When a rollup publishes its transaction data through calldata, that data becomes part of the Ethereum transaction's permanent historical record.

Blobs are a mechanism introduced by Ethereum's Dencun upgrade that allows Layer 2 rollups to publish large amounts of data to Ethereum at a lower cost.

How Do Blobs Work, and When Is the Data Deleted?

Consider a rollup that has processed hundreds of L2 transactions and needs to publish their data to Ethereum.

1. Collect and compress: The rollup collects and compresses its L2 transaction data.
2. Publish the batch: The batch poster submits an Ethereum transaction containing blobs with the data. The transaction includes a cryptographic commitment to the blob data, represented by a versioned hash.
3. Make the data available: Ethereum's blob data-availability mechanism makes the full blob contents available for a limited period, approximately 18 days.
4. Retrieve and verify: During this period, rollup nodes and other participants can retrieve the data to reconstruct or verify the relevant L2 transaction history.
5. Prune the data: After the retention period, ordinary Ethereum consensus nodes can delete the full blob contents. The Ethereum transaction and its cryptographic commitment remain on-chain, but the commitment cannot reconstruct the deleted data. Historical copies may still exist if other participants have preserved them.

Why Is a Limited Retention Period Acceptable?

Blob data needs to remain available only long enough for anyone who depends on it to retrieve it. The roughly 18-day window is designed to exceed the typical seven-day challenge period of optimistic rollups, giving participants time to download the data and dispute an invalid state claim. Rollup nodes, indexers and archive services keep their own copies for longer-term history.

Blobs vs Calldata

Not every rollup uses blobs for every batch. The choice depends on the rollup's architecture and fee economics.

9. How Do Bridges Move Assets Between L1 and L2?

Ethereum and each L2 maintain separate balances. Holding 10,000 USDC on Ethereum does not automatically give you 10,000 USDC on Base. A bridge enables assets or value to move between these networks.

Depositing From Ethereum to an L2

Suppose you want to move 10,000 USDC from Ethereum to Base using a lock-and-mint bridge.

1. Lock: You deposit 10,000 USDC into the bridge contract on Ethereum. The original USDC is locked in the contract.
2. Verify: The bridge mechanism confirms that the deposit occurred.
3. Mint: The destination-side bridge issues or releases the corresponding representation of USDC on Base.
4. Use: You can now use the USDC available on Base in applications deployed on that network.

The original USDC remains locked on Ethereum while the corresponding assets are available on Base. The exact mechanism depends on the bridge and token. Some bridges use other approaches, including burning tokens on the source network and minting native tokens on the destination.

Four Ways to Move Funds Onto an L2

A direct exchange withdrawal can be convenient, but the exchange's custody and operational risks still apply. A third-party bridge can avoid the standard withdrawal delay by using liquidity or a different mechanism, but it introduces its own risks.

Example: Receiving USDC on Base and Bridging to Ethereum

Suppose you receive 10,000 USDC on Base but want native USDC on Ethereum.

You can use a supported bridge. For example, Circle's Cross-Chain Transfer Protocol (CCTP) burns native USDC on the source network and mints native USDC on the destination network, subject to its protocol requirements. This differs from a lock-and-mint bridge because the source tokens are burned rather than held in a bridge contract.

The transfer may involve source-network gas, a bridge or service fee, and destination-network gas where applicable.

Practical Bridging Precautions

• Check the network before sending. The same address can exist on Ethereum and many L2s, but the balances on those networks are separate.
• Confirm the recipient supports the network. Sending to an exchange through an unsupported network can result in funds becoming inaccessible.
• Keep a little ETH on each network. Gas on one network cannot pay for a transaction on another.
• Start with a small test transfer when using an unfamiliar route.
• Use verified official links. Fake bridge websites are a common phishing risk.
• Understand the withdrawal delay before moving significant funds.

10. Why Are Bridges Risky?

Bridges connect different networks, which introduces additional technical and operational dependencies. Many bridges control or coordinate substantial pools of assets, making them attractive targets for attackers.

Historical incidents illustrate the potential scale of the risk:

These are approximate historical figures, and the incidents differed in their technical causes. None of these incidents involved a rollup's official bridge: Ronin served a sidechain, while Wormhole and Nomad were cross-chain messaging bridges.

Bridge vulnerabilities can involve compromised keys, flawed verification logic, smart contract bugs or weaknesses in the systems used to validate cross-chain messages.

A third-party bridge can be faster or more convenient, but users must evaluate its contracts, operators, liquidity arrangements and security model.

11. Are All Layer 2s Equally Trustworthy?

Not necessarily.

A rollup can inherit important security properties from Ethereum, but the practical level of protection depends on how its components are implemented and controlled.

Three issues are particularly important: sequencer centralisation, upgrade permissions and where the network publishes its data.

Sequencer Centralisation

Many L2s rely on a single sequencer or a limited set of operators.

A centralised sequencer can provide fast confirmations and efficient transaction ordering, but it can also create operational dependencies.

If the sequencer goes offline, transaction processing can stall. A sequencer might also delay or censor transactions.

Some rollups provide mechanisms for users to submit transactions through Ethereum or other fallback routes when the sequencer is unavailable. The availability, speed and exact conditions of these mechanisms differ by network.

Therefore, a quick user experience does not necessarily imply a highly decentralised transaction-processing system.

Upgrade Powers

The teams behind L2s often retain the ability to upgrade contracts or change parts of the system.

These powers can be essential for fixing bugs, improving performance and responding to emergencies. However, they can also create trust assumptions.

A security council or another privileged group might be able to authorise upgrades or intervene under certain conditions. Users should understand who controls these powers and whether they are constrained by delays, safeguards or exit mechanisms.

Data Availability Outside Ethereum

Not every network described as an L2 publishes its transaction data to Ethereum. Some use an external data-availability layer or a data-availability committee instead, such as Arbitrum Nova's AnyTrust committee or chains that publish data to EigenDA or Celestia. These designs can be cheaper, but if the external provider withholds the data, users may be unable to reconstruct the chain's state or prove their balances in order to exit. L2BEAT classifies such networks separately, often as validiums or optimiums, rather than as rollups.

Understanding L2BEAT Stages

L2BEAT publishes assessments of rollup architectures, including their trust assumptions and maturity.

Its stage framework provides a simplified way to understand how much a network still relies on operator control.

These are simplified descriptions. A stage is not a universal security score, and the details of a network's risks must still be examined.

12. Fragmentation: The Cost of Having Many L2s

Layer 2s make transactions cheaper, but they also divide activity across separate networks.

Suppose you hold USDC on Base and want to use a lending application that operates on Arbitrum. Your Base balance is not automatically available on Arbitrum. You must bridge or otherwise transfer the funds through a supported mechanism.

This creates fragmentation. It affects:

• Liquidity: Capital is distributed across different networks.
• Composability: Applications on separate networks cannot automatically interact as if they shared the same state.
• User experience: Users must manage network selection, transfers and sometimes multiple gas balances.
• Business operations: A business may need to support several networks to reach its customers and partners.

Ethereum applications benefit from composability when they operate on a shared execution environment. When applications are spread across multiple L2s, cross-network interactions become more complex.

Initiatives such as the Optimism Superchain aim to connect networks that use shared software and infrastructure. Broader interoperability efforts also seek to make moving assets and interacting across L2s easier.

However, interoperability does not automatically make all networks equivalent or remove the security assumptions of cross-chain transfers.

13. Does Ethereum Still Capture Value From Layer 2s?

This is an important economic question.

Rollups pay Ethereum for resources such as blob space and, depending on their design, other L1 execution or settlement operations. These payments help fund the infrastructure that supports rollup activity.

However, cheaper data publication can reduce the amount each L2 pays Ethereum per transaction.

Some argue that large L2 operators capture a significant share of the economic value generated by users while paying relatively little to Ethereum. Others argue that L2s expand the use of Ethereum's security and ecosystem, while ETH remains important for L1 fees, settlement and collateral.

14. How Should a Business Choose a Network?

For a business, the decision is not simply whether to use Ethereum. It is which network best fits the product, transaction volume, user base and security requirements.

Match the Network to the Use Case

These are starting points, not universal recommendations. A high-value transaction can still be executed on an L2 if its security model, regulatory requirements and operational arrangements are appropriate.

Why Transaction Volume Matters

Imagine a business issuing loyalty points.

If every point issuance costs 50 cents on Ethereum, issuing millions of low-value points may not be commercially viable. An L2 can reduce the transaction cost substantially, making the business model more practical.

Conversely, a high-value, infrequent transaction may justify the expense of executing directly on Ethereum, depending on the required settlement assurances.

Businesses Can Launch Their Own L2s

Because much L2 software is open source, businesses can launch their own networks using established software stacks.

Coinbase built Base using the OP Stack. Other businesses have explored application-specific chains, including networks based on Arbitrum's technology.

A branded network can give a business greater control over transaction fees, user experience and application-specific features. It also creates responsibilities: operating infrastructure, managing upgrades, maintaining security, supporting users and attracting enough activity to justify the effort.

Launching a separate network does not automatically create demand or liquidity. Smaller networks may struggle if they do not attract users, applications and integration partners.

Questions a Business Should Ask

Before choosing a network, consider:

1. Where are our users and partners already? Existing activity makes integrations and customer onboarding easier.
2. What is the transaction profile? Consider value, frequency, volume and fee sensitivity.
3. What security assumptions are acceptable? Review proof systems, upgrade powers, sequencer dependencies and the network's current risk assessment.
4. How will customers move funds in and out? Exchange support, bridge availability and withdrawal delays affect the user experience.
5. What happens during an outage? Establish operational fallback procedures.
6. Can the complexity be hidden? Smart wallets, account abstraction and integrated bridging can reduce the burden of network management on users.

15. Bringing Everything Together

Consider a user sending 20 USDC to a friend on an optimistic rollup. The complete lifecycle looks like this:

1. The wallet constructs and signs the transaction.
2. An RPC endpoint submits it to the L2 infrastructure.
3. The sequencer receives the transaction and establishes its order.
4. The L2 execution environment processes it and updates the token balances.
5. The transaction becomes part of the L2's block history.
6. The batch poster publishes transaction data to Ethereum.
7. A validator proposes an assertion about the resulting L2 state.
8. Eligible participants can challenge an invalid assertion under the rollup's dispute rules.
9. The assertion is confirmed or rejected according to the protocol.
10. The relevant Ethereum records reach consensus finality.
11. If the user later withdraws assets to Ethereum, the bridge applies the required withdrawal and finalisation process.

A ZK rollup follows a similar initial transaction lifecycle, but uses a cryptographic validity proof rather than relying on a fraud-proof challenge mechanism to establish computational correctness.

The Key Roles at a Glance

16. Conclusion

Layer 2s scale Ethereum by moving much of transaction execution into a separate environment while retaining an important connection to Ethereum for security, data availability and settlement.

The sequencer orders transactions, the execution environment determines their effects, and the rollup publishes transaction data and establishes the validity of its state transitions through its chosen verification mechanism.

Optimistic rollups rely on fraud-proof dispute mechanisms, while validity-proof rollups use cryptographic proofs. Blobs provide a more cost-efficient way to publish rollup data, but their contents have a finite protocol-guaranteed availability window. Bridges move assets between networks, while RPC providers connect wallets to the infrastructure needed to interact with them.

However, lower fees and faster transactions do not eliminate every trade-off. Users still need to consider sequencer centralisation, upgrade permissions, bridge security, data availability and fragmentation across networks.

For businesses, the appropriate network depends on transaction value and volume, where users and partners already operate, the required security assurances and how easily customers can move funds.

The most important distinction is that fast transaction execution, data publication, state verification and final settlement are separate milestones. Understanding those milestones makes it much easier to understand how Ethereum's scaling ecosystem works.

Key Takeaways