The concept of the Ethereum platform was proposed in 2013, and its Mainnet was launched on 30 July 2015. During the platform’s early years, cryptocurrencies were used by a relatively small number of enthusiasts, blockchain activity remained low, and transaction fees were therefore generally insignificant.
As the number of users, decentralised applications, tokens, NFTs and DeFi protocols increased, Ethereum’s throughput limitations became more apparent. During periods of high demand, users faced rising fees and had to wait for transactions to be included in a block. Layer 2 scaling solutions became one of the principal responses to this problem.
In this article, we will discuss Layer 1 and Layer 2 solutions for scaling Ethereum. You will learn what L1 and L2 are, how scaling solutions are categorised, how rollups differ from sidechains and how alternative networks can be used to reduce transaction costs.
Key Takeaways
- Ethereum Layer 2 solutions process transactions outside the main network while using Ethereum for data publication, proof verification or final settlement.
- The principal L2 technologies for Ethereum are optimistic rollups and ZK-rollups. They combine multiple operations into batches, reducing the average cost of each transaction.
- Sidechains, including Polygon PoS and Gnosis Chain, operate under their own consensus rules and do not inherit Ethereum’s security to the same extent as rollups.
- Not all Layer 2 networks are EVM-compatible, and the security of a particular solution depends on data availability, proofs, bridges, the sequencer, administrative keys and the maturity of the protocol.
- Ethereum upgrades, including Dencun and PeerDAS, do not replace L2 solutions but provide rollups with cheaper and more scalable data-publication capacity.
The Ethereum Scalability Problem
Ethereum has existed since 2015 and processes significantly more types of operations than simple monetary transfers, including smart-contract execution, token swaps, NFT issuance, lending and other activities. Frequently cited figures such as 15 transactions per second for Ethereum and 7 transactions per second for Bitcoin are only approximate: actual throughput depends on transaction complexity, the gas limit and network conditions. Direct comparisons with traditional payment systems are also conditional because blockchains and centralised processing networks use different security and settlement-finality models.
The number of operations that can be included in an Ethereum block is limited not by a fixed transaction count but by the available amount of gas. Since Ethereum moved to Proof-of-Stake, blocks have been proposed in 12-second slots, although an individual slot may theoretically pass without a block. Simply increasing block capacity raises the requirements placed on nodes, so excessive L1 expansion could negatively affect decentralisation.
Block Gas Limit
The amount of computation available in a single block is determined by the block gas limit. Gas is a unit used to measure the computational resources required to perform an operation. A simple ETH transfer requires less gas than interacting with a complex smart contract.
Each transaction consumes a certain amount of gas. Following the implementation of EIP-1559, the transaction fee consists of the base fee, which is calculated by the protocol and burned, and the priority fee, which is paid to the validator. Transactions wait in the mempool to be included in a block, and their processing order depends on the effective reward offered to the validator, the available gas, local block-building policies and other factors.
If one user submits a transaction before another, this does not guarantee that it will be included in a block first. An operation offering a more attractive priority fee or more suitable parameters may be processed sooner. At the same time, an insufficient maximum fee may result in a lengthy delay, particularly if the network’s base fee is rising.
After the London hard fork, the target gas usage was 15 million units, while the maximum size of an individual block could temporarily reach 30 million. The limit was subsequently changed through validator voting, so its current value should be checked using live network data. The minimum gas consumption for a standard ETH transfer between two externally owned accounts is 21,000 units. For the historical 30 million limit, the theoretical calculation was as follows:
30,000,000 / 21,000 ≈ 1,428 transactions
This result is only a theoretical maximum for a block consisting entirely of simple ETH transfers. An ERC-20 token transfer may require approximately 45,000-100,000 gas or more, while interaction with a DeFi protocol may consume hundreds of thousands of units. The precise amount depends on the contract code, storage state and functions being executed. For a hypothetical operation costing 210,000 gas, the calculation with a 30 million limit would be as follows:
30,000,000 / 210,000 ≈ 142 transactions
To have a transaction included in a block without a lengthy delay, appropriate maximum-fee and priority-fee parameters must be set. Most modern wallets calculate them automatically. Fees should not be set excessively high without good reason: EIP-1559 returns the unused difference between the maximum fee and the fee actually paid, but an unnecessarily high priority fee may be spent in full.
Why Ethereum Cannot Be Scaled Simply by Increasing Block Size
Increasing the number of validators does not, by itself, increase Ethereum’s throughput: every full node must be able to verify the network state and the required data. Unlimited growth in block size would require more powerful hardware and faster internet connections, potentially reducing the number of independent node operators. Ethereum therefore develops L1 scaling alongside Layer 2 solutions while preserving the ability of participants to verify the network independently.
Ethereum Upgrades and Network Scaling
Ethereum’s early roadmap considered dividing the network into 64 execution shards that would process transactions in parallel. This model was later abandoned in favour of a rollup-centric approach. The Merge moved Ethereum from Proof-of-Work to Proof-of-Stake in September 2022 but did not increase throughput through execution shards. The Dencun upgrade in March 2024 implemented EIP-4844 and introduced specialised data objects known as blobs, which were designed to reduce the cost of publishing rollup data.
The collection of changes was previously often referred to as Ethereum 2.0, but this term created the misleading impression that a separate network or new coin would be launched. The terms execution layer, consensus layer and Ethereum roadmap are now generally used instead. Subsequent upgrades, including PeerDAS, continue to develop data availability for L2 networks and rollup-centric scaling.
The upgraded Ethereum is a continuation of the same network rather than a separate blockchain. ETH was not transferred or converted into a new coin at a 1:1 ratio: existing balances and smart contracts remained within the network’s shared history. Offers to exchange “old ETH” for “ETH 2.0” are a common sign of fraud.
Layer 2 solutions remain a central part of Ethereum scaling. L1 changes are designed to allow rollups to publish more data at a lower cost. However, fees within a particular L2 network depend on its activity, data-publication mechanism, sequencer operation and the cost of interacting with Ethereum.
What Is the Difference Between L1 and L2?
Let us consider the difference between L1 and L2 using Bitcoin as an example. The Lightning Network is a Layer 2 solution for Bitcoin that uses payment channels between participants. Most operations are carried out outside the main chain, while the Bitcoin blockchain is used to open and close channels and resolve disputes. We discussed this in greater detail in the article “Lightning Network: A Bitcoin Scaling Solution”.
In this example, Bitcoin is the Layer 1 network. An L1 solution changes the base protocol itself or its rules. One example is Taproot, which was activated on the Bitcoin Mainnet in November 2021.
For Ethereum, an example of an L1 upgrade is London with EIP-1559, which changed the fee market and introduced the burning of the base fee. The Merge was also a Layer 1 upgrade because it changed the consensus mechanism. Dencun and PeerDAS develop data-availability infrastructure for rollups. The execution shards previously mentioned in the roadmap were not introduced.
The Lightning Network is an L2 because it operates on top of Bitcoin. Similarly, Ethereum Layer 2 processes operations outside the main execution environment and then uses Ethereum for settlement, proofs and data publication. However, a sidechain connected to Ethereum by a bridge is not necessarily an L2: it may have its own independent consensus and a separate security model.
Why Do Blockchains Need Layer 2 Solutions and Which Problems Do They Solve?
Layer 2 solutions perform several useful functions:
Network scaling. L2 processes a large number of operations outside Ethereum’s main execution environment, combines them and publishes the required data or proofs to L1. This increases the ecosystem’s total throughput, although not by a fixed multiple: the outcome depends on the particular technology, transaction type and amount of data.
Faster processing and lower fees. Users generally receive preliminary confirmation of an L2 transaction within a few seconds, while the costs of interacting with Ethereum are distributed across multiple operations in a batch. L2 fees are normally lower, but they are not zero and may increase when the network is congested or the cost of L1 data rises.
Reduced load on the main network. Instead of publishing every user operation directly to Ethereum, a rollup submits a data batch and a state update. This allows the limited space available on L1 to be used more efficiently. However, L2 activity does not necessarily reduce Ethereum’s base fee to a minimum because rollups themselves compete for blob space and other network resources.
Execution environments for different purposes. Many L2 networks are EVM-compatible or EVM-equivalent, allowing existing smart contracts to be migrated with only minor changes. Other solutions use their own virtual machines, programming languages and account models. Communication between networks is provided through bridges and messaging protocols, but interoperability does not arise automatically and creates additional risks.
Ecosystem diversity and resilience. Multiple networks allow applications to choose different cost, performance, privacy and functionality parameters. However, the appearance of additional blockchains does not automatically make the ecosystem more decentralised or secure. An L2 failure, bridge vulnerability, compromise of administrative keys or sequencer outage may affect users of a particular network even if Ethereum continues operating normally.
Examples of Ethereum Layer 2 Solutions
L2 networks have become widely adopted as the principal method of scaling Ethereum. They reduce the cost of user operations and increase throughput while maintaining varying degrees of connection to Ethereum’s security. Before using one, it is important to distinguish rollups from sidechains, validium networks and other compatible blockchains.
Polygon: PoS Sidechain and ZK Technologies
The Polygon ecosystem includes several technologies. Polygon PoS is a popular EVM-compatible sidechain with its own validator set. It is connected to Ethereum through bridges but is not a conventional rollup and does not inherit Ethereum’s security to the same extent. The Polygon ecosystem has also developed ZK solutions and infrastructure for creating compatible chains.
TVL figures, the number of applications and Polygon’s position among blockchain networks change continuously. Fixed rankings and amounts of locked funds therefore become outdated quickly. Before using the network, users should check its current activity, bridge security, network status and data from analytics platforms.
POL is the native token used to pay gas fees and for staking on Polygon PoS. It replaced MATIC as the network’s system token in September 2024. The former MATIC designation may still appear in interfaces, historical materials and certain contracts, but new instructions should take the migration to POL into account.
Immutable X
Immutable X was a specialised solution for NFTs and gaming assets created jointly with StarkWare using StarkEx. The platform offered fast operations and the ability to subsidise fees for end users, although depositing and withdrawing assets through Ethereum could still require gas fees.
In early 2026, Immutable X was merged with Immutable Chain. New transaction submission to the former sequencer was stopped, and the Immutable X interfaces and SDKs are being deprecated. Users holding legacy NFTs and tokens must follow the official instructions issued by the relevant project to migrate their assets.
Most modern L2 solutions use rollups — protocols that execute operations outside Ethereum, combine them into batches and publish the data and results required to verify the state on the main network. Rollups are divided into two principal categories:
- Optimistic rollups — published state updates are considered correct unless someone submits proof of an error during the specified challenge period.
- ZK-rollups, or validity rollups — a cryptographic proof that the computation was performed correctly is published together with the state update and verified by an Ethereum smart contract.
Gnosis Chain, Formerly xDai
Gnosis Chain, formerly known as xDai Chain, is an independent EVM-compatible sidechain rather than an Ethereum rollup. It uses its own Proof-of-Stake consensus and validator set. xDAI is used as a stable token for gas payments, while consensus security is associated with GNO. The presence of a bridge to Ethereum does not mean that the network inherits all the security guarantees of L1.
Optimistic Rollup Solutions
Optimistic rollups provide users with rapid preliminary confirmation of operations, but final withdrawal through a standard bridge to Ethereum may take several days because of the challenge period. Third-party bridges and liquidity providers can accelerate withdrawals, but their use creates additional counterparty and smart-contract risks.
The security of an optimistic rollup should not be based solely on trust in a group of validators. A proper model provides for publishing data to Ethereum and allows an invalid state to be challenged using a fault proof. However, a particular network may still have a centralised sequencer, administrative keys, a security council and other trust assumptions that must be considered separately.
Arbitrum
Arbitrum is an ecosystem of Ethereum scaling solutions. Arbitrum One is an optimistic rollup operating on the Nitro technology stack. The network is compatible with Ethereum tools and allows smart contracts to run with lower fees. Its architecture includes a sequencer, execution nodes, bridge contracts and a system for verifying disputed states.
- Nitro — an Ethereum-compatible execution and proof technology stack.
- Bridge and Inbox contracts — contracts used to transfer messages and assets between Ethereum and Arbitrum.
- Sequencer and validators — components responsible for ordering operations, publishing batches and verifying the state.
Arbitrum One combines transactions into batches and publishes data to Ethereum, while the validity of the state may be challenged using a fault proof. The modern BoLD protocol allows participants to take part in verification without prior permission and limits the duration of disputes. Standard asset withdrawals to Ethereum are still subject to a challenge period, which is generally around seven days.
Optimism
OP Mainnet is an optimistic rollup built on the OP Stack. This open technology stack is also used by other networks. OP Mainnet publishes data and state updates to Ethereum, and the validity of proposals may be challenged through permissionless fault proofs.
Earlier versions of Arbitrum and Optimism used different dispute-resolution schemes, which were frequently compared as multi-round and single-step proofs. Both architectures have changed substantially following subsequent upgrades, so this simplified comparison no longer reflects the current state of the protocols. When choosing a network, it is more important to assess its current proof system, administrative keys, sequencer, forced-transaction inclusion capabilities and withdrawal rules.
The market capitalisation of tokens, TVL and activity on Arbitrum and Optimism change continuously. These indicators are not direct measures of L2 security and should be checked using current data. For a technical assessment, it is more useful to examine proof-system maturity, upgrade risks and the degree of decentralisation of the network’s components.
Boba Network
Boba Network is an EVM-compatible optimistic rollup built on top of Ethereum. The network is designed to reduce fees and move part of the computation away from L1. Its architecture includes rollup components, a sequencer, bridges and mechanisms for publishing data to Ethereum.
Hybrid Compute technology allows smart contracts to initiate certain computations in external infrastructure and receive the results. This approach expands application capabilities, but developers must consider trust in external services, data availability and the accuracy of the information received.
Fuel Network
Fuel is developing a modular Ethereum L2 and the FuelVM execution environment. Fuel Ignition uses Ethereum for settlement and data availability, while its transaction model is based on UTXOs and supports parallel execution. Actual throughput depends on the type of operation, network parameters, data publication and demand, so a fixed claim about a particular number of transactions per second should not be treated as a guarantee.
Cartesi
Cartesi provides an optimistic-rollup framework for creating applications with verifiable computation outside the main network. The Cartesi Machine is based on the RISC-V architecture and can run Linux and familiar software libraries in a deterministic environment. This makes it possible to execute more complex logic than is normally placed directly in the EVM. The CTSI token is used within the project’s ecosystem, but its presence does not replace an assessment of the security of a particular application.
ZK-Rollup Solutions
ZK-rollups execute transactions outside Ethereum and generate a validity proof confirming that the state update is correct. Once the proof has been verified by an L1 contract, the state receives Ethereum finality. A standard withdrawal from a ZK-rollup does not require the seven-day challenge period associated with optimistic rollups, but generating the proof, publishing the batch and processing the bridge may still take some time.
ZK technologies allow data to be compressed: for example, an account index may be used within a batch instead of a complete address. However, ZK-rollups are not protected from every type of attack. Errors may occur in proof systems, contracts, sequencers, bridges, upgrade mechanisms and user applications. EVM compatibility also varies: some solutions support conventional Ethereum bytecode or programming languages, while others use their own virtual machines.
We will not examine every validity-proof solution in detail but will briefly consider several examples:
- Loopring — a specialised ZK-rollup for trading, payments and liquidity provision. Its functionality is designed for specific financial operations rather than arbitrary EVM applications.
- StarkWare develops STARK proof technologies. Starknet is an independent permissionless validity rollup for general-purpose applications, while StarkEx has been used as infrastructure for specialised projects and services.
- ZKsync Era — an Ethereum L2 based on validity proofs and the ZK Stack technology stack. The sequencer orders operations, the prover generates a proof, and an Ethereum smart contract verifies it and records the state.
- Aztec — a privacy-first zkRollup designed for applications with confidential state and programmable privacy. During the early stages of the Mainnet, users and developers should pay particular attention to protocol maturity and the project’s warnings about potential errors.
- Polygon Hermez became part of Polygon’s ZK technology development and is not a project independent of the Polygon ecosystem. Its technology contributed to the development of Polygon zkEVM and other components. Polygon PoS remains a separate sidechain and does not use the same security model as a ZK-rollup.
- zkTube was positioned as a ZK solution for scaling Ethereum. The project is not among the most mature or widely used modern rollups, so users should verify the current state of development, contract audits, source-code availability, liquidity and independent security data before interacting with it.
How to Use Layer 2 Solutions to Save on Transaction Fees
First, you will need a cryptocurrency wallet that supports the selected network, such as Arbitrum One, OP Mainnet, ZKsync Era or Polygon PoS. It is important to remember that Polygon PoS is a sidechain rather than a conventional L2 rollup. Trustee Wallet supports Polygon; we will use it as an example to examine the general process of using an alternative network.
- Install the application and create a wallet.
When creating a non-custodial wallet, the seed phrase must be stored securely offline. If a user loses the seed phrase and simultaneously loses access to the device or forgets the password, it will be impossible to restore control of the funds. The seed phrase must not be entered on websites, shared with customer support or stored in a publicly accessible cloud document.
To add Polygon, tap “Add Asset”, find the Polygon network and select POL or the required token on that network. Before receiving the asset, check that the sending exchange or wallet is using Polygon PoS rather than Ethereum or another network containing a similar token.
- Fund the wallet with a token used to pay network fees.
A small amount of POL, the network’s native gas token, is required to conduct operations on Polygon PoS. MATIC was used previously and has been replaced by POL. ETH is required to pay gas fees on Ethereum and many rollups, including Arbitrum and OP Mainnet. Holding a token with the same name on a different network does not automatically allow it to be used to pay fees.
The balance can be funded through a transfer from another wallet, a withdrawal from an exchange using the correct network, or purchase and exchange functions available in the application. Before confirming the operation, check the address, network, token, fee and minimum withdrawal amount. For first-time use, a small test transfer is recommended.
- Select a decentralised application.
Once the balance has been funded, applications supporting the selected network can be used. Their current list is best obtained from the ecosystem’s official directory. The availability of individual services, including ChainSwap, which was mentioned in an earlier version of the article, may change. Before connecting a wallet, check the domain, contract audits, the project’s reputation and the permissions requested by the application.
- Connect the wallet to the dApp.
Click “Connect Wallet” on the application’s official website and select WalletConnect if this method is supported. WalletConnect creates an encrypted session between the application and the mobile wallet. A QR-code connection is not completely air-gapped because the devices communicate over the internet. It also does not eliminate phishing or malicious signature requests, so every operation must be checked in the wallet.
Scan the QR code using the WalletConnect function in the application and make sure that the displayed domain corresponds to the selected service.
Once connected, you can perform the operations available through the application: swap tokens, provide liquidity, use staking, purchase NFTs or interact with a bridge. When assets are transferred between Ethereum and another network, the user receives a representation of the asset on the destination network. Use an official or thoroughly verified bridge and consider fees, finality periods and smart-contract risks.
The Future of Ethereum Layer 2 Scaling Solutions
The popularity of Ethereum Layer 2 solutions continues to grow. L2 networks have become the principal environment for many payments, trading operations, DeFi applications, games and social services that require lower fees and rapid user confirmation.
The future of Ethereum scaling is directly linked to the development of rollups. Dencun introduced blobs for cheaper data publication, while subsequent upgrades are expanding their availability and capacity. Full Danksharding is regarded as a long-term technology capable of providing data to multiple rollups and supporting the combined processing of a very large number of transactions.
Increasing Ethereum’s performance should not significantly reduce demand for L2 networks. On the contrary, the modern L1 roadmap is designed to expand Layer 2 capabilities. As data costs decline, rollups can process more operations, while competition between them may improve fees and the user experience. However, users must continue to consider liquidity fragmentation, bridge risks, sequencer centralisation and the maturity of each network.
Frequently Asked Questions About Ethereum Layer 2
How Does Ethereum Layer 2 Differ from a Sidechain?
An L2 rollup uses Ethereum for data publication, proof verification and final settlement, so a significant part of its security is connected to L1. A sidechain has its own consensus and validators and is connected to Ethereum through a bridge. Polygon PoS and Gnosis Chain are sidechains, while Arbitrum One and OP Mainnet are rollups.
What Types of Ethereum Rollups Are There?
The principal categories are optimistic rollups and ZK-rollups. Optimistic rollups provide a period in which a published state can be challenged, while ZK-rollups confirm the state using a cryptographic validity proof. Arbitrum One and OP Mainnet belong to the first category, while Starknet, ZKsync Era and other validity rollups belong to the second.
Why Can a Withdrawal from an Optimistic Rollup Take Seven Days?
The standard bridge must wait until the challenge period has ended to ensure that the published state has not been shown to be invalid. The L2 transaction itself is normally confirmed much faster. Fast bridges may provide liquidity earlier, but they introduce the risks of a third-party protocol or counterparty.
Are Layer 2 Networks Secure?
The level of security varies. Users should assess the proof system, data availability, administrative keys, sequencer, bridge contracts, forced-withdrawal mechanisms and network maturity. Even a rollup that uses Ethereum may temporarily have additional trust assumptions.
How Can ETH or Tokens Be Transferred to L2 Safely?
Use an official bridge or a verified service, confirm the correct network and contract address, examine the fees and withdrawal period, and make the first transfer using a small amount. Never enter a seed phrase on a bridge website, and carefully check signature requests and token-spending permissions.
