Capacity at peak is very important, as we don’t want the transaction price to increase when activity spikes: we always want actual usage to be below max capacity.
Today, Linea supports 12 million gas per second (vs. Ethereum mainnet at 1.25Mg/s), with a 24-million block size with a block time of 2 seconds. We want to increase this capacity forever. Scalability comes from: (1) lower block time - 100ms or less would be great (2) bigger blocks - 200M gas or more would be great. The two together should bring the capacity to 2Ggas / second and more.
This document gives an overview of the problem and of the things to do.
Prover
For lower block time, the prover scales linearly, with potentially hundreds of prover processes (the maximum reached so far is ~600 hpc6a at the same time), so there is no scalability point here: improving the prover is still very important to lower the cost and to decrease the latency, but this is not the topic of the document.
For bigger blocks, this increases the memory used by the prover, so a specific effort is potentially needed to split the work in smaller tasks that can fit a reasonable computer (eg. an hpc7a with 768 GB of ram).
Arithmetization aka trace generation
Like the prover, the arithmetization scales linearly: it is always possible to add trace generation processes. With bigger blocks, traces will also become bigger, but we do not expect any major impact.
Data availability
With more transactions, there will be more data to send on the data availability layer. Today, looking at the compressed size of the average transaction, Ethereum Blobs can support 400 TPS, obviously less than the capacity we are targeting. We don’t want to replace Ethereum’s data availability layer, but we also expect that the capacity of Ethereum will increase dramatically in the near future.
Sequencer
The sequencer needs to execute the transactions to include them in the block. Currently, the sequencer also measures the prover resources (“limits”) used by the transaction, to be sure that the block stays below the prover’s limit and to be sure that the transaction is profitable. This is very expensive for the sequencer.
Linea’s plan is to remove the prover’s limit in 2025. That will remove the first cause.
Vitalik’s plan is to increase the gas cost of prover-expensive opcode to the L1’s cost in gas will represent the prover’s cost. That will remove the second reason.
In other words, we need to make the measurement of the resources good enough for the next months, but we don’t need to over optimize it as the whole part will go away. As well, we should not hesitate to “throw hardware at the problem”, as in the medium term the problem will disappear: the hardware is almost always cheaper than developer time.
Regardless of counting the resources used by the prover, there is a need to build the blocks as quickly as possible, wherever the bottleneck are (execution, state access, synchronization between the tasks, etc.).
Transaction execution - RPC context
Having very good performance for RPC calls is always useful, typically it reduces the cost for RPC providers. It is not needed directly for Linea scalability, but it is always useful, and many tasks done for the sequencing will be useful for transaction execution within RPC calls. Measuring the result will be great.
State
State is known to be the bottleneck for the execution layer: the state does not fit in memory, creating cache misses when reading the state. The state grows with the number of transactions. For the same number of transactions, state growth depends on the number of different users and the number of applications used by the user. The state representation, and the performance tuning, must take into account this growth.
Linea uses today a very optimized state representation (for the prover), based on a linked list on a sparse Merkle tree. However, Ethereum is going to move from Patricia Merkle Trees to Verkle trees, theoretically easier to prove. This will still be less efficient than current Linea’s representation, but Linea still want to move to Verkle trees as it allows Linea to be a type-1 EVM: having the same state as the standard client simplifies the technical stack, but as well is a key step in the direction of the multiprover: we expect all zkEVM to move to this state representation, allowing it to be verified by independent provers.
In other words, it is worth optimizing the state once the migration to Verkle trees is done in the client. There is a caveat: this roadmap is not yet final (telegram message from Vitalik on July 6th 2024: “there’s now some momentum for dumping verkle and replacing it with going straight to binary hash trees”), so we will need to monitor the L1 decision very carefully.
Consensus
Consensus requires multiple messages, so the consensus time depends on the number of participants and on the network.
A lot of work will be required here, between defining the number of participants, optimizing the network stack, the protocol vs. the network stack (eg. use of QUIC), and potentially using a pipeline between blocks and consensus (i.e. running multiple consensus at the same time for consecutive block height), with the drawback of having intermediary states where the block is available but not finalized.
Network
On top of the network usage for the consensus, we will need to exchange a lot of blocks. End users or dapps do not have to receive blocks: they can rely on layer 1 and the proof. However, we still want block propagation to be as smooth as possible to have as many clients as possible for data safety reasons. If each block has a size of 100KB compressed, then 100ms block time leads to 1MB of data per second just for receiving blocks (vs. 6.25KB/s of non compressed data for Ethereum mainnet).
Node synchronization
With more and more txs, adding a new node will be complicated in terms of synchronization: re-executing 2 years of history is obviously more complicated when there are thousands of TPS. This can be solved with a snapshot feature plus fast execution when syncing.
Coordinator
Coordination, eg. trace generation and proving, sending data and proof to L1 will have a 20 time increase in activity if we go from 2-second block time to 100-ms. Data in transit will be multiplied by more than 150. Ideally, this won’t require scaling the coordinator, just “good enough” performance, but in any case there will be a designing and testing effort for this component.
Decentralization, PBS / Proposer Builder Separation
With decentralization, the sequencer will be replaced by a committee, with one node in charge of the block building, and multiple nodes in charge of validating the block.
Block building is already expensive in Ethereum mainnet. However, we would like the validation to be as cheap as possible, to allow anyone to be a validator without requiring a heavy infrastructure. A possible solution would be to have a stateless client for the validators: the state will be provided, with the proof, by the builder. Verkle trees are supposed to provide this.
External components
Linea also relies on external components, such as block explorers. They need to support these capacities too.
Potential timeline
That’s a reasonable timeline from a technical point of view. Actual implementation can be delayed / accelerated depending on product priorities.
| Q2 2023 | Q4/2024 | H1/2025 | H2/2025 | 2026 | 2027? | |
|---|---|---|---|---|---|---|
| Data availability | Capacity: 32KB/s | |||||
| Need: 12KB/s | Need: 20KB/s | Need: 100KB/s | Need: 3-500KB/s | 1GB/s | ||
| Gas/Besu | Capacity: 100Mg/s | |||||
| Need: 12Mg/s | Capacity: 150Mg/s | |||||
| Need: 17Mg/s | Capacity: 300Mg/s | |||||
| Need: 25Mg/s | Capacity: 500Mg/s | Capacity: 1_000Mg/s | 2_000Mg/s | |||
| Network | Capacity: 100MB/s | |||||
| Consensus | X | X | 0.5 blocks/s | 1 blocks/s (a 200mgas/s) | ||
| Permissioned decentralization | 3-5 blocks/s | |||||
| Block pipelining | 10 blocks/s | |||||
| Block builder | Capacity: 20Mg/s | Parallelization of tx including line counting | ||||
| 40Mg/s | 40Mg/s | Remove line counting | ||||
| 500Mg/s | 1_000Mg/s | 2_000Mg/s | ||||
| Verkle | X | X | X | X | O | O |
| State manager | Capacity: 20Mg/s | Capacity: 40Mg/s | 40Mg/s | 500Mg/s or Verkle | X |