As discussed previously on this blog, the proof of work (PoW) mechanism is used by Bitcoin and some other cryptocurrencies to enable network nodes to arrive at a consensus as to the valid public blockchain, and to ensure its immutability. There are, however, many other blockchains making use of alternative protocols. Examples include proof of stake (PoS), delegated proof of stake (DPoS), proof of burn (PoB), proof of authority (PoA), proof of exchange, proof of space, and others. There is considerable debate and strong feelings surrounding these issues, with many people arguing that one or other of these protocols is better than the alternatives. Often though, the specific implementation is as important as which category a particular chain’s mechanism fits into. So, here, I take a high-level approach and consider what we should be looking for in a consensus mechanism.
The following are required of a consensus mechanism:
- enable users to have their transactions included in blocks that are added to the blockchain.
- enable the network to come to a consensus as to the valid state of the blockchain.
- ensure immutability, so that once transactions have been confirmed on the blockchain, they are never altered or removed.
In addition, we can consider how efficiently the protocol achieves these goals. For example, how quick and how cheaply can transactions be made? Also, what is the cost of maintaining the network, both financially and environmentally? These are separate points though, which will also likely factor into the choice of a preferred protocol, but which I will not pursue here.
The first of the points above is straightforward. So long as the network is open for anyone to submit transactions to the miners/validators for inclusion in a block, and has sufficient capacity, then we should be able to have our transactions added to the chain regardless of which consensus mechanism is in place. The second point is also reasonably simple. Any consensus mechanism should provide both an algorithm for deciding if a blockchain is valid and, if a node receives two competing chains, which is to be preferred. That is, the algorithm should also assign a score to each chain, and the one with the biggest score is the winner. In the case of the Bitcoin proof of work protocol, this is the chainwork (often described as the chain length). Then, the network should arrive at a consensus on the highest scoring valid chain.
The final point, of blockchain immutability, is the most complex and often the one which separates the different protocols. Once a user submits a transaction, has it included in a block, and is considered confirmed, then it should never be removed or altered in any way. Here, confirmation usually just means that several blocks have already been added on top of the one containing the transaction. So, immutability reduces to the statement that once the network arrives at a consensus on the valid public blockchain then, other than adding new blocks on top or possibly a reorganisation of the final few blocks, it should never change. But, how does the blockchain change? This goes back to the idea mentioned above of assigning a score to the chain, so that the highest scoring one wins. Clearly, it is necessary that new blocks can be added to the end of the chain, so that new transactions can be included, which should increase the score. Although a rogue miner could try changing a confirmed block in the chain, it should be so difficult to do this whilst achieving a higher score than the public chain as to be practically impossible.
Figure 1 below demonstrates how a rogue miner could try and remove or change blocks which have already been confirmed. Here, he starts by creating his own alternative block number 6. Assuming that the method of block hashes is being employed to chain blocks together, this breaks the miner’s chain so that it is only 6 blocks long. In order to achieve a higher scoring chain than the public one, he needs to keep mining further blocks in his own private fork of the blockchain until it overtakes the public chain.
The idea is that producing a block requires utilising some scarce resource. The ‘score’ for a blockchain is then a measure of the amount of the resource that is required to construct it. Any rogue miner attempting to replace the public blockchain with his own modified one would need to acquire large quantities of this resource. Examples for different protocols are:
- Proof of work: The resource is hashpower, which requires computing hardware, and electricity to run it at as high a speed as possible.
- Proof of stake: This requires miners/validators to stake coins on the blockchain.
- Proof of burn: Users must spend coins in order to mine blocks.
- Proof of authority: Permission must be gained from some authority in order to create new blocks.
- Proof of space: This uses storage space as the resource.
With the possible exception of proof of authority, these all essentially come down to money. Assuming that the resource in question is publicly available, anyone trying to mine blocks needs to purchase sufficient resources to be able to do this.
Implementations typically assign each miner a probability of producing the next block in proportion to the quantity of the resource that they are able to prove. For proof of work, this is automatic. Each hash has a certain probability of producing a valid block and, so, the probability of an individual miner producing the next block increases in proportion to the number of hashes performed. For other approaches, such as proof of stake, this requires a method of selecting random or sufficiently strong pseudo-random numbers in order to decide who creates the next valid block. The effect of this is that, in order for the rogue miner to be able to reliably produce blocks with a higher score than the public chain, he needs to acquire more resources than the entire rest of the network combined. This is the often-discussed idea of a 51% attack. Also, because of the randomness, it is possible for a rogue miner with fewer resources to still be able to change the last few blocks of the chain, just by chance. The probability of this will decrease exponentially in the number of blocks that he tries to change. For Bitcoin, it is generally assumed that it is highly unlikely for someone to alter as many as 6 blocks in this way, hence why transactions usually require 6 confirmations to be considered secure.
External vs Internal Resources
We can split the type of resource employed by the blockchain protocols into two categories:
External: For example, proof of work/space/authority. The resource is external to and exists independently of the blockchain. These protocols are usually relatively straightforward to analyse. So long as the resource is sufficiently scarce and the total amount being used to build the blockchain is high enough to make 51% attacks impractical, then the chain should be effectively immutable.
Internal: For example, proof of stake/burn. The resource is internal to the blockchain itself, such as the staking or spending of native coins. This can be more difficult to analyse. For one thing, it is a bit circular, since the security and immutability of the blockchain will depend on the value and scarcity of the resource being used to mine blocks but, in turn, this resource depends on the security of the chain. Additionally, an attack on the chain by a rogue miner could also go hand-in-hand with an attack on the distribution of the resource in question. For example, consider figure 1 above. The rogue miner is trying to create blocks in his forked chain in order to overtake the main chain. This requires him to gain control over the majority of the total resource (e.g., of the total amount of the staked coins). Even if he cannot achieve this in the public chain, it is possible that in his own private chain he has redistributed coins (or whatever resources are required) to himself. Then, even though publicly it does not appear that he is able to launch a 51% attack, it may be possible to do just this in his forked chain which, if he succeeds, will replace the public one.
Short vs Long Range Attacks
Consider again, a rogue miner trying to attack the public blockchain by mining his own fork, as in figure 1. He succeeds if his chain eventually grows longer (i.e., has a higher score) than the public one. We can split such attacks, roughly, into two categories.
Short Range: Here, the miner is only trying to replace a relatively small number of blocks near the end of the chain. For example, suppose that he pays a merchant by sending a transaction to be included in a block. Once it has sufficient confirmations, the merchant accepts the payment and, in return, hands over the item being purchased. However, the miner immediately starts trying to mine a separate fork of the blockchain which does not include the transaction, in order to take back the payment. To do this, it is only necessary to mine blocks starting at the one containing the recent transaction. Such short-range attacks are relatively straightforward to analyse. Assuming that the distribution of resources amongst miners does not radically change from one block to the next, then he would need to have over half of the total resources to succeed or, at least, very close to a half if he is just aiming for a reasonable probability of success. Proof of stake and other protocols based on internal resources can further protect against such attacks by having the mining power depend on the distribution of the resource several blocks prior. This means that the rogue miner is not able to gain control of the majority mining power separately in his fork of the blockchain.
Long Range: This describes an attack where the rogue miner starts his fork many blocks from the end of the chain, possibly even mining an entire new chain from scratch. As available mining resources will change over time, this can be more difficult to analyse than for the short-range attacks described above.
Consider, for example, trying to mine a fork of the Bitcoin chain starting all the way back at the genesis block. Back in those days, very little computing power was being used for Bitcoin mining and the difficulty was set at 1, rather than trillions as it is today. So, we could mine early blocks much faster than was originally done, and we would quickly catch up with the main public blockchain. However, as we start mining blocks corresponding to times closer to the current day, it would get harder and harder to achieve the same level of chainwork (or, expected number of hashes) as in the public chain. Assuming we do not have over half of the current total hashrate then, at some point, we would no longer be able to mine blocks (with a high enough chainwork) as fast as the public chain. At that point, we would no longer be able to compete and would start falling further and further behind, so the attack fails.
It is interesting to note that, in its initial release, the Bitcoin protocol did not sufficiently defend against long range attacks. This is because, to decide the winning chain, the number of blocks was used instead of the chainwork. For short-range attacks, this is essentially the same thing but, due to difficulty adjustments, for longer range attacks it is possible for the alternative chain to have more blocks than the public one, even if its chainwork is lower.
Analysing long-range attacks for protocols like proof of stake, which depend on a resource internal to the chain, is even harder. First, if an attacker tries forking the public chain at a block that was mined a long time ago, then the resources available for mining will depend on the state of the chain at that time rather than as it is now. Maybe an attacker does not have many resources (i.e., staked coins) now but, at some point in the past, they did. They could then try forking the blockchain from this point and, as far as this fork is concerned, they have much more mining power available than they currently do on the public chain. Furthermore, the more blocks that they try and mine in their fork, the more opportunity there is to reassign control of resources and mining power in this fork to themselves. As such, how well a proof of stake or similar protocol defends against such attacks will depend on the specific implementation used.
Summary
Proof of work, where mining power depends on hashrate, and other protocols depending on an external resource, are relatively straightforward to analyse. We just need to understand the resource in question. As long as it is scarce, and the total amount of resources being employed for mining the public blockchain is sufficiently large and widely distributed, then the chain will be resistant against 51% attacks and will satisfy immutability. Proof of authority is similar although, by design, it is more centralised and requires trust in the party that controls the authorisation for mining.
Approaches like proof of stake where mining power depends on a resource internal to the blockchain itself are harder to analyse. So long as the resource (i.e., staked coins) is widely distributed, it should be resistant to short range attacks. However, resistance to long range attacks is harder to analyse, and will depend on the specific implementation being employed. One benefit of such protocols, though, is that they do not make use of external resources, so avoid some external effects that are sometimes blamed on other methods, such as pollution from power plants required to generate the electricity or consuming resources that could be used elsewhere.
Zero Knowledge 