What is the Blockchain Consensus Protocol?
Cryptocurrency and blockchain terminology can be difficult to handle at times. As crypto tends to function in ways that are wildly different from the traditional monetary system, explaining it in a way that the average person can understand can be difficult.
One of the most challenging concepts in crypto is consensus, or how a group of strangers can come together to decide toward the governance of the system. As crypto is trustless, the consensus system must be, too; presenting challenges for those that must design the system and for those that must place blind faith into the system’s decision-making.
This article will look at how this is done.
What is Consensus?
Wikipedia defines “consensus” decision-making in this way: “Consensus decision-making is a group decision-making process in which group members develop, and agree to support a decision in the best interest of the whole. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the ‘favourite’ of each individual. Consensus is defined by Merriam-Webster as, first, general agreement, and second, group solidarity of belief or sentiment.”
In a group with known members, consensus-making constitute what is politics. It is the weighing of contrasting ideologies against personal biases, desires, and prejudices toward finding a solution that works for the group. Sometimes, this works efficiently and everyone is happy, but usually, one group’s personal desires or fears drown out any semblance of compromising to the point that the other side gives in to prevent a full collapse of the system. Occasionally, a compromise is reached that satisfies no one and that forces the issue to be re-examined under a harsher lens at another time, and sometimes, no decision is made, and the issue is pushed further down the road.
The point is that politics is a difficult matter. It is the science of how people collectively decide, and understanding it fully requires a master’s understanding of psychology, sociology, anthropology, theology, and linguistics. For most of us, we just fumble through it, trying to make sense of it as we go.
Now, what would happen if you took this political confusion and place it in a system where the participants are unknown? Would you be able to trust that everyone in the system has the interest of thee system in mind? What if an outside force started tampering with votes. How would you be able to tell? Could you honestly trust the decision of such a system?
This is a well-known problem in computer science known as the Byzantine Generals Problem or Byzantine Fault Tolerance. In a large computer system, individual components like servers and data clusters must be polled to solve complex problems. The central processor must be able to trust the component’s work, even though the processor may not be aware that the component is malfunctioning, the component itself may not know that it is malfunctioning, or the data line between the processor and the component may be compromised. To solve this, both the processor and the component must be able to “prove” the legitimacy of its communication.
“A reliable computer system must be able to cope with the failure of one or more of its components. A failed component may exhibit a type of behavior that is often overlooked–namely, sending conflicting information to different parts of the system.,” Leslie Lamport, Robert Shostak, and Marshall Pease of SRI International wrote explaining the Byzantine Generals Problem. “The problem of coping with this type of failure is expressed abstractly as the Byzantine Generals Problem. We devote the major part of the paper to a discussion of this abstract problem and conclude by indicating how our solutions can be used in implementing a reliable computer system.”
“We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement. The generals must have an algorithm to guarantee that A. All loyal generals decide upon the same plan of action. The loyal generals will all do what the algorithm says they should, but the traitors may do anything they wish. The algorithm must guarantee condition A regardless of what the traitors do.”
“The loyal generals should not only reach agreement, but should agree upon a reasonable plan. We therefore also want to insure that B. A small number of traitors cannot cause the loyal generals to adopt a bad plan.”
“Condition B is hard to formalize, since it requires saying precisely what a bad plan is, and we do not attempt to do so. Instead, we consider how the generals reach a decision. Each general observes the enemy and communicates his observations to the others. Let v(i) be the information communicated by the ith general. Each general uses some method for combining the values v (1) ….. v (n) into a single plan of action, where n is the number of generals. Condition A is achieved by having all generals use the same method for combining the information, and Condition B is achieved by using a robust method. For example, if the only decision to be made is whether to attack or retreat, then v(i) con be General i’s opinion of which option is best, and the final decision can be based upon a majority vote among them. A small number of traitors can affect the decision only if the loyal generals were almost equally divided between the two possibilities, in which case neither decision could be called bad.”
In crypto, there is no consensus on how to find consensus. The original idea came from the creator of bitcoin, Satoshi Nakamoto. “To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back’s Hashcash, rather than newspaper or Usenet posts,” Nakamoto wrote in his whitepaper. “The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.”
“For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block’s hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.”
“The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.”
“To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they’re generated too fast, the difficulty increases.”
The method Nakamoto described – proof-of-work – requires “miners” or computer nodes running the bitcoin software to solve a calculation-intensive equation that utilizes transactions as input. Since this transaction takes time and energy to perform, it represents a “stake” to serve as the miner’s proof of sincerity. The equation itself is designed to make verification of the transaction much simpler than establishing it in the first place.
Proof-of-work requires every node to verify the transaction and agree that it is valid, although only a few verifications are needed to assume acceptance. This is energy-intensive. The way this works is this:
- A sender and a receiver wish to trade bitcoin. The sender sends the order using his/her wallet, which transfers the public keys for the coins from the sender to the receiver. The wallet creates a transaction by affixing its signature to a transaction file (since SegWit, the signature is hashed separately and affixed to the end of the transaction file), adding the sending and receiving wallet addresses and the transmitted coins’ ID. To this transaction, it affixes a nonce (number only used once) that effectively randomizes the transaction. The combined string is then hashed twice using the SHA-256 algorithm and is examined by the wallet software. Only if the resulting hash meets certain specifications, such as having the right number of leading zeroes, is the transaction broadcasted to all nodes on the network.
- The hashed transaction is added to the node’s input pool, which handles transactions by the size of their wallet-designated transaction fee. On SegWit-compliant nodes, the signature is removed from the transaction file, verified, and affix to its own ledger. The rest of the transaction is verified and placed in the current block.
- Throughout the verification process, the node will attempt to guess the address of the next block. To do this, it will take to content of the current block, add a nonce, and double-hash it using the same algorithm the wallets use. The node will convert the resulting hash from 64-bits to 32-bits. If the resulting address works (have the right number of zeroes, is greater than the current address and less than the “target,” etc.), the node broadcast a “stop order” to all the other nodes, along with the winning address. The node creates a block with this address and start adding verified transactions in it. If it does not guess correctly, it will continue verifying and it will try again with a new nonce until it finds the address or until it receives a “stop order” from another node.
- Correctly guessing the address awards the node the coins for that block, but only after a certain number of blocks have succeed it.
While this makes it extremely hard to hack a proof-of-work system, it is not impossible. A hacker would need to gain more than 50 percent of the hashing capability of the network, but if he/she can get it, he/she can fork the blockchain, double-spending the coins of any block he/she choose to “re-prove.” For smaller networks, “51 Percent Attacks” are common.
Additionally, proof of work is highly energy inefficient and is proving to be a drain on the global electrical network. Fortunately, there are other options:
Proof-of-stake: Per Hackernoon: “Unlike PoW where new transaction blocks are created based on computational work done by solving a complex cryptographic puzzle, PoS allows a forger (instead of a miner) to stake any amount of cryptocurrency she has, to be probabilistically assigned a chance to be the one validating the block — the probability based on the amount of cryptocurrency staked.”
“Additionally, for most PoS systems, instead of receiving a cryptocurrency reward (in the above case, the Bitcoin miners receives some Bitcoins for solving a PoW), the forgers instead takes the transaction fees as rewards.”
“The idea of putting coins to be ‘staked’ prevents bad actors from making fraudulent validations — upon false validation of transactions, the amount staked will be forfeited. Hence, this incentivises forgers to validate legitimately.”
Delegated Proof-of-Stake: “DPoS is similar to PoS in regard to staking but has a different and a more democratic system that is said to be fair. Like PoS, token holders stake their tokens in this consensus protocol.”
“Instead of the probabilistic algorithm in PoS, token holders within a DPoS network are able to cast votes proportional to their stake to appoint delegates to serve on a panel of witnesses — these witnesses secure the blockchain network. In DPoS, delegates do not need to have a large stake, but they must compete to gain the most votes from users.”
“It provides better scalability compared to PoW and PoS as there are fully dedicated nodes who are voted to power the blockchain. Block producers can be voted in or out at any time, and hence the threat of tarnishing their reputation and loss of income plays a major role against bad actors. No doubt, DPoS seem to result in a semi-centralised network, but its traded off for scalability.”
Proof-of-Authority: “PoA is known to bear many similarities to PoS and DPoS, where only a group of pre-selected authorities (called validators) secure the blockchain and are able to produce new blocks. New blocks on the blockchain are created only when a super majority is reached by the validators.”
“The identities of all validators are public and verifiable by any third party — resulting in the validator’s public identity performing the role of proof of stake. As these validators identity are at stake, the threat of their identity being ruined incentivises them to act in the best interest of the network.”
“Due to the fact that PoA’s trust system is predetermined, concerns has been raised that there might be a centralised element with this consensus algorithm. However, it can be argued that semi-centralisation could actually be appropriate within private/consortium blockchains — in exchange for better scalability.”