Since Ethereum followed the rollup-centric roadmap, the whole community believed that rollups would be the solution to Ethereum’s scalability problem. However, as of today, rollups are still inferior to some high performance L1s in terms of computing power.

This is probably due to the fact that rollup teams have to deal not only with execution, but also with various proof systems, bridges, and other things in their efforts to scale Ethereum.

But we have a type of rollup that has emerged to bring out the real power of the rollups: Gigagas rollups. In our previous series, we explored based rollups, booster rollups and native rollups. In this article, we will examine gigagas rollups by looking at what they are trying to solve and how they work.

What are performance challenges for rollups?

The primary performance issue for L2s has centered around the DA problem. However, with recent advancements in external DA solutions like @eigen_da and introduction of blobs, DA is no longer the bottleneck. Instead, we now encounter multiple new constraints.

One of the biggest reasons for the performance issue is that EVM implementations are usually single-threaded, meaning they utilize only one CPU core at a time, even though modern CPUs have multiple cores capable of handling different tasks simultaneously. As a result, the performance ceiling is set by the clock speed of a single core.

Transitioning to parallel execution is complex due to the necessary changes required in the EVM, state management, and transaction structure. Meanwhile, recent research by @VangelisAndr, showed that 64.85% of Ethereum transactions can be parallelized, imagine how many transactions can be parallelized on L2s to boost performance even further.

Another challenge arises when increasing the block gas limit on L2s to achieve higher throughput, as this might compromise the proof mechanisms. If fraud proofs require submitting entire blocks, they could conflict with Ethereum’s own block size limits. L2 block production differs from L1, offering opportunities for optimization and parallelization in the sequencer and execution client, moving away from traditional L1 concepts.

A significant challenge is achieving shared sequencing to enhance L2 interoperability while maintaining decentralization. However, this approach is still novel, and major rollups may be resistant to handing over sequencing control to third parties, as the benefits of increased composability are unclear and performance might suffer.

Ethereum employs modified Merkle-Patricia Tries (MPTs) to manage and verify its key-value data. The EVM doesn’t specify how state should be stored, thus enabling node clients to experiment with different solutions. Currently, implementations like LevelDB, PebbleDB, and MDBX are in use, yet they lack the inherent properties of authenticated key-value stores, such as cryptographic proofs of integrity. This increases trust assumptions, complicates fraud proofs, and adds overhead to verifying state changes, impacting efficiency and security.

For most rollups, performance is typically measured by transactions rather than gas. However, before diving into how gigagas rollups address the scalability issues, let’s explore why gas, rather than TPS, is a more meaningful metric and why we should pay attention to it.

Why do we measure gas?

Performance in rollups and Ethereum itself is often measured by Transactions Per Second (TPS), but a more precise metric might be ‘gas per second.’ This measure indicates the computational capacity of the network each second, with ‘gas’ representing the computational cost of executing operations like transactions or smart contracts.

TPS, however, overlooks the complexity and varying resource demands of different transactions and operations, making it an incomplete and often misleading indicator of network performance. A network may handle more transactions at lower computational cost, yet TPS would fail to reflect the true capacity of the system.

Adopting gas per second as a standard performance metric provides a clearer and more accurate picture of a blockchain’s throughput and efficiency. You can read an article by @paramonoww on why TPS is a silly metric.

Caring about gas matters because it reflects how much work the network can handle, providing a clearer picture of scalability and efficiency. Gas pricing influences network economics, affecting transaction fees and rewards, which in turn impacts user behavior and network security. Therefore, while transactions per second give a broad overview, gas per second offers a deeper insight into a blockchain’s true performance capabilities.

Now that we understand gas, what are gigagas and gigagas rollups specifically?

What are gigagas rollups?

Gigagas measures bandwidth in billions of gas units per second, providing a superior measurement of capacity over TPS. Gigagas rollups are essentially rollups designed to manage a bandwidth of 1 gigagas per second, processing 1 billion gas units per second. While the concept is straightforward, its implementation is challenging. Currently, even with centralized sequencing, no Ethereum rollup comes close to this benchmark, with the entire ecosystem only managing about 60 Mgas (60 million gas units) per second.

Source: rollup.wtf

Gigagas rollups would scale throughput by handling transactions in gigagas, allowing for vast transaction volumes or complex operations quickly. They would improve efficiency via innovations in data compression, proof generation, and main chain data posting, aiming for minimal overhead and maximum throughput.

Several teams are actively developing gigagas rollups. For instance, @Abundance_xyz is crafting an entire gigagas rollup stack, whereas @rise_chain is focusing on constructing gigagas rollup, introducing extensive modifications and optimizations to the EVM and beyond. Let’s delve into how gigagas rollups function, with a particular emphasis on RISE.

How do gigagas rollups work?

RISE is a L2 platform designed to tackle Ethereum’s rollup performance issues. Despite advancements, current L2 solutions can’t match Solana’s speed. RISE uses a parallel EVM, continuous execution, and a new state architecture on the RethSDK to increase throughput. RISE is aiming for bandwidth over 1 Gigagas per second.

RISE’s architecture includes a fully open source parallel EVM execution engine called pevm, which supports continuous execution through a block pipeline. For state access, RISE uses Versioned Merkle Trees to optimize performance and a custom database, RiseDB, tailored for EVM chain states.

The RISE stack is built on Reth. Regarding data availability, the architecture requires high bandwidth and is modular to accommodate various data availability solutions. RISE also employs based sequencing to decentralize block production. If you don’t know what based rollups are, you can take a look at the first article in this series, which examines its pros and cons.

In typical Layer 2 setups, only about 8% of block time is spent on execution due to a sequential process involving consensus, execution, and merklization. This becomes inefficient as consensus can take 40-80% and merklization up to 60% of the remaining time. RISE’s Continuous Block Pipeline (CBP) improves this with parallel execution, continuous transaction processing, and concurrent state root computation. This allows for nearly 100% utilization of block time for transaction execution, significantly improving efficiency over traditional methods.

Ethereum uses a two-layered state system with a Merkle Patricia Trie (MPT). The MPT ensures data integrity but leads to high read and write amplification due to its structure and the database’s LSM (Log-Structured-Merge) tree nature. This results in numerous I/O operations for state queries. MPT employs extension nodes to reduce redundancy, but challenges include inefficient SSD usage, significant compaction overhead, and CPU underutilization during I/O waits.

RISE counters these issues by using a Versioned Merkle Tree, which improves storage efficiency with versioned keys. It also employs the LETUS approach with delta encoding and log-structured files to reduce amplification effects. This results in better storage management and more efficient data retrieval.

Will every rollup become gigagas rollup?

There are many reasons that not every rollup will become a gigagas rollup. Not all applications require such high performance, and the complexity and cost associated with gigagas technology might not be justified for projects with lower transaction needs or simpler use cases.

Some rollups prioritize other aspects like ease of use, privacy, or specific sector applications over sheer throughput. There’s also the balance between scalability and decentralization, where some prefer maintaining a more decentralized structure rather than pushing for gigagas performance. Incremental scalability can be more practical, avoiding the need for extensive system changes.

Moving to gigagas levels might disrupt existing integrations or complicate user interactions without necessity. The choice to become a gigagas rollup depends heavily on resources, strategic goals, and overall positioning of the chain.

Conclusion

Gigagas rollups represent a significant leap forward in Ethereum’s scalability journey by introducing several enhancements to the rollup stack. With these new features, gigagas rollups address core bottlenecks such as single-threaded execution, merkleization management, and state storage inefficiencies that traditional L2 rollups currently face.

However, achieving gigagas-level performance requires a relatively complex and transformative architectural change. Additionally, it involves trade-offs, such as the balance between scalability and decentralization. As a result, it is not necessary for every rollup in the ecosystem to be a Gigagas rollup.

Apart from all of this, it seems that gigagas rollups will provide great opportunities for the Ethereum community to demonstrate the true power of Ethereum.

Throughout this rollup series, we’ve taken a deep dive into different types of Ethereum scaling: from based rollups in Part I to booster rollups in Part II, native rollups in Part III, and finally gigagas rollups in this final part. This article wraps up our exploration of rollups, but it is far from the end of the journey. Stay tuned for new series and in-depth articles on the latest innovations shaping Ethereum’s future!

Disclaimer:

1. This article is reprinted from [2077 Research]. All copyrights belong to the original author [2077 Research]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.