How Do Uncle Blocks Affect Blockchain Performance?
In our previous article, we cite uncle rate as one of the primary threats to the security and performance of the Ethereum blockchain, which is only exacerbated as block time decreases. While the current difficulty algorithm targets a block time of around 15 seconds, it’s prone to fluctuation and displays an average of 10.66 uncles per block, according to data derived from Amberdata.
But What Does It Mean?
There are several implications of this data:
The higher the uncle rate, the lower the amount of control over the network’s total hashing power required to actually engage a 51% attack on the blockchain. Refer to our previous article to check out the results of our test series related to this hypothesis.
Uncle rate has a negative impact on transactional throughput. Since miners may be processing transactions which have already been accounted for in the previous block rather than new transactions, the ability of the network to process a larger amount of transactions will decrease. This can also result in bloating of the mempool. We can also assume that a high uncle rate is indicative of a suboptimal network since a portion of the network’s total hashing power is wasted on mining uncles.
Since uncle rate is a factor of network latency, the lower the block time, the higher the uncle rate. Given the current architecture of the Ethereum network, we can observe a direct correlation between network latency, uncle rate, block time, and block propagation time. The lower the block time, the more dramatic the effect of network latency. Since blockchain protocols are mostly asynchronous processes, a blockchain can only be as fast as its slowest node (or only as fast as the slowest node within the group establishing consensus).
Block propagation time refers to the length of time it takes for every node within the network to hear the news that the latest block has been added to the canonical chain, signaling miners to move on to building the next block. Since this news is spread via gossip protocol, not every node in the network is going to hear about the latest block at the same time, meaning that the last ones in line to hear about it will be mining stale blocks, or uncles.
TCP/IP: It Pretty Much Sucks
In a perfect world, there is no network latency and it only takes a few milliseconds for every node to communicate with one another, but that isn’t the case.
TCP/IP are imperfect protocols, so unless this stack is redesigned, we shouldn’t expect a dramatic increase in performance, even if the Ethereum client is completely optimized.
While it’s speculated that block propagation time in the Ethereum network is around 10–20 seconds, it’s reasonable to assume that lowering the block time will only result in an increase in uncle rate.
So What Can We Do About It?
One potential solution is raising the block time which we explored in our latest research that we conducted for the Ubiq blockchain, an early fork of Geth that enforces an 88-second block time through the implementation of a custom difficulty algorithm referred to as Flux. Our next article will share the results of this test series and dive deeper into the research conducted here at Whiteblock.
If you have any questions or comments about blockchain testing, feel free to reach out to us at firstname.lastname@example.org and check out our channel on Telegram to join the discussion about blockchain performance.