A flock of starlings

Starling murmurations are completely leaderless and decentralized and are governed by a surprisingly simple algorithm followed by each actor. Would that core devs were as simple! Photo by James Wainscoat on Unsplash.

[This is part of a multi-part series on the key ingredients to a better blockchain. I recommend starting with part one, Tech and Protocol. See the full list of articles in the series.]

While decentralization is never an end in and of itself, it is a means to many ends including resistance to censorship, corruption, and collusion; antifragility; participatory, inclusive institutions; and a fair distribution of wealth, power, and influence. Decentralization is inappropriate for most applications due to its inefficiency and higher costs, but for those that do require it, it’s essential that the underlying platform pays more than lip service to decentralization. As are we decentralized yet? likes to remind us, decentralization is multidimensional and far from binary. A closely related topic is permissionlessness, also discussed in this part: allowing anyone, anywhere to contribute to your project, platform, or community is an essential part of the decentralization ethos.

  • Are there multiple client implementations? There are two schools of thought here. One posits that a single, canonical client implementation allows scarce resources to be focused on one project, and a single team of developers can communicate more easily, maximizing the likelihood of success and competitiveness vis-a-vis other platforms. Additionally, a single reference client implementation by definition prevents consensus failures, where different nodes disagree on the state of the ledger (at least as long as everyone upgrades their software after a hard fork). The other school posits that the existence of multiple implementations makes a network more likely to survive an attack (where one client may stop producing blocks completely) or a consensus failure (where one or more clients fail to implement the protocol correctly, which could cause bad blocks to be produced, or no blocks at all). Indeed, both have happened in Ethereum. But there are more subtle reasons as well. For one, the existence of multiple, viable client implementations reduces the dominant influence that a single team of core devs can have on a network, arguably one of the biggest issues with Bitcoin governance (see also the Zcash Foundation’s decision to commission a second Zcash client implementation in order to counterbalance the power of the Electric Coin Company). What’s more, different clients may make different architectural decisions and have different strengths (e.g., mining, data lookup), and having clients written in different languages can make core development accessible to a much broader set of developers. While reference implementations, beta implementations, etc., are nice to have, truly viable mainnet clients are where it’s it, and as awdy likes to remind us, they are rare indeed: Bitcoin, for instance, has at least 15 client implementations, but 97% of all nodes run a single implementation, Bitcoin Core.
  • How many organizations control mining power? The more parties that participate in mining, the harder it is to collude, engage in selfish mining, or carry out a double spend attack (commonly known as a 51% attack, although the real math is more complex). This is not a hypothetical risk, as it has happened to networks such as Ethereum Classic and Bitcoin Gold. Also, more miners means a fairer distribution of mining rewards, since proof of work miners have a head start building another block on top of one they’ve just mined. While many individual miners may participate in mining, they are incentivized to cluster into a small number of mining pools, and even networks that seem relatively decentralized may be reliant upon a tiny number of individual entities for mining: the three largest Ethereum mining pools together control around 60% of total hashpower, and the top four in Bitcoin control about 56%.
  • How many full nodes are running? While non-mining, public full nodes don’t protect against double spend attacks, they can help protect against other types of attacks such as eclipse attacks or routing attacks. It helps if it’s as cheap and easy as possible to run a full node, and ideally a user can run one on commodity hardware such as a consumer-grade laptop (or a device like DappNode or Casa Node) without unreasonable bandwidth requirements.
  • How decentralized is governance? Are there many independent decision makers in charge of the protocol, brand, meetings and events, resource allocation, social media channels, Github repositories, etc., or are these centralized in the hands of a small number of wealthy, powerful entities? Even a very logically decentralized protocol may have relatively centralized decision making or resource allocation. (More to follow on this topic in the Governance section, to come.)
  • Is the platform censorship resistant? Censorship resistance is one of the primary raisons d’être of blockchain platforms. It’s one of the most important features that set these platforms, and the applications built on them, apart from the Web2 and social media world where phenomena including arbitrary censorship and deplatforming are becoming de facto. Censorship resistance is a product of the other aspects of decentralization laid out above, especially architectural decentralization of miners and full nodes, and politically decentralized governance. Note that there are degrees of censorship resistance, proportional to the degree of decentralization. A network with only a dozen or two block producers cannot be called sovereign-grade censorship resistant on the scale of Bitcoin or Ethereum, but it may be platform-grade censorship resistant, which is probably sufficient for most applications.
  • Does everyone have the freedom to operate under your brand? Is there a trademark, and if so, how is its use governed? Is it held by a single party? Is it enforced? Is there a single party that claims to speak “on behalf of” your project, or are brand communications handled in a more decentralized fashion? While keeping tight control of a brand may be something that firms tend to do at the advice of their lawyers, doing so can have a detrimental effect on a blockchain community because it contradicts core principles such as decentralization and permissionlessness. (More on this topic in Part III: Community and in the Governance section, to come.)
  • Is all of the code open source? Making it as easy as possible to contribute to your platform is not only a great way to cheaply increase the quality and speed of development, it’s also a way to recruit a diverse set of talented contributors, spot bugs and exploits, combat groupthink, and cultivate a sense of buy-in and enfranchisement in your community. Many of the best developers in the world today will only work on open source software. Using a permissive license gives your community members the confidence that, if they disagree with the design or governance of the software, they can easily fork the code and take the project in another direction. This lowers the cost of exit, encouraging more contributors to join, and keeps you honest. It’s important to note that just open-sourcing the code is not enough. Actively managing an open source project requires a great deal of work; see these best practices from GitHub as a starting point.
  • How hard is it to fork? Forks are the superpowers of decentralized, open source and blockchain projects, and are the mechanism that sets them apart from default world politics. Forks play many important roles: they keep all parties honest, act as a “release valve” in case of disagreements and disputes, and are generally the purest manifestation of the principles of decentralization and permissionless innovation: anyone, anywhere is free to contribute any idea at any time without gatekeepers. A project that is afraid of forks is one that has insecure leadership and poor governance: in other words, probably not a project you want to work on. In addition to easily forking the code, it should be as easy as possible to fork the ledger: features such as chain IDs and replay protection can make a big difference. In order to allow easy forking of governance-related resources and processes, it’s also helpful to keep as much content as possible in public, forkable open source repositories, such as Github, as opposed to proprietary accounts such as wikis, YouTube, etc.
  • What are the barriers to entry? Do you need to work for a particular organization to contribute to a project? Do you need to sign paperwork, provide documentation, or be subject to a KYC/AML process? Do you need to purchase some token? In general, do you need anyone’s permission before contributing to or transacting on the network? These are all antithetical to the spirit of decentralization and permissionlessness, prevent many groups of people from contributing, and, as a result, have the effect of severely reducing innovation.

This article is part of a multi-part series on the key ingredients to a better blockchain. Check out the other articles in the series:

Special thanks to Greg Colvin for valuable feedback on an earlier draft of this article. Several of the questions in this section were inspired by awdy.