Tl,Dr
- Consensus is a fancy word for agreement
- Not every consensus mechanism serves the same function
- Consensus is the key element that creates trust in a system.

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

Preclude, 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 The Byzantine Generals Problem which explains the difficulty of establishing secure communication in decentralized environments. Basically, if 3 generals surround a city & want to capture it, they must attack all at once. Any less than all 3 & it 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 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 (can happen for prolonged periods of time)
- liveliness
the guarantee 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.

Source: Research Gate

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, proof-of-work & proof-of-stake. Every other variation will just be some modular adjustment or combination of these two.

Now that we have a general understanding of Consensus mechanisms; lets 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. (but these do)
- Byzantine Fault Tolerance is an element of any/every mechanism.

POW — Proof Of Work

Decentralization: Very High
Fault Tolerance: 51%
Use case: Securing blockchain history
Description: 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. 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

Decentralization: moderate-high
Fault Tolerance: 67%
Use case: Securing blockchain history
Description: 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. 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), Ontology (ONT) is a variant of POS

dPOS — Delegated Proof Of Stake

Decentralization: Low
Fault Tolerance: 67%
Use case: Securing blockchain history
Description: 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.

dPOS Examples — Polygon (MATIC), Tron (TRX), EOS (EOS), Lisk (LSK), Ark (ARK), Radix (XRD),

LPOS — Leased Proof Of Stake

Decentralization: Low - Moderate
Fault Tolerance: 67%
Use case: Securing blockchain history
Description: 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 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, very high level of technical knowledge & equipment is needed. So far this implementation has only been utilized in one project.

LPOS Examples — Waves (WAVES)

HPOS — Hybrid Proof Of Stake (also called Proof of Activity)

Decentralization: Moderate
Fault Tolerance: 51%
Use case: Securing blockchain history
Description: 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.

HPOS Examples — DASH (DASH), Decred (DCR)

PPOS — Pure Proof Of Stake

Decentralization: Very High*
Fault Tolerance: 67%
Use case: Securing blockchain history
Description: 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.

PPOS Examples — Algorand (ALGO)

POI — Proof Of Importance

Decentralization: Low-Moderate
Fault Tolerance: 67%
Use case: Securing blockchain history
Description: 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:
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

Decentralization: None - very low
Fault Tolerance: 51%
Use case: Securing blockchain history
Description: 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 reputation 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 not a mechanism that you want underpinning any public goods blockchains, but that hasn’t stopped projects from leveraging it.

POA Examples — VeChain (VET)

pBFT — Practical Byzantine Fault Tolerance

Decentralization: Low
Fault Tolerance: 67%
Use case: Developing robustness of a mechanism
Description: 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).

pBFT Examples — Zilliqa (ZIL) {uses a mixture of POW + pBFT}

dBFT — Delegated Byzantine Fault Tolerance

Decentralization: Low
Fault Tolerance: 51%
Use case: Developing robustness of a mechanism
Description: 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.

dBFT Examples — NEO (NEO)

POC — Proof Of Capacity/Commitment

Decentralization: Low
Fault Tolerance: 51%
Use case: Securing blockchain history
Description: 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).

POC Examples — Storj (STORJ), Chia (XCH), Signum (SIGNA)

POH — Proof Of History

Decentralization: N/A
Fault Tolerance: N/A
Use case: Timestamping & organization
Description: 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.

POS Examples — Solana (SOL)

POET — Proof Of Elapsed Time

Decentralization: Nope
Fault Tolerance: 51%
Use case: Securing blockchain history
Description: 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 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.

POET Example — HyperLedger Sawtooth

POA — Proof Of Access

Decentralization: Low
Fault Tolerance: 51%
Use case: Securing Storage & data
Description: 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 though 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.

POA Examples — Arweave (AR)

POREP — Proof Of Replication

Decentralization: N/A
Fault Tolerance: 51%
Use case: Securing Storage & data + Cloud Computing
Description: 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.

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, everything is subjective.

With infinite opportunity ahead of us,
I thank you for reading

May your journey be incredible
&
Your portfolio be plentiful 🥂