By Jamie Burke with contributions from Aron van Ammers & Lawrence Lundy
Decentralisation is often cited as the core metric by which all blockchain projects are measured. But what exactly is decentralisation? Is it a starting point or destination? Is it quantifiable or even desirable in every instance? This has become increasingly pressing now the SEC (U.S. Securities and Exchange Commission) has explicitly communicated ‘decentralisation’ as a determining factor in whether it categorises a crypto-asset (aka token) as a security.
‘A decentralised project is one with the absence of a central third party / promoter whose efforts are a key determining factor in the enterprise: through developing the asset, building the network, use of proceeds to enhance functionality, exercise of governance rights, retaining a significant stake’.
William Hinman SEC 14 June, 2018
What’s surprising for an industry so hung up on definitions and classifications is the term ‘decentralisation’ is used so liberally and often without any real analysis. Furthermore, whilst the early crypto community that formed around Bitcoin, as libertarians and cypherpunks, prized decentralisation above all else, the industry has now evolved and attracted the wider world of enterprise, banks and governments each with different and sometimes conflicting agendas. For these new stakeholder groups the trade-offs made by the Bitcoin and Ethereum networks are impractical or worse, at odds with regulations around how they insist they can / should be financed and operated. So understanding the realities of decentralisation and framing them in a wider historical context of governance has never been more important to inform sensible and sound debate.
What exactly is decentralisation?
Firstly, it is important and sensible to say decentralisation is a spectrum. Whilst often preferable in systems because it can be more resilient and less vulnerable to attack, failure or censorship it is not in reality binary. Furthermore, decentralisation in the context of distributed ledger technology (DLT) is complex and multi-faceted and ultimately informs all aspects of how a network, and with a token, an economy is governed. It’s also important to note that different classes of decisions will have different levels of decentralisation.
In the Bitcoin and Ethereum networks it is critical to try and have decentralised consensus formation for the security of the network. However other classes of decisions such as conflict-resolution (judiciary) or network updates (legislative) remain relatively centralised. We believe decentralisation in DLT whilst complex can be distilled down into 5 domains.
[image id=’2668′ alignment=’center’]
Forks
Many see how decentralised a project is at its genesis block as a bellwether as to how vulnerable it may or may not be to future forking, however there have been no efforts we are aware of to quantify this. This also makes the assumption that forking is always a destructive and negative thing rather than something just inherent to open source protocols. This becomes an increasingly important thing to understand within the ongoing debate about where value will accrue in decentralised networks: either at the application layer or the protocols themselves (see our recent post on The Hungry Protocol). If it is at the latter then how well a protocol is designed and governed will inform the resilience of not just the protocol but the overall economic system something we discuss in more detail later.
A hard fork is a rule change such that software validating according to old rules will see blocks produced according to new rules as invalid. All nodes meant to work in accordance with the new rules need to upgrade their software. If one group of nodes continues to use the old software while the other nodes use the new software, a split can occur.
A user activated soft fork (UASF) is a contentious concept of enforcing a soft fork rule change without the majority support of miners
A Brief History of Decentralisation
It is sadly outside of the scope of this article to discuss the age-old governance challenge of collective decision-making and balancing the efficiency of centralised governance vs. the diversity, participation and protection against tyranny that come from more devolved or decentralised forms of governance. The separation of powers, federalism, devolution and other constitutional mechanisms are all designed to limit individual power and increase subsidiarity, the principle that the lowest or least centralized authority which is capable of addressing an issue effectively should do so. The key point we want to make here is decentralisation is a political ideal much like sovereignty and just like sovereignty one that is hard to design and even harder to maintain. But more importantly, decentralisation is a design choice with a set of trade-offs and it are these we want to consider here.
Information and communication technologies like the telegraph, telephone, and Internet have increasingly allowed decision making to become faster, more participatory, distributed and sometimes automated. However, for our purposes of this article we will start from the 1970s and the emergence of open source software (OSS). Whilst participation in OSS is distributed it is difficult to say open-source projects are inherently decentralised from a policy perspective because whilst open to any and all contributors and highly egalitarian, decision making is largely hierarchical and ultimately controlled by a benevolent dictatorship with the strong contribution by and therefore influence of a corporation as seen in Linux and Mozilla.
So what’s different?
We believe there are some important differences between classic open source systems (OSS), distributed p2p networks and today’s tokenised DLT, which we will refer to from now on as Open Economic Systems (OES). The innovation of digital scarcity now allows us to add an economic incentive in the coordination of a distributed network, and potentially a more decentralised system of governance, where incorruptible rules can be hardcoded into the ledger itself.
[image id=’2671′ alignment=’center’]
However, this becomes a double edge sword and raises the stake for adversarial behaviour where a fork is not just of a codebase’s development pathway but also monetary governance and potentially wealth distribution.
So are we decentralised yet?
As we mentioned in the introduction the degree of decentralisation is becoming an increasingly important measure for some regulators as they try to get to grips with this fast-moving space. The SEC recently stated Bitcoin and Ethereum (as they are today) are likely not securities because of their (quote) ‘high degree of decentralisation’. However to those more deeply involved in the space this raises more questions than it answers. On closer inspection, and with an appreciation for the nuances of OES, it can largely be seen below to be a myth on most objective measures.
[image id=’2672′ alignment=’center’]
AreWeDecentralisedYet.com
The Pathway To Decentralisation
It is becoming increasingly clear to us that decentralisation is not a start point or even an end-state but rather a pathway which requires pragmatism and agility. Understanding and planning for optimal decentralisation is especially important to us at Outlier Ventures because we are not only investors but also advisors in tokenomics, systems design and governance to our portfolio. Through vesting structures the majority of our holdings are typically tied into the long term success of our projects so we need them to be both viable and sustainable.
And this is no easy topic. If we look at the short history of crypto (circa 10 years) it is littered with examples of challenges to decentralised governance; be that the scaling issues seen in Bitcoin, roll-backs in response to hacks and consequently debates about how decisions are made (Ethereum) as well as simple network upgrades.
At best this has been bad PR, at worst has arguably limited user growth, network improvements and in the worst case led to contentious forks. It could be argued this is just a consequence of projects being the first generation of protocols with radically novel solutions which would always have needed to be forked over time to allow them to mature. However there have been some common themes that can potentially be mitigated with good planning and governance, including:
- Scaling – strongly differing opinions about how and when changes should be made to make the protocol scale. The best known examples are those around the block size debate in Bitcoin.
- Centralisation – part of the community around a protocol feels control over the protocol is too centralised, and creates a fork that aims to realise a more decentralised governance model, for example through a different governance model or changes to the consensus algorithm aimed to make mining more decentralised.
- Upgrades – a new version of the protocol introduces breaking changes, and hence requires a hard fork. This a clear case of desired forks, assuming there is wide community support. As a counter perspective, more contentious forks are sometimes branded as “upgrades” to try and win community support.
[image id=’2673′ alignment=’center’]
As a consequence the crypto industry has brought many new changes to the already complex subject of governance in decentralisation systems and upped the stakes of getting it right. That’s why we believe there needs to be an agile process that serves as a pathway to optimal decentralisation for the use-case in hand.
Pathway to Decentralisation Framework
Below we have laid out some possible considerations across the spectrum of decentralisation from basic board meetings through to introducing machine learning into decisioning and governance. The central theme is given the regulatory considerations around the degree of decentralisation, and the level of utility at the point-of-sale to retail users, governance and its codification need to be considered in parallel to the token sale process: who can participate in the system and at what stage. There potentially even being a geographic dimension to account for differences in the various worldwide regulatory environments, such as the nuances of US securities law. This is not meant to be fully comprehensive or prescriptive but more a mental model to show you how we think about decentralisation in our work.
The most important thing to stress is that we always propose it is optimal to keep decisioning ‘wet’ (analog and people intensive) and agile as a project moves towards key milestones starting with ‘full functionality’ (an SEC phrase: as complete as an open source technology can ever be) and towards Network Market Fit (when the network is being used for its intended purpose within the context of one or more industry verticals). Commiting to the codification of design choices too early can become restrictive when faced with the realities of the market and events generally (such as hacks) making the system more fragile and vulnerable to forking.
[image id=’2674′ alignment=’center’]
At the outset a project should consider its desired optimal degree of decentralisation at the various layers of the network, and as is sensible for its utility and compliance requirements, in order to find consensus with the majority of the network and avoid value leakage or hard forks over the long-term.
During the early periods of high degrees of centralisation we can borrow learnings from the open source community who deploy radical levels of transparency. So whilst decisioning making may not be completely inclusive, trust can be developed with the community (e.g. Linux) by good and open regular communications. Obviously, the general characteristics of DLT serve this purpose well and need no explanation.
We recommend investing considerable time to evaluating the range of possible adversarial attacks a network might experience, whilst carrying out the token design process, to inform the pathway and how much governance will ever be devolved to the ledger. In our visualisation we have included some examples of just how far you can take decentralisation in theory; such as algorithmic monetary policy decisioning & implementation.
Next Steps
This is obviously a very high level thought piece to surface and frame the live work we are undertaking with our portfolio companies. During this time we are developing a series of crypto-economic and network governance tools that we will continue to share with the community for feedback and iteration. But we would love your thoughts and feedback on these considerations and tradeoffs you may be working through.
Many of the topics covered here are also discussed regularly at the Token Engineering Meetups we host in London, Toronto and soon Chicago. However the community is much broader than that so if we like this kind of stuff you highly recommend you reach out and find your local chapter and if it doesn’t exist.. found it.
