Blockchain and the elephant in the room

Mance Harmon, CEO at Swirlds looks at the security concerns associated with blockchain

This is a contributed piece by Mance Harmon, CEO at Swirlds

In 2015 the blockchain market split into two categories: public networks (such as Bitcoin and Ethereum), and private/permissioned networks. The split occurred as users weighed the costs and benefits of trust vs. performance/costs. But has one camp left themselves vulnerable to a single, easy point of attack?

Public networks allow general participation without approval. For example, anyone can download the Bitcoin software and participate in the Bitcoin network as a full node. In the public networks, the members are mutually untrusted, and may even be unknown. To address this, these networks enable a level of trust through Proof-of-Work, which requires that expensive computations be performed in order to facilitate transactions on the blockchain.

Bitcoin blockchain eliminates the need for a Leader (or single point of failure) by creating, instead, a competition among peers in the network. All transactions are sent to all peers.  Each peer collects the transactions into a block, and then competes to be the first to solve a hard cryptographic puzzle. The first peer to solve the puzzle earns the right to publish their block of transactions to all other peers. Upon receipt, each peer adds the new block of transactions to the top of the chain of blocks (blockchain). Because it’s impossible for an attacker to predict who will win the competition, it’s resilient to DDoS attacks. The tradeoff is that the use of Proof-of-Work slows performance and dramatically increases costs to operate the network. 

On the other hand, permissioned networks require application and approval by the governing body of the network, in order to join. For example, banks or credit unions might create a private network for conducting certain financial transactions, and only allow banks or credit unions that meet certain criteria to participate. Permissioned networks don’t typically use Proof-of-Work, and therefore have improved performance and lower cost. The members are typically both known and trusted, which is often cited as the justification for not using Proof-of-Work and relaxing the security properties of the system. 

Therein lies the Achilles Heel of permissioned networks…

The most important security mechanism used in public networks is removed in permissioned networks, to improve performance. Proof-of-Work is replaced with trust in network members. But what are members trusted to do or not to do?  What is the nature of that trust? The answer is disturbing.  

In a DDoS attack, an attacker can flood a computer with enough messages to stop that computer from communicating. If the attacker has enough resources to flood all the computers, they can shut down the network.  But if they can only shut down a few computers, the network can keep running. The challenge for current permissioned systems is that they use Leaders, which allows DDoS attacks to succeed even when only a single computer is attacked.

In order to prevent DDoS across a permissioned network, each member must trust every other member to protect their computers.  If even a single member of the network is compromised and can communicate with outside attackers, transaction flow for the entire network can be shut down by merely attacking one computer at a time. 

To understand why this is the case, it’s important to understand how pre-Bitcoin consensus algorithms work. 

Leader-based algorithms such as Paxos, RAFT, PBFT and variants have existed for decades, and require a Leader or Coordinator. All nodes send all transactions to the Leader, and the Leader has responsibility for putting transactions in order and sending them to all nodes. Conventional databases can use these algorithms for ensuring consistency across all database instances.

Non-PoW blockchain algorithms invariably have a Leader. For example, members of the network might take turns publishing blocks of transactions. Because an attacker can predict who will next publish a block, the attacker can DDoS the appropriate member. 

Voting-based consensus algorithms enable a community to decide on a yes / no question, which can be extended to put all transactions in order. But even for a single yes / no question, there can be many rounds of voting, and in each round every peer sends a vote to all other peers, and perhaps even a receipt on each vote received. Voting-based systems don’t require a Leader, and as a result are resilient to DDoS attacks. However, voting systems have been around for decades, and few in the industry use them because of their gross inefficiencies in bandwidth.  


Next-gen algorithms offer hope

A new generation of algorithms is beginning to emerge that provides both high performance and high security without the need to trade one for the other. For example, Hashgraph-based consensus combines voting-based consensus algorithms with virtual voting, making it possible to have the benefits of voting-based algorithms without the need to send votes over the network.  The result is exceptional performance and DDoS resilience, without the need for inefficient and costly Proof-of-Work.

Today the most prominent platforms for creating private, or permissioned, distributed consensus networks primarily use Leader-based algorithms. For example, according to the official documentation, R3 Corda uses RAFT, and HyperLedger Fabric uses PBFT. As a result, each member must trust every other member to prevent malicious insider threats and malware infections that enable an attacker to DDoS the Leader. The good news is that both of these organizations have made clear that the currently used consensus algorithm is a pluggable component of their architecture. Clearly this decision was made in anticipation of a new generation of algorithms that will, for the first time, enable true ‘bank-grade’ security. Until then, it will be hard to ignore the elephant in the room.


Also read:
Public vs. private blockchains: It could all prove a bit like the cloud