Consensus Mechanism Rabbit Hole: Part II —Laying a Foundation for Deeper Exploration
In continuing with this series, but before diving deeper into the granularities of the timeline of each of the major consensus mechanisms, it is important to more specifically define what these tools do- and provide some definitions for those new to both the Web3/ Crypto/Blockchain space and these concepts, so that their ability to understand, conceive opinions, and contribute to the conversation are optimal.
A formal definition of Consensus Mechanism is a protocol for validating transactions that all participants in the network agree to abide by honestly and for which they invariably are rewarded.
So let’s break this definition down for the freshmen in the crowd. A protocol is a defined set of rules and regulations, while validation is a prescribed system of approval of a transaction.
The participant group represented in the definition centers around Nodes. Formally, a node represents “any system or physical device that is connected to a network and can execute certain functions like creating, receiving or sending information via a communication channel” (Alexandria). In more layperson terms, anyone who either supplies their physical device (sometimes called “bare metal”) or subscribes to a VPS hosting service(virtual private server), to store the blockchain ledger for the purposes of securing the network is a node. More simply even, the device I tap away on right now is a node when I download a particular blockchain distributed ledger (comprehensive history of blocks on that chain) on it. If my device has this ledger, meets the requirements to be a network node, and is equipped with any additional necessary blockchain specific elements (operating system etc), then it qualifies as a node. The term distributed ledger technology (DLT) simply means that the ledger (full history of blocks, in a chain) is distributed amongst and across all those running the same set up on their devices. Hence, a network of nodes. Devices classified as nodes can be categorized as miners, validators, or another function-based moniker. For our purposes, we will focus on these two as they are most relevant in the study of Consensus Mechanisms.
For a little more clarification, and to provide as comprehensive a foundation for the increasingly technical components of this series, blockchain is defined “as a chain of chronologically ordered and cryptographically linked blocks (Perboli, Musso, & Rosano, 2018). These blocks contain transaction information that is sent across the network for validation. When a block is to be appended (added) to the blockchain, the consensus mechanism ensures that the transactions included in the new block are valid and approved by the majority of the nodes. (Haouari, et al) This concept of majority is tied to what is called the Byzantine Generals Problem or Byzantine Fault Tolerance.
If it is not already obvious, the primary purpose of this design is security. With people investing financial resources into cryptocurrencies, the stability and safety of the individual’s investment is paramount. It takes tremendous trust in the functionality of the network to trade one’s hard-earned fiat (centralized government issues money) for a cryptographically secured asset. Further, one must also trust that no matter how big (scaled) an asset grows, that the functionality of the network and consensus mechanism will always work as safely, stably, and securely as intended.
Also, new inhabitants of the space, or those exploring to dip a metaphorical toe into the crypto waters, might notice is that the purpose of crypto assets is to decentralize the global financial system, thus removing third party intermediaries (governments) as the obstacle to humankind’s path to financial freedom, wherever they are on the planet. The more distributed the network, the less centralized, the more freedom users have.
That said, all of this comes with concerns and challenges. The primary of which are commonly referred to as The Trilemma, which is a belief that the system can only have 2 of the 3 aforementioned prioritized conditions: decentralization, scalability, and security. In the short history of cryptocurrency, designers, builders, mathematicians, and other academics (we call them “big brains”), have sought the proverbial Holy Grail of consensus mechanism. So far, we haven’t gotten there- but spoiler alert- it’s coming, and we will discuss what “it” is in this series.
Earlier, I referred to something about Byzantine. This consensus-based anecdotal metaphor illustrates the primary security concern that Satoshi Nakamoto elucidated in the Bitcoin Whitepaper.
Byzantine Fault Tolerance refers to the property of a DLT that allows it to overcome the Byzantine General’s problem to achieve consensus (more than 2/3 of all nodes verifying/validating a transaction/block regardless of the fact that some nodes disagree with the rest, either accidentally or on purpose. An algorithm-based consensus mechanism protocol determines how this BFT is achieved.
So looking at that last sentence, readers can likely understand what might have been too complex at the outset of this journey of discovery that we are sharing in this series. The term algorithm is the only one not yet discussed- so here it is, simply: algorithms are sets of rules for solving tasks. To use an example likely familiar to most, the order of operations in solving a complex arithmetic problem is commonly referred to PEMDAS- this is an example of a set of rules for solving a task: an algorithm.
So lot’s to digest here. I will pause and let you all process and ask questions, or DYOR.
Next Up: Proof-of-Work