What determines the performance of the public blockchain — the misunderstood TPS
The slow transaction speed of public blockchains has always been criticized by everyone. In recent years, several mainstream public blockchains have experienced congestion. Now many projects advertise themselves as one million TPS, thus solving the problem of insufficient public blockchain performance. But is the blockchain performance problem really solved? Let’s analyze it together to see where the bottleneck of the performance of the public blockchain is.
1 Traditional POW consensus
As the originator of blockchain technology, Bitcoin’s performance has long been unable to meet the current transaction needs, so congestion often occurs. Let’s first look at the accounting process of Bitcoin:
Bitcoin adopts POW consensus (Proof of Work), and there are two main steps that take a lot of time. The first is to do proof of work, that is, to calculate the hash value of the block that meets the requirements. The second is the process of network-wide broadcasting, waiting for other miners to confirm the block.
At the time of design, the block time of Bitcoin is set to 10 minutes (that is, 10 minutes of proof-of-work is required), the size of each block is about 1MB, and a block can pack up to several thousand transaction data. Although a single block can contain thousands of transaction information, it takes at least 10 minutes to complete a block, which leads to low transaction information recorded per unit time, that is, low TPS.
TPS (transaction per second) is a commonly used indicator to describe the performance of the blockchain, which refers to the number of transactions processed per second, and is an important parameter to measure the throughput of a system.
Due to the slow block generation, the TPS of Bitcoin is only about 7. Therefore, Bitcoin’s congestion is often blamed on the POW consensus mechanism it uses.
Some people will say that TPS can be increased by increasing the size of the block or increasing the speed of the block, so that there will be no congestion. It’s a nice idea, but it’s not actually that simple to increase transaction throughput. Increasing the block size will lead to an increase in block confirmation time (longer broadcast time), because a single block contains more bytes, and the required transmission time will be correspondingly longer; although increasing the block speed will The proof-of-work time is reduced, but when the block production speed is too fast and the broadcast speed cannot keep up, a new block will be mined before a block is confirmed by the miners of the whole network, which will cause a fork. Forks reduce the security of the network.
The cost of doing evil without forking is not less than 51% of the computing power of the entire network. Forks reduce the cost of doing evil and make the network insecure. Therefore, the 10-minute block time is a compromise between Bitcoin’s security and efficiency.
Therefore, under POW, it is not possible to arbitrarily increase the block capacity or increase the block generation speed. This increases the possibility of forks and reduces the security of the network.
2 POS consensus improves transaction speed
Due to the slow transaction speed and high energy consumption of POW, POS consensus (Proof of Stake) is gradually being more widely adopted. For example, an important step in Ethereum 2.0 is to switch from POW consensus to POS consensus. Different from POW, POS obtains the right to package blocks and vote by staking Token.
In POS, the blocks produced by miners are directly candidate blocks, eliminating the proof-of-work step in POW. Because the right to package is assigned to miners by default when the tokens are pledged to become miners. POS allocates the packaging right before the block is produced, and POW has to compete for the packaging right after the block is produced. Therefore, POS will be more efficient than POW, and it can even be confirmed in seconds. It can be seen that the transaction performance of POS has been significantly improved compared to POW.
Under the existing POW consensus of Ethereum, the TPS is about 30 to 40. Although much higher than Bitcoin, it is still congested from time to time, and transfers sometimes take hours to complete. In order to solve this problem, Ethereum chose to abandon POW and adopt a more efficient POS mechanism. ETH2.0’s phase 0 Bacon Chain is launched, and POS will gradually replace POW. At that time, only 32 ETHs need to be pledged to become a miner.
3 Higher speed DPOS
EOS’s DPOS consensus belongs to POS, and token holders elect some representatives, and these representatives take turns to keep accounts. The essence of DPOS is to sacrifice decentralization to obtain high throughput. The EOS network has only 21 super nodes to produce blocks.
Compared with the hundreds or thousands of nodes of POS, EOS only needs to be broadcast in 21 nodes, so the time required for Time2 will be further shortened, and the TPS will also be greatly improved.
EOS claims in the white paper that it has millions of TPS, but there was still congestion during the EIDOS airdrop in 2019. Although the consensus algorithm has been improved to obtain a super high TPS, why does even an airdrop project cause congestion? It can be seen that there are other factors that restrict the performance of the blockchain.
The performance of a blockchain network is not only related to TPS, that is, throughput; it is also related to the performance of a single full node. There are roughly two types of common nodes in a blockchain network: full nodes and light nodes. Each full node in the network is responsible for broadcasting blocks and confirming transactions. Therefore, the full node must save the transaction history of the entire blockchain, as well as the status of all users and DAPPs in the entire network to verify this information during transactions. The light node is only responsible for querying the information of the full node, and does not participate in the accounting process, so the light node will not make any contribution to the network performance. When executing a transaction or running a DAPP, it will rely on the full node to complete, so the performance of the full node determines the processing speed of transaction execution. However, the performance of the blockchain network is not the superposition of the performance of all full nodes, but there is a barrel effect. The water storage capacity of the barrel depends on the shortest board in the barrel, and the performance of the entire network is also subject to the performance of a single full node: the performance of the entire network will not be higher than that of a single full node.
The congestion of EOS is limited by the performance of a single full node. EOS divides the performance of the full node into RAM, CPU and other resources. These resources are then tokenized, allowing users in the network to maximize the utilization of full nodes by leasing. When a large number of processing requests occur in a short period of time, the performance resources of the full node will be quickly exhausted, just like a computer running too many programs, and then opening a web page will be very stuck. The congestion caused by the EIDOS airdrop in 2019 was officially put on hold due to the rapid shortage of CPU resources in the EOS network, and the CPU required for a transfer exceeded the CPU that the network could allocate to it.
4 Where is the bottleneck of public blockchain performance?
As can be seen from the above examples, changing the consensus algorithm can improve throughput and increase TPS to a certain extent. But no matter how the consensus algorithm changes, this step cannot be escaped: the entire network is fully broadcast, and the block is confirmed after the node has verified it. The processing efficiency of this process is mainly related to the transmission efficiency of broadcast and the ability of nodes to process information.
The higher the transmission efficiency of the broadcast, the greater the throughput of the network and the higher the TPS. The physical upper limit of throughput is the network bandwidth between each full node, and the network bandwidth is limited by communication technology and hardware devices. Many projects are now advocating tens of millions of TPS, which requires a very high network bandwidth, and it is possible to trap all full nodes in a local area network, but such a network has almost no decentralization at all.
The better the performance of a single full node, the higher its ability to process information, and the stronger the performance of the public blockchain. Blindly increasing the requirements for full nodes will also lead to centralization. For example, only some high-configuration servers can be full nodes, and these nodes may be controlled by some large companies.
Taken together, the performance of the blockchain is mainly limited by the network bandwidth and the performance of a single full node. Nowadays, many projects only blindly pursue high TPS, which makes people mistakenly think that this improves the performance of the public blockchain. In fact, they only focus on network bandwidth and ignore the impact of full node performance on the overall network performance. The key to improving performance for public blockchains is to ensure that these two limitations are broken on the basis of a certain degree of decentralization.
5 Ways to break through the bottleneck
The most likely implementation proposed now is the sharding scheme: a single chain is divided into several groups, each group is called a shard. Assuming that there are 100 full nodes in the whole network, there are only 20 full nodes in each group after grouping. A transaction does not need to broadcast confirmation to all full nodes in the whole network, as long as the group of 20 full nodes is locally verified. This improves the utilization of network bandwidth. The nodes of each group also store the user information and DAPP status of the entire network differently; it is better to store the group of their own, which reduces the burden on nodes and can effectively avoid congestion.
Of course, the sharding scheme should also pay attention to coordinating the operation between different shards. The ultimate goal of Ethereum 2.0 is to solve the problem of insufficient performance of the existing Ethereum through the expansion solution of sharding. The plan of Ethereum 2.0 is 5 years, which shows that the implementation is not small.
