Consensus, Governance and Voting are at the heart of processes that affect people beyond everyday operations and policies. But this illusion of equality only exists in principles and protocols, never in practice. The reality is that nobody is able to get his/her voice to count at all time, no matter how critical his/her whistle-blowing might be. Let’s have a go at mapping the requirements of a trustless Web 3.0.

Experience vs Experiment

In the world of development, the requirements of a project formally determine the features that will be implemented and the items that participants will trade. But when you are building a new product or software, you cannot always rely on what has been done before or what has worked in the past. In fact, you probably shouldn’t base your Quality Assurance metrics on what is being done elsewhere, as you risk losing your value proposition.

The tug-of-war between cutting-edge experimentation vs time-tested experience is most visible in the blockchain space, where hundreds of projects emerge day-in day-out, all vying for people’s time and trust. In the world of open-source development, forks and splits are fast becoming the preferred way to test and entrench the viability of an entreprise. The advantages are two-fold: there is no need to launch an Initial Coin Offering (ICO) so long as you can convince existing contributors to stay by your side.

The latest occurrence of this trend is observed in the Bitcoin Cash community of miners, developers and founders. Back in 2017, the BCH project evolved as a fork of the BTC protocol as a follow-up on the “Block size debate”. In November 2019, the BCH project underwent a hard fork that created a new protocol called BSV, as the result of ongoing disputes between the two co-founders. On the 15th November 2020, the BCH project was once again splitting into Bitcoin Cash Node (BCHN) and Bitcoin Cash ABC (BCHA). This time around, the partition originated from a disputed Infrastructure Funding Plan (aka “Miner tax”).

Communal commitment

Without a doubt, the requirements of a project in development are tightly linked to the needs and wants of select users. Market research, polls and bug bounties are some effective ways to create community engagement while the software is still in production. But this doesn’t mean that the developing teams can’t specify their own vision of how things should work. Code, just like documentation, is always work-in-progress that goes through numerous iterations to refine itself over time.

However, there are times when the input from the community of participants needs to be considered as a priority over the protocols that have been developed. This is because a plan on paper or in abstract can never account for the changes that occur in real-life: a decision unanimously made at one point in time can evolve to become a hurdle in the practical sense, preventing a project from following its due course. This is one aspect of development that coders and engineers struggle to deal with: they must come to term with the fact that their modelling remains incomplete by human metrics.

This is what recently happened during a referendum call on the Polkadot project by a user who fell prey to an online scam. The proposal suggested that the runtime of the blockchain be updated with the method “forceTransfer” so that the DOT tokens that he transferred to the scammers can be redirected back into his own wallet. In the six weeks leading up to the final voting count, the user submitted a series of documents to multiple stakeholders with good standing in the community. Yet the referendum failed on the 11th November 2020 due to low voting turnout. Interestingly, a similar proposal has re-emerged from a user who experienced a problem when backing-up his/her wallet.

Mutable rules and regulations

Given that requirements are always changing to meet the demands of users who constantly redefine their priorities based on their own personal experiences, rules and procedures must also change. And for change to be rapidly implemented, the software itself needs to be designed well-enough to tolerate unexpected calls and inputs without failing. Common approaches for testing the mutability of a platform include coding on node templates, creating beta apps or launching testnets. After which, it is easier to proceed with updates that are the most popular among users.

Unfortunately, testing is not always easy to perform on forked code, even less so on older platforms that have experienced many patches. This means that vulnerabilities in existence on someone’s master branch are likely to become points of failure on someone else’s programme. Here lies the incentive to review and upgrade the code by introducing new features and parameters, moving away from the initial release. In-house development follows a life-cycle that doesn’t end when the software becomes distributed around the web. If anything, the imperative to keep everyone else on the same page by scheduling upgrades becomes a necessity to avoid costly downtimes.

Evidence of this can be found in the accidental hard fork that shook the Ethereum ecosystem on 11th November 2020, disrupting the course of thousands of transactions. At the heart of the problem was the fix for a 2-year-old bug that was introduced by Go Ethereum developers without any announcement to stakeholders. Essential service providers who were running the old client version were separated from the rest of the network and remained stuck on a minor chain for some hours. More than the lack of governance and accountability regarding this episode, it is the decision to risk the integrity of consensus on the world’s second largest blockchain that is being condemned.

Without the majority’s concern and streamlined updates, it is difficult to achieve real consensus. This is why every new system needs a core of believers and defenders to establish itself and become resilient over time. Nevertheless, there is no guarantee that the set of elected trustees (i.e founders, developers and influencers) will remain magnanimously loyal to the project in thought and purpose. There is only so much trust that can be given or taken; and if you wait long enough to gain enough standing and stature within a community, you are then enabled to stir the proverbial pot as you see fit.

Useful resources:

Bitcoin Magazine: How and Why Bitcoin Cash might split again […]

Decrypt: Proposal to make it easier to vote on Uniswap’s future fails

Futures: Ethereum blockchain split creates issues