Web 3 Consensus Mechanisms
…and the protocols that use them
The blockchain ecosystem is in a constant state of evolution due to the experimental nature of its development. Whether or not you play a significant role in shaping the environment, keeping up with the fast-paced technological changes is no small feat. Fortunately, members of the blockchain community are creating valuable resources that help alleviate this burden. Our team is on a mission to fortify these efforts by sharing the knowledge accrued as we build a foundation that allows blockchain technology to flourish.
With the influx of new blockchain protocols, there have been fascinating discussions regarding different consensus mechanisms. These conversations can become quite convoluted, so we put together a small guide on the topic for those in a hurry. Let’s begin!
What is a Consensus Mechanism?
To put it simply, a consensus mechanism is the means by which people reach agreement within a particular blockchain, specifically on the validity of transactions. In a centralized system, it is easy for people to arrive at consensus because the authority to validate truth is based in one local (central) source. In a decentralized system, this process becomes much more difficult because there are multiple sources contributing to the validation of a global truth.
The Byzantine Generals Problem
In computer science, the Byzantine Generals Problem is an abstract expression that describes how a system must cope with the failure of one of more of its components. Imagine a group of Byzantine generals surround an enemy city and they need to coordinate a plan. Unfortunately, the generals can only communicate by courier and message because they are spread too far apart. Some number of generals may want to attack the city, while some number of generals want to retreat. How do the generals reach consensus on whether to attack or retreat? If a message is sent from one general to the next, its authenticity may be at risk. Votes cast from previous generals could be corrupted by subsequent messengers or generals. The problem is that while they are in it together, the generals are independent nodes in a network whose sustainability depends on the interaction of their individual behaviors. They have equal stature among them and autonomy to make decisions. They can cooperate, disagree or betray the group. In addition, communication between them is asynchronous, increasing the time for varied interpretation, error and incomplete messaging. The solution to the problem faced by this distributed group of generals (or any decentralized network) is some form of consensus model that would enable them to recognize and agree on valid messages (the core of their ability to function at all), minimize the likelihood of faulty communication, and protect them from attacks (be they internal betrayals or external enemies), so that they can contribute individually and execute collectively on one shared mission.
Modeling consensus isn’t easy, and isn’t a one size fits all. It is the foundation of any form of group work. How do you determine what’s true? Who gets to designate valid information and on what basis? How will we communicate to maintain clarity and security of our messages? How will we protect and maintain the workings of our ecosystem, so that they satisfy the interests of the individuals comprising the group and sustain the group’s overall purpose?
Types of Consensus Mechanisms
A Proof of Work (PoW) is defined as a piece of data which is difficult (costly, time-consuming) to produce, yet easy for others to verify. Bitcoin and Ethereum utilize this type of work to reduce spam on the network and prevent double spending. It requires powerful computers, or specialized hardware, to confirm a block of transactions by solving complex mathematical puzzles in exchange for newly mined cryptocurrency and transaction fees; however, only the first machine to correctly solve the puzzle receives the reward. Although proof of work has been extremely reliable at maintaining consensus through economic incentives, the energy consumption required to confirm transactions is increasing at an alarming rate. As a result, blockchain developers are beginning to use different consensus mechanisms such as proof of stake.
Instead of confirming transactions using computational power, blockchains that use Proof of Stake (PoS) rely on users providing an economic stake in the network. The stake is effectively a deposit made by users who wish to validate transactions and become eligible to collect transaction fees. In order to protect their stake, the user must only validate the transactions confirmed by majority consensus. Despite potential issues, proof of stake prevents cartel-based conduct and other centralizing behaviors. This consensus mechanism is used by Decred and will be adopted by Ethereum in the near future.
Byzantine Fault Tolerance (BFT) was introduced in 1999 in a white paper by Miguel Castro and Barbara Liskov, two computer scientists from MIT. BFT algorithms manage relationships between blockchain nodes, making the network resilient to the Byzantine Generals Problem mentioned above. These nodes are not predetermined and they join the network at will. Practical Byzantine Fault Tolerant (PBFT) systems have a predefined set of validators that are usually chosen by the protocol developers. These systems achieve a lower latency and higher file storing capabilities than the traditional BFT systems. Hyperledger and Ripple are two protocols that use a PBFT system. Federated Byzantine Agreement (FBA)was proposed in 2015 by David Mazieries and is used by Stellar. FBA’s have no predefined set of validators and nodes openly choose who they trust. These trusted nodes create what are called Quorum Slices. These Quorum Slices are tallied to form the Quorum Network or the agreed upon truth of the state. These slices are later put together to form the Quorum Network.
A Directed Acyclic Graph (DAG) is a consensus mechanism that isn’t used by traditional blockchains such as Bitcoin and Ethereum. DAGs are used by distributed systems such as IOTA and Byteball where transactions are validated by paying-it-forward. In order to send a transaction, users must validate two transactions. This can allow for faster transaction speed when the network is under increased load. Contrary to the traditional blockchain architecture, where blocks are mined and filled in a linear fashion, transactions take place and can be connected in different ways.
The downside of using a DAG is the low threshold for malicious activity. It would take only 33% to overtake a DAG’s network of vs 51% for Bitcoin which uses proof of work.
Holochain uses a Distributed Hash Table (DHT). A DHT is a distributed system with a lookup service that uses (key, value) pairs. These pairs are stored in the DHT, and any participating node can retrieve the data associated with the key. The maintenance and mapping of the keys are distributed amongst the nodes.Holochain is an agent-centric model, a git-like mechanism where every node has its own version of the data (truth). Everything can be verified historically (most blockchains are data centric: everybody downloads a copy of the ledger, e.g. Bitcoin). Based on version control, every node owns a local store of the data that it can reference to a previous commit in its private space. Outside nodes don’t know what is going on within external nodes’ private space. To establish an external communication line and data redundancy, Holochain uses it’s distributed hash table. Holochain has distributed validation rules (called DNA) that are determined not by the protocol but by application developers. How does this work without consensus? Holochain has what they call an immune system. Holochains Immune System is a gossip like system existing between applications built on top of Holochain. Applications determine independently which nodes they trust and distrust based on their own consensus rules and broadcast this out to other applications in the network. It’s up to each individual application to determine which consensus rules they want to abide by. Determining consensus rules at the application layer is risky. These rules need to be well defined and if not properly executed can open up other applications to vulnerabilities.
Proof of Location (PoL) Protocol
Proof of Location (PoL) is a new protocol enabling location verification. Instead of node operators receiving payouts for verifying transactions like in PoW, PoL payouts are location based, meaning participants are required to visit each site in a predefined order. PoL helps prevent fake location reports (that can be easily spoofed with fake GPS apps), by using location and time stamps. Several projects using PoL include Paltin, FOAM and Sikorka.
Proof of Activity
Certain cryptocurrencies, including Bitcoin, that are operating under the proof of work consensus mechanism have deflationary currency supplies. Questions have risen as to what will happen when these protocols reach their currency distribution limits and miners are no longer receiving the block rewards. The concern is a potential “tragedy of the commons” where individuals begin acting out in self interest. PoA was engineered to mitigate this security by creating a hybrid between PoW and PoS.
This consensus mechanism requires miners to use PoW to generate the header of a block. Once the header is generated, the system switches over to PoS until the block is completely formed. Fees are split between those who contributed to the formation of the block. Although PoA attempts to combine the best of both worlds, criticisms often include excessive energy consumption (PoW) and the potential double signing transactions (PoS).
Reaching Consensus
Consensus mechanisms are a integral to blockchain technology and other distributed systems. They are the basis on which participants of a given network with a range of varied self-interests, and even a mutual distrust for one another, can come to an agreement on the validity of data and transactions. The consensus model implemented by a project, company or team is the heart of its security, communication, and sustainability.
The Byzantine Generals Problem does not have one solution. Decentralized networks, built to engage participants with autonomy to make decisions in their self-interest, while protecting and sustaining the ecosystem’s continued service, are inherently complex. They seek to orchestrate the interests of the one (purpose) and the many (actors), and since there will always be diversity, growth and conflicting interests among us in any situation, this isn’t a race to the finish line where we solve consensus. It’s more like a wide-open door to the lab, where different lines of inquiry investigate the fundamental questions informing the mechanism design of a given project:
- How do you determine what’s true?
- Who gets to designate valid information and on what basis?
- How will we communicate to maintain clarity and security of our messages?
- How will we protect and maintain the workings of our ecosystem, so that they satisfy the interests of the individuals comprising the group and sustain the group’s overall purpose?
What do you think?
(ping us on Twitter!)
Some good reads on consensus mechanisms:
The Byzantine Generals’ Problem
Understanding Blockchain Fundamentals, Part 1: Byzantine Fault Tolerance
