Musings on Governance around Consensus Development for Open Source Blockchain
Introduction
Over the last several months I have become involved in several blockchain development teams. One of the things which struck me about governance of these projects was how centralized the control around the source code repos are. Most of these projects claim to be “totally decentralized” and consensus driven, primarily, I believe, for liability reasons. The people who benefit from these technologies want to keep the rewards while simultaneously being held harmless for any losses experienced by their users or shielded from zealous government regulators looking to protect inexperienced investors. In reality, these projects have a small number of gatekeepers who control when code can actually be merged into a production release. Those people are usually aligned in their common vision of the project creating an echo chamber that reinforces the project’s trajectory. In my review of the major crypto coins that I became involved with, none of them had a true consensus based development process; not even close.
Here I will lay out some of the challenges of consensus development and then present several potential solutions. This article assumes familiarity with open source development processes and will use some semi-technical terms, such as “repo”, “PR” and “merge”.
Challenges to consensus driven development
Challenge #1 — Merge permissions
Nearly all open source crypto projects use GitHub as their repo management. Although this is not a requirement, it is a de facto standard. Coins which do not use GitHub may be perceived as untrustworthy or scams. GitHub code merge permission is limited by account which is connected to a login. Although there are many options on how and when merges occur, those controls are in the hands of the administrator(s) of the repo. This is the first step toward centralized control.
Challenge #2 — Change governance
Open source crypto projects usually have some sort of change governance policy, which mostly consists of an inviting platitude “we accept all changes that are good for the community”. This of course means absolutely nothing. Governance on changes, e.g. deciding which changes to accept, has numerous pitfalls. What group of people decide which change to accept? At what frequency are changes merged into production? How is voting managed, who gets to vote and how long is voting open for? What level of consensus is needed to ratify a change? Once a change is ratified, who certifies that it actually works and is not malicious? Having a meaningless, unclear, or entirely absent governance process is another step toward central control.
Challenge #3 — Security
A unique property of open source crypto is that the system acts as a store of value. This imposes special requirements on production commits. A malicious developer who sneaks in value stealing routines can destroy the entire project overnight. Special care must be taken in the testing phase to ensure the integrity of every change. The project gatekeepers will wield the sword of security in the name of centralization — “the code must be protected and I am your protector”.
Possible solutions
The possible solutions below are all suggestions for tools in a toolbox. There’s certainly no single solution because of the inherent tug of war between open source community involvement and security.
Tool #1 — Stake based voting
As a way to align individuals to a project’s value, create a system, on chain, which allows votes to be cast for change commits based on total coins held at the time of voting. Alternatively, set a tiered structure, where X amount of coins allows for some class of commits (say non hard/soft fork) vs Y amount for another class of commits (something that impacts the wallet). This system protects the overall project value by forcing people to have something at risk if a bad thing happens. The drawback is that it reduces the egalitarian feel of open source (only “wealthy” people can make changes instead of every voice counts) and is open to some exploits, such as gathering a large amount of coin, committing a nefarious “timebomb” change and then dumping the coin before the bomb goes off.
Tool #2 — Scheduled releases
Most commercial projects work on a timed release schedule with sprints or scrums and point releases that follow based on a task board. This allows developers to be organized around their changes and reduces code conflict. Open source resists some of that organization due to its free flowing nature — people join and leave the project at will and there is no central management. However, having a published scheduled release process would facilitate fair and open voting (people know the next time that votes are due) and would help disparate project developers coordinate changes.
Tool #3 — Merge process is ministerial / automated
By defining the merge process as a duty that is simply carried out by the account holder, instead of having the account holder approve the change, all contention is removed from the role. If the account holder refuses to act, the community can simply clone the repo and assign a new merge delegate. Having explicit consensus governance rules around the merge process alleviates community contention about hidden agendas or “power grabs” by the person holding merge permissions. This could be taken a step further by having the process entirely automated on chain. Once votes are cast, a technological mechanism could auto-commit changes and publish new binaries without any human intervention.
Tool #4 — No core changes
A possible solution to community governance would be to state that there are no core changes. This only works if the core is extensible enough to “keep up” with features of other competing crypto projects. This type of extensibility would need to allow for pluggable modules which could be developed by anyone and the community of users could then decide if they want to install a module or not. A design of this type would likely be a ground up endeavor as BTC core does not readily allow for such a concept.
Tool #5 — Progressive trust
A manual or automated system of increasing trust could be created as a way to gradually allow developers to merge commits. The governance procedure could allow for tiered permissions based on number of commits, on chain “star” awards from users, length of time spent developing (hard to measure), lines of code committed or other similar work based metrics. Trust could also be doled out based on positive community participation — 5 points for each month that someone runs a full node, 10 points for each 1% of mining power contributed, etc. The points or user based awards could be stored on chain and the permission mechanism automated according to the governance policy.
Tool #6 — Prohibit corporate sponsored core development
This is difficult to track and implement and would likely need to be enforced manually. By prohibiting corporate sponsored development on the core, the core remains ideologically free from profit driven motives of company owners who seek to influence the development for their own gain at the expense of users, other core developers or miners. The down side of this is that the project will need to expend extra work to make risk capital feel welcome to build extensions and not appear elitist or anti-commercial.
Tool #7 — External or rotating security analysis
Because security on an open source crypto project is critical, part of the governance should allow for pre-release security evaluations. This can be performed by reputable and neutral third parties or by a randomly selected community member based on qualifications. This has several downsides. External security testing can be expensive and time consuming. There is a risk that a community member could collude with the third party security company. By selecting random community members, from a pool, the risk of collusion is less, but this requires a large(ish) number of members skilled in security assessment. Automated testing and code analysis can alleviate some security risk, however independent security review is crucial if the project is truly open source (e.g. -anyone- can contribute).
Summary
I have presented some of the challenges to open source crypto development as well as a few potential solutions in the form of governance objectives. There is no silver bullet because of the competing goals of community contribution and high levels of security.
What I have observed in the open source crypto market currently is high levels of concentrated control and centralized management under either technical evangelists (e.g. coin creators) or third party commercial enterprises. Evangelists exert control over projects which they deem “their coin” for various reasons — ego, altruism, social justice or just plain greed. Commercial enterprises exert control over projects for profit generation. Both solutions result in what I would call hypocritical open source. These projects are open source in name only. They lack any true governance tools that allow developers, at large, to contribute, which in turn reduces the amount of innovation and overall credibility of the open source crypto space.
In order to move beyond these constructs I propose that open source crypto projects adopt clear governance policies, preferably automated, which allow for true consensus development.