POA Network: How Honey Badger BFT Consensus Works

POA Network
Nov 9, 2018 · 14 min read
Image for post
Image for post

Reaching Consensus

Blockchain networks allow transaction processing and recording across an entire network. Every node in the network contains a record of all transactions in the blockchain, creating transparency and eliminating the need to rely on a central authority.

  1. Nodes process and order these transactions.
  2. The transactions are grouped into blocks.
  • which transactions to discard
  • the indisputable and unchangeable order of valid transactions

Consensus Types

Nakamoto Consensus

Nakamoto consensus is commonly referred to as Proof of Work. It is currently used with Bitcoin, Ethereum, and several other cryptocurrencies (although Ethereum plans to change models in the future).

Non-mining Consensus

By eliminating mining, these consensus methods (which include specified nodes running consensus protocols) address the scalability problems that can impact distributed networks. Non-mining consensus may utilize Proof of Stake (POS), Delegated Proof of Stake (dPOS), Proof of Authority (POA), or other means to designate network nodes responsible for validating transactions. Consensus mechanisms like practical Byzantine Fault Tolerance (pBFT), Honey Badger Byzantine Fault Tolerance (HBBFT), and others are used to ensure agreement is achieved among these nodes.

  1. Leaderless consensus. Unlike pBFT, the HBBFT consensus mechanism does not require a leader node to propose transactions. Every node is a proposer. This eliminates potential attacks where a leader node can be stalled indefinitely, bringing the entire network to a halt. For more information and a demonstration of this attack, see section 3.2 in the The Honey Badger of BFT Protocols paper.
  2. Efficient, secure message distribution. Based on algorithms developed by Miller et al., the Honey Badger library uses several techniques to effectively encrypt, split and send messages in small chunks. This saves bandwidth and creates an extremely efficient process.

HBBFT Architecture

At POA Network, we are excited to implement the HBBFT protocol in Rust. Rust is a systems programming language that prevents many classes of programming errors without sacrificing efficiency, and provides opportunities for integration with blockchain clients like Parity.

Image for post
Image for post

Queueing Honey Badger (QHB)

QHB is the top level algorithm, responsible for taking in potential transactions and returning validated batches of transactions that are ready to be turned into blocks. Each validator node in the network runs an instance of QHB, and all other processes are contained and run within that instance of QHB.

Image for post
Image for post

Honey Badger (HB)

Honey Badger is a management layer, responsible for keeping track of epochs and encrypting and decrypting messages.

Image for post
Image for post

Subset

Subset is the main functional component of the Honey Badger consensus process. This is where agreement takes place. Subset receives a contribution from each validator node and returns a subset of contributions agreed upon by all validators.

Image for post
Image for post
  • f = the maximum possible number of faulty validators. f = (N-1)/3.

Reliable Broadcast

The purpose of Reliable Broadcast is to distribute a single node’s contribution to the rest of the nodes in the network. A contribution is input into one node and output into every other node’s RB instance. Reliable Broadcast guarantees that every node gets the same output, even if the sender or other nodes try to cheat (for example, by sending different information to different nodes).

Image for post
Image for post

Binary Agreement

Binary Agreement is at the core of the agreement process. This algorithm determines whether or not a contribution is included in the Subset, based on a composite of votes from all nodes in the network.

Image for post
Image for post

Putting it all together: The Honey Badger Transaction Flow

Now that we’ve provided an overview of the main algorithms in Honey Badger, let’s attempt to follow an imaginary transaction from a user’s wallet to finality on a blockchain. Please note that Honey Badger is not yet live; this transaction flow is hypothetical. POA network currently uses Aura (Authority Round) consensus to validate transactions.

  1. A node on the blockchain receives this transaction request through an internet request. The node is running Parity in order to interface with the blockchain.
  2. The node inputs this transaction into HBBFT, starting with Queueing Honey Badger (QHB). QHB places this transaction, along with others it has received, into a queue of pending transactions.
  3. A new epoch begins. A random process determines which transactions to include in the next block. Your transaction is selected to be a part of the next contribution!
  4. QHB prepares a list. There are 21 validators in the network, so the list size is 1/21 the size of a block.
  5. The list of transactions is submitted to Honey Badger. HB encrypts the list using threshold cryptography, creating a garbled version that contains your transaction but can’t be read.
  6. The contribution is submitted to the Subset Algorithm.
  7. Subset puts it into a Reliable Broadcast instance labelled with the node id (for example Node 1). This distributes the contribution to every other node in the network.
  8. Once every node has received the encrypted contribution, via RB, they know that all other correct nodes will also receive this contribution. They vote Y in the Binary Agreement instance labelled ‘Node 1’.
  9. Every node then returns Y for the Binary Agreement instance labelled Node 1, meaning they all agree that this contribution should be included as a part of the next block.
  10. Agreement has been reached! The contribution flows back up the stack.
  11. Subset returns to HB 21 contributions by 21 nodes, all are encrypted (note, this could be fewer contributions, as long as it is greater than ⅔).
  12. Back in HB, the whole network collaborates to decrypt the contribution. Every node gets 21 lists of transactions which are decrypted. These lists include the original transaction.
  13. QHB then makes a union of the contributions and creates a single finalized list of transactions that all nodes have agreed on.
  14. This final list is sent out of QHB and back to the application client (Parity).
  15. Parity executes the transaction and declares it as a part of the next block. 200 POA are officially transferred to your friend’s wallet, and the results can be viewed in BlockScout.


POA Network

Open, public, permissioned network based on Ethereum…

POA Network

Written by

Public platform for smart contracts. An open Ethereum sidechain with Proof of Authority (PoA) consensus by independent validators.

POA Network

Open, public, permissioned network based on Ethereum protocol with Proof of Authority consensus, reached by independent pre-selected validators. Join our discussion on Telegram:https://t.me/joinchat/FlX0FD_ndCsB4_n60sCu2w

POA Network

Written by

Public platform for smart contracts. An open Ethereum sidechain with Proof of Authority (PoA) consensus by independent validators.

POA Network

Open, public, permissioned network based on Ethereum protocol with Proof of Authority consensus, reached by independent pre-selected validators. Join our discussion on Telegram:https://t.me/joinchat/FlX0FD_ndCsB4_n60sCu2w

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store