Photo by Markus Spiske on Unsplash

A Primer on Consensus in DLT

Distributed Ledger Technology (DLT) brings together a number of capabilities — shared views of tamper-resistant data, smart contracts, etc. — to create a powerful solution for new applications. Underlying DLT are two core concepts: cryptography and consensus. Both are complex in nature and grounded in mathematics and computer science. However, unlike cryptography where standards bodies (e.g. ANSI, ISO) and government agencies (e.g. NIST) can be relied upon to certify an algorithm, there is not the same convenience for consensus. This puts the onus on organizations to do their own due diligence to confirm whether a consensus algorithm behaves and performs in a way that is expected.

  1. Within an algorithm family, there are many variants (e.g. Istanbul BFT is an offspring of PBFT) and it will be impractical to cover every variant;
  2. Minimize the loss of accuracy due to summarization

What is consensus?

While there is no shortage of definitions for “consensus” (Google is Your Friend), for the purpose of this paper, we define consensus as:

  • Fault tolerance
  • Performance
  • Finality

Popular Consensus Algorithms

Byzantine Fault Tolerance

Before going into different algorithm families, it’s worth taking a moment to understand what Byzantine failures mean. A Byzantine failure places no restrictions on how a node on the network can “fail”:

  • Loss of network connectivity or network delays
  • Pretending to be good, but actually producing bogus data
  • Basically anything goes!

Proof-of-Work

Proof-of-Work is arguably the only BFT algorithm demonstrated to work at planetary scale. In Proof-of-Work (PoW), any node that wants to append transactions (typically packaged in blocks) to the ledger must solve very difficult — even for a computer — puzzles; the solving of these puzzles is also referred to as mining. Naturally, a node that is mining is called a miner. At a high level, a PoW-based consensus works as follows:

  • As soon as a miner finds a solution to the puzzle for its block, it broadcasts that block along with the solution to all other nodes.
  • Other nodes may accept the block by verifying that the puzzle solution is indeed correct and all transactions in the block are valid.
  • Once a node accepts a block, it appends the block to its ledger and the cycle starts again for a new block of transactions..
  • In the case of any conflicts, the ledger with the most number of blocks is deemed the correct ledger.

Proof-of-Stake

Proof-of-Stake (PoS) is another lottery-based algorithm family. Instead of miners expending computational resources in order to participate in the consensus process, a node is randomly selected with a probability proportional to the stake that node possesses according to the current ledger. The node that is selected is called a minter. A stake may be denominated in any asset or currency widely accepted on the network as having significant value; for example, in Ethereum a stake is denominated in ether.

  1. Block minting: whether minters are directly minting blocks of transactions or whether they are simply proposing blocks and other stakeholders of the network will need to vote on the proposed block before it will be accepted on the ledger.

Practical Byzantine Fault Tolerance (PBFT)

Outside of PoW and PoS, of particular significance is the work from MIT researchers which led to the Practical Byzantine Fault Tolerance (PBFT) algorithm. PBFT was important in that it spawned a whole new family of protocols.

  • All nodes are connected to each other and the network itself is assumed to be partially synchronous.
  • Time is divided into views and for each view, a node is designated the Leader of the network.
  • Each node takes turns being the Leader in a never-ending cycle, starting with the first node. For example, in a ten node network, node 0 is the leader for View 0, node 1 is the leader for View 1 and so on and so forth. When the network gets to View 10, node 0 will get another chance at being the leader again.
  • Transactions are sent to the Leader node which is responsible for sharing those transactions with all other nodes (called Replicas).
  • Every replica executes the same transactions in the same order as provided by the Leader node. After execution, at least 1/3 of the replicas must arrive at the same ledger state for the ledger to be updated.

Raft

Raft also relies on a leader node to drive consensus. Time is divided into terms (similar to PBFT’s views) and for each term, a node is elected Leader of the network. A voting process is used to elect the leader; the node with a simple majority of votes will be the leader for the term. Nodes not acting as a leader are called followers.

Consensus in Permissioned Networks

In a permissioned network, participants’ identities, and by extension, individual node identities are known. Contrary to what some may want you to believe, permissioned networks are not fully decentralized — they all rely on some degree of centralization or authoritative service to properly function.

Corda

Consensus in Corda is fairly straightforward: each transaction is routed between appropriate participants for signing and a Notary service handles the final verification to make sure there is no double-spending for the transaction. While the Notary service can optionally also validate smart contract results (i.e. validating notary), this has not been widely used due to implementation complexity.

Fabric

Consensus in Hyperledger Fabric is broken out into 3 phases: Proposal, Ordering, and Validation:

EXPR(E[, E...]) where EXPR is AND or OR and E is a principal or nested EXPR(...)
AND(Superman, AND(Batman OR WonderWoman))
  • Validation and Commit: takes a block of ordered transactions and validates the correctness of the results, including checking endorsement policy and double-spending.

Enterprise-flavors of Ethereum

Ethereum was built from the ground up for decentralization. Nevertheless, in deployments of enterprise-flavors of Ethereum, usually only a subset of nodes are allowed to participate in consensus. These nodes (referred to as validators) collectively act as an authoritative service and are responsible for “certifying” all transactions. The validators use a CFT or BFT algorithm to reach consensus amongst themselves before propagating a block to other non-validating nodes.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store