Claire Jencks 🤘

There’s been some recent discussion about execution bottlenecks and gas limits, both for L1 and L2. I'll discuss a few of the bottlenecks below. 1. DA With the introduction of blob data (EIP-4844), Eth DA has become cheaper than before (because it doesn't have to compete with ordinary L1 transactions in the priority gas auction). The median capacity is 3x 125 kb blobs per 12s block, or 31.25 kb/s. Transactions are currently about 100 bytes, so this translates to about 300 tps across all rollups. Footnotes: - This could increase with better compression of transaction data. - Rollups could theoretically utilize both calldata and blob data although doing so would add complexity. - Some ZK-rollups post state diffs (notably, zkSync Era and Starknet) so the math is different for those. 2. Rollup gas limits Base has been getting a lot of attention recently because gas fees have spiked and have been several dollars for a simple swap. This is because blocks on Base have a gas limit, and with any limited-supply resource, when demand exceeds supply the clearing price becomes whatever price causes demand to match supply. This gas limit is a parameter in code. Base currently uses the same gas target as Optimism (5 million gas per L2 block, i.e. 5 million gas every 2 seconds). Why doesn’t Base raise the gas limits? (Or more generally, why does any rollup need a gas limit?) While they can (and probably will), there are two additional motivations (other than DA) for keeping it low: execution throughput and concerns about state growth. 3. Execution throughput EVM rollups generally run an EVM which is a fork of the EVM from geth. This means that they have similar performance characteristics to the geth client. The geth client is single-threaded and stores its state in a merkle patricia trie (MPT) which is encoded using LevelDB/PebbleDB. These are commodity databases that use another tree structure (an LSM tree) under the hood to store data on SSD. State access (reading values from the merkle trie) and state updates (updating the merkle trie at the end of each block) are the most expensive parts of execution. That makes sense when you consider that a single read from SSD costs 40-100 us and that, due to the fact that the merkle trie datastructure is being embedded in another datastructure, there are many excess lookups. A simple mental picture: you are navigating to a node at the bottom of a merkle trie, i.e. traversing from the root to one of the leaves. Each node you visit requires looking up a key in LevelDB. But each of those LevelDB lookups requires navigating the underlying LSM-tree, visiting many LSM-tree nodes in the process. In Monad, we addressed this with MonadDb, a custom database which 1) directly stores the merkle trie on disk, avoiding the overhead of LevelDb; 2) supports asynchronous IO, allowing many reads to proceed in parallel; 3) bypasses the filesystem. Additionally, optimistic parallel execution in Monad allows many transactions to proceed in parallel and pull their state dependencies from MonadDb in parallel. However, rollups don’t have these optimizations so are bottlenecked on execution throughput. Footnotes: - Erigon/reth offer some improvements to database efficiency, and some rollups have clients that are based on these clients (in particular op-reth). Erigon/reth use a flattened datastructure which reduces lookup costs somewhat for reads; however there isn’t support for asynchronous reads or multithreading. Also, the merkle root still needs to be recomputed after each block, and this is quite slow. 4. Concerns about state growth Rollups, like any other blockchain, also limit their throughput to prevent their active state from growing too quickly. A common refrain is that state growth is concerning because if the state grows a lot, the SSD size requirements will have to increase. However, I think this is a bit imprecise. SSDs are relatively cheap (a high-quality 2 TB SSD costs about $200) and the full Ethereum state after nearly 10 years of history is “only” about 200 GB right now. From a pure storage perspective, there is room to grow. The bigger concern is that, as state grows larger, lookup times for any given piece of state become larger. This is because the merkle patricia trie uses “shortcuts” when a node only has one child, which reduces the effective depth of the trie, thus speeding up lookups. As the merkle trie gets fuller, there are few “shortcuts” available. Concerns about state growth ultimately boil down to similar concerns about the inefficiency of state access. Accelerating state access is what is needed to make state growth more tenable. 5. Epilogue: Why not throw hardware at the problem? L2s are (currently) centralized, with a single sequencer maintaining the state and producing blocks. One might ask: why not just make that sequencer run on hardware with extremely high RAM requirements, so that all state can live in memory? Two reasons. First, this doesn’t address the bottleneck of Ethereum DA, which (while not the constraint in the case of Base at the present moment) will ultimately be a significant bottleneck. Second and more importantly: decentralization. Although sequencing is highly centralized, it is still extremely important for anyone else to be able to independently run nodes that replay the same transaction history and maintain the same state. Raw transaction data and state commitments on the L1 are not enough to unpack the full state. Anyone who needs reliable access to the full state (for example, a merchant, an exchange, or an automated trader) should run a full L2 node to process the transactions and have an up-to-date copy of the state of the world. Rollups are still blockchains, and blockchains are interesting because they enable global coordination through shared global state. Performant software is necessary for any blockchain; it's not sufficient to throw hardware at the problem.