The shape and topology of blockchain (or DAG) based consensus protocols is inherent to future development and research of scalable cryptocurrencies. To that end, it is useful to classify and remark upon how each differs and provide improvements or drawbacks in relation to one another. I also think it’s important to get these ideas out in the open to help educate people who are interested in cryptocurrency & decentralized technology research.

In this first section we will analyze 2 consensus mechanisms, that of Bitcoin and protocols adhering to similar constructions and the GHOST protocol.

As a primer for those interested in consensus research, I would recommend the following topics:

Some jargon

Before we dive in, recall that blockchains are distributed systems. They are run in a decentralized fashion by nodes that do not need to trust one another. Participants do work solving computationally challenging problems (from the perspective of Proof of Work) in order to compete to win block rewards and secure the network. This process provides the underlying security and consensus model for agreeing on the honest state of the blockchain.

We use the term honest as follows. In a blockchain network, honest participants follow the protocol. They compete to mine blocks on the correct blockchain they have seen so far. They may see many blockchains at some time t, but honest miners mine according to the blockchain that adheres to the underlying consensus protocol. On the other hand, malicious miners mine on a malicious or incorrect chain. Usually we consider these scenarios as they relate to double-spending attacks on blockchains. Malicious miners are interested in overtaking the honest chain with a malicious chain.

Consensus

Consensus, in distributed systems terms, is the process of getting a set of processes (in many cases faulty) to agree on a history or state of the world. When we design blockchain consensus protocols we want them to satisfy certain properties defined below:

Liveness. Every non-faulty node decides on a blockchain in finite time

Every non-faulty node decides on a blockchain in finite time Safety. Every non-faulty node decides on the same blockchain

Proof of Work

Proofs of work were initially introduced by Dwork in this paper to combat spam. The main goal of a proof of work is to prevent Sybil attacks; these are attacks that can be highly parallelized by the abundance of computing resources in existence today. Thus, a proof of work is some computationally hard but tractable puzzle that requires users interested in a resource to provide to gain access to said resource. Its computational nature allows us the ability to quantify how much work a given proof contains. Blockchains utilize these to prevent Sybil attacks and most importantly achieve consensus. These proofs provide the necessary security to make claims above the likelihood that transactions on blockchains are confirmed.

Bitcoin

The first consensus protocol worth mentioning is precisely the first blockchain based consensus mechanism, Bitcoin’s longest chain consensus rule. The protocol is to mine on top of the longest chain with respect to the highest aggregate amount of work put into a chain. Recall that Bitcoin miners mine a block when they find inputs that hash to outputs smaller than a dynamically updating, difficulty parameter D. In aggregate, we can compute the longest chain by considering which chain took the most work to mine by analyzing the difficulties of each block in that specific blockchain. For simplicity, we assume the longest chain by height also correlates to the longest chain by aggregate work/hashes computed.

Taken from: SPECTRE: Serialization of Proof-of-Work Events, Confirming Transactions via Recursive Elections

(by Yoad Lewenberg, Yonatan Sompolinsky, and Aviv Zohar)

The rules of the game are as follow. Consider a miner, Alice. Alice is participating in Bitcoin protocol as an honest miner. Over time, Alice constructs a blockchain based on the messages (blocks) she has seen from other peers she is connected to in the Bitcoin network. Since she follows the protocol, at some time t, Alice mines a block b_t+1 on top of her most up-to-date, correct blockchain B=(b_1, b_2, …, b_t), a list of blocks.

Let’s denote the height of a blockchain by the function h, such that h(B) is B’s height. If at any point, Alice sees a new block b’ from one of her peers extending B, Alice will stop mining on B and begin mining on B’=(b_1, b_2,…, b_t, b’). This is because Alice is an honest participant and honest participants adhere to the protocol.

Throughout this process, the difficulty D continuously updates to keep block arrivals around ~10 minutes. The combination of this with the added proof of work/computational hash power provides liveness and safety of the Bitcoin protocol. We can assume with high probability that after some number of blocks, it is infeasible to reverse transactions. Therefore, every 10 minutes we are guaranteed liveness and every k*10 minutes safety in the Bitcoin protol.

Forks

In the figure above, a fork in the blockchain is depicted. Fork’s are a common occurrence since blockchain networks are run asynchronously. Peers gossip about the latest blocks they’ve seen, but, due to network delays and geographic separation, they may hear about different blocks which are mined at seemingly similar times. In the event a fork as described previously, nodes on opposing ends of the fork compete independently to extend their differing blockchains. This race finalizes with 1 longest chain. Since the probability that two distinct subsets of the blockchain network continuously find blocks simultaneously vanishes as the length of the forked chains increases, we can say with high probability that these forks will eventually converge to one correct chain. Make note that once a fork is resolved, all transactions on the “losing” blockchain are invalidated unless they were simultaneously included in the correct, winning blockchain by the consensus rules. We call these blocks orphans. Orphaned blocks are valid blocks (eventually invalid), and the transactions are eventually invalidated. Instead, the transactions are re-included into the transaction pool for future inclusion into blocks on the correct blockchain.

Given this concept, a core attack that adversaries look to execute is that of overtaking the honest blockchain. If an adversarial coalition can create blocks at a faster rate than the honest coalition, the attack will succeed with probability 1. This result has been formulated by Lewenberg, Sompolinsky, and Zohar and is easy to accept. If the bad actors create blocks faster than the good ones, then they can immediately start rewriting the history and publish this to the network at some later point (once they overtake the honest chain). From the picture above, simply imagine the attack builds a longer chain in secret.

Bitcoin’s longest chain consensus rule is thus susceptible to attacks in this variant, commonly called the 51% attack and with decent probability smaller fractions of the network. We won’t go into much detail on how other attacks relate to this ability but yield references to interesting analyses and research.

Eclipse attacks & censhorship for causing forks by Heilman et al.

Selfish mining & block withholding attacks by Eyal et al.

Currently, Ethereum also follows this rule with small changes to how orphaned block miners are rewarded.

For more papers utilizing this consensus mechanism albeit improving security concerns, there has been work in combining Proof of Work with general Byzantine fault-tolerant consensus algorithms using leader elections.

Future Work