Decentralization is often talked about as a key quality for blockchain projects. But what is decentralization? Is it a starting point or, conversely, a destination? Can it be quantified and will it be useful in every case?
These questions are becoming increasingly pressing now that the SEC has explicitly named decentralization as a determining factor when deciding whether to classify crypto assets (tokens) as securities.
“Decentralized is a project in which there is no third party, an intermediary, whose efforts are a key factor determining the success of the enterprise: through the development of an asset, building a network, using financial proceeds to improve functionality, exercising control rights and owning a significant share in the project.” William Hinman, SEC, June 14, 2018
It's interesting that in an industry so careful about definitions and classifications, the term "decentralization" is used so liberally and often without any real analysis.
Moreover, while previously the crypto community that formed around Bitcoin, consisting mainly of libertarians and cypherpunks, sought decentralization as a core value, now the industry is evolving and attracting the wider world of businesses, banks and governments, and these new participants have different, and sometimes conflicting agendas.
For these new interest groups, the trade-offs underlying the Bitcoin and Ethereum networks are impractical, or worse, inconsistent with the regulation under which they insist they can/should be funded and operate.
Therefore, understanding the realities of decentralization and their formation within the broader historical context of governance has never been more important to being able to have informed and intelligent debate.
What is decentralization?
It would be important and reasonable to start with the fact that decentralization is a spectrum. While often a preferred property of systems because it can be more resilient and less vulnerable to attack, failure, or censorship, it is not really a binary quality.
Moreover, decentralization in the context of Distributed Ledger Technology (DLT) is complex and multifaceted, and ultimately includes all aspects of how the network, its token, and the economy are governed. It is also important to note that different classes of solutions will have different levels of decentralization.
In the Bitcoin and Ethereum networks, it is extremely important to try to build a mechanism for decentralized consensus generation to ensure the security of the network. However, other classes of decisions—such as conflict resolution (judicial) or network updates (legislative)—remain relatively centralized.
While decentralization is a complex concept, we believe that when talking about it in the context of DLT, the topic can be divided into five areas:
How will this be implemented in practice?
Let’s say that supporters of the “decentralized plan” were able to gain power in the country and tried to implement their idea in practice. Where it leads? Some enterprises will refuse to carry out their plan. For various reasons - the owner’s political views, disagreement with the plan, and so on. Some enterprises will refuse to monitor the implementation of the plan. Some enterprises will agree and will control, but will not fulfill the plans. Some enterprises will close, thereby not fulfilling the plan - after all, with decentralization, no one has the right to force them to fulfill it, no matter what. All this together will lead to failure to fulfill the economic development plan and unsatisfied demand. Supporters of a planned economy will either have to force enterprises to carry out the plan, or their plan will not be fulfilled and will have to be abandoned. In the first case, they will begin to exercise the strictest centralized control, which will lead to a repetition of the Soviet experience. This is what a planned economy was in practice and always will be.
Hard forks and soft forks
Many people judge by how a project looks at the time the genesis block is formed how prone it may or may not be to forks in the future, but we don’t know of any way to quantify this likelihood.
Such assumptions often also imply that a fork is always a destructive event that has a negative impact on the network, rather than a common occurrence inherent in open source protocols. This is all the more important to understand in the context of ongoing discussions about where in decentralized networks the increase in value will occur: at the application level or at the basic protocol level.
Regarding the latter, how well the protocol is designed and managed will speak about the sustainability of not only the protocol, but also the entire economic system being created, which we will talk about in more detail later.
A hard fork is a rule change in which software that validates blocks under the old rules will identify blocks created under the new rules as invalid.
To work under the new rules, node owners must update their software. If one group of network hosts continues to use the old software while other hosts have switched to the new software, network fragmentation may occur.
User-activated soft fork (UASF) is a controversial concept of forcing a rule change through a soft fork without the support of the majority of miners.
The role of smart contracts in DeFi
Most applications in the DeFi space involve the creation and execution of smart contracts. Smart contracts use computer code to define the terms between parties entering into an agreement, whereas a regular contract uses legal terminology. All terms of the agreement are described in the smart contract. This ensures reliable execution and automation of business processes.
Smart contracts are easier and faster to use. This has the effect of reducing the likelihood of adverse events for both parties. However, because computer code is error-prone, sensitive information locked in smart contracts is at risk.
History of decentralization
Unfortunately, a discussion of the age-old challenge of governance in collective decision-making and the balance between the efficiency of centralized governance and the distribution, participation, and protection from tyranny inherent in more decentralized forms of governance is beyond the scope of this article.
Separation of powers, federalism, delegation of powers, and other constitutional mechanisms are designed to limit personal power and increase subsidiarity, the principle that problems should be solved by the least centralized authority capable of dealing with them effectively.
The key point we want to make here is that decentralization is a political ideal, like sovereignty. And, as with sovereignty, it is difficult to design and even more difficult to maintain. But more importantly, decentralization is a design decision that involves a number of trade-offs, and those are what we want to explore here.
Information and communications technologies—such as the telegraph, telephone, and Internet—increasingly make decision-making faster, more collegial, distributed, and sometimes automated.
However, to stay within the scope of this article, we'll start with the 1970s and the rise of open source software. Although participation in open source software development is distributed, from a political point of view it is difficult to call such projects decentralized because, although they are open to all participants and very democratic, the decision-making process in them is largely hierarchical and ultimately controlled a benevolent dictatorship that makes a significant contribution to the process and therefore has a great influence, as is clearly seen in the examples of Linux or Mozilla.
Numbers
DeFi services have relatively few users. According to the Dune Analytics service, the total number of unique addresses in DeFi at the end of July 2022 was just over 3 million. In addition, according to the results of a study conducted by Chainalysis, more than 60% of transactions in the decentralized finance market were transactions with a volume of more than $10 million, which carried out by large investors. That is, in the early 2020s, the decentralized finance market is more of a closed club than a product for the masses.
Key differences between open systems, p2p networks and tokenized DLTs
We believe that there are significant differences between classical open systems, distributed peer-to-peer networks, and today's tokenized DLTs, which we will call open economic systems.
The digital scarcity innovation allows us to bring an economic incentive to distributed network coordination and potentially a more decentralized governance system in which enforceable rules can be written directly into the ledger code.
However, this is a double-edged sword, as such systems raise the stakes for unfavorable behavior by participants, where a fork can be a way to not only develop the code base, but also manage monetary policy and potentially distribute wealth.
Sources
- Economy. Explanatory dictionary // General edition: Doctor of Economics. Osadchaya I.M. - M.: “INFRA-M”, Publishing House “Ves Mir”, 2000
- Dictionary of Economic Theory // Compiled by V.P. Teplov - 136 p. — Novosibirsk: RGTEU, Novosibirsk branch, 2007
- M.S. Voslensky. Nomenclature. The ruling class of the Soviet Union. – 294 p. - Moscow: MP "October" - Soviet Russia, 1991. - With. 215-222.
- A.A. Tkachenko. Indicative planning // Great Russian Encyclopedia. Volume 11. Moscow, 2008, p. 242. [Electronic resource]. URL: https://bigenc.ru/economics/text/2009079 (access date: 06/07/2021).
- Decentralized planning // Libertarian Socialist Movement. VKontakte (vk.com). August 10, 2022. [Electronic resource]. URL: https://vk.com/@lisomo-decentralizovannoe-planirovanie (date of access: 06/07/2021).
So are our new systems decentralized?
As we mentioned in the introduction, the degree of decentralization is becoming an increasingly important criterion for some regulators as they try to navigate this rapidly evolving area.
The SEC recently stated that Bitcoin and Ethereum (as they stand today) probably cannot be classified as securities due to their inherent (quote) “high degree of decentralization.”
However, for those deeply involved in this area, this formulation raises more questions than answers. As can be seen from the table below, upon closer examination and taking into account the nuances of open economic systems, this statement can largely be called a myth.
| Name | # entities controlling >50% of mining power or votes | % of money supply held by top 100 accounts | # client codebases that account for >90% of nodes | # public nodes |
| Bitcoin | 3 | 19 % | 1 | 9624 |
| Bitcoin Cash | 3 | 25 % | 2 | 2124 |
| Ripple | 1 | 81 % | 1 | 732 |
| Stellar | 1 | 95 % | 1 | 111 |
| Ethereum | 3 | 34 % | 2 | 15708 |
| Cardano | 1 | 40 % | 1 | 1 |
| Decred | 2 | 39 % | 1 | 259 |
The path to decentralization
We understand with increasing clarity that decentralization is not a starting point or even an end state, but rather a path that requires pragmatism and flexibility on the part of those who follow it.
Understanding and optimally planning for decentralization is especially important to us at Outlier Ventures because we are not only investors, but also advisors in the areas of tokenized economies, system design, and our portfolio management. The success of most of our investments usually depends on the long-term success of our projects, so we need them to be viable and sustainable.
And this is not an easy task. If we look at the short (only about 10 years) history of the cryptosphere, we see that it is full of examples of challenges to decentralized governance - be it the scaling problems faced by Bitcoin, the rollback of the network state as a result of a hack, and the ensuing debate about how to adopt solutions (Ethereum), as well as simply updating networks.
At best this was bad PR, at worst it could limit user growth and network updates, and at worst it led to controversial forks. This can only be considered a consequence of the fact that these projects are the first generation of protocols with radically new solutions that will eventually need to be forked to become more mature. However, there are several common themes that can potentially be mitigated through good planning and management, such as:
- Scaling – strong division of opinion regarding how and when changes should be made at the protocol level. The most famous example is the block size controversy in Bitcoin.
- Centralization - part of the community that has formed around the protocol believes that the protocol is governed too centrally, and creates a fork aimed at implementing a more decentralized governance model - for example, with a completely different governance model or through a change in the consensus algorithm designed to counteract the centralization of mining.
- Updates – the new version of the protocol contains critical changes, and therefore requires a hard fork. An obvious example would be desirable forks, which involve the support of the majority of the community. On the other hand, controversial forks are sometimes referred to simply as "updates" in order to gain community support.
As a result, the crypto industry has introduced many new changes to the already complex subject of managing decentralized systems and increased the cost of error. This is why we believe it is necessary to have an agile process that acts as a guiding route to optimal decentralization for a given use case.
Mapping the path to decentralization
Below we have outlined some possible considerations across the spectrum of decentralization - from basic board meetings, through the introduction of machine learning, to decision-making and governance processes. The main theme is the regulatory considerations available regarding the degree of decentralization, and the level of utility at the point of sale to the end user, governance and its codification need to be considered in parallel with the token sale process: who can participate in the system and at what stage.
Potentially, even a geographic dimension could be included to account for differences in the various regulatory environments that exist around the world, such as the nuances of US securities laws. Our framework is not intended to be completely comprehensive or prescriptive, but rather a cognitive map to show you how we think about decentralization in our work.
The most important thing we would like to emphasize is that we always believe it is optimal to keep the decision-making process “raw” (analog and involving human participation) and flexible, as the project moves towards key stages of its development, starting with “full functionality” (the formulation SEC: as complete as open source technology can be) and before marketization of the network (when the network is used for its intended purpose in the context of one or more industry verticals).
Codifying design decisions too early can become restrictive when faced with market realities and general events (such as hacker attacks), making the system more vulnerable and susceptible to forks.
At the initial stage, the project must consider the desired optimal degree of decentralization at different levels of the network and how reasonable this is in terms of its utility to users and regulatory compliance requirements, in order to find consensus with the majority of network participants and avoid value leakage or hard forks in the long term.
In early periods of highly centralized projects, we can gain the necessary knowledge from the open source community, which practices radical levels of transparency. While decision making can be completely inclusive, trust in the project community can be maintained and increased through good and open practices of regular interaction. Clearly, the general characteristics of DLT fit this purpose well and do not need explanation.
During the token design process, we recommend investing significant time in assessing the range of possible adversarial attacks that could occur on the network, and depending on the results, adjusting the intended route to decentralization and how manageable the ledger should be in the future.
We included in our visualization examples of how far you could theoretically go in your quest for decentralization, such as algorithmic monetary policy decision-making and automated implementation.
Work risks
- Vulnerability of smart contracts. The security measures of smart contracts are at a high level, but they are not immune to the risk of hacker attacks.
- Vulnerabilities on the user side. Not everyone monitors the safety of their private keys and passwords. It is recommended to use hardware wallets, as well as two-factor authentication.
- Protocol update failed. Many projects are governed by the votes of all token holders. However, the majority opinion may not always coincide with yours.
- Financial risks. The main one is a fall in the value of an asset. It is almost impossible to predict exchange rate fluctuations.
