In our previous 101 articles which you can find on our Blockchain Consensus blog, we have explored blockchain, cryptocurrencies, ICOs and blockchain-based smart contracts. This article focusses on an often used but seldom understood piece of technical jargon which often accompanies this field: the consensus protocol.
Because of the complexity, we’re breaking this article down into a number of instalments, with this instalment representing an introduction to consensus protocols as a concept (distinguishing between confirmation mechanisms and consensus rules), and future instalments providing a deep-dive into specific ‘flavours’ of consensus protocols, e.g. proof of work and proof of stake.
What is a consensus protocol?
Information recorded on a blockchain can digitally represent nearly anything, from a transfer of money, ownership, or liability to an individual’s identity, rights and obligations or energy usage. However, achieving consensus, i.e. some agreement between all network participants as to the state of such digitally represented information at a given point in time, poses a significant challenge.
Each network participant (node) has its own view of the state of the ledger at a given time, meaning at any one time, there will be as many views of the state of the ledger as there are nodes in the network. In order to make the ledger fit for purpose (i.e. able to reconcile differences and record transactions in a harmonious fashion), we require a set of rules and processes (a consensus protocol) which allows all of the nodes to agree on the ledger state and update their respective views accordingly.
A blockchain seeks to overcome this challenge in two ways:
- it adopts a confirmation mechanism which needs to be satisfied in order for a block of information to be appended to its ledger (thereby reducing the number of possible ledger states at any given time); and
- where multiple entries have satisfied the confirmation mechanism and have each been appended as blocks to the chain (i.e. splitting the chain into multiple versions of ‘the truth’), it implements a concrete rule for establishing consensus as to which chain is the ‘valid chain’ and will continue to be used moving forwards.
A brief note on terminology – most sources will tell you that concepts such as ‘proof of work’ and ‘proof of stake’ are examples of consensus protocols. This is not technically accurate – rather, they are examples of confirmation mechanisms (i.e. that referred to at 1 above). The consensus protocol, as defined in the strictest sense, is that referred to at 2 above and, happily, is often much simpler. Subsequent instalments of this article and mini-series will use the term ‘consensus protocol’ more broadly, encompassing both 1 and 2 above. Nevertheless, for the purposes of this article we will seek to be very precise in our terminology and explore both 1 and 2 separately and in turn.
- Confirmation mechanismCrafting precise and exhaustive definitions of computational terms is often difficult in the abstract but this article adopts the following definition:
“A confirmation system is simply a set of rules and processes which set out how a blockchain network’s nodes (i.e. the distributed network of computers which collectively store and process the blockchain ledger) record and validate ledger entries and commit blocks to the chain.”
There are a number of ‘flavours’ of confirmation mechanisms, depending on how its rules and processes are constituted. The flavour of confirmation mechanism incorporated by a blockchain will have a direct impact on its characteristics and efficacy by determining fundamental aspects of its performance such as its throughput (i.e. the rate at which it can process information), latency (i.e. the ‘lag’ between the delivery of an instruction and the execution of that instruction) and security (i.e. the way in which a blockchain protects itself from nefarious actors and tampering of its ledger). Confirmation mechanisms can also be used to incentivise desirable behaviours of its nodes by integrating rewards mechanisms.
Future instalments of this article will unpick some of these flavours, how they work and their respective strengths and weaknesses.
- Consensus rule
At any given point in time, each node will only have a partial view of the ledger. As a result, sometimes two or more ‘candidate blocks’ will link to the same predecessor.
Figure 1: competing chains
In such an eventuality, there needs to be a clearly defined rule which identifies the ‘active’ branch for subsequent blocks to be appended to. This is important, as one of the key functions of a blockchain-based ledger is to provide a single ledger which is maintained in real-time. The rule adopted by most blockchains here is simple – the block which satisfies the confirmation mechanism first ‘wins’ and is broadcast to the network as the latest block, a hash of which needs to be included in the following block.
Now imagine two nodes, one operated by Anne in Hong Kong, the other by Ross in New York, each with an incomplete view of the ledger. Anne’s node may satisfy the confirmation mechanism and begin to propagate his new block to the network. In the meantime, Ross’ node may also satisfy the confirmation mechanism and begin to propagate his new block to the network. Two ‘valid’ chains now exist and, by the time Anne, Ross and the entire network hears of the other ‘rival’ chain, they may have committed significant work and resources to trying to satisfy the confirmation mechanism for ‘their’ chain.
Where two ‘valid’ chains exist, it becomes a race to append the next block on one of the chains. A basic consensus rule is that new blocks be appended to the longest available chain. If the new block (Block 5a) is appended to branch A before a block is appended to branch B, branch A becomes the longest chain and is therefore accepted by the whole network as the ‘valid chain’ moving forwards.
Figure 2: competing chains – the first branch to append a new block ‘wins’
The shorter branch, i.e. branch B in the above, is discarded by the nodes which now focus all of their work and attention on branch A. The discarded branch is referred to as an ‘orphan’.
This article represents a very high-level introduction to what is an interesting and multi-faceted topic. The ‘meat’ of the topic is focussed around the confirmation mechanism and the different flavours thereof. These go to the very heart of the blockchain design and shape the blockchain’s efficacy and specific use-case applicability. Further instalments of this article will explore a couple of the better known flavours, in more detail.
If you have any questions regarding blockchain technology or how a blockchain solution might impact you or your business, please get in touch – firstname.lastname@example.org.