51% Attack? Think Again: The Case for Longer Block Times
A lot of blockchain-based protocols and projects make grand claims concerning performance and throughput. With so much innovation stemming from the R&D stages of these projects, many neglect to account for the real performance challenges these protocols will face once they go live in a real-world network. In many cases, performance cannot be optimized without sacrificing security or finality probability.
Apart from these security concerns, problems relating to centralization also arise, as cited in this article written by Vitalik Buterin titled “Toward a 12-second Block Time”.
Assuming that a one-second block time is even possible for Ethereum, network impairments like random outages and inter-node latency will have a much more obvious and dramatic effect than can be observed in the current 12–17 second block time. One specific metric that would be uncle rate, which would increase exponentially as block time decreases. This could provide mining pools that already demonstrate a computational advantage over the rest of the network with the ability to further increase their influence over the blockchain.
In his presentation at EDCON 2018, Shawn Douglass of Amberdata proposed that if there are more than 1 uncle blocks per 2 blocks, a 51% attack would only require 38% control of the network’s hashing power in order to successfully engage. If this is true, then uncle rate is a pretty big deal which is only exacerbated by the presence of network latency with faster block times.
We tried to get in touch with Shawn to figure out how they came to this conclusion, but didn’t manage to get an answer. There was also a real lack of practical data to support this hypothesis, so we decided to run some tests of our own here in the Whiteblock lab to validate this hypothesis.
The following sections outline the methodology we used to replicate the scenario as well as results of our test series.
Methodology
To successfully replicate the testing scenario, a few requirements needed to be met:
- Network conditions ( latency, random network outages, congestion)
- A supernode with more computational resources than the rest of the network in order to simulate a mining pool
- A few normal mining nodes
- A few client nodes that broadcast transactions to the network
- Close to 1 second block time
To meet the requirements above, we used the Whiteblock blockchain testing platform to deploy a private blockchain network, provision the required nodes, and apply the various network conditions in a few minutes.
The network consisted of a supernode with roughly 2.6 times more hashing power than the normal miners. Three miner nodes were then added to the network, giving the supernode roughly 46% of the total network’s hashing power.
A few client nodes were added to the network to constantly generate transactions, difficulty was adjusted to implement a 1 second block time, and 80ms roundtrip latency was applied within the network. 80 ms seemed reasonable considering cross-continental latency can be averaged somewhere around 91.92 ms.
The test was run for 1000 blocks and the following section presents the results of the testing series.
Results:
Shown below from Fig 2 to Fig5 are the plots obtained through the test, including gas use, block time, throughput, and uncle rate. As we can see, the test network has a block time of about 1.06s with 28.94 tx/s and an uncle rate of 57%.
As indicated below in Fig6, the node with the 0x71e1 address was the supernode and the remaining 3 were the normal mining nodes (0xd706, 0x6231, 0x66a6). The supernode produced over 52% of the total blocks during the test which implies the capability and the potential for a 51% attack even though the supernode only has 45% of the network hashing power.
{
'0xd706e078dddC51c070E397BEB51E847f1FDd83fb': 177', '0x6231bBc8130e0783578b370dEd1F0f934A3fD2ad': 169', '0x66A6f059E31E46F24C59285b27597ED9152f6484': 147', '0x71E17Df65e507bb1E320B9CD7751ca41a0b1bC6d': 542
}total_blocks: 103552.36% of network is controlled by the mining group with 45% of mining power due to centralization and network latencies.
Quick Reflections:
As we found out from the test results, the increase of throughput performance came at the cost of security. Under the given testing circumstances, a potential 51% attack can be initiated by a mining pool with control over 45% of network hashing power. This vulnerability arises from the presence of network latency and centralization of block producers.
Further performance optimization measures should be examined with caution and keep this in mind. The trilemma of blockchain is observed here as performance, security and decentralization and seems to indicate a complex relationship between the three.
Obviously, this was a quick test series, so a more in-depth study should be conducted in order to flush out the results, but this is a good starting point that allows us to practically demonstrate the negative effects of a shorter block time in a network with a high uncle rate.
If you have any questions or comments about our testing series, feel free to reach out to us at hello@whiteblock.io or check out our channel on Telegram to join the discussion about blockchain performance and testing.
