Rise In Logo



Ankit Raj

Head of Growth at Rise In

May 18, 2024

The Ultimate Layer-2 Guide: From L1s to L2s

Unlocking Blockchain's Potential: How Layer-2s are Revolutionizing Ethereum


Introduction

In this article, we will begin by exploring the architecture, key components, and limitations of Layer-1 blockchains. Following that, we will discuss what Layer-2 solutions are, including outdated L2 solutions like plasma and state channels, and focus on the more promising rollup solutions. We will also cover Ethereum’s shift towards a rollup-centric roadmap and the implications of EIP-4844. Furthermore, we will delve into the details of rollups and hybrid solutions, examining their architecture and transaction cycles. Finally, we will provide a summary of these topics in the conclusion section.

Layer-1 Blockchains

Layer-1 blockchains are where data availability, settlement, execution, and consensus mechanisms are in one blockchain. These blockchains operate independently without the need for another underlying network and are called monolithic blockchains because of their architecture.

Comparison Monolithic vs Modular Stack

Bitcoin and Ethereum can be given as examples of monolithic chains, where all components are in a single chain. Unlike monolithic chains, the components of modular chains can be customized. For instance, a modular chain can use a different chain for data availability and consensus, while using another chain for settlement. Due to the flexibility that specialization provides, there are many possibilities in which that stack can be arranged.

Understanding Key Components

  • Settlement: In a blockchain, settlement refers to the finalization of transactions, ensuring that once a transaction is completed, it is irreversible and recorded permanently on the blockchain.
  • Data Availability: Data availability in blockchain pertains to the ability of all network participants to access and verify the full set of transaction data, which is crucial for maintaining transparency and security.
  • Execution: Execution in the blockchain context means the process of carrying out the instructions of smart contracts or transactions according to the coded logic, resulting in state changes on the blockchain.
  • Consensus: Consensus in blockchain is the mechanism by which network participants agree on the validity of transactions, ensuring a single, consistent version of the blockchain is maintained and securing the network against fraudulent transactions.

Limitations of Layer-1s

The primary challenge facing Ethereum and other L1 chains is scalability. Scalability refers to the ability of a network to efficiently manage an increasing volume of traffic. In blockchains, transaction data are stored in blocks, the size and generation time of which can vary significantly between different blockchains. For Ethereum and some other L1 chains, the size of blocks is fixed, and the time it takes for blocks to be produced is relatively predictable. This sets a cap on the number of transactions that can be included in a single block, thereby limiting the networks’ transactions per second (TPS). For instance, Bitcoin can process up to 7 transactions per second.

Imagine transactions are people and blocks are buses in the blockchain. The bus can carry a limited number of people at once, for example, 10 people per bus. If the capacity of the bus is low and the bus is slow, people have to wait new bus or pay more for ticket prices to get on the bus.

Analogy Between Block and Buses

There is only one reality for the driver of the bus, to earn more money. Let the bus have a capacity of 10 people, the 11th person comes and says I want to get on the bus. The driver looks at the lowest ticket price and says that the cheapest person on this bus paid $10 and If you pay me $11, I will throw that guy away and pick you up. That’s why there is a competition between people who get on the first bus and do not want to wait. Could using a larger bus, thereby allowing more people to board, solve this problem? Although the answer may be yes in the short term, it is no in the long term. Here is why.

Full nodes are devices that maintain a complete record of all transactions that have occurred on the blockchain since its inception. Imagine that they are traffic cameras that record buses and people. When a new block is mined, full nodes download the block’s data and synchronize with other nodes across the network. Some projects attempt to increase the TPS and speed of transaction confirmations by increasing the size of blocks or accelerating the rate at which blocks are produced. However, these solutions may complicate the synchronization process for devices and lead to an exponential increase in the amount of data required to set up a full node. The substantial growth in data volume complicates the establishment of full nodes. Additionally, difficulties in node synchronization can cause nodes to fall out of the network. Increasing challenges in setting up full nodes could harm decentralization, as greater scalability will reduce decentralization and security. This dilemma is known as the “Blockchain Trilemma.”

Blockchain Trilemma

Currently, Ethereum and other L1 networks are characterized by low TPS, high transaction fees, and slow network confirmations, making them less user-friendly. To scale without compromising on decentralization and security, Ethereum and other L1 chains have turned to L2 solutions.

What is Layer-2?

Layer-2 or L2 is a scalability solution that executes transactions off-chain and publishes transaction data and If exists proof to the L1 network.

Types of Layer-2s

Ethereum and Bitcoin have specifically turned to Layer-2 solutions to increase scalability. The majority of these developments have progressed on Ethereum. We can categorize these solutions as plasma, state channels, rollups, and hybrid solutions.

Plasma

Plasma consists of chains referred to as child chains, which are smaller versions of the Ethereum mainnet. Initially, these chains were referred to as shadow chains, but later they took on the name child chains.

Plasma Architecture

When we consider the main network at the top, an infinite number of child chains can be added underneath the main network. In fact, we can add as many child chains under the child chains as we want. Child chains send the data of the transactions they perform on their own chains to the parent chain, and ultimately, the data reaches the Ethereum mainnet. All sent data is assumed correct due to the system’s structure. When each data group is sent to a parent chain, a 7-day challenge period begins. During this period, if someone believes the data is incorrect or faulty, they can publish a fraud-proof to contest the data. For this reason, there is a 7-day waiting period for withdrawals in plasma solutions.

As previously mentioned by Vitalik Buterin, the technology used by the plasma solution is very suitable for the unique structure of NFTs, offering high transactions per second and low transaction fees. However, like every solution, it has some disadvantages.


Initially, plasma was thought to help solve Ethereum’s scalability problem but later fell out of favor due to its inability to run EVM, only allowing simple transactions, mass exit problem, long withdrawal times, etc., and has been replaced by more current solutions.

State-Channels

State Channels are solutions that allow countless transactions off-chain using smart contracts and a deposit fund, where these numerous transactions cost only two on-chain transaction fees on the main network.

State-Channel Architecture

Initially, participants lock their funds in a multi-signature smart contract on the main network. This is used to denote the initial state. Subsequently, participants can perform countless cheap and fast transactions off-chain. The final state and balances are communicated to the main network through smart contracts. The state channel is closed once all participants have confirmed the final state.

Despite offering high transactions per second and low transaction fees, this solution has some disadvantages. These include the time and fund costs of creating a smart contract, the inability to run EVM, and the responsibility of monitoring the network. Participants also need to be predetermined, meaning it is not an open participation solution. The lack of open participation means that an external third party cannot join the channel without permission.

However, state channels are very suitable for payments, especially for subscriptions that require regular payments. The inability to run EVM and the lack of open participation prevent it from being a universal solution.

Ethereum’s Rollup-centric Roadmap

Initially, Ethereum planned to scale through Sharding, but in 2020, Vitalik proposed a rollup-centric roadmap, shifting Ethereum’s focus from Sharding to rollups. With this roadmap, Ethereum delegated the execution load to rollup projects. The Ethereum infrastructure started to be planned according to the needs of rollups. For example, EIP-4844, aka proto-danksharding, was a proposal developed in this context. Part of EIP-4844 was implemented with the Dencun update, introducing a new data field as blobs specifically for carrying rollup data.

The transaction fees for rollup projects dramatically decreased with the use of this new data field. This new data field is stored in the consensus layer and can not be readable by EVM. Remember our bus and people analogy. Rollups also trying to get on the bus like people. EIP-4844 says that let’s add a trailer to the buses and that trailer is specifically designed for rollups. So, rollups can get on the trailer of the bus without paying high fees and any competition between people and rollups. That’s why EIP-4844 reduced transaction fees for rollup projects.

Analogy of EIP-4844

Ethereum continues to provide design flexibility and infrastructure support to rollup projects. Transferring the scaling issue to them contributes to making rollups scalable, secure, and decentralized chains within Ethereum’s security.

Emerging Solution: Rollups

The inadequacies and disadvantages of plasma and state channels have led to the emergence of rollups, which are a more general solution. Rollups work by executing transactions on a rollup chain and then publishing the data and proofs of these transactions to the Ethereum mainnet. Remember our block-bus analogy. Unlike Layer-1s, rollup blocks are like metro instead of buses. So, rollups can carry more people cheaply and fast.

Analogy of rollups

There are two types of Rollups, zkRollups and optimistic rollups. Rollups consist of a series of smart contracts and an actor known as the sequencer. The most important smart contract for rollups is the bridge contract. To conduct transactions on L2, users must use the native bridge contract or third-party bridges. So, how does a transaction cycle occur in rollups?

Rollup Architecture

  • Bob transfers his assets to the Rollup using either the native bridge or a third-party bridge.
  • Bob signs a transaction on the Rollup.
  • The transactions made by Bob and other users are placed in a waiting area called the mempool.
  • The actor known as the sequencer collects these transactions, orders them, and places them into blocks to execute the transactions.
  • The sequencer sends the transaction data and If exists proof to the L1 network.
  • The Rollup verifier contract on L1 verifies the proof, and the transactions are finalized.

This cycle is applicable to both zkRollups and optimistic rollups. Both send transaction data and proofs to the L1 network and rely on Ethereum for consensus and settlement. Sending data to the L1 network means that the data is always available and accessible on L1, a concept known as data availability we learned before.

However, data does not necessarily have to be stored on L1. L2 projects may choose to store their data externally, either through a committee they establish or in a data availability layer. For instance, if an optimistic rollup stores its data in an external solution, it is no longer called a Rollup but an optimium. The same applies to zkRollups; if their data is stored in an external solution, they are classified as validiums.

Optimistic Rollups

Due to their architecture, optimistic rollups are simpler solutions compared to zkRollups. They have EVM equivalence and are easier to develop on. They operate in the same manner as classic rollups, with the type of proof used being the differentiating factor. Optimistic rollups utilize fraud-proofs.

Optimistic Rollup Transaction Cycle

In optimistic rollups, transactions are still collected by a sequencer, ordered, and executed in blocks. The data of these transactions is compressed and published to the main network. Due to the structure of optimistic rollups, the transaction data published to the main network is considered correct unless contested. There is a 7-day waiting period to challenge the data. Anyone believing the data to be incorrect can publish a fraud-proof by calculating the result of the transaction data within this period. For this reason, withdrawals from a native bridge to the main network can take up to 7 days. Examples of Optimistic Rollups include Arbitrum, Optimism, Base, and Blast.

zkRollups

zkRollups derive their name from zero-knowledge proofs, a method of proving the possession of knowledge without revealing the information itself. For example, in a conversation with a bank, you might be asked for certain letters of your mother’s maiden name. The bank can ask for different combinations of letters until they are convinced. Each time, your answers will be correct, but you won’t have disclosed the full information. Zero-knowledge proofs work similarly.

zkRollup Transaction Cycle

In zkRollups, an actor called the sequencer collects transactions, orders them, and executes them within blocks. At this moment, the transactions have been soft-confirmed. Then, an actor known as the prover uses zero-knowledge technology to mathematically prove the correctness of the transactions through validity proof. This proof is sent to the verifier contract on the main network for confirmation. Simultaneously, the compressed data of the transactions or the state difference is also sent to the main network. So, the transactions reach their final confirmation. Starknet, zkSync, Scroll and Linea are some of the zkRollups we know.

Hybrid Solutions: Validiums and Optimiums

As we talk before, rollups don’t have to use Ethereum for data availability. Rollup projects may choose to post their data to an external off-chain solution while relying on Ethereum for settlement and consensus.

Stack of Hybrid Solutions

If a zkRollup project chooses to post data to an external off-chain solution such as Celestia, Avail, or the Data Availability Committee (DAC), it’s no longer called zkRollup, it’s called validium. Here is how the validium transactions cycle occurs in the image below. Storing data off-chain reduces transaction fees while reaching high TPS.

Validium Transaction Cycle

Just like validium, If an optimistic rollup uses external off-chain for data storage, it is called optimium. Optimium solutions work just like optimistic rollups, with one difference. The transaction data is stored in an external off-chain solution, not on Ethereum. You can find how existing optimiums work in the image below.

Optimium Transaction Cycle

Conclusion

Scalability is one of the biggest problems of current L1 networks. Especially, L2 solutions developed on the Ethereum mainnet aim to solve the scalability issue while targeting low transaction fees, decentralization, and high throughput.


Today, EIP-4844 has dramatically reduced the transaction fees for rollups. So much so that the transaction fee for many rollup solutions supporting EIP-4844 is below 1 cent. Thus, data storage is no longer the bottleneck for rollup projects. The next step for rollups will be to decentralize the sequencer and improve the block production mechanism. Considering the importance Ethereum’s roadmap places on rollups, it is inevitable that rollups will become better and more efficient over time.

Stay in the know

Never miss updates on new programs and opportunities.

Rise In Logo

Rise together in web3!