- CoinStic
- Posts
- Is a Multi-Layered Consensus System Able to Provide Network Resilience to 51 Percent Attacks up to 90 Percent?
Is a Multi-Layered Consensus System Able to Provide Network Resilience to 51 Percent Attacks up to 90 Percent?
HodlX Guest Post Submit Your Post
Recently, we’ve seen more and more blockchain networks falling victim to a 51 percent attack. This attack is possible because thresholds can be quite low, amounting to slightly more than 50 percent of hashrate. When an attacker takes over a network, there are many ways it can be abused. For example, the attacker can perform a double spend. However, it’s more important that while the network is controlled by malicious users, its operations cannot be considered normal. Essentially, such attacks make the blockchain inoperative.
This explains why developing a new consensus with high resilience to 51 percent attack is a very timely task. In his recent article, A Guide to 99% Fault Tolerant Consensus, Vitalik Buterin proposes a way to increase the threshold of the 51 percent attack from 51 percent of stake or hashrate to 99 percent. The key is the introduction of additional validators, called observers, who do not participate in block generation. Observers perform the post-validation of blockchain and can alert the network if compromised blocks are found. For post-validation, Vitalik suggests that 512 nodes are randomly chosen every 4,096 seconds by the latency-dependent algorithm.
Although this approach definitely improves network protection, it has substantial faults. The most critical weaknesses are dependency on time required for consensus, dependency on network throughput and time synchronization between observers.
Here, the minimum time interval of D is an empirical value, through which observers can exchange data correctly. Calculation of D takes into account poor internet connection and processing power of observers. Blocks are considered valid only if confirmation time interval divided by D is no less than the number of observers that signed this block.
As D value is the minimum of all possible ones, there is a potential situation when during D interval, a block is confirmed by only one observer. So time required for consensus is linearly dependent on the number of observers. This places significant limitations on scalability and decentralization of the network.
In the case of limited number of observers (Buterin suggests using only 512 observers), validation is only pseudo-decentralized. Significant or unlimited increases in the number of observers may lead to significantly higher required D time. In that case, validation would take much longer or even become pointless.
Modern communication channel bandwidth is still limited, hindering post-validation of large blocks. Assuming that transaction size is 200 bytes, which is actually quite small and possible only in financial transactions without smart contracts, and that there are 50,000 transactions in a block (modern blockchains are actively trying to reach that level), the block size is 10Mb. Transmitting this amount of data within a second requires a 100Mbps channel. Trunk channels are definitely able to guarantee this throughput level, but regional connections would be a lot slower. This would make validation either impossible due to the requirement of getting signatures within a set period of time, or pseudo-decentralized where only observers with the best trunk channels are selected.
Another weakness is mandatory synchronization of time between observers which increases network vulnerability to potential attacks, as no blockchain networks use secure protocols of time sync (such as SNTP). Working with unsecured NTP creates multiple opportunities for unsynchronization of observers’ pools, that can later completely sabotage the validation.
In an attempt to eliminate the issues described above and enhance network resilience from 51 percent attack up to 90 percent, an approach utilizing additional roles could provide a solution for network consensus. Alternatively to the solution described by Vitalik Buterin, in this case a network would require five roles that are dynamically assigned to nodes.
Because of this setup, solving the Byzantine Fault Tolerance (BFT) problem of getting the 67 percent stake simultaneously on several layers requires having control of over 90 percent of stake. Moreover, resilience is so high that it takes more than 53 percent of stake for malicious transactions to even appear.
Even with the unlikely emergence of the network with 90 percent of single-handedly owned stake, the clients will start retroactively rejecting the blocks and stop trusting the compromised network, effectively splitting the network in twain. Since clients using the network are its most valuable part, possessing 90 percent of control over the stake only gives control over the dead network with no clients, while the remaining 10 percent will become the 100 percent of coin holders in the new network.
The network uses asynchronous block validation to eliminate the dependency of consensus time on number of validators. The next block starts generating as soon as the current one is generated and has completed basic post-validation. Full validation is happening on different layers in tandem (by verifier, torrent, peer and client roles). Whenever a malicious block is identified, blockchain rolls back to the last confirmed state and rebuilds from raw transactions.
The issue of potentially poor internet connections is mitigated by using BitTorrent-like technology. Data is transmitted across the network in fragments, ensuring faster exchange rates in regions with low bandwidth. This enables data delivery to even artificially isolated regions.
Resolution for the time synchronization challenge is twofold: internal time of process (in ticks) is used wherever possible, and time sync is done via protected proprietary SNTP protocol.
In conclusion, presenting different roles in consensus, as described above, is likely the most perspective approach nowadays and can hopefully significantly improve the security in blockchain.
Gleb NikitinGleb Nikitin, Tech Lead and Co-founder at #MetaHash