The Byzantine Generals’ Problem describes a dilemma related to consensus. In this classic problem, a group of generals must come to an agreement about attacking or retreating from an enemy stronghold. However, they are located at different points around the perimeter of the city and have no way to communicate other than sending messengers back and forth. To complicate matters, there may be malicious (Byzantine) generals who will purposefully send incorrect information.

If they all attack, they will win. If they all retreat, they will live to fight another day. However, if some attack and some retreat, the attacking armies will suffer catastrophic losses. In this case, reaching a reliable consensus is a life or death situation.

Without digging too much into the details, it is known that an agreement to attack or retreat can be reached as long as fewer than ⅓ of the generals are Byzantine. They reach agreement by passing signed messages back and forth. Signatures cannot be forged, and any general can verify any other general’s signature.

The same principles hold true for blockchain BFT consensus. Less than ⅓ of the nodes (generals) in a blockchain can be malicious, signed messages are sent back and forth in multiple rounds, and signatures must be cryptographically secure and verifiable.

BFT in the modern age

In a distributed networking environment (e.g. a blockchain), some form of BFT is vital to maintaining functionality, security and reliability. However, there are issues with current implementations.

Many BFT networks rely on timing assumptions in order to complete messaging rounds. Timeout parameters are selected and ‘tuned’ or changed if there are difficulties with message delivery. This can result in non-optimized networks, slow recovery time, and vulnerabilities to attacks involving message scheduling. Some BFT protocols (such as Nakamoto consensus — commonly called proof-of-work) do not produce block finality. In other words, blocks may be mined at the same time by several miners, resulting in a temporary dual-chain state. This can result in long waits before a transaction is verified, and transactions can be removed all together if they only exist on the short chain. Proof-of-work blockchains are notorious for their vast use of computational power and unsustainable energy consumption. For insight into this issue, see Bitcoin’s Growing Energy Problem and Decarbonizing Bitcoin. BFT protocols can create slow throughput rates and inefficient data transfer.

Honey Badger BFT addresses these issues, and POA Network’s implementation will provide an efficient consensus protocol that maintains both liveness (the network continues to make progress) and safety (all honest nodes eventually reach consensus) through a range of network conditions.

Why we need Honey Badger BFT

Evolving Network Types

As noted above, PBFT has been around since 1999. A lot has changed since then! Future blockchain networks may be comprised of mobile phones, IOT devices, and many other types of nodes. These networks run at varying speeds, and timing parameters are difficult to set correctly. Networks like TOR also provide additional security but introduce significant variance in data transport speeds.

HBBFT solves the timing problem, as there are no timing parameters! Honey badger doesn’t care! It is an asynchronous protocol where transactions can arrive at different times to different nodes. The only assumption we make about message delivery is that messages will eventually be delivered. The block rate matches the network speed.

Advanced Adversaries

Blockchains are an enticing target for attackers. They hold billions of dollars in cryptocurrency, and ledgers can store contractual agreements, proof of ownership, legal records, and other sensitive information. As blockchain technology matures, so do the breadth and depth of attacks. DDOS attacks, where a node is flooded with incoming messages it cannot process, are more effective on networks that rely on timeouts to proceed. Attacks designed to hit message scheduling can freeze a network completely.

HBBFT offers several features to guard against attacks:

Asynchrony allows for message delivery even if a network is under duress. Some messages can be delivered and others can be delayed, but progress will still be made.

Agreement occurs on a batch of encrypted transactions; the transaction contents are only revealed after consensus has been reached. This prevents censorship attacks where information is selectively held back by a malicious node. If a node doesn’t know what is in a message, it can’t suppress specific information.

Malicious nodes can be identified and are reported through a fault log. Networks can then decide the best methods to remove them.

Improved Efficiency

Most people who use the blockchain are interested in faster transaction times. Cryptography and other security measures are resource intensive, and security is always the first priority. However, small changes to how transactions are delivered can result in faster speeds and more scalable networks.

Node communication is optimized in HBBFT. Every block is assembled from several nodes’ proposed transactions, so each node only sends a percentage of the total transactions that make up a block. These proposals are further segmented by something called Reliable Broadcast, where nodes split and distribute their proposal segments to other nodes in the network. This creates smaller, consistent data packets and faster block production rates.

In addition, the HBBFT protocol provides instant block finality. A block is only produced after the transactions have been finalized by the validating nodes in the network. If a block is signed by the validators, it is finalized, even if it is the latest block. This prevents transitory forking and creates an immutable, immediate ledger of transactions.

Additional consensus options

Different networks may want to choose from a number of consensus protocols depending on the applications they are running. The ability to choose between a number of protocols is important, especially for private chains designed for different purposes.

So, how does it work?

Stay tuned! In our next post we will explore the inner workings of HBBFT and provide a high level overview of how the individual algorithms work together to create a robust consensus protocol. This will highlight some of the advanced methods and cryptography required to secure the next generation of blockchains.

In the meantime, please checkout our GitHub page to view the open source code.

POA Network and Honey Badger

POA Network is busy building, testing and optimizing the HBBFT consensus in the Rust programming language. Other groups are simultaneously implementing HBBFT in additional languages, including Python, Go, and Erlang.

Over the next several months, we will continue streamlining our instance of HBBFT as we prepare for a security audit. We are currently creating the ‘Honey Badger of test suites’ in order to ensure adversarial scenarios are accounted for. We will continue to share updates as we work to optimize and integrate HBBFT into the existing blockchain ecosystem.

Warmly,

POA Network Team

Connect with us:

Website: https://poa.network/

Twitter: https://twitter.com/poanetwork

Medium: https://medium.com/poa-network

Forum: https://forum.poa.network/

Reddit: https://reddit.com/r/poa