What is Decentralised Consensus?
A decentralised consensus is an agreement of a decentralised network to authenticate and validate a transaction or a value, after which every distributed node shares and stores the same data and state to its persistent storage and so preventing malicious nodes from manipulating data with traditional centralised client-server architecture. There are a few parameters to consider a consensus mechanism, namely the authentication, data integrity, byzantine fault tolerance, decentralised governance, quorum structure, performance, and non-repudiation.
For instance, Proof-of-Work (PoW) is a computation-expensive mining protocol to work around the Sybil attack where a minority can control the whole network and cause the infamous double-spend problem. Proof-of-Stake (PoS) is more focused on the scalability and efficiency of the network handling block mining and transaction validation. For permissioned blockchains, it is all down to organisations or consortia running the blockchain network to determine its consensus protocol and process; however, the classic PoW consensus algorithm may not be a sensible choice as every node would be certified and authenticated to join the consortium network, thus computation-expensive on mining blocks could be unnecessary and so a more effective and scalable consensus protocol can be adopted. In short, the process of achieving a non-disputable agreement, amongst distributed nodes’ states, is termed as decentralised consensus.
Typical Consensus Algorithms of Permissioned Blockchains
The popular options of consensus algorithm for any enterprise blockchain solution, are ranging from Proof-of-Authority (PoA) on Ethereum, the Crash Fault Tolerant (CFT) algorithm, such as the Reliable, Replicated, Redundant, And Fault-Tolerant (RAFT) applied in Hyperledger Fabric and Consensys Quorum, to the Practical Byzantine Fault Tolerance (pBFT) like the Istanbul Byzantine Fault Tolerant (iBFT) applied in Consensys Quorum, which is an enterprise blockchain platform forked from the open-source Go-Ethereum (Geth) client of Ethereum with several protocol-level enhancements to support different needs of any proposed use case.
Which is the Best Consensus Algorithm to develop Enterprise Blockchains then?
Well, it really depends. PoA, RAFT and iBFT all offer absolute finality implying that a confirmed transaction cannot be reverted or annulled in any case. Both RAFT and iBFT, which are permissioned voting-based, offer immediate finality, where no fork is ever allowed to happen. While the permissoned lottery-based PoA Clique offers finality within the
(N / 2) + 1 blocks because each of those blocks are protected by a different signer sealing blocks based on the public key cryptography, thus forming a chain of digital signatures. It is therefore achieving proof of origin and data immutability for every transaction, which cannot be broken without majority of a network colluding together. The comparison of typical consensus algorithms of open-source enterprise blockchain protocol is listed as follows.
PoA Clique and PoA Aura both rely on a set of trusted authorities utilising a simplified messaging algorithm to achieve better performance than typical pBFT algorithms. There is only one round of messages exchanged among authorities in PoA, compared with at least three rounds in pBFT, namely the primary
commit stages respectively, excluding request and reply, to validate a transaction and sign a block once there are signatures amounted to
2 * N / 3 of a validation group, comprised of a validation leader by vote and a group of validators. pBFT requires 2 voting rounds for finality and a partially synchronous network given its message-heavy property of the consensus mechanism itself.
Therefore, better performance is one of the claims of PoA when measured against other permissioned voting-based algorithms, such as pBFT. PoA network can tolerate up to
N / 2 — 1 byzantine authority nodes. It could operate correctly when
N / 2 + 1 authority nodes are honest, compared with
2 * N / 3 in pBFT which is based on the optimal
N / 3 fault tolerance. Multiple validator nodes are allowed to propose any block. Contrary to pBFT, the design of PoA might sacrifice consistency for better availability so faster block committal but with eventual consistency guarantee once the forks get sorted out by the
GHOST protocol. PoA produces blocks at a configurable but fixed interval, regardless of whether there is any transaction to include or not, and PoA Clique is an appropriate choice for a network containing parties that do not trust each other. For instance, with a network of 4 blockchain nodes, 3 validator nodes and a node of consortium administrator, it would be up to
N — (N / 2 + 1)which is 1 validator node, for this case, can propose a block for any given block interval. An Ethereum PoA Clique is set up and run, with a sample block demonstrated below:
A Sample Block on Ethereum PoA (Clique)
instance: Geth/v1.9.25-stable/darwin-amd64/go1.15.5coinbase: 0x575267f8a7d44421adb4399a41c70f10ec8ef586at block: 62 (Sat Feb 06 2021 13:16:14 GMT+0000 (GMT)) modules: eth:1.0 net:1.0 rpc:1.0 web3:1.0> eth.getBlock("latest")
PoA Clique or Aura is a more appropriate choice than RAFT given its decentralised mechanism and signature-protected data immutability of validated transaction. For instance, validator nodes on the PoA Clique network take turns to validate transactions and sign a block for which the block sealing process is lottery-based amongst participating nodes of the network, instead of being executed by a specific leading validator node. While for RAFT, the consensus model assumed the elected leader node always acts honestly and correctly with followers blindly replicate state transitions proposed by the leader node with no further validation.
In Hyperledger Fabric, the elected leader node controls the order of transactions endorsed in a centralised ordering service of a channel aiming at fast finality on blocks. Blocks mined in a Quorum RAFT consensus network are not protected by signatures, as a result, blockchain data can be rewritten rather easily by modifying historical data, such as transaction inputs and recalculated block hash, transactions trie root, etc. RAFT consensus does not mint new blocks unless there are pending transactions. This would result in significant storage savings, but trade-offs are difficulty and security of the blockchain which could be lowered without any signature protection. The canonical chain is far simpler than its counterparts of enterprise blockchain protocols. Consensys Quorum networks with both consensus algorithms of iBFT and RAFT are set up and run, with sample blocks of both networks demonstrated below:
A Sample Block on Consensys Quorum (iBFT)
at block: 17 (Sat, 06 Feb 2021 12:32:11 UTC)
modules: admin:1.0 debug:1.0 eth:1.0 istanbul:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0> eth.getBlock("latest")
A Sample Block on Consensys Quorum (RAFT)
at block: 6 (Sat, 06 Feb 2021 12:45:21 UTC)
modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 raft:1.0 rpc:1.0 txpool:1.0 web3:1.0> eth.getBlock("latest")
Other Consensus Algorithms for Permissioned Blockchains
There are more consensus algorithms, with which development of permissioned blockchains and further to Enterprise blockchain implementations could be based on and suitable for building decentralised use cases in specific service sectors of supply chain industry or even of financial industry for addressing feasible use cases in advancing with decentralised finance (DeFi).
- Federated Byzantine Agreement (FBA)— The consensus protocols that both Ripple Blockchain and Stellar Blockchain (with refined version) are adopting. With FBA, there is no central authority and gatekeeper (normally administrator node could still be required for development of consortia in early stages). Every node on the network does not have to be known and does have a say on choosing nodes and multiple system-wide quorum slices (a subset of a quorum convincing other nodes to reach consensus) they trust for data sharing with state transitioned. Though the control and membership of FBA is decentralised and open without a concept of peer-permissing, its ability to handle security attacks such as the Sybil attack is in question, given the fact that each node on FBA could choose its own quorum slices which is not possible in traditional Byzantine Agreement systems.
- Proof-of-Importance (PoI) — A consensus algorithm introduced by NEM, determines which nodes on the network could mine “in NEM’s term — harvest” a block, based on an importance score given to the accounts held by individual nodes. The higher importance score means the more probable a block could be mined (or harvested) by the specific node. Accounts are expected to vest with specific amount of XEM in order to be eligible for importance calculation. Unlike Proof-of-Stake (PoS), where a node could mine a block is not merely based on the amounts staked, it is instead based on vesting, transaction partners, as well as the size and frequency of transactions processed in a specific preset period, of a specific node with accounts running on the network to be considered.
- Proof-of-Elapsed-Time (PoET) — Developed by Intel for use cases such as network entry verification in conjunction with its SGX (Software Guard Extensions) as a solution of Trusted Execution Environment (TEE), is also the consensus algorithm of Hyperledger Sawtooth, the modular framework in the setting of permissioned blockchain implementation. PoET is developed for enabling permissioned blockchain implementations to determine mining eligibilities and block winners, based on a randomly predefined wait time imposed, in every round of block-mining process, to each node under which a node with shortest wait time would be allowed to compute then mine a block. It is therefore claimed to be based on an elapsed time lottery random selection which is an alternative of PoW with better efficiency, less computation power consumption, and random block time given the random wait time imposed on every participant node.
However, the trust of these consensus algorithms is not implemented in an automated manner, and it normally requires human interference with preset parameters for permissioned blockchain development, such as choosing own quorum slices in FBA, setting the eligibility criteria of choosing nodes to be rewarded from block harvesting in PoI, or setting the waiting time period in PoET to determine the winner of a new mined block. Security risks could be expected on the chosen enterprise blockchain protocols with wrong configurations on these consensus algorithms.
While other than PoW, there are more popular consensus algorithms for which many public blockchain networks and dApps built on, are implementing with, such as Proof-of-Stake (PoS) and Delegated Proof-of-Stake (DPoS), for which ETH 2.0 and EOS are based on respectively. Discussions about these popular consensus algorithms will be covered in another article focused on existing public blockchain implementations.
Further analyses on consensus algorithms adopted in Enterprise Blockchain protocols, with performance tests performed on a variety of EVM-based consensus algorithms applied to the setting of Enterprise Blockchains for a specific use case of building decentralised supply chain anti-counterfeiting and traceability solutions for supply chain industry, are available on my research paper — An Empirical Analysis of Implementing Enterprise Blockchain Protocols in Supply Chain Anti-Counterfeiting and Traceability