Analysis: Why L2 Gas Fees Increased Instead of Decreasing?
Source: Monad Co-founder Keone Hon’s X Platform
Translated and compiled by Odaily
Summary:
In a recent in-depth article released by Keone Hon, co-founder of Monad, he discussed the performance of Rollups after the London upgrade and explained why the gas fees for some Layer2 (Base) transactions remain high. Additionally, Keone outlined the bottlenecks and potential improvements of Rollups.
Article Content:
Recently, there have been discussions about the execution bottlenecks and gas limitations of Rollups, not only in Layer1 but also in Layer2. In this article, I will discuss these bottlenecks.
With the introduction of the Blob data structure (EIP-4844) in the London upgrade, the data availability (DA) of Ethereum has been significantly improved. Layer2 data synchronization transactions no longer need to compete in the same fee market as regular Layer1 transactions.
Currently, the Blob capacity is approximately 3 125kb Blobs per block (12 seconds), which is about 31.25kb per second. Considering that a single transaction is about 100 bytes, this means that the shared TPS of all Rollups is approximately 300.
Of course, there are some important points to note here.
First, if Rollups adopt better transaction data compression techniques, the TPS can be increased.
Second, theoretically, Rollups can continue to use calldata synchronization in addition to Blob synchronization (the old scheme before the London upgrade), although this will introduce additional complexity.
Third, different ZK-rollups have different ways of releasing states (especially zkSync Era and Starknet), so the calculation methods and results may vary for these Rollups.
Recently, there has been significant attention on the high gas fees on the Base network due to its gas cost surge, with ordinary transactions costing several dollars on the network.
Why did the gas fees on the Base network decrease temporarily after the London upgrade, but now have returned to or even exceeded the pre-upgrade level? This is because there is a gas limit on the blocks on the Base network, which is set through an argument in its code.
The gas parameter currently used by Base is the same as Optimism, which means that there is a total gas limit of 5 million gas per Layer2 block (2 seconds). When the demand (total number of transactions) on the network exceeds the supply (block space), the settlement price will be determined by on-demand execution, resulting in a surge in gas fees on the network.
Why doesn’t Base increase this gas limit? Or in other words, why does Rollup need to set a gas limit?
In addition to the previously mentioned data availability limiting the TPS, there are two other main reasons: the bottleneck of execution throughput and the hidden danger of state growth.
Generally, EVM Rollups execute a fork of Geth’s EVM, which means that they have similar performance characteristics to the Geth client. The Geth client is single-threaded (i.e., it can only handle one task at a time) and uses LevelDB/PebbleDB encoding to store its state in a merkle patricia trie (MPT). This is a general-purpose database that uses another tree structure (LSM tree) as the underlying storage for data on solid-state drives (SSDs).
For Rollups, “state access” (reading values from the merkle trie) and “state updates” (updating the merkle trie at the end of each block) are the most costly processes. This is because reading from the solid-state drive once costs between 40-100 microseconds, and the merkle trie data structure is embedded in another data structure (LSM tree), resulting in many unnecessary additional queries.
This process can be imagined as searching for a specific file in a complex file system. You need to navigate from the root directory (trie root node) to the target file (leaf node). For each file query, a specific key in the LevelDB database needs to be queried, and within LevelDB, actual data storage operations need to be performed through another data structure called the LSM tree. These additional steps make the entire data reading and updating process slow and inefficient.
In Monad’s design, we have solved this problem through MonadDb. MonadDb is a custom database that supports storing the merkle trie directly on disk, eliminating the overhead of LevelDb. It also supports asynchronous IO, allowing parallel processing of multiple reads, and bypasses the file system.
Furthermore, Monad uses an “optimistic parallel execution” mechanism, which allows multiple transactions to be executed in parallel and extract their state from MonadDb in parallel.
However, Rollups do not have these optimizations, resulting in a bottleneck in execution throughput.
It should be noted that the efficiency of the database has been optimized in the Erigon/Reth client, and some Rollup clients are built based on these clients (such as OP-Reth). Erigon/Reth uses a flat data structure, which reduces the query cost during reads to some extent. However, they do not support asynchronous reads or multi-threaded processing. Additionally, the merkle root needs to be recomputed after each block, which is a relatively slow process.
Like other blockchains, Rollups also limit their throughput to prevent rapid growth of their active state.
A common argument in the market is that the concern about state growth is due to the potential increase in solid-state drive (SSD) requirements if the state data grows significantly. However, I believe this is somewhat inaccurate. SSDs are relatively inexpensive (a high-quality 2TB SSD is only about $200), and in the nearly 10-year history of Ethereum, the full state is only about 200 GB. From a storage perspective, there is still a lot of room for growth.
The bigger concern is that as the state continues to grow, the time to query specific state segments will become longer. This is because the current merkle patricia trie uses “shortcuts” when the condition of “a node has only one child node” is met, which reduces the effective depth of the trie and speeds up the query process. However, if the merkle trie becomes increasingly full, the available “shortcuts” will become fewer.
In summary, the hidden danger of state growth is ultimately an efficiency issue in state access. Therefore, accelerating state access is the key to making state growth more sustainable.
Currently, Layer2 is still relatively centralized, with the network relying on a single sequencer to maintain the state and produce blocks. One might ask why not run the sequencer on hardware with high RAM capacity so that all states can be stored in memory?
There are two reasons for this.
First, it does not solve the data availability bottleneck of the Ethereum mainnet. Although the gas surge on the Base network is not due to insufficient mainnet data availability, in the long run, this will become a major bottleneck for Rollups.
Second, it is a decentralization issue. Although the sequencer is highly centralized, other roles participating in the network are also important, and they need to be able to run nodes independently, replay the same transaction history, and maintain the same state.
The original transaction data and state submissions on Layer1 are not sufficient to unlock the complete state. Any role that requires access to the complete state (e.g., merchants, exchanges, or automated traders) should run a full Layer2 node to process transactions and have an up-to-date state copy.
Rollups are still blockchains, and what makes blockchains interesting is their ability to achieve global coordination through shared global states. Powerful software is necessary for all blockchains, and simply optimizing hardware is not enough to solve the problem.
After Keone published this article, key personnel from several top Layer2 projects interacted in the comments section.
zkSync co-founder Alex Gluchowski asked about Monad’s differences in terms of optimizing the calculation of the merkle root after each block.
Keone’s response was that there is an optimization algorithm for calculating the merkle root after each block.
Jesse Pollak, the head of Base, also explained why gas fees on Base increased instead of decreasing after the London upgrade. He stated that EIP-4844 significantly reduced the DA cost at the Layer1 level, and gas fees should have decreased. However, due to the more than fivefold increase in network transaction demand and the 250 gas/s limit on the Base network blocks, the demand exceeded the supply, resulting in an increase in gas fees.
Related Report:
Vitalik Buterin sees Validium as a better choice for many DApps than Rollups
Can Rollups truly scale Ethereum, or are we deceiving ourselves?
Interpretation: The competition among Ethereum Rollups, Solana, and Cosmos application chains