The Ethereum Throughput Bottleneck and Its Solutions
The Ethereum throughput bottleneck
A blockchain consists of many components, such as its consensus mechanism, network, and transaction validation. Given that, its efficiency also relies on those factors. Is it too slow to reach consensus, to transmit data through the network, or to validate transactions? For Ethereum, its biggest efficiency bottleneck lies in the transaction's validation speed, rather than the speed to reach consensus or send data through the network.
Note: this bottleneck also exists for other EVM-compatible chains. Regardless of the performance and the TPS of a consensus algorithm, the overall efficiency of a blockchain will be constrained by the execution speed of its EVM, as long as transaction validation needs to be executed by the EVM.
Could the hardware requirements be adjusted if protocol parameters cannot be changed?
It is intuitive to assume that the network speed of nodes could be increased fast enough to solve the problem of low network speed. Likewise, could nodes be featured with a hard drive that is big and fast enough to handle the problem of a slow read speed? All these two solutions compromise one thing, which is the network will be more centralized given a smaller number of nodes meeting the flavor of the network.
Next, let’s get straight to the point to introduce one way to increase throughput, which is separating transaction execution from the consensus layer.
Separating transaction execution from the consensus layer
Why will the throughput be capped by its transaction validation speed? This is because each transaction needs to be executed by all nodes to ensure the result is the same across different nodes. Only when the validation succeeds can nodes reach consensus on the transactions and the block. In other words, transaction execution is included in the process of reaching consensus. Therefore, even with a consensus algorithm reaching consensus on 1000 transactions in one second, the TPS of a network could stand at 100, since only 100 transactions can be executed and validated by its nodes at the same time.
Note: a faster VM is the first thing that naturally comes to the mind of developers who realize that throughput is capped by EVM performance. So EWASM, or Ethereum plus WebAssembly, had been frequently discussed several years ago. Later, however, their research focus has been shifted to other fields.
If transaction execution is separated from the consensus layer, validators won’t have to execute the received transactions. Instead, the transaction initiator will be checked to see whether he has enough balance to pay for inclusion of the data of his transaction. In this way, network efficiency will no longer depend on how many transactions a node executes, or EVM performance. In this case, miners under the PoW consensus mechanism or validators under the PoS consensus mechanism can focus on reaching consensus on the balance of a transaction, or data. Thus, the TPS of a network is only bounded by its transmission speed or the speed to reach consensus. No consensus is needed for execution results.
You may wonder how many ETH can I get with 300 USD through Uniswap if nodes are executing the transaction. In fact, the solution of separating transaction execution will not be applied on the Ethereum mainnet (formerly Eth1). Let’s have a look at Sharding and Rollup before introducing how that solution works.
Sharding
For Sharding, which is a part of the Ethereum's future upgrades, block data of each shard chain, hereinafter called SC, are added into blocks on the beacon chain, or BC in the following paragraphs. Therefore, validators of BC can reach consensus on blocks of SC when they do so for those of BC.
Rollup
Transactions are packaged by Rollup Sequencer to Layer1 to leverage Layer 1's security One can be sure that the order hasn’t been tampered with as long as Layer1 was not hacked or suffered from a “reorg”. With the right order, the current state of Rollup can be calculated by anyone.
Let’s assume that the original state shows that the balance of A,B, and C is 10, 5, and 0 dollars respectively with three transactions executed in the following order:
Tx1: A →$5 → C
Tx2: B →$2 →A
Tx3: C →$3 →A
Based on the order, you can calculate the latest state that A, B, and C have 10, 3, and 2 dollars left accordingly.
All in all, transaction execution is not truly separated from the process of reaching consensus for Rollup as the Sequencer still needs to execute a transaction to decide if the transaction can be included in a block.
Nevertheless, there is one thing in common for Rollup and Sharding: transactions in Rollup are meaningless to Layer 1. This is because those transactions will only be added by Layer1 validators who will not execute them. On the other hand, nodes of different Rollup will identify transactions belonging to their Rollup and execute.
Sharding + Rollup
Shard chains will serve as blockchains for storing transaction data from Rollup, similar to how Rollup puts its data on Layer1 right now. Then, consensus will be reached on BC for SC blocks to make sure that the transaction order will not change. After that, transactions selected by Rollup nodes from those blocks will be executed.
Execution Environment / Execution Layer
Given the two examples above, validators on BC or Layer1 reached consensus on data, how to interpret the data is left for Rollup nodes.They are not data interpreters like Rollup nodes. In this sense, Rollup can be regarded as an execution environment or the execution layer for data interpretation. For instance, data can be interpreted as a transaction on Uniswap to be executed.
Rollups such as Optimism, Arbitrum, StarkNet, and zkSync, vary in their protocol design with unique VM and fee charging schemes. But they all rely on Layer1’s security to ensure transaction order will not change. On top of that, data will be interpreted according to their protocol and executed. In this way, those protocols can be compared to different execution environments.
For the question mentioned above, the answer will be provided by Rollup nodes, instead of those on Layer1 or SC for data storage under the design to make transaction execution independent from the consensus layer.