Table of Links Abstract and 1. Introduction Abstract and 1. Introduction 2 Methodology 2 Methodology 3 Hardware 3 Hardware 4 Software 4 Software 5 Network 5 Network 6 Consensus 6 Consensus 7 Cryptocurrency Economics 7 Cryptocurrency Economics 8 Client API 8 Client API 9 Governance 9 Governance 10 Geography 10 Geography 11 Case Studies 11 Case Studies 12 Discussion and References 12 Discussion and References A. Decentralization and Policymaking A. Decentralization and Policymaking B. Software Testing B. Software Testing C. Brief Evaluations per Layer C. Brief Evaluations per Layer D. Measuring decentralization D. Measuring decentralization E. Fault Tolerance and 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. safety liveness privacy price stability 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 legal persons 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. 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). Authors:
(1) Christina Ovezik, University of Edinburgh (c.ovezik@ed.ac.uk);
(2) Dimitris Karakostas, University of Edinburgh (dkarakos@ed.ac.uk);
(3) Aggelos Kiayias, University of Edinburgh and IOG (akiayias@ed.ac.uk). Authors: Authors: (1) Christina Ovezik, University of Edinburgh (c.ovezik@ed.ac.uk); (2) Dimitris Karakostas, University of Edinburgh (dkarakos@ed.ac.uk); (3) Aggelos Kiayias, University of Edinburgh and IOG (akiayias@ed.ac.uk). This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv [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.

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

SoK: A Stratified Approach to Blockchain Decentralization

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps