The cryptocurrency industry is notorious for its ability to use exotic terminology to confuse the shit out of non-technical people. Hell, sometimes even the most technical of people can get lost in the sauce. The absurd rate of innovation that takes place in crypto is a breeding ground for new ideas. These new ideas require new, yet familiar forms of being communicated. One of the most overused forms of communication is through the formulation of terminology as “PROOF-OF- ”. xyz Everybody is always trying to prove something & this is for good reason, after all, the very essence of blockchain is “Don’t Trust, Verify.” However, at some point it all just becomes overwhelming. Today we put an end to this! Ok, not really, but we will dissect one of the most important technical aspects upon which the entire industry is built: Consensus Mechanisms This is a very dense topic that requires an understanding of many different technical elements; I will try to break them all down as we go through it & provide links/resources for those that want to dive in deeper. Cryptocurrency operates through a cloud computing system called a DLT (Distributed Ledger Technology), such as a Blockchain or DAG (Directed Acyclic Graph). This technology has been developed as a solution to a computational “paradigm” known as which explains the difficulty of establishing secure communication in decentralized environments. The Byzantine Generals Problem Basically, if 3 generals surround a city & want to capture it, they must attack all at once. Any less than all 3 & the plan will fail. How can these generals coordinate with each other if there is so much risk involved in sending a message? The messenger getting lost, being delayed, losing the message, forging a fake message, getting caught by the enemy or just lying about it. It is actually a pretty stimulating read for anybody interested; but for the sake of brevity, we must move on. Blockchains/DLTs are (supposed to be) immutable, transparent, append-only digital ledgers that provide an operational guarantee of consistently only showing the truth. These properties have given blockchain technology the colloquial nickname as “ ”. the trust machine While we intuitively know what trust is, defining it is no simple task. Trust is the assurance that future outcomes are dependable. It is the ability to put faith into something/someone without the fear, uncertainty, or doubt of that something/someone fucking you over. Trusting is the ability to make a decision, with a high degree of confidence, and not have to worry about the counterparty risk. Consensus mechanisms are the vehicles for establishing the truth, avoiding non-truth, & in turn garnering user trust in cryptocurrencies. What is a consensus mechanism? As it relates to crypto, consensus mechanisms provide the dual functionality of security guarantees & reward regulation. They are systems/protocols that are used to agree on a single version of history for all the chain’s activity. A code of conduct for establishing a common agreement on the shared, single, true state. They dictate:- who verifies & confirms the transactions that are submitted into a blockchain block(s).- how that verification & confirmation happens- who & how is somebody rewarded for their efforts/contributions This is where things get a little tricky: Consensus mechanisms do not have to only have to deal with the cold hard computational logic of blockchain security. They can be used to express the coming to an agreement of trust on virtually any arbitrary social, technical or mechanical element. The nuances of the delicate architecture behind consensus mechanisms are extremely complex… but at the highest level they can be boiled down to four core composing design elements: Computational complexity The amount of resources & steps that are necessary in order to arrive at the desired outcome (the quicker/shorter, the better) Fault-tolerance At the core of any computational network’s consensus is the ability to maintain operations in the event that network participants drop out or stop working (which can happen sporadically) The higher the fault tolerance, the easier it is to game the system; the lower the tolerance the more resilient the system it. So if the fault tolerance of a system is 51% that means that the system can continue to operate as long as 49% is compromised. If the tolerance is 67%, that means the system can handle only 33% of compromised nodes. Resilience The ability to continue delivering proper results in the event of malicious activity (which can happen for prolonged periods of time) Liveliness The guarantees that even after some unforeseen event happens, the network will continue to operate truthfully Tradeoffs in Mechanisms: There is no single universal mechanism to rule them all. Consensus mechanisms are radically different according to their application. The blockchain trilemma poses that it is impossible to have the presence of all 3 properties: Security, Scalability, & Decentralization in a single system. There can only be some degree of a mixture between 2-of-3 elements. Based on which combination is present in a blockchain, each mechanism will differ according to: - performance - consistency, - scalability, - efficiency While there are hundreds, if not thousands of different mechanisms out in the marketplace today; there are two general types of Consensus mechanisms based on their operational logic, . Every other variation will just be some modular adjustment or combination of these two. proof-of-work & proof-of-stake Now that we have a general understanding of Consensus mechanisms; let’s review some of them: Disclaimer - Not every “Proof-Of-something” serves the same functions as the others. - Not every consensus mechanism needs to have “Proof-Of” in its name. - Byzantine Fault Tolerance is an element of any/every mechanism. POW — Proof Of Work Very High Decentralization: 51% Fault Tolerance: Securing blockchain history Use case: Resource-intensive process of extreme mathematical complexity that demands dedicated hardware. POW consensus is reached via the contribution of computational resources to solving mathematical problems of monstrous complexity. Here, nodes are called miners and earn their rewards through the emission of new network tokens. Leaders for block proposals are chosen on a first-come, first-serve basis according to whoever is able to solve the mathematical problem. Description: POW itself has a built-in sub-rule of “chain weight” or “chain height” & truncation. Whenever POW is running, miners are building their own versions of the next block; however, only one block will be accepted. Meaning that the network will truncate/discard all non-accepted blocks & always recalibrate to the version of the chain that is longest/heaviest (in terms of the amount of work done on it). This is considered the most secure/decentralized model of consensus because of its ability to resist global government scrutiny. , , , POW Examples - Bitcoin (BTC) Dogecoin (DOGE) Litecoin (LTC) Kaspa (KAS) POS — Proof Of Stake moderate-high Decentralization: 67% Fault Tolerance: Securing blockchain history Use case: The most popular model for consensus. The concept behind this one is straightforward, users lockup/collateralize their tokens in order to participate. In POS models there are fixed circulating supplies meaning that no new tokens are issued as block rewards, the rewards are earned through the accrual of transaction fees. Additionally, unlike POW, POS models employ stake-slashing for any misbehavior; in the event that malicious/subversive behavior is found, that violating node will have ~50% of its stake forfeited to the network for redistribution amongst the fair nodes. Commonly considered to be less secure & more centralized than POW in the sense that incentives of network nodes are similar to legacy financial systems; deeper-pocketed players have a better chance to own the network nodes. Description: Another important element to not overlook in POS is that there in order to become a node there is a minimal requirement of stake. In the example of Ethereum, it is 32 ETH. The tradeoff with this design is that a high level of truthful activity is expected in order to not lose stake; while it does minimize potential accessibility & in turn, decentralization count. Additionally, POS is known to suffer the “rich getting richer” problem, the consensus is rooted primarily in just the amount/value at stake; therefore those who have more, will earn more & not give others a fair chance. Aside from the prior, the truth of why this scores lower on decentralization than POW is resilience against governments. Governments can in theory hunt down these networks & force them to shut down operations; POS is easier to subvert on a mass scale. However, one major benefit of POS over POW is energy efficiency. , , , , , , POS Examples — Ethereum (ETH) Cardano (ADA) Tezos (TEZ) CELO (CELO) Polkadot (DOT) Avalanche (AVAX) ThorChain (RUNE) dPOS — Delegated Proof Of Stake Low Decentralization: ** 67% : Fault Tolerance Securing blockchain history Use case: The most popular adaptation of regular POS; delegated Proof of Stake is an attempt to democratize access to participation in the network’s operations & rewards. Only the largest can partake in the securing process while smaller-sized token holders “delegate” their tokens to the operating nodes; basically, they vote with their tokens, never giving them to the actual node. dPOS consensus models will typically have in the range of 21–101 nodes that are handling network operations. These network operators are selected based on the amount of tokens they have at stake. The largest benefit of the dPOS variant is that by constraining the amount of nodes; while this leads to centralization, it does also bring the added benefit of faster processing times. Description: , , , , dPOS Examples — Polygon (MATIC) , Tron (TRX) EOS (EOS) Lisk (LSK) Ark (ARK) Radix (XRD) LPOS — Leased Proof Of Stake Low - Moderate Decentralization: 67% Fault Tolerance: Securing blockchain history Use case: This is an advanced variation of POS. Very similar to the delegated proof of stake model, Leased Proof-of-Stake provides the technical difference in; that in dPOS the network nodes accrue the rewards & then distribute them to their delegators; but in LPOS users are actually lending their tokens to the nodes, thereby they own a portion of that nodes weight & accrue the rewards directly, rather than through the delegate. The tradeoff here is that to run the physical node, a very high level of technical knowledge & equipment is needed. So far this implementation has only been utilized in one project. Description: LPOS Examples — Waves (WAVES) HPOS — Hybrid Proof Of Stake (also called Proof of Activity) Moderate Decentralization: 51% Fault Tolerance: Securing blockchain history Use case: As the name might have hinted out, HPOS is a creative architecture that leverages both base consensus models (POW + POS). In this model, there are two tiers of processes that take place. On the base level, miners (just as in POW) verify & package transactions into blocks. Then these pre-vetted blocks are submitted into the mempool of the second tier, where POS nodes run an extra round of checks on the blocks & validate them. Description: , HPOS Examples — DASH (DASH) Decred (DCR) PPOS — Pure Proof Of Stake Very High* (not really) Decentralization: 67% Fault Tolerance: Securing blockchain history Use case: Another variation of POS. Novel in design when compared to other variations because it is arguably more decentralized (not). This variant does not have a punishment mechanism; so technically bad actors can act badly & not suffer. However, this design is extremely low in its barrier to entry, only 1 single token is required to join as a node. In theory, this is easy to game because a single actor can make a silent-Sybil attack by distributing 1,000 tokens over 1,000 different wallets. Description: PPOS Examples — Algorand (ALGO) POI — Proof Of Importance Low-Moderate Decentralization: 67% Fault Tolerance: Securing blockchain history Use case: Reputation-based model that is yet another implementation of POS. Difficult to become accepted as a valid node, easy to get kicked out. I must admit, this one is a little more creative in its approach. Proof of importance utilizes two factors outside of just the stake; these include: Description: 1. the staking nodes’ network activity *(rather than just staking passively, they must contribute to the velocity of the token on the network) 2. the quality of the nodes’ activity (spam transactions will not help) POI Examples — NEM (XEM) POA — Proof Of Authority None - very low' Decentralization: 51% Fault Tolerance: Securing blockchain history Use case: Centralization is the name of the game here. POA utilizes a valuable non-financial primitive to operate, identity. By using identity, all of the operating network participants risk their reputations in order to be part of the consensus circle. Anywhere there is identity there is centralization. However, by having small constrained amounts of known operators, networks that use POA have extremely high throughput potential. This is definitely a mechanism that you want underpinning any public goods blockchains, but that hasn’t stopped projects from leveraging it. Description: not POA Examples — VeChain (VET) pBFT — Practical Byzantine Fault Tolerance Low Decentralization: 67% Fault Tolerance: Developing robustness of a mechanism Use case: A key compositional component for building other consensus mechanisms. Typically found in permissioned networks, pBFT works by leveraging the replication of data throughout nodes. Not the most efficient of models due to inherent communication restraints, but very resilient (obviously tolerance is high in centralized systems, the players only have themselves & their friends to blame). Description: pBFT Examples — Zilliqa (ZIL) {uses a mixture of POW + pBFT} dBFT — Delegated Byzantine Fault Tolerance Low Decentralization: 51% Fault Tolerance: Developing robustness of a mechanism Use case: As is the case with its cousin above (pBFT) delegated Byzantine fault tolerance is a compositional element for the creation of more robust blockchain systems. On its own, the mechanism can be used to support distributed communications, however, they are limited by communication constraints that make dBFT systems centralized by default. Description: dBFT Examples — NEO (NEO) POC — Proof Of Capacity/Commitment Low Decentralization: 51% Fault Tolerance: Securing blockchain history Use case: Unique twist on the POW consensus mechanisms; rather than utilizing processing units to constantly solve problems; proof-of-Capacity leverages disk space/memory. POC plots potential solutions to future problems & stores them in the empty disk space of miners. Not to be confused with a total lack of mining, because mining still takes place; it just happens pre-emptively (which then might bring up potential security risks). Not very effective at large scale due to high sensitivity in the event of a node dropping out, which requires a re-plotting of the whole network & becomes less efficient as more mining nodes join (they require additional plotting which then creates huge backlogs on the computers allocating disk space). Description: , , POC Examples — Storj (STORJ) Chia (XCH) Signum (SIGNA) POH — Proof Of History N/A Decentralization: N/A Fault Tolerance: Timestamping & organization Use case: This is not a standalone protocol to build a blockchain on. POH is used with, you guessed it, POS, as a technique used to timestamp transactions using a VRF (verifiable random function) hashing method that allows for blocks in a blockchain to be processed & submitted into a mempool. This allows for a network to continue operations at maximum capacity regardless of what might be happening with any individual node at a given time. If a node did not submit a block on time that is not going to hinder the production of the next block because the delayed block will be organized into its correct position as soon as possible. Description: POS Examples — Solana (SOL) POET — Proof Of Elapsed Time Nope Decentralization: 51% Fault Tolerance: Securing blockchain history Use case: This is an extremely centralized model for building a network, primarily because it is Intellectual property (IP) that is protected by patents & nobody wants to go to war with Intel. Nevertheless, the design itself is brilliant. POET is yet another model that leverages POS logic with a mixture of the Nakamoto consensus principle of the longest/heaviest chain, along with its own added concepts of an internal timer & “resting”. Miner nodes are selected at random & the same node cannot be selected back to back. Once a node commits a block a random timer is put on the node & it falls “asleep”. While it is asleep it does not use any computational resources; which makes this model greener in terms of electrical consumption than other POS variants. Description: POET Example — HyperLedger Sawtooth POA — Proof Of Access Low Decentralization: 51% Fault Tolerance: Securing Storage & data Use case: An augmented version of POW, Proof-of-Access is an algorithm created by the Arweave project that uses a clever technique to verify incoming blocks. Instead of solely relying on the previous block, miners use something called a “recall block” along with a randomly picked previous block. Recall blocks can be thought of as reliable points in the history of the chain that do not require the storage of all the chain data. This creates a lightweight model for proving data, resulting in more efficient storage capabilities, less computational resource waste & increased throughput. One potential downside of this model is that it prefers older nodes due to their history archives; newer nodes do not have access to the same archived data & will only be downloading the recall blocks. Which in theory creates a hierarchy by age. Description: POA Examples — Arweave (AR) POREP — Proof Of Replication N/A Decentralization: 51% Fault Tolerance: Securing Storage & data + Cloud Computing Use case: This beauty of a model is actually an expansion of a predecessor model in data storage (Proof-of-Space) with a build-out integration of POW that prioritizes the ability of storage space on the network/in the operational node’s disk space. There are elements of the pBFT consensus mechanism in that data that is added into the network, is replicated throughout network miners. The ingenuity of POREP is defined by its ability to combat the decentralized cloud computing industry’s most devious attack vector known as a “generation attack”, whereby a mining node pays to upload a document & then infinitely requests that document, collecting fees for providing the storage of it. Description: POREP Examples — Filecoin (FIL) That is only a small sample of how much incredible work is actually out there. Consensus mechanisms are the crux of a distributed system’s trust. The mechanism dictates the rules/laws by which the system operates. Every choice in a system’s design must be made with extreme scrutiny, applying an improper mechanism to a system will cause cognitive dissonance between the users & network operators; in turn, causing a loss of trust. It is impossible to quantify which mechanism is better than the other; everything is contextual, and everything is subjective. With infinite opportunity ahead of us, Thank you for reading May your journey be incredible & Your portfolio be plentiful 🥂 Also published here.

Too Long; Didn't Read

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

Mastering Consensus Mechanisms: 15 Powerful Forms of Distributed Agreements in Crypto

Too Long; Didn't Read

Andrey Didovskiy

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Mastering Consensus Mechanisms: 15 Powerful Forms of Distributed Agreements in Crypto

Too Long; Didn't Read

Andrey Didovskiy

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES