Honey Badger BFT - Testing (SonnWende+ Project)

Authors: Thomas Zeinzinger, David Forstenlechner, Thomas Haller , Dietmar Hofer

Introduction

The use of blockchain systems in the energy sector has already received a lot of global attention and has prompted large and small utilities and grid operators to conduct various proof-of-concept studies. In the context of the SonnWende+ project, we have concluded that typical public blockchains have significant constraints in terms of throughput, latency and cost for many applications in the energy sector.

When dealing with reports about the performance of blockchain systems, one has to be careful about how to interpret various figures and claims. Oftentimes, TPS (transactions per second) is presented as the only relevant performance metric. There's two important caveats though: 1) TPS suggests to be a simple metric which allows for easy and meaningful comparisons of various transaction systems. That's however not the case, because the achievable TPS figure depends on a large number of factors and parameters, often with seemingly minor changes making a big difference. 2) While TPS is an important metric for many applications, it is by far not the only important one when it comes to a resilient blockchain network. Oftentimes, high TPS figures are achieved by running the network with a small number of participants (validator / miner nodes). But that's not that big of a challenge. As an example, the global payment network of Visa processes an average of about 4000 TPS [1] and can likely handle 10x during high demand.

To get a more complete picture, we have therefore looked at several important key figures to find a suitable blockchain system for the energy sector in order to improve on the relevant qualities.

Blockchain Trilemma

The term Blockchain Trilemma [2], coined by Vitalik Buterin (founder of Ethereum), describes the difficulty of reconciling decentralization, security and scalability. This is an extremely difficult problem, because although the throughput of a blockchain can be increased to about 1000 - 1500 TPS, there's usually tradeoffs regarding decentralization. This also means that security is no longer guaranteed to the same extent, because a concentrated attack or a simple power failure on the centralized blockchain system can paralyze everything.

The properties of a blockchain system are determined by several factors, but most importantly by the consensus protocol it employs. Bitcoin and many other blockchains use the proof-of-work consensus protocol [3] which is notorious for its enormous energy consumption - Bitcoin uses about as much power as the whole of Austria - 70 TWh [4].

In systems where anyone can participate in the block production, the transaction throughput is rather low. In order to keep the requirements in terms of computing power and network performance low - with the goal of allowing participation to as many people as possible globally - those systems are parametrized very conservatively. As a consequence, Bitcoin has currently a max. throughput of about 4 TPS and Ethereum of about 15 TPS. Ethereum is aiming to improve the already significantly lower energy consumption per transaction compared to Bitcoin by shifting the whole network to Proof-of-Stake [5] consensus. Delegated Proof-of-Stake (dPoS) or Proof-of-Authority (PoA) are solutions where the decentralization is reduced, leading to drastically lower specific energy consumption per transaction, shorter block times of about 4-5 sec. and significantly increased TPS numbers. Censorship resistance - i.e. resistance to the censorship of certain transactions - can unfortunately no longer be guaranteed in such systems. Another - often underestimated - problem is the usually unavoidable formation of blockchain bifurcations. This occurs when the distribution of transactions and blocks is not equally fast for every validator (or "block producer"), leading to two or more competing valid blocks being created at a given block height. In such situations, the so-called fork choice rule is used to decide which is the correct fork. In Proof-of-Work systems the leader selection for block production is determined by the fork choice rule and the fastest solution of a complex puzzle. In dPoS and PoA systems it is usually a round robin algorithm where one of the validators produces the block and the other validators check it.

In general it can be said that the use of dPoS and PoA systems leads to a significant increase in energy efficiency, thus reduced cost, but many scalability problems remain unsolved. A further problem is the often high hurdle for new participants to participate in the validator network. If these blockchain systems are not publicly available, requiring users to be whitelisted before allowing interactions, many advantages of blockchain systems are lost.

In systems providing high global decentralization and security, transaction cost will necessarily remain orders of magnitude higher than the cost of processing a comparable transaction in a simple centralized system - even in a Proof-of-Stake system as is envisioned for Ethereum 2.0. This is a challenge to price sensitive use cases e.g. within the energy sector.

Energy sector - Expectations towards Blockchain systems

Here we want to address the special requirements of the energy sector so that future productive implementations can be aligned with the technological systems. One of the basic prerequisites for the use of blockchain systems in the energy sector is their programmability (through so-called Smart Contracts). The Ethereum blockchain ecosystem was already highlighted as the leading system during the ComForEn 2018 conference [6], which is still valid one year later. Ethereum itself, however, currently has a very limited max. throughput of about 15 TPS. While this will change significantly with Ethereum 2.0 [7], it's not yet clear when the multi-phase process of transitioning to Ethereum 2.0 will be finished (it will likely take in the order of years) and what exactly the performance characteristics and constraints of this sharded system will be. Currently, the Ethereum blockchain is developing towards becoming a decentralized financial system. If the pace of innovation and growth in that space remains at current levels or keeps accelerating, it's not unlikely that even the transaction capacity of Ethereum 2.0 will quickly be saturated, driving transaction cost beyond what's sustainable for many energy applications.

We therefore assume that although Ethereum technology will be used in energy systems, many applications will either operate in networks other than Ethereum itself. How large and how open these networks will be cannot be foreseen yet and will certainly depend on the respective applications. In general, the security of blockchain systems is very high, but there are many influencing parameters, depending on the use cases. If for example a blockchain system is used to communicate sensor values for controlling an energy system, that would require a higher degree of security and reliability than a blockchain system which just timestamps data for public auditing.

SonnWende+ has investigated the following use cases:

Use Case	Est. Tx Load	Est. TPS / 100k People	Latency	Censorship Resistance	Finality
P2P Trading	5 Tx / 15 min. pP	~ 550 TPS	important (< 5 sec.)	very important	very important
Energy Account	1 Tx / day pP	< 1 TPS	important (< 5 sec.)	less important	less important
Transparent Crowdinvest	1 Tx / day pP	< 1 TPS	important (< 5 sec.)	n/a (full KYC / AML)	less important
Interactionless EV-Charging	5 Tx / day pP	~ 6 TPS	important (< 5 sec.)	important	important

Definitions: Latency - time until a transaction is added to a block | Censorship Resistance - ability of validators, block producers or pool operators to censor transactions | Finality - time until a transaction can't be reverted anymore or is highly unlikely to be reverted

The above table clearly shows that P2P Trading requires a very high throughput and also has the highest requirements in the areas of latency, censorship resistance and finality. Current node software and consensus algorithms are not yet suitable for fulfilling these requirements in real-world usage scenarios. We have therefore studied various consensus algorithms carefully in order to solve the problems mentioned above and finally arrived at the so-called Honey Badger BFT consensus, which, at least according to the tests conducted by A. Miller et al. [8], should be suited to deliver enough performance for applications like P2P trading on a blockchain system.

To confirm this, the HBBFT consensus algorithm had to be built into an existing node software and tested in a real environment. The node software from Parity Technologies ("Parity Ethereum") is already equipped with several consensus algorithms (aka engines) and has a substantial share among the nodes running the Ethereum mainnet. It is implemented in the programming language Rust, known for delivering superior safety guarantees while matching performance of the C++ programming language. We therefore decided to integrate HBBFT into Parity Ethereum, which comes with the benefit of having a codebase which is mature and constantly improved by the larger Ethereum community.

Honey Badger - An Efficient BFT Consensus Algorithm

Honey Badger BFT is the first practical asynchronous BFT (Byzantine fault tolerant) consensus protocol. Unlike most alternatives, it is also a leaderless consensus protocol and offers instant finality of new blocks. It uses threshold encryption to hide the contributions to a new block from other validators until the very point the block is finalized, providing high censorship resistance.

These properties result in a unique set of advantages over competing available BFT consensus algorithms, which we will explore in the following sections.

Latency

The high efficiency of Honey Badger BFT consensus follows directly from its asynchronous nature and instant finality.

Synchronous BFT protocols rely on specific timing parameters to assure the chain continues if a specific validator is not available or behaves maliciously. This results in the need to produce blocks at a specified interval, regardless if transactions are available for processing or not. The choice of those timing parameters has to balance the need for low latency execution of transactions with unnecessarily bloating the chain with a high frequency of empty blocks.

Also, synchronous protocols are sensitive to violations of these timing assumptions, either requiring long delays between blocks or sophisticated variable block time heuristics to adapt to changing network latency conditions (example: Tendermint). Typical choices for block time are 4-15 seconds, introducing a minimum time distance between blocks, limiting transaction latency and throughput, as visualized in the following diagram:

As an asynchronous protocol, Honey Badger BFT needs no such lower bounds and can start producing new blocks the moment new transactions are available for inclusion, while producing no blocks when no transactions are available.

It produces exactly as many blocks as needed, when they are actually needed - no more, no less:

Note that if the transactions do not fit into a single block an asynchronous protocol can immediately start creating more blocks until the transaction queue is empty ("bursts"):

Also note that the time it takes to create a block can vary widely depending on fluctuating network latencies on the Internet. Honey Badger BFT is uniquely equipped to adapt to these changing conditions, progressing as fast, or slow, as the network allows. This resilient behavior is in stark contrast to most other protocols which either completely stall or experience massive slowdowns if network conditions deteriorate beyond some threshold.

The latency in this case is the time it takes for the transaction to be included in the upcoming block.

Honey Badger BFT is highly efficient in terms of:

• Transaction Latency

  • Transactions are getting processed without artificial delay.

• Transaction Throughput

  • The frequency of blocks is not artificially constrained by a block time parameter

  • Creates new blocks on-demand, no mandatory waiting time between blocks.

• Disk Space

  • No empty blocks when there's no transactions

• Energy

  • Only produces new blocks in the presence of transactions to process - idle otherwise.

• Graceful degradation

  • Can always reach the maximum throughput possible with current network conditions

Instant Absolute Finality

With other consensus protocols in practical use today, the inclusion of a transaction in a block usually does not guarantee its continued presence on the chain, since the block is not instantly finalized. This results in further delays until the finality of the block is assured with a reasonable probability (so called confirmations).

As a leaderless consensus algorithm with the requirement of at least 2/3 of the nodes signing each block, Honey Badger BFT guarantees instant absolute finality [9] of newly produced blocks. This means that in addition to the efficiency advantages mentioned in the previous section, transactions can be considered final as soon as they are included in a new block.

Censorship Resistance

Most other available Byzantine fault tolerant consensus algorithms have to choose an author/leader per block who has full control over the block's content. That leader is free to choose the set of transactions (if any) to include in the next block and the ordering of those transactions, as long as the transactions are valid according to the protocol.

As a leaderless algorithm, Honey Badger BFT effectively prevents the withholding/censoring of transactions, because every participating node can contribute a set of transactions to every block.

To prevent any participating validator from knowing the contributions of others, a threshold crypto-system is used. The threshold for decryption is defined at exactly to the number of contributions required to finalize a block. This means that validators contributing to a block can only read the content of the individual contributions at the time the block is already finalized, effectively preventing censorship attacks against specific transactions. This concealment technique forms the basis for other advantageous properties described below.

Randomness

For many algorithms in computer science, a secure source of randomness is essential. An example for this is the consensus algorithm itself. Like many other PoS protocols, Honey Badger BFT relies on random selection of validators for each epoch. In Ethereum, this problem is usually solved with RANDAO [10], a commit-reveal scheme for generating providing randomness. Such a generic source of randomness is also known as Random Beacon.

It is essential for such beacons to be unpredictable before a new block of transactions is final. The threshold cryptography used by Honey Badger BFT provides such a guarantee. Combined with instant finality this results in a very robust environment for build business logic requiring secure randomness.

Every validator sends a random number as part of their encrypted contribution. As such it will only be decodeable when the block is already final, preventing any single validator from knowing the random number beforehand. The random numbers are combined using the "XOR" operation, assuring that as long as a single validator is honest, the number is unpredictable.

Frontrunning

The term frontrunning refers to an attack which doesn't violate the consensus protocol, but which often violates assumptions of applications. An attacker can take advantage of the time window between the broadcasting and the execution (via block inclusion) of a transaction by promptly adding a competing transaction in front of the intercepted one. This frontrunning transaction can change the state of a specific contract such that it takes advantage of the anticipated actions of the intercepted transaction, to the advantage of the attacker. In most public blockchains, block producers tend to order transactions by the fee they offer, thus it is enough for the attacker to offer higher transaction fees than the transaction it wants to frontrun. The attacker may also be a block producer itself, giving it almost total freedom in the picking and ordering of transactions.

The strict requirements Honey Badger BFT has on the order of transactions, combined with the availability of a secure source of randomness, makes frontrunning much more difficult. The random beacon can be used to shuffle transactions at the time the collection of transactions to include is final. No party can predict or manipulate the position of any transaction on the queue, effectively preventing frontrunning attacks. An attacker may still do probabilistic attacks by broadcasting many frontrunning transactions, hoping for at least one of them to successfully frontrun. But even that strategy could be mitigated by relaying transactions sensitive to frontrunning only to validators which the transaction author trusts to not participate in frontrunning themselves. In this case an attacker would not see the transaction before it's already part of a final block.

Honey Badger BFT - Performance Tests

To test our assumptions, we set up a Honey Badger BFT blockchain consisting of 7 validator nodes, providing a tolerance of 3 faulty nodes. The nodes were distributed on servers in Germany and Finland to approximate a real-world environment. The client software used was the Parity Ethereum client with our modifications to run the Honey Badger BFT protocol as consensus engine.

Test Infrastructure

The test network was run on 7 virtual servers of which 2 were set up in Finland by hetzner.de and 5 in Germany by netcup.de.

The specs of these servers were:

• 2 vCPUs

• 8GB RAM

• SSD Storage

Latency

Figure 1: Processing of transactions to include them into a block.

As shown in Figure 1 the latency is very low, reflecting roughly the time it takes to create a block. It cannot be overemphasized that Honey Badger BFT has instant finality, meaning the numbers reflect the time from sending the transaction to the time the transaction is final on the blockchain, a value often measured in minutes rather than milliseconds [11].

For comparison, another blockchain using the same test infrastructure was set up, running the AuRa consensus protocol [12] (also available in the Parity Ethereum client), configured to 4 seconds block time - a very low value for that protocol.

Figure 2: Latency comparison HBBFT vs. AuRa consensus with Parity client software

The orange line represents AuRa, the blue line Honey Badger BFT. The test results reflect the outstanding performance of Honey Badger BFT, with Aura at 2 seconds on average while Honey Badger BFT consistently stays below 1 second on average. Note that the numbers for AuRa - despite being considerably higher - don't yet denote time to finality, just time to block inclusion.

Throughput

Figure 3: Throughput in TPS over time for Honey Badger consensus with Parity client software

The property of instant finality requires a higher communication overhead compared to simple protocols like AuRa. This is reflected in a lower theoretical throughput, especially pronounced in newly started, empty blockchains. With chains of realistic lengths the consensus protocol is rarely the limiting factor - nevertheless, the roughly 450 tx/s shown in Figure 3 are in the range of P2P trading scenarios outlined above.

A number of potential optimization targets in the Parity client as well as in the Honey Badger BFT engine implementation have been identified and will be subject of future research, some of which are:

• More efficient transaction gossiping strategies

• Better compression of messages

• Improvements in transaction contribution selection

Conclusion

It was demonstrated that the Honey Badger BFT consensus algorithm can be used in the established Parity client and deliver a comparatively high performance and other very desirable properties needed for various energy sector specific applications.

Due to the low latency and instant absolute finality in combination with the high performance, we expect that after further improvements, this client will be a very good choice for both private and public networks. In a recent publication [13] the Honey Badger BFT consensus was also ranked high considering decentralization and throughput, but in contrast to the outlined limitation to 'permissioned' networks, we already can see how it can also be made available for 'permissionless' networks with a defined validator set, via the POSDAO protocol [14].

The conducted tests paint a good outlook for the Honey Badger BFT consensus algorithm to be applied in real live blockchain applications, which are definitely not limited to the energy sector alone, but can propel applications deemed to be impossible so far.

References

[1] VISA CSR Report 2018: https://usa.visa.com/dam/VCOM/download/corporate-responsibility/visa-2018-corporate-responsibility-report.pdf

[2] Blockchain Trilemma, Vitalik Buterin: https://github.com/ethereum/wiki/wiki/Sharding-FAQ#this-sounds-like-theres-some-kind-of-scalability-trilemma-at-play-what-is-this-trilemma-and-can-we-break-through-it

[3] Proof-of-Work: https://en.bitcoin.it/wiki/Proof_of_work

[4] Bitcoin Energy Consumption Index: https://digiconomist.net/bitcoin-energy-consumption

[5] Caspar the Friendly Finality Gadget: https://arxiv.org/abs/1710.09437

[6] ComForEn 2018 Tagungsband, p40: https://www.comforen.org/.cm4all/uproc.php/0/Tagungsbaende/ComForEn_2018_Tagungsband_final.pdf?cdp=a&_=1662e488e98

[7] Ethereum 2.0: https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/

[8] The Honey Badger of BFT Protocols, A. Miller et al.: https://eprint.iacr.org/2016/199.pdf

[9] Absolute Finality: https://medium.com/mechanism-labs/finality-in-blockchain-consensus-d1f83c120a9a

[10] RANDAO: https://github.com/randao/randao

[11] Blockchain finality: https://medium.com/coinmonks/blockchain-finality-pow-and-pos-35915a37c682

[12] AuRa Consensus in Parity: https://wiki.parity.io/Aura

[13] A Survey of Distributed Consensus Protocols for Blockchain Networks, Yang Xiao et al.: https://arxiv.org/pdf/1904.04098.pdf

[14] POSDAO: Proof of Stake Decentralized Autonomous Organization, I. Barionv et al.: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3368483