Block Propagation Problem
by Юрий Шишацкий (Iurii Shyshatskyi), Chief Scientific Officer at JAX.Network
The lack of scalability is known to be the foremost obstacle standing in the way of mass adoption of blockchain technology. All existing blockchain projects look for solutions that could improve the performance of their network. Many emerging projects claim that they have a magic bullet that could solve the problem. However, such assertions are not always valid. Unfortunately, many observers and investors do not realize the core and root of this problem. Without deep investigation and considerable technical background, it’s difficult to determine hidden bottlenecks and trade-offs. In this post, we are going to discuss one well-known bottleneck that prevents Bitcoin from scaling.
Shortly after the invention of decentralized peer-to-peer network Bitcoin, researchers got interested in what determines the limits of Bitcoin’s scaling. Soon the core issue was determined and described in terms of block propagation time or block propagation delay. It’s an average time that is needed for the new block to reach the majority of nodes in the network. In a large decentralized network like Bitcoin, whenever the new block is generated, it is broadcasted according to the Gossip protocol. If some node has got the new valid block, it informs nodes connected to it about its new possession. Then the node transfers this block to those nodes which asked it to do that. Before the block reaches each full-node in the network, it passes through 7 intermediary nodes. It’s important that every honest node verifies the block before relaying it to other peers. Obviously, the whole thing takes a while. Every new block shakes the network and makes nodes and ethernet connections between them work at full power.
One might argue that since the launch of the network, there have been many improvements to the Gossip protocol. For example, the Bitcoin improvement proposal BIP 0152 introduced the option to transfer only short transaction IDs, instead of the whole list of transactions, in the block body. However, if the node doesn’t have that transaction in its mempool, it has to ask its peers to transfer it in a separate message. If there is a large number of such transactions in the block, then improvement from BIP 0152 disappears.
Since data transmission is the most time-consuming part of the block relay, researchers got interested in determining how much time is required for a data packet of a certain size to reach 50%, 90%, or 95% of nodes in the network. It was found that for blocks of a size larger than 20kB, the block propagation delay is nearly proportional to the block size. According to research published in 2013, every extra kB of data in the block caused an extra 80ms of block propagation delay. Since then, a couple of academic papers and surveys on this topic have been published every year. They update the aforementioned data and discuss various improvement proposals. Moreover, the site monitors the current state of the Bitcoin network and the block propagation time. Also, it provides charts with historical data on this subject.
The majority of well-established blockchain networks have the same design as Bitcoin. As a result, the block propagation time in these networks obeys the same rules. Unfortunately, the block propagation time has a massive effect on the blockchain security. The longer the propagation time in the network, the more often miners mine on top of old blocks. As a result, forking of the main chain occurs more often, and the percentage of orphan blocks rises. The long propagation delay leads to the so-called Verifiers Dilemma. Some nodes may find that skipping the block verification step could be a profitable strategy. In this case, they face the risk of mining on top of the wrong block. However, if block verification time is significant, this strategy could be profitable. Researchers found that long propagation delay reduces the node’s resistance against 51% attacks and selfish mining.
In order to address the aforementioned problem, blockchain developers often try to keep the block propagation time to be less than 1% of the average block time.
This is true for Bitcoin, Ethereum, and other major blockchain networks that are based on PoW consensus. For this reason, block propagation time to 50% of the nodes in the Bitcoin network is often below 6 seconds.
Although fast block relay, like the one described in BIP 0152, reduces the average block propagation time, in the worst-case scenario it could take more time than the basic protocol. It’s important that even in the worst-case scenario, the propagation delay should be reasonable so that miners will keep their nodes synchronized most of the time, and will always verify proposed blocks.
Whenever people talk about the scalability of the blockchain, they mention the transaction throughput of the system. However, people forgot that improvements in transaction throughput shouldn’t compromise the network’s security, or raise data storage requirements for nodes desiring to participate in the network. These modifications could decrease the number of independent transaction validators in the network, thereby reducing decentralization.
Transaction throughput in Bitcoin could be easily calculated using the formula:
where
Bsize is the block size in bytes,
Tsize is the average size of transaction record in the block,
Btime is the average time between consecutive blocks in the blockchain.
Obviously, transaction throughput could be increased by increasing the block size, by reducing the transaction record size, or by reducing the interval between blocks. It’s rather hard to reduce the size of the transaction records. One might instead try the other two options. However, these actions will increase the percentage of time that is spent on block propagation. Thus, the security and decentralization of the network could get compromised.
One might notice that in the described Bitcoin protocol, network resources are used inefficiently. Every node processes and transmits the vital data about a new block only a small fraction of time. Its network bandwidth is really important, but it is used in full for only a few seconds at a time. The rest of the time, this node transmits only pending transactions and auxiliary data. This observation has inspired researchers to look for more efficient protocol designs that could dramatically improve transaction throughput without compromising the security and decentralization of the network. In our next post, we will discuss approaches for solving the block propagation problem that have been proposed in recent years.
