Let’s agree about the consensus
For me, it is one of the key design decisions when developing blockchain or distributed ledger solutions in corporate environments. Selecting the wrong consensus algorithm may condition the efficiency, performance, transaction rate, potential vulnerabilities, costs and required infrastructure for your product.
“A consensus algorithm is a process in computer science used to achieve agreement on a single data value among distributed processes or systems. Consensus algorithms are designed to achieve reliability in a network involving multiple unreliable nodes” [1]. In short, the consensus algorithm is responsible for making a Distributed Ledger Technology (DLT) work, ensuring its fault-tolerance. But how to select the optimal consensus for my project? Lots of different algorithms have been proposed so far for DLTs, and each of them have their own advantages and drawbacks. Let’s have a quick look at them, so you have a “go-to” cheatsheet of DLT consensus algorithms.
- Proof-of-work: The consensus algorithm par excellence. Not because it is the best, but because it was the first one implemented in a blockchain. Specifically in bitcoin, and is the one currently running on bitcoin and Ethereum. In proof of work, miners compete to add the next block (a set of transactions) in the chain by racing to solve a extremely difficult cryptographic puzzle. The first to solve the puzzle, earns some bitcoin for the inconvenience (and the amount of energy it consumed in the process). It has been shown secure for ten years in production (just have look at bitcoin). However, it has two main drawbacks: its throughput is pretty low, and the amount of computational energy required for mining is outstanding, not being, thus, suitable for medium to high throughput solutions or high-performance/efficiency products.
- Proof-of-stake: The potential successor of proof-of-work. Ethereum is already releasing test-nets with this consensus. In this type of consensus algorithms, instead of investing in expensive computer equipment in a race to mine blocks, a ‘validator’ invests in the coins of the system. In proof of stake, your chance of being picked to create the next block depends on the fraction of coins in the system you own (or set aside for staking). A validator with 300 coins will be three times as likely to be chosen as someone with 100 coins. This consensus is more energy efficient and, the fact that miners do not have to solve a hard puzzles, allow higher throughputs. However, as every node in the network is a potential validator, we can face the ‘nothing-at-stake’ problem, where nodes force forks in the ledger to earn double in the validation process. There are other alternative fault-tolerant consensus algorithms (which are not strictly PoS), such as IBFT, where in the block proposal stage not every node is a candidate. Modifications over byzantine fault-tolerant consensus and PoS algorithms seem to be, so far, the best solution for corporate environment and consortiums, where efficiency and performance are important, and nodes are “kind of trusted”. More about this in the next bullet point…
- Consensus inherited from distributed systems: For corporate environments, there is a new trend where traditional peer-reviewed consensus algorithms from distributed systems are being recovered, modified and implemented for DLTs. The fact that they are peer-reviewed mean that they have been well-studied and tested. Some of them are even used in production systems already. The most used, and preferred currently for DLTs are RAFT (Quorum, etcd), BFT/IBFT (Quorum, Hyperledger), Paxos (Neo4j, Hyperledger), etc. They may be good candidates for industrial blockchains, where some trust is sacrificed in benefit of higher performance, efficiency, security and throughput.
- Proof-of-activity: Proof of activity is a hybrid approach that combines both proof of work and proof of stake. According to the stage in the block validation process, it uses one or the other. It solves the ‘tragedy of the commons’ problem from proof-of-work, however, we still have the problem of low throughput and high energy consumption.
- Proof-of-burn: With proof of burn, instead of pouring money into expensive computer equipment, you ‘burn’ coins by sending them to an address where they are irretrievable. By committing your coins to never-never land, you earn a lifetime privilege to mine on the system based on a random selection process.
- Proof-of-elapsed time: This system works similarly to proof of work, but consumes far less electricity. Instead of having participants solve a cryptographic puzzle, the algorithm uses a trusted execution environment (TEE) — such as SGX — to ensure blocks get produced in a random lottery fashion, but without the required work. Thus, every participant is equally likely of being selected for the proposal of the next block according to a random timeout chosen in each node. This type of consensus algorithms along with other random-based consensus are already being implemented and evaluated in Hyperledger.
But the question is, can I chose the consensus algorithm to run on my blockchain technology? It is true that, for now, you can not change the consensus algorithm used in Bitcoin. However, all the blockchain technologies designed for corporate environments already enable you to plug in your desired consensus. This is the case of Quorum, Hyperledger, and even Ethereum. Thus, in the design of our blockchain solution we don’t need to adapt to a specific consensus algorithm to fuel our Distributed Ledger, but we can select the algorithm that best suits our use case. This provides an additional degree of freedom in the design of DLT systems. Through this, we can act over the security, performance and throughput of the system at the same time, instead of adapting to the specifics of a “forced-by-design” blockchain consensus (as limiting as this is).
Nevertheless, it is true that designing from scratch a consensus algorithm is pretty hard. There has been a lot of academic research on this end, and this is why I recommend, unless you have an expert on distributed systems in your team and you know what you are doing, to use an implementation of well-known, tested, and preferably peer-reviewed consensus algorithms for your systems.
The following image depicts a summarised comparison of different types of consensus algorithms according to three main features (where, for instance, PoS and BFT are voting-based, and Proof-of-elapsed time lottery-based). This is a good head-start when evaluating an optimal consensus algorithm for you system.
In upcoming posts I will introduce some examples of the steps to follow in order to select the best consensus algorithm for an specific project or use case, so stay tuned!.
[1] http://whatis.techtarget.com/definition/consensus-algorithm
[2] https://www.coindesk.com/short-guide-blockchain-consensus-protocols/
