Note (2021–02–01): After the original publication of this article, the Bitcoin Cash network separated into two versions during the November 15, 2020 upgrade. Bitcoin ABC is now developing Avalanche technology for deployment on the eCash network, not for Bitcoin Cash.
Abstract: The Avalanche protocol is a robust consensus algorithm, with proofs of its Byzantine Fault Tolerant (BFT) properties. It has different properties than Proof of Work (PoW), which makes it suitable to be used as a complement to PoW. Using both algorithms where they are strongest would allow Bitcoin Cash to enjoy the benefits of both Avalanche and PoW.
A previous article by Chris Pacia explained how Avalanche can help improve the payment experience with instant transactions. This article will discuss how Avalanche can be used for “post-consensus”, to provide robust defense against 51% blockchain reorganization attacks.
Comparison of Avalanche and Proof of Work.
In order to understand Avalanche, and how it could fit into the Bitcoin Cash protocol, it is useful to compare and contrast its properties with Nakamoto consensus via Proof of Work. Avalanche and Proof of Work both fall into the category of BFT algorithms, but they are different from each other and have distinct characteristics that make them suitable for different purposes.
How Avalanche Works
The Avalanche protocol is a method by which a network of nodes can communicate in real time and come to reliable consensus. The details are described in the Avalanche paper, along with a series of proofs describing the security guarantees of the protocol [1]. For an accurate and detailed description of the protocol, please refer to the Avalanche paper, as the summary here is simplified and incomplete.
To decide on the status of a particular consensus decision, say selecting Transaction A versus Transaction B, an Avalanche node will queries other nodes on the network and ask their preference. It queries a random set of nodes, and if the majority agree with its choice, it will stay with that choice, if not it will switch. Based on the results of the round, it may query again, choosing a new random set of peers. The number of random nodes to query, the number of rounds, and the criteria to stop querying, and the expected number of malicious nodes are all parameters of the protocol.
On the surface, this protocol seems fairly simple. The thing that makes it interesting, is that it has the property of “metastability”. This means that it is not stable in an undecided state, it will tend to converge rapidly to an agreed common decision for all the cooperative nodes. Additionally, the protocol has been proven to provide probabilistic safety guarantees based on the parameters of the system. This means that it can be used to reliably arrive to consensus for a given threat model, by adjusting parameters such as the number of rounds and criteria for stopping and accepting a decision.
There are many differences between Avalanche and Nakamoto consensus. For this article I will focus on two properties: Objectivity and Speed.
Objectivity
One of the nice features of Nakamoto consensus and Proof of Work, is that it is “objective”. The amount of work on a chain is very easy to check, and provides unforgeable proof that a certain amount of economic resources were expended to create it. By creating an objective record of how much work went into a chain, PoW acts a reliable signal of the value of the information contained in that ledger.
The fact that PoW is objective in this way means that a node doesn’t need to be constantly connected to the network. It can re-join later and still have enough information to be able to recognize the correct chain with high confidence. This property makes PoW a good method for maintaining a permanent unforgeable record of the state of consensus over time.
The flip-side of this objectivity, is that the objective record can be changed by spending economic resources. This is particularly pernicious in the case where an attacker hides the higher PoW chain, then releases it at a later point in time. Even if nodes online at the time detect this attack, they cannot be sure whether it is a deliberate attack, or some error due to network connectivity. And latecomers would have absolutely no way to know that a chain had been withheld. This causes a blockchain reorganization, also known as a “reorg attack”. It is particularly harmful, as it exposes exchanges and other businesses to reversal of payment, thereby destroying the monetary properties of the system.
The Avalanche protocol functions a bit differently. It arrives at consensus via a “chatty” communication process among the peers in the network. This means that in order for a node to have confidence that it is following the correct network consensus, it must communicate with other nodes for a while. While a node is connected to the network, the protocol provides guarantees that it will be able to arrive at accurate information that cannot be changed. In principle, however, a network of Avalanche nodes could agree to change historical records, and there would be no way for a latecomer to reliably detect it.
Speed
Where Avalanche excels is the speed with which it can reliably arrive at consensus. It is also guaranteed that this consensus will not change at some later time, as long as the correct nodes are connected in the network.
Nakamoto consensus relies on gradually building up work, and thus it cannot arrive at a “final” state very quickly. In practical terms, attempts to reduce block times below a certain limit (somewhere around 10 seconds) result in an unstable process with large numbers of orphans.
We can summarize the difference between Avalanche and Nakamoto consensus using an analogy. Avalanche is like instant messaging a group of friends. The message client is always on, and is very reliable and resilient to attacks. All members of the group message make decisions quickly and instantly.
Proof of Work is like carving messages onto stone tablets every ten minutes. It is much more permanent, and more expensive to participate. Over long time periods, the stone tablets provide a good lasting record of the messages that are inscribed on them.
Division of Labor
Similar to how an economy can be wealthier if people with different abilities and interests fulfill different tasks that suit them, the Bitcoin Cash protocol can be better by using both PoW and Avalanche where they are most suited with their strengths.
Proof of Work is good at providing an objective record of consensus over long time periods, and Avalanche is good for reliably coming to consensus quickly in real-time communication. So it makes sense to use use each protocol for those purposes.
The real-time transaction broadcast network for Bitcoin Cash currently uses a basic flooding protocol, with a “first seen” rule for each node to decide which transaction is valid in the case of attempted double-spending. This method works well enough in a benign environment, but is not very reliable in the face of a determined adversary. To be absolutely sure that a transaction is not double-spent, it is necessary to wait for blocks to be mined. It seems evident that using Avalanche as a drop-in replacement for this system would be a clear win.
Once we have a reliable system for resolving double-spends in real time, it becomes possible use this system to make instant transactions even more reliable with pre-consensus. Chris Pacia has written a good article on this topic [2].
This is not the only area of the protocol that could benefit from Avalanche, however. Another is defense from reorg attacks using post-consensus. Where pre-consensus is for deciding which transactions go into blocks in the case of double-spends, post-consensus of for deciding which chain tip to mine on in the case of competing chain tips.
Avalanche for Post-Consensus
Similar to the transaction networking protocol, miners communicate blocks to each other with a simple broadcast system. Another similarity is that this system works well enough in a benign scenario, but has problems in an adversarial situation.
Bitcoin Cash is in a situation where it shares the PoW algorithm with the much larger Bitcoin (BTC) network. At the time of writing, the BCH hash rate is around 5% of the total SHA256 hash, but recently it has been as low as around 2.5%. The lower this proportion is, the more feasible it becomes for a large SHA256 miner to conduct reorg attacks on the BCH network. Additionally, many of the events and rhetoric surrounding the recent “hash war” suggest that parties exist who may wish to conduct such an attack.
In order to provide a way for BCH to survive such an attack, Bitcoin ABC implemented a 10-block finalization method to prevent reorgs after 10 confirmations. The problem with this method is that it cannot reliably come to consensus in edge cases, at the border of the criterion for detecting an attack scenario. This means that, theoretically, a network split that could be engineered by designing the reorg to be right at the edge condition where finalization overrides the longest PoW chain, causing some nodes to follow a reorg, and others to reject it.
But we can see that this is a consensus problem, and Avalanche can solve those! This means that, for the case of reorg attacks, Avalanche is a solid method for all miners to come to consensus on when to reject large reorgs, without risk of splitting the defender chain. If a persistent 51% attacker keeps building a longer chain, it would still cause issues for SPV nodes, and nodes that are unaware of the Avalanche consensus. But for miners, merchants, and exchanges following the Avalanche consensus, this provides a viable method of surviving 51% attacks. The defenders could at least coordinate their efforts reliably, and not be thrown into chaos by a crafty attacker.
In our stone tablet analogy, miners using Avalanche for post-consensus is like the stone tablet scribes communicating with each other to make sure they are working on carving the correct messages into the tablets. If some random scribe suddenly shows up with a bundle of pre-carved tablets that contradict the previously carved messages, the rest of the scribes can reject them. Their real-time communication will be reliable so that they can have confidence that they all agree when to reject impostor tablets.
The Economics of Bitcoin Cash
When people talk about how different protocol improvements “change the economics” of the system, it is a bit of a red herring. Avalanche can simply be viewed as a more reliable way for nodes to communicate with each other. This, in turn,enables cooperative nodes to coordinate reliably to defend against non-cooperative nodes. As an analogy, one could say that marine radio “changed the economics” of fish markets by allowing the fish vendors to coordinate with the ships before they reach land, and set prices accordingly. But this just increases market efficiency, and does not change the fact that the fishermen still need to catch fish, and the vendors still need to sell to people who want fish.
A similar analysis applies with Avalanche and PoW. Avalanche can help honest miners cooperate to build on the same chain, and prevent attackers from splitting their efforts. Ultimately though, they will still try to build the longest PoW chain, and create a useful form of money that people will want to use.
Conclusion
Given that the Bitcoin Cash hash rate is a very small percentage of overall SHA256 hash, and the presence of declared aggressors, it makes sense to employ defensive measures which will ensure BCH chain survival. This will also help encourage commerce to reducing the risk of disruption.
The Avalanche protocol provides a good mechanism for post-consensus defense against blockchain reorganization attacks. This gives honest nodes a fighting chance, enabling them to cooperate to defend against those who wish to dominate and disrupt.
Strengthening Bitcoin Cash to ensure it survives under difficult conditions bolsters confidence that it can be relied on as a good form of money. Making Bitcoin Cash indestructible in hard times will help make it unbeatable in good times.
References
[1] “Snowflake to Avalanche” paper https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV
[2] Chris Pacia “Avalanche Pre-Consensus: Making Zeroconf Secure” https://medium.com/@chrispacia/avalanche-pre-consensus-making-zeroconf-secure-ddedec254339
Acknowledgements
Thank you to Corbin Fraser, Amaury Séchet, and Chris Pacia for reviewing and providing feedback for this article.
