Scalability is the major issue when it comes to Ethereum & other EVM-based blockchain networks. These networks have limited processing capacity, which results in high transaction fees & long transaction processing time. To overcome this problem, Layer 2 scaling solutions, such as Rollups, Plasma, and Sidechains, have emerged. In this article, we will focus on how Layer 2 solutions are scaling Ethereum & other EVM-based networks, specifically via optimistic rollups.

What is Layer 2 in Blockchain?

Layer 2 refers to a set of off-chain solutions that are built on top of Layer 1 blockchain to address scalability issues. This works by creating a secondary framework that does not require the Layer 1 chain.

Layer 2 can improve on two fronts:

1. Transaction Speed (the amount of time it takes to complete a transaction), and,

2. Transaction Throughput (the number of transactions that a network can process in a given amount of time).

When the Layer 1 network gets overloaded, Layer 2 can pick up the load to improve transaction time and lower transaction fees.

There are various other ways through which LAYER 2 can solve the scalability issues and one such way is via Rollups

LAYER 2 Rollups

Layer 2 (Rollup) helps Ethereum handle more transactions efficiently. It works by processing transactions separately from the main Ethereum network (L1). However, Rollups still rely on the main Ethereum network to validate and keep a permanent record of the transactions.

The main idea behind rollups is to free up space on Ethereum's main network (L1) while making sure that L1 can verify everything is accurate and correct. This means we can handle more transactions and keep gas fees low, all while keeping Ethereum secure.

Now, Rollups are divided into two broad categories- optimistic rollups and zk-rollups.

Let's understand the difference between the two below-

Optimistic Rollups vs ZK-Rollups

Let's talk about Optimistic Rollups in detail-

What are Optimistic Rollups?

Optimistic Rollup is an off-chain scaling solution built on top of the Ethereum network. It works by grouping off-chain transactions into big bundles before sending them to Ethereum Mainnet. This way, optimistic rollups can spread out the fixed costs over many transactions, which means lower gas fees for users.

It does not require building an entirely new security infrastructure from the base. Instead of creating its own security rules, Optimism takes a different route. It extends an invitation to Ethereum, saying, "Hey, Ethereum, you're exceptionally good at keeping things secure. Can we borrow your security protocols for our transactions?"

Hence, Optimistic rollups rely on Ethereum's tried-and-true security measures to ensure the safety and integrity of its transactions. Once a rollup batch is sent to Ethereum Mainnet, there's a time period called the "challenge period." During this time, anyone can question a rollup transaction by providing evidence of a problem.

If the evidence shows there's a problem, the rollup system will redo the transaction and fix the issue. Also, the person in charge (the sequencer) who made the mistake will face consequences. If no one challenges the batch after the time period, it means transactions are accurately executed, and Ethereum accepts it as a valid transaction.

Users have often complained about optimistic rollups- that it takes 7 days to execute transactions on the Ethereum main network (L1). However, this one-week wait only affects certain types of transactions, specifically when you want to move your digital assets from the Rollup back to Ethereum.

But for regular transactions within the rollup system itself, things happen almost instantly. This quick confirmation is possible due to the sequencer- responsible for order and execution. It does not take advantage of making a profit via user transactions.

Let's dig in deeper and look at the architecture of optimistic rollups -

Architecture of Optimistic Rollups

Optimistic Rollups are a layer 2 scaling solution for blockchain networks designed to improve scalability and reduce transaction costs. In this system, the "sequencer" plays a crucial role, much like a librarian. Here's how it all comes together:

Transaction Handling (Checking Out Books)

Users submit transactions to the Optimistic Rollup network, which are similar to borrowers in a library checking out books. The sequencer, acting as the librarian, receives these transaction requests. Just as a librarian checks if books are available and borrowing forms are correctly filled out, the sequencer verifies the validity of these transactions. It ensures they adhere to the rules of the blockchain.

Block Creation(Creating Borrower's List)

With valid transactions in hand, the sequencer compiles them into a new block into what we call L2 blocks, akin to creating a borrowing list. To maintain the integrity of this block, the sequencer calculates a unique code (cryptographic hash). It adds a timestamp to it, much like stamping the borrowing list with the library's seal.

Sequencer Batches (Grouping Borrowers):

To efficiently manage the increasing number of transactions, the sequencer groups them into batches, just as the librarian organizes borrowing lists from multiple people into batches. Batching transactions streamlines the process and reduces the computational load on the network, ensuring scalability.

Data Delivery (Sharing the Borrowing Lists):

Now, the sequencer broadcasts the completed block (borrowing list) to the Optimistic Rollup network. The batcher's mission is to send these sequencer batches to a data availability provider, such as Ethereum Calldata. In the library analogy, this is similar to the librarian announcing over the intercom that a new batch of borrowing lists is ready for review (data delivery).

In the Optimistic Rollup network, there are other participants known as "validators" or "challengers." Validators are like diligent library staff who double-check the borrowing lists.

They verify the correctness of the transactions within the block by examining the cryptographic proofs provided by the sequencer, just as library staff ensure that the books borrowed match the list and that the library seal is intact (validation).

If a validator detects any fraudulent or invalid transactions, they can raise a challenge, much like a library staff member questioning a borrowing list. Once the block is deemed valid and any disputes are resolved, it becomes an integral part of the Optimistic Rollup blockchain's history.

Similarly, in the library, once borrowing lists are validated and disputes, if any, are resolved, they become part of the official library record. The borrowed books are considered checked out and added to the library's ledger.

In the context of Optimistic Rollup, where validators ensure the integrity of transactions and maintain the blockchain's historical record, it's crucial to recognize the importance between an L2 block and a sequencer batch.

L2 Block:

Imagine an L2 block as a complete chapter in a book. It's a self-contained entity that comprises a set of transactions. Moreover, it includes a reference, known as the L2 state root, which summarizes the state of affairs after those transactions have been executed. It's the chapter with a title and a summary.

Sequencer Batch:

In contrast, a sequencer batch is akin to an annotated timeline of events. It precisely indicates when specific transactions occurred within an L2 block, much like time stamping each event in chronological order. It's the detailed record of events within the chapter.

Why does this distinction matter? Well, even if there's an unexpected hiccup in how the sequencer processes the state within an L2 block, fear not! The sequencer batch remains steadfast, storing the record of individual transactions.

Rest assured; stringent validation procedures are in place for both sequencer batches and individual transactions within them to ensure correctness. Any anomaly, such as incorrect encoding or faulty signatures, is promptly identified and discarded.

In rare events, the sequencer commits a substantial error and provides an inaccurate output root. A failsafe mechanism stands ready to challenge & rectify the mistake, safeguarding the accuracy and integrity of data.

While validators and the distinction between L2 blocks and sequencer batches play a central role in Optimistic Rollup, another pivotal component in this ecosystem is the batcher.

Streamlined Data Propagation: The Role of the Batcher

The batcher, a critical component in this ecosystem, handles the submission of batcher transactions to a data availability provider. These transactions contain one or multiple channel frames, which are chunks of data belonging to a channel.

But what exactly is a channel? A channel is a carefully curated sequence of sequencer batches spanning multiple L2 blocks compressed together. The rationale behind grouping multiple batches into a single channel is to optimize data storage and reduce data availability costs. It's akin to bundling chapters from various books into a single, more efficient volume.

Now, considering that channels can sometimes become voluminous, much like lengthy chapters in a book, there's a need to break them down into more manageable parts known as "channel frames." These channel frames serve as smaller subsections, akin to chapters within a chapter. They are the finer segments of the overarching story.

The beauty of this design lies in its flexibility. It empowers us to aggregate batches into channels and distribute channels across more batch transactions in the most efficient manner possible. This flexibility ensures that we make the most of our data resources, even allowing us to cleverly pack a smaller fragment from one chapter with larger segments from another.

Furthermore, in the future, this design allows multiple 'signers' with private keys to work together and submit several transactions or data channels simultaneously. This teamwork becomes essential when the order of transactions and their interconnections matter.

One of the most noteworthy aspects of this approach is that we don't need to predetermine the eventual size of a channel. It's akin to starting to read a book without having a clue about the total number of chapters it holds.

By segmenting channels across multiple data transactions, we gain the ability to handle more extensive datasets than the traditional data-availability layer might conventionally support. It's like having a book with chapters that are too numerous to fit in a single volume, so we cleverly distribute them across multiple volumes for ease of access.

Please keep in mind that the process we've explained is specifically for regular L2-to-L2 transactions. However, it's important to note that there are different steps for two other types of transactions: when you're moving assets from Ethereum to the rollup, called Deposit(L1-to-L2) and when you're moving assets from the rollup back to Ethereum, called Withdrawal (L2-to-L1).

Deposit:

Deposited transactions, often called deposits, are transactions that start on Ethereum's main network (L1) and then move to the Layer 2 network (L2) for execution. These transactions have some important differences compared to regular ones:

Origin from Layer 1 Blocks:

Deposited transactions emerge from Layer 1 blocks, and they are an integral part of the protocol. They carry the legacy of Ethereum's main network.

No Signature Validation:

Unlike standard transactions, deposited transactions don't require signature validation.

L2 Gas Payment on L1:

Deposited transactions cover their L2 transaction costs right from Ethereum's main network (L1). These costs are non-refundable, ensuring a seamless financial transition.

Withdrawal:

Withdrawals are like transactions that start in one place (L2) and finish in another (L1). They can be used by an L2 account to do things like interact with an L1 contract or move ETH from L2 to L1.

Here's a closer look at the different stages of withdrawals:

Withdrawal Initiation:

To kickstart the withdrawal process, an L2 transaction is sent to the Withdrawals pre-deploy on L2.

Withdrawal Verification:

Now, on the L1 side of things, we have an L1 transaction that serves as proof, confirming that the withdrawal is legitimate. This proof shows that the withdrawal has been included in a Merkle tree, with its root accessible on L1.

Withdrawal Finalization:

The final step happens back on L1. An L1 transaction takes charge of finalizing and transmitting the withdrawal, ensuring that the fault challenge period has passed since the withdrawal proof was established.

What makes withdrawals unique is that unlike deposits, which have a dedicated transaction type in the execution engine client, withdrawals rely on smart contracts on L1 for their completion. It's a journey that spans both Layer 2 and Layer 1, offering versatility and functionality.

We'll explore Deposits and Withdrawals further in upcoming articles, offering in-depth explanations.

Reference

https://community.optimism.io/docs/protocol/2-rollup-protocol