In Part 2 of CoinGecko's Consensus Algorithm guide (Read Part 1 here, in case you missed it) we'll be covering several other type of consensus algorithms/mechanisms - Directed Acyclic Graphs (DAGs), Practical Byzantine Fault Tolerance (PBFT), Federated Byzantine Agreement (FBA) and Proof of Elapsed Time (PoET).

A quick recap: consensus algorithm is what allows millions of different users to agree on one particular version of a shared ledger that is continuously updated and broadcasted amongst all the participants. Without it, there will not be Bitcoin, Ethereum, Litecoin or any other cryptocurrencies as we know it.

Directed-Acyclic-Graphs (DAGs)

A blockchain that has many, many branches – like a tree

Implementations: IOTA, Nano/Raiblocks
Pros: High throughput, scalable, feeless transactions
Cons: Relatively new, untested, somewhat centralized

Instead of one single chain (regular blockchain), you have a “branched-out” chain with a higher throughput. (Image from Ministry of Blockchain)

To be clear, DAGs itself is not a consensus algorithm, but rather a different way to utilize existing algorithms (Proof of Work etc.). DAGs is a consensus mechanism that has been receiving a lot of attention lately with the promise to fix energy use and scalability issues of PoW. Although not as time-proven and battle tested compared to PoW, DAG-based coins are largely popular and have been dubbed as the “Blockchain killer”.

DAGs can be explained by their own name:

• Directed = Connections between two points (nodes) have directions such that A -> B is not the same as B -> A.
• Acyclic = Opposite of cyclic where you’ll end up where you started from after some time. In an acyclic system, you’ll never encounter the same point (node) twice.
• Graphs = A structure consisting of points (nodes) that are connected.

So, essentially instead of a straight line (like our current blockchain) where the only reference is one previous block, a DAG based systems have more breadth – they have reference to multiple blocks from past transactions. As a result, there is more throughput (more transactions) since the network is more like an expanding tree rather than a straight chain and transactions are handled mostly asynchronously.

Theoretically, DAG structures allow for infinite transactions per second to solve the scalability issue that has plagued traditional blockchain structure coins such as Bitcoin, Litecoin and many others – but the security aspects, centralization and resistance to various forms of attack have yet to be proven and/or tested. There are many “flavors” of DAG and we will briefly go through two of the more popular ones here:

Tangle (IOTA): Tangle is the DAG consensus algorithm in use by IOTA. In Tangle, the rules are that you will have to validate two previous transactions you’ve received in order to send a new transaction. In this manner, the network grows stronger the more people use it – validity of transactions increase as more transactions are added. However, as of today the IOTA’s Tangle does not have sufficient transaction volume to render creating 1/3 of the transaction volume unfeasible and to counter that, they currently rely on a centralized node called “The Coordinator”, which assists with validating transactions and will be removed once the Tangle gets big enough.

Block-lattice: Nano/Raiblocks introduces a new way to leverage on the blockchain tech called the Block-lattice. In this system:

• Every user (address) has their own blockhain only they can write to in addition to the main ledger.
• To perform a transaction, there must be a “Send” block (at the sender’s blockchain) and a “Receive” block (at the receiver’s blockchain) instead of our usual “Alice sends 10 BTC to Bob” as a line item. 
• Nano also relies on validators with dPoS as a means to achieve consensus (verify transactions, vote for conflicting transactions) on the network. 
• To reduce spam, a small PoW element is also added – each user spends about 5 seconds to sign their transaction and it takes about 1 microsecond for the nodes to validate them.

Nano is fairly unique in the sense that, it combines several different consensus mechanism to form a usable ecosystem – although untested/proven at this point, it is no doubt innovative!  

Practical Byzantine Fault Tolerant (PBFT)

All about the two-thirds majority to move forward – much like democratic systems.

Implementation: Hyperledger’s Fabric, Zilliqa
Pros: High throughput, scalable, fast
Cons: Requires trust, somewhat centralized.

 
With the two-thirds + 1 majority, the system will move forward with Decision X.

Originally described by Castro & Liskov in 1999, PBFT is one of the ways to overcome the Byzantine Fault in computing systems much like how PoW/PoS aims to – albeit from a slightly different angle. In PoW/PoS, the next block is generated in a probabilistic manner (having 50% of the hashing power likely equals to finding 50% of the block) whereas in a PBFT system, blocks can be generated deterministically as long as more than 2/3 of the validators agree on the same result.

In a PBFT system, the major underlying condition to maintain a “correct” consensus is that no more than 1/3 of all nodes active are simultaneously faulty. I will use the following example to briefly explain the PBFT model.

1. In a system of 100 nodes, there is 1 (one) elected Leader node, and 99 (ninety-nine) Backup nodes.
2. A client communicates with the Leader node with a service request (eg. Send funds).
3. The Leader node broadcasts the request to all 99 (ninety-nine) Backup nodes.
4. The Backup nodes process these the request and reverts to the client.
5. The client then waits until he/she receives more than 67 (2/3 of 100 nodes + 1 node) replies from different node with similar results – the result is then the answer to the client’s request.

For the next round (next block creation), the Leader node is changed in a round robin manner and in the event where a Leader node is malicious/faulty (eg. not broadcasting requests), Backup nodes may trigger the View Change protocol to replace the said Leader node. 

Compared to PoW/PoS (probabilistic), PBFT’s (deterministic) blocks are final and there is no need to wait for 6 extra confirmations (like in BTC/LTC) to cushion against double spending.  All nodes agree on the same state of the system at a particular time.

In short, the PBFT algorithm allows for quick and confirmation-less transactions, but falls short of being trustless.
 

Federated Byzantine Agreement (FBA)

I don’t trust you, but if a trusted friend of mine trusts you… we can do business.

Implementation: XRP, Stellar
Pros: High throughput, scalable, fast
Cons: Requires trust, centralized 

An FBA system is one that achieves consensus through the use of three components: 

• Node – The users who perform the validation work in the network.
• Quorum – The number of nodes required to achieve a consensus/an agreement.
• Quorum Slice – A subset of a quorum.

In this system, a node can rely on numerous quorum slices and each quorum slice can be made up of different entities (eg. banks, other nodes or various organizations). To illustrate this, consider the following:

1. Imagine each quorum slice to be a small “team” of people with their own consensus/agreement 
2. Between different teams, there may be members who agree on the same things despite being on a different team.
3. With the existence of these members, an overlapping agreement and thus consensus can form between different groups.

Illustration of a FBA system (Image credit: Pavel Kravchenko)

In this system, agreement can form between different groups even if they don’t all agree on the same thing – as long as there is some form of overlapping. It is a little similar to how when there is a new place in town that serves absolutely gob-smacking ice cream & waffles you tried it because your friends said it’s good. You try it, and pass on the idea that “the waffles there are pretty darn good!” to someone else. Over time, everyone eventually agrees that it’s a good place (consensus is formed!).

FBA was first pioneered by Ripple (XRP) and subsequently adapted and modified by Stellar (XLM) into what’s known as the Stellar Consensus Protocol (SCP). Fundamentally, both are similar except that in XRP, all the validator nodes are known and trusted whereas in XLM, the nodes are decentralized and users can choose nodes to trust (setup in a node’s config file).

However, it’s worth noting that for XLM, Stellar has mandated that each quorum slice requires it’s own appointed quorum members. This is achieved through the consolidation of voting rights such that the nodes are unlikely to be able to vote out the core Stellar quorum members. Ripple on the other hand, pursued a different strategy – all quorum members of the network are known and trusted from the very beginning. 

Proof of Elapsed Time (PoET)

A lottery of waiting time – hosted by Intel. 

Implementation: Hyperledger’s Sawtooth
Pros: Scalable, energy efficient.
Cons: Somewhat centralized, not trustless, not battle-tested.

 
Keep waiting, you might be the next one! (Image from GIPHY)

The PoET consensus algorithm is developed by Intel and essentially emulates Bitcoin’s Proof-of-Work. It is currently in use by Sawtooth, with is an open-source project under Hyperledger’s umbrella and has been designed with enterprise use in mind. It is claimed to be extremely scalable to large number of nodes and can function even when large number of nodes aren’t available. 

In PoET, instead of competing with everyone else to solve the cryptographic puzzle to try and mine the next block, each user enters a random lottery system of waiting time. The Leader (first person to finish waiting) gets to be the creator of the next block. However, for this to work there are two requirements which must be satisfied first: 

• Did all participants actually choose their waiting time randomly?
• Did the winner actually wait as per his/her chosen waiting time?

For that, all participants must rely on a CPU instruction set called Intel Software Guard Extensions (SGX) which allows codes to run in a trusted environment. However, this means that participant must trust Intel and when this set of consensus algorithm is applied on any public/private blockchain, it is similar to handling them the keys to the safe. 

This basically goes against the purpose of cryptocurrency – which existed to remove trust/reliance on any parties. But the scalability and energy efficient approach to block propagation enabled by this particular set of consensus algorithm is no doubt an interesting one, and likely also indicates that technology giants are looking at leveraging the blockchain technology for their business. 

Final word on Consensus Algorithms

An efficient consensus algorithm for blockchain systems should comprise of the following:

• Decentralized – No single point of failure since there should be no central authority controlling/mediating anything.
• Secure – Reasonably resistant to various faults/byzantine fault tolerant to be truly free from a central authority among many other reasons.
• Incentivizes users – A well-designed incentive system for a consensus algorithm naturally forces participants to play by the rules for maximum economic benefits. 

As it currently is today, Proof-of-Work remains as the de-facto champion in terms of being proven to be able to work reasonably well against various threats. That said, it would be ignorant to think that there won’t be a new kid around the block that will threaten PoW’s position and change thing for the better. After all, each consensus model has its own strengths and weaknesses and perhaps a reasonable solution could be synthesized as a result of what has been known today.

Familiarizing yourself with the various solutions currently present in the market will help in making an informed decision when deciding on which cryptocurrency to invest in or to use since the consensus algorithm is a large part of a cryptocurrency. Take time to study the differences between coins, and you’ll be able to better see why market capitalization of a coin doesn’t tell the full story – good luck!

CoinGecko's Content Editorial Guidelines

CoinGecko’s content aims to demystify the crypto industry. While certain posts you see may be sponsored, we strive to uphold the highest standards of editorial quality and integrity, and do not publish any content that has not been vetted by our editors.

Learn more

Jin

Jin is a Product Manager at CoinGecko. In his free time, Jin enjoys messing with crypto related stuffs on a slightly technical side and generally learns about crypto as he munches on snacks. Follow the author on Twitter @jin_8315