It’s no secret that the Bitcoin Verde team is a big proponent of diversity among node implementations. We’ve been persistent with our calls for node diversity for as long as we’ve existed. Generally, we like to think the greater community shares these views with us, but on occasion we do still hear questions relating to “why multiple node implementations are a good thing”.
So, why are multiple implementations important for the network?
Distribution of Social Influence
When I think of a healthy decentralized network one of the first things that comes to mind is a balance of power and control. Deploying multiple types of node implementations is an easy way to strike that balance.
It’s a slippery slope to become overly reliant on single entities, and it's an effective way for a public project to be taken over or misdirected (either maliciously or accidentally), as we’ve seen in the past with Bitcoin Core. When using someone else's software, users are generally reliant on what updates the developers provide. If the community becomes too reliant on a single entity to support their network, the reach of social influence and control is ultimately going to be tipped out of balance.
Unfortunately, as history has shown, people tend to act in their own self interest when left to their own governance. The problem really arises when the providers and the users eventually come to a hard disagreement, and in terms of BCH’s history, a network split is almost always the result. An easy way to remove this risk is to simply not become overly reliant on any single entity; this raises the cost for node’s to disagree and applies pressure for them to find a compromise, especially if the mining hash power and user support distribution is uncertain.
While this is certainly true for node operators, it is even more important among mining implementations. As we have seen with Bitcoin ABC’s departure last year, a healthy network also requires multiple mining implementations. The utilization of which could help prevent any one node implementation from having a disproportionate amount of influence over any other.
Ideally mining pools would utilize an array of software and whichever performed best at the time would be the current selection, but the reality is mining BCH is a resource intensive job that produces a small margin of profit for most operators. If there are small discrepancies between implementations resulting in work being performed on invalid blocks, the miner is at risk of losing revenue. Due to these circumstances, there is a very large disincentive for operators to use anything other than the current standard.
This is all not to say the status-quo majority implementation is not a fantastic choice for miners. The BCHN client is stable and performs well. Furthermore, their team has intelligent and talented people on it that put a priority on inter-node collaboration. However, in the name of decentralization, the network should strive to break free from its reliance on any single client.
Our team has tried to incentivize this behavior ourselves with the creation of a block template validation service, the BitBalancer. This service is used to prevent miners from mining an incompatible block before they spend the electricity to create its hash; instead, the BitBalancer offers a universally compatible block template. This functionality avoids what would otherwise be an orphaned block, or worse: an accidental fork in the BCH blockchain. In the future we hope this tool will help miners feel more confident using multiple node implementations to mine BCH, and when they do, there will be no single group to easily attack.
Resiliency to Exploits and Bugs
In a similar fashion, utilization of multiple implementations helps sustain our network’s resiliency to undiscovered bugs and exploits.
Although there have not been any major discoveries in the past several months, undiscovered bugs and exploits are always a major concern, potentially one of the network’s largest threats. Today, with an ever-increasing supply of new technologies (and cryptocurrencies), there is little forgiveness among the average consumer for failure, certainly not when it comes to finances.
Over-reliance on single implementations has the potential to amplify the effect of undiscovered bugs, some of which could result rolling back large portions of the blockchain. (Yes, we’ve seen this happen even in Bitcoin’s history.)
While it did not result in a rollback, a lesser example of this problem was presented in 2018 with the Bitcoin ABC’s “SIGHASH_BUG”. The result of a code refactoring, the sighash bug would have allowed a user to submit a malicious transaction that, when validated, would have resulted in a large portion Bitcoin ABC (upgraded vs non-upgraded) nodes splitting from one another due to incompatibility issues. This issue is oddly reminiscent of the 2013 Bitcoin BerkeleyDB/LevelDB upgrade.
Although the full ramifications of this bug’s effect can still be debated, the reality is the size of the split and severity of impact would have been in direct relation to the percentage of the network using that version of ABC. Fortunately the potential impact of this bug paled in comparison to Bitcoin Core’s (unexploited) infinite inflation bug, but this example is proof that even we (BCH) are not immune to protocol bugs. Thankfully, due to the inherent mechanisms of BCH (i.e. Nakamoto consensus) a split would not necessarily mean the death of the network and could ultimately be settled without a rollback. In the hyper-competitive market of cryptocurrencies today, the reputational damage of something catastrophic such as a chain-rollback such as what was done in the early Bitcoin Core days, would be quite disruptive for the Bitcoin Cash network both financially and reputationally.
As a network, we should strive to make the chances of this occurrence an absolute minimum and it is just another reason why software diversity is so important. Typically, a bug in one implementation is unlikely to appear in others. Certainly even less so as implementations diverge in programming languages. With less chance of a critical bug affecting a majority of the network, a diverse network can be more robust and resilient to critical bugs.
Attraction of New Developers
While decentralization and network resiliency are exceedingly important ways diversity helps sustain our network, I think it is equally important to highlight how it helps our community grow.
Our community is always looking for continued growth and adoption. The more BCH is adopted for its utility, the more value it provides to its supporters. Who doesn’t want their asset to increase in value? While security and functionality are certainly important for the functional health of the network, and ultimately its value offering to users, I think it is equally important to highlight the benefits diversity provides to attracting new developers.
When our team first began development on Bitcoin Verde, Bitcoin Cash’s split from Bitcoin Core was fresh and the network consisted of only 3 primary node implementations. Of the three, each one was a forked version of the core client. At that time, if a developer was interested in contributing to BCH it would have been a requirement to familiarize themselves with a vastly complex codebase in C/C++. Although this is not to say C++ isn’t a great language choice, its pool of available developers is substantially less than other languages, and its learning curve and required mastery shouldn’t be a prerequisite to contributing to peer-to-peer electronic cash.
By limiting the amount of languages available to interested developers, we are limiting opportunities for network growth and adoption.
In the last decade the number of people interested in programming has undoubtedly grown substantially. As technology is integrated further into our lives each day, individuals looking to create new technologies continue to multiply in its support. Cryptocurrencies are not the skeptical side projects many had once considered them and the opportunity to capture new talent is available. As a new market and ever growing network, the Bitcoin Cash community should strive to capture the interest of as many developers as possible.
In the last few years, our network has done an exceptional job of welcoming new teams, individuals, services, and businesses, and in order to continue to support the growth we all hope to achieve, it will be important to continue to embrace these additions.
Conclusion
So, why do I think multiple BCH implementations are important? Because to me a healthy decentralized network is secure, resilient, and always growing, and without a diverse offering becoming a world-wide cryptocurrencies will just be a temporary dream. We should not allow an opportunity for Bitcoin Cash to fail us like Bitcoin Core has.
