Table of Links
Abstract and 1. Introduction
2 Methodology
3 Hardware
4 Software
5 Network
6 Consensus
7 Cryptocurrency Economics
8 Client API
9 Governance
10 Geography
11 Case Studies
12 Discussion and References
A. Decentralization and Policymaking
B. Software Testing
C. Brief Evaluations per Layer
D. Measuring decentralization
E. Fault Tolerance and Decentralization
2 Methodology
Decentralization in the context of blockchains is often reduced to particular aspects of the system e.g., consensus participation. Nonetheless, distributed ledgers comprise multiple essential, interacting components. Drawing from all sources of prior research, our work discerns the layers that form a ledger in a “bottomup” manner.[5] Starting from the physical layer, i.e., Hardware, we systematize blockchain decentralization in multiple strata, all the way up to Governance. We also include Geography as a dimension that touches upon all other layers (Figure 1). We note that this layering is applied only on the ledger’s stack; exploring decentralization in exogenous infrastructure (e.g., physical links, Internet routing, operating systems etc.) is an interesting question, but outside the scope of this paper.
A first step to understand the importance of decentralization for such systems is to identify the properties of interest that distributed ledgers should satisfy and
which can be affected by the ledger’s degree of decentralization. The two core security properties that each ledger should guarantee are safety and liveness. Safety ensures that all honest users hold the same, “settled” view of the ledger. Liveness reflects the ability to update the ledger’s settled view regularly, as new transactions are submitted. We note that safety and liveness typically incorporate and express other useful properties for real-world applications, such as transaction finality or censorship resistance. A third property, privacy, guarantees that users’ actions enjoy a certain degree of dissociation from their real-world identities and individually are unlinkable. Finally, specifically in the context of blockchain systems, price stability captures the property that the ledger’s core digital asset’s supply and market price are predictable (to a reasonable extent). In particular, price stability is violated if the asset’s market price demonstrates high volatility in the short term (e.g., monthly).[6] For ease of reading, we will refer to this property only as “stability” for the rest of the paper.
We view these properties through the lens of (cyber-)security, i.e., in the context of an adversary who wishes to subvert them. This is strictly stronger compared to settings where failures are assumed to be benign (e.g., crash faults due to power outages). A single point of failure exists when a single party, if controlled by the adversary, can violate one or more of the ledger’s properties.
We lay out the following methodology: for each system layer we identify (a) one or more resources, that can be thought of as the basic “unit” of the layer pertaining to the ledger’s security properties; (b) the relevant parties that control, either directly or indirectly, said resources; (c) the ledger’s properties that are at risk, if the resources’ distribution across the relevant parties becomes centralized. For example, considering Bitcoin’s consensus layer, the resource is hashing power and the relevant parties are the miners; the properties at risk are safety, liveness and, to a somewhat lesser degree, stability and privacy. Table 1 provides a summary of our systematization, with resources and relevant parties presented for each identified layer and sub-category.
Notably, a resource might be modular, with some parts considered more important than others. For instance, software products are typically not monolithic, with e.g., documentation being less crucial than a library or a configuration file. Therefore, the parties that maintain the former have (arguably) less influence over the resource (i.e., the software product) than the coders of the latter. To resolve this concern, one could compute an aggregate level of decentralization, after weighing each component based on its significance. Such aggregation methodology could also be applied to compute the decentralization level of the whole system, assuming weights for each layer (cf. Section 12).
Another issue is that one relevant party may encompass multiple real-world identities. For instance, consider two software products, one maintained by a single organization with many members, the other maintained by a handful of independent developers. Although the first may be more decentralized in terms of people, from a legal perspective the second may be deemed more decentralized, as the first is authored by a single legal entity.
By projecting the relevant parties of each category to legal persons, we articulate a test that can be useful in assessing systems w.r.t. their decentralization in a legal sense (Definition 1). Here, a legal person can be an organization, e.g., a company or non-profit foundation, or an individual
Definition 1. A blockchain system fails the Minimum Decentralization Test (MDT) if and only if there exists a layer (cf. Table 1) for which there is a single legal person that controls a sufficient number of relevant parties so that it is able to violate a property of interest.
In the following sections, we provide detailed explanations as to why each identified layer is important and how it fits into our framework (Sections 3-10). Then, we apply our methodology on case studies (Section 11), and finally, we suggest various directions for future research that our work points to (Section 12).
[5] Our stratification is inspired by the OSI conceptual network model, cf. [162].
[6] The cryptocurrency market is notoriously volatile, so one could apply different thresholds for “reasonable” levels of volatility. An interesting line of future research would be to identify non-cryptocurrency assets, which could serve as a base of comparison for which levels of volatility are acceptable in this case.
