Skip to content

Consensus

Abstract

This section describes the selection and usage of the consensus method or algorithm for a blockchain network.

Motivation

The choice of the consensus algorithm must be carefully evaluated and adapted to the respective situation. The governance model of consortium will massively guide the selection of the consensus algorithm.

The consensus protocol defines the technical communication protocol by which the state in the network converges onto a singleton state, by means of creating and appending new blocks. The consensus defines the common up to date state of the system creates new blocks. The security and integrity are based on it.

Consensus procedures are a crucial element of any blockchain network as they ensure that certain integrity and security guarantees of these decentralized systems are maintained. Agreement on the consensus and the implications of the chosen protocol is essential because the network has to use one and changing it one a for a running network is potentially expensive.

Elaboration

Types and Definitions of Consensus Algorithms

todo

Characteristics of Consensus Algorithms

todo

Examples for Consensus Algorithms

For the trust relationships in a consortial blockchain, the following concepts should be considered for choosing a consensus algorithm:

  • Proof of Authority (PoA)
  • Proof of Importance
  • Byzantine Fault Tolerance
  • Crash Tolerance
  • Proof of Elapsed Time (PoET, only available in Hyperledger Sawtooth on Intel CPU)

The following consensus algorithmus are not recommended for public permissioned blockchain networks.

  • Proof of Work is designed to be run in a permissionless network with untrusted participants
  • Proof of Stake (in combination with a PBFT consensus) necessarily requires a native cryptocurrency or token with a significant value

Before choosing a consensus algorithm the attack vectors and trust assumptions of the system need to be considered because they imply the level of fault tolerance, i.e. Crash Fault Tolerance vs Byzantine Fault Tolerance.

Crash Fault Tolerance protects against potential crashing nodes / nodes that experience frequent downtimes.

Byzantine Fault Tolerance protects against dishonest nodes. With this regards, quantifiable criteria for those aspects, should be defined (e.g. BFT with 2n + 1, or <50% faulty nodes).

Note that the safety of the network has to be evaluated against performance and costs considerations, while in addition, the acceptable intersection between safety and liveness needs to be defined and understood.

For a productive implementation it is recommended to use one of the Practical Byzantine Fault Tolerance (PBFT) consensus algorithms. This is used by Hyperledger Besu, among others.

However, the choice of the consensus algorithm must be carefully evaluated and adapted to the respective situation.

A further distinction needs to be made between PoA and PBFT. Both families of algorithms are well-suited for permissioned networks. However, there is a trade-off the members need to be aware of: PBFT favors safety, i.e. the instant finality of blocks, whereas PoA algorithms favor liveness, i.e. a stable block time without halts in the case of not reaching the ⅔ majority immediately. In both cases, the number of validators participating in the consensus is limited, either because of the communication complexity (PBFT) or because of the delayed finality (PoA).

Should the algorithm be optimized? As a rule of thumb, algorithms relevant for security should never be changed by end users or “optimized”. Instead, the standards defined by experts in the field should always be used. The correct selection of algorithms and their parameters requires deep knowledge of the field, and any deviation from the standard may create risks in other areas the user may not be aware of.

Unresolved Issues:

  • Maturity level of consensus algorithm
  • Various attacks can be mitigated by enforcing registered participants. This can be an easy solution for consortium blockchains

References to best practices, examples

There might be a number of different consensus algorithms, that implement concepts such as PoA:

  • AuRa or IBFT for PoA.
  • Practical Byzantine Fault Tolerance (PBFT, e.g. Tendermint, IBFT, BFT-SMaRt)
  • Raft

Govdigital

Govdigital decision 2020: Hyperledger Besu with IBFT2

Govdigital decision 2020: Go Etherum with Clique not production ready

Sovrin

We can look at the Sovrin Steward Technical and Organizational Policies as an example implementation:

Node Selection Algorithm

  1. The selection of active Validator Nodes at any point in time, at least on the Sovrin Main Network, MUST be governed by the Node Selection Algorithm as specified by the Sovrin TGB.

  2. Non-technical inputs or policy decisions implemented by the Node Selection Algorithm MUST be approved by the Sovrin Board of Trustees.

  3. At any point in time, the Node Selection Algorithm MUST represent the TGB’s best efforts at designing an algorithm that applies the Core Principles of the Sovrin Governance Framework. Recognizing the inherent tension and tradeoffs between some of the Core Principles, the design of this algorithm should give priority to balancing:

a. The Decentralization by Design principles, in particular the principles of Diffuse Trust and High Availability.

b. The Security by Design principles, in particular the principles of System Diversity and Secure Failure.

  1. A human-readable, understandable, and explainable description of the current design of the algorithm as approved by the TGB MUST be published by the TGB in the official Sovrin Code Repository and made publicly visible via a web page on the Sovrin Foundation website.

Hyperledger Besu

Hyperledger Besu offers a set of consensus algorithms:

Hyperledger Besu implements the following consensus protocols:

  • Ethash (Proof of Work)
  • Clique (Proof of Authority)
  • IBFT 2.0 (Proof of Authority)
  • Quorum IBFT 1.0 (Proof of Authority).

Comparing Proof of Authority consensus protocols

Besu implements the Clique and IBFT 2.0 Proof of Authority consensus protocols. Proof of Authority consensus protocols work when participants know each other and there is a level of trust between them. For example, in a permissioned consortium network.

Proof of Authority consensus protocols have faster block times and a much greater transaction throughput than the Ethash Proof of Work consensus protocol used on the Ethereum MainNet.

In Clique and IBFT 2.0, a group of nodes in the network act as signers (Clique) or validators (IBFT 2.0). The existing nodes in the signer/validator pool vote to add nodes to or remove nodes from the pool.

Bibliography of selected references

Sovrin Steward Technical and Organizational Policies

Hyperledger Besu Overview-Consensus

RFC-1008
Authors: David Maas, Ingo Keck, Andrei Ionita, Zoltan Fazekas, Kevin Wittek, Mirko Mollik
Status: work in progress
Last modified: 2021-03-16