# SoK: A Stratified Approach to Blockchain Decentralization

Dimitris Karakostas
U. of Edinburgh
<EMAIL_ADDRESS>Aggelos Kiayias
U. of Edinburgh and IOG
<EMAIL_ADDRESS>Christina Ovezik
U. of Edinburgh
<EMAIL_ADDRESS>
###### Abstract

Decentralization has been touted as the principal security advantage which
propelled blockchain systems at the forefront of developments in the financial
technology space. Its exact semantics nevertheless remain highly contested and
ambiguous, with proponents and critics disagreeing widely on the level of
decentralization offered. To address this, we put forth a systematization of
the current landscape with respect to decentralization and we derive a
methodology that can help direct future research towards defining and
measuring decentralization. Our approach dissects blockchain systems into
multiple layers, or strata, each possibly encapsulating multiple categories,
and enables a unified method for measuring decentralization in each one. Our
layers are  (1) hardware,  (2) software,  (3) network,  (4) consensus,  (5)
economics (“tokenomics”),  (6) API,  (7) governance, and  (8) geography.
Armed with this stratification, we examine for each layer which pertinent
properties of distributed ledgers (safety, liveness, privacy, stability) can
be at risk due to centralization and in what way. Our work highlights the
challenges in measuring and achieving decentralization, points to the degree
of (de)centralization of various existing systems, where such assessment can
be made from presently available public information, and suggests potential
metrics and directions where future research is needed. We also introduce the
“Minimum Decentralization Test”, as a way to assess the decentralization state
of a blockchain system and, as an exemplary case, we showcase how it can be
applied to Bitcoin.

##  1 Introduction

Bitcoin [Nak08], the first blockchain-based distributed ledger,111For the rest
of this work we use the terms “blockchain” and “distributed ledger”
interchangeably, even though strictly speaking, the latter describes an
objective while the former is a means to it. put forth a new paradigm, that
inspired numerous systems to enhance and expand its model and thousands of
applications to be built on them. Alongside, a research discipline emerged
across cryptography, distributed systems, game theory and economics, to
analyze the properties and capabilities of this paradigm-shifting protocol.

Bitcoin’s arguably most important contribution was offering a solution to the
consensus problem [LSP82, PSL80] in an open setting. Contrary to classic
protocols, cf. [GK20], Bitcoin participants are not known a priori; instead,
the system only assumes a peer-to-peer (P2P) synchronous network and a public
setup.222Bitcoin uses the following newspaper headline as the common, setup
string: “The Times 03/Jan/2009 Chancellor on brink of second bailout for
banks.” Bitcoin’s core security argument is that, if a majority of
computational power acts honestly, the protocol solves the consensus problem
and implements a distributed ledger, shown formally in [GKL15, PSs17, GKL17].
This, in conjunction with the premise that computational power is widely
distributed over the network participants, gives rise to the “security via
decentralization” proposition: the system has no single point of failure, as
any network participant is individually too weak to influence the properties
of the protocol, no matter how they behave. Consequently, ensuring that an
adversary is not able to corrupt enough parties to control a majority (or that
such a majority is not economically incentivized to collude and deviate from
the protocol) is the fundamental issue that blockchain systems should
establish for practical security. Intuitively, a high degree of
decentralization suggests that the trust for safe system operation is spread
across the largest possible set of parties.

The appeal of this narrative, and the emergence of ledgers like Ethereum with
APIs of higher functionality, gave rise to various “Decentralized Finance”
(DeFi) [WPG+21] applications. Such systems have drawn the attention of
industry, governments, regulators, and banks worldwide. What does
decentralization really mean though, and how decentralized are blockchain
networks? Proponents often tout the existence of diverse communities, wide
geographical distribution, or a theoretical ability of open participation as
evidence of decentralization.333A vocal Bitcoin advocate, Andreas
Antonopoulos, argues: “[Bitcoin’s] characteristics [are] openness,
decentralization, borderlessness, and permissionless access” [Ara16].
Antagonists point to power concentration around a few entities when it comes
to system maintenance, protocol upgrades, or wealth ownership.444A prime
contender is Nouriel Roubini: “Decentralization in crypto is a myth. It is a
system more centralized than North Korea: miners are centralized, exchanges
are centralized, developers are centralized dictators (Buterin is “dictator
for life” ) & the Gini inequality coefficient of bitcoin is worse than North
Korea” [Twitter]. Interestingly, both sides might be correct at the same time
— to some extent. Blockchains may exhibit high levels of decentralization
w.r.t. some aspects, but not others. Thus, the pertinent question is more
nuanced than just a simple binary one “is the system decentralized or not?” —
we are interested to also know to what degree and for which aspects.

Our work sets on exploring decentralization across different layers, or
strata, of blockchain systems, systematizing a methodology for evaluating how
existing systems fare w.r.t. each layer, and identifying relevant directions
for future research. Our systematization effort aims to inform users,
practitioners, and researchers, as well as to support policymaking and law
enforcement processes. Decentralization — or the lack of it — plays a major
role in policy discussions and the debate over the regulation, or even
usefulness, of blockchain systems.

In the US, an early policymaking decision was the SEC’s ruling of “DAO” tokens
as securities [SC+17b]. It argued that the DAO was predominantly controlled by
its creators, who handpicked parties with decisive operational capabilities.
In $2018$, it was posited that characterization as a security depended on
whether the token’s network is sufficiently decentralized [Hin18]. This was
highlighted in SEC’s guidance [SC+19], where the existence of “active
participants” (APs) that undertake essential responsibilities was named as a
deciding factor for the classification of a digital asset as a security —
particularly an “investment contract.”555In $2019$, a core argument for
characterizing XRP as a security was that token ownership, distribution,
development, and management were controlled by a single entity [SC+20]. Our
methodology, which measures decentralization as the distance from single
points of failure in different strata, could thus aid law enforcement in
making such decisions. In essence, an AP, as described by the SEC, is also a
single point of failure from a (cyber-) security perspective so, if a system
is centralized under our methodology, the sale of its digital asset is
possibly constituting an investment contract, as opposed to a system
proclaimed to be decentralized. Our minimum decentralization test (Definition
1) formalizes this perspective and could serve as a litmus test.

In the UK, the Financial Stability Board (FSB) identified the possibility of
power concentration around a small set of parties, when it comes to ownership
and operation of key infrastructure, as a major concern in the risks of the
application of decentralized technologies [Boa19]. Nonetheless, it also warned
that decentralization in conjunction with inadequate governance “makes it
difficult to resolve technological limitations or errors and may lead to
uncertainty” [Boa18].

Decentralization is also a matter of interest in the European Union. EU member
states have suggested that legislation should take into account the
decentralized nature of the technology on which various businesses operate
[SA19]. In late $2022$, the Markets in Crypto-assets regulation (MiCA) was
approved by the EU council and the Parliament Committee on Economic and
Monetary Affairs [otEU22].666A final vote in a full parliament session is
expected by the end of $2022$. This regulation makes a specific mention of
decentralization as _the_ distinguishing factor on whether a system falls
within its scope. Interestingly, systems might fall under this regulation even
if some parts of them are decentralized, but they are not fully decentralized,
i.e., across all relevant strata.777“This Regulation applies to natural, legal
persons and other undertakings and the activities and services performed,
provided or controlled, directly or indirectly, by them, including when part
of such activity or services is performed in a decentralized way. Where
crypto-asset services as defined in this Regulation are provided in a fully
decentralised manner without any intermediary they do not fall within the
scope of this Regulation.” [otEU22]

##  2 Methodology

Decentralization has been a topic of interest for centuries [Bas46, UND99,
Joh99]. In computer science, it often implies no central coordination, i.e.,
all agents or units are _peers_. Decentralization is typically touted as _the_
distinguishing property of blockchains, compared to traditional information
technology systems. However, it is mostly reduced to particular aspects of the
system e.g., consensus participation. Nonetheless, distributed ledgers
comprise multiple essential, interacting components. Our work discerns the
layers that form a ledger in a “bottom-up” manner.888Our stratification is
inspired by the OSI conceptual network model. Starting from the physical
layer, i.e., hardware, we analyze decentralization in multiple strata up to
API services and across inter-layer dimensions (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.

Figure 1:  Illustration of our methodology: the layers of a blockchain system,
identification of some type of resources in two of the layers (tokens, peers),
their assignment to relevant parties exhibiting a higher (network) and lower
(tokenomics) degree of decentralization and an example of equal joint
ownership of one token.

Another common fallacy is perceiving decentralization as a goal, instead of a
means to an end, and equating it with security, stability, or even efficiency.
In reality, decentralization guarantees none of these properties. It can be
synergistic to them, but centralized systems can be more secure and fail-safe
than decentralized ones and vice versa in practice depending on the relevant
threat model. Decentralization’s major advantage from a security perspective
is related to the system’s _resilience to single points of failure_.

A first step to understand decentralization through the lens of
(cyber-)security, in the context of blockchain systems, is identifying the
security properties of interest. The two core 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. 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, _stability_ captures the property that the ledger’s core
digital asset’s supply and market price are predictable (to a reasonable
extent). We note that we view these properties through the lens of
(cyber-)security, i.e., we envision them 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., 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.

We employ this framework for each layer, along with relevant evaluations from
the literature regarding deployed systems.999The lack of public data w.r.t.
some dimensions makes it impossible to evaluate the same set of systems
throughout our paper, hence, we present findings depending on the available
information. As the most studied systems, Bitcoin and Ethereum are included in
most evaluations, with others (e.g., Solana, Cardano) evaluated when possible.
The main benefit of our systematization effort is thus laying out the
foundations for assessing any given system’s decentralization level in a
quantitative manner. Table 1 provides a summary of our systematization, with
resources and relevant parties presented for each identified layer and sub-
category.

A caveat to consider here is that 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. Notably, 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.

Layer | Subcategory | Resources | Relevant Parties
---|---|---|---
Hardware | Proof-of-Work | Computational power |  | Manufacturers of
---
mining hardware
2-4 |  |  |
| Proof-of-Stake | Stake | Hosting providers
| Protocol participation |  | 1) Participating power
---
2) Full nodes
| Developers of
---
full node software
2-4 |  |  |
Software | Asset management | Tokens |  | Developers of
---
wallet software
2-4 |  |  |
| Testing | Testnets | Development teams
Network | Peer discovery | Peer connections | Owners of peers
2-4 |  |  |
| Topology | Component bridges | Owners of bridges
Consensus | Direct Participation |  | 1) Participating power
---
2) Block content
| Owners of
---
participation nodes
2-4 |  |  |
|  | Representative Participation
---
Validator identities |  | Owners of
---
validator nodes
| Initial distribution | Bootstrapping tokens | Token holders
2-4 |  |  |
Tokenomics | Token ownership | Tokens |  | 1) Addresses
---
2) Key managers
3) Legal stakeholders
2-4 |  |  |
| Secondary markets | Market liquidity |  | 1) Exchanges
---
2) Trading pairs
API |  |  | 1) Light wallet tokens
---
2) Light nodes
Full node operators
Governance | Conflict resolution | Decision-making power |  | All system entities
---
2-4 |  |  |
| Development funding | Capital | Active developers
Geography | Physical safety | All resources above | Regions
2-4 |  |  |
| Legal compliance | All resources above | Jurisdictions
Table 1:  Overview of blockchain decentralization layers.

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
a company (e.g., a foundation that performs the development of the system),
but also an individual (e.g., a so-called “whale”, an individual who possesses
a significant number of tokens). We note that, although in this work the MDT
is considered w.r.t. legal parties, it could be adapted to treat exogenous
centralization aspects as well, e.g., relating to natural disasters.

######  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.

#### Dimensions of Decentralization and Paper Structure

We identify $8$ layers in a distributed ledger where decentralization must be
examined:  (1) Hardware;  (2) Software;  (3) Network;  (4) Consensus;  (5)
Economics (“Tokenomics”);  (6) API;  (7) Governance;  (8) Geography.  Each is
divided into sub-categories and analyzed using the framework outlined above.
Specifically, Section 3 looks into the hardware and diversity in manufacturers
of mining equipment and cloud hosting. Section 4 focuses on the major types of
relevant software, that realize participation and asset management, and the
diversity of software products and development teams. Section 5 considers the
network over which the nodes communicate and evaluates decentralization on
both a microscopic level, w.r.t. a specific node’s network access, and a
macroscopic level, w.r.t. the overall network’s topology. Section 6 explores
the consensus mechanism and categorizes systems based on the mode of
participation they allow. Section 7 focuses on the economics of blockchain
systems and evaluates the hazards of a centralized initial token distribution,
subsequent control of the ledger’s native tokens by few investors, and
centralization in few secondary markets. Section 8 considers how developers
and users typically interact with the blockchains system - in essence the
blockchain’s API services. In this context we examine wallets and ledger
service nodes, that enhance efficiency and scalability of a blockchain by
offering its functionality “as a Service”. Sections 9 and 10 explore multi-
layer dimensions; Section 9 examines governance, i.e., how peers propose and
decide on system improvements and funding allocation, while Section 10 delves
into the geographic and jurisdictional distribution of blockchain systems.
Section 11 presents a case study, where all of the above decentralization
dimensions are evaluated for a specific system, Bitcoin and enable us to apply
the MDT. Finally, Section 12 offers a comparison with related work and
enhances the discussion with various possible research directions.

##  3 Hardware

The material base of each computing system is the hardware. The primary
interest in blockchains is machines that host the consensus software. Here, we
categorize the different systems based on their Sybil resilience mechanisms.
Many systems, starting with Bitcoin, rely on computational assumptions in the
form of Proof-of-Work (PoW), while the most common alternative is Proof-of-
Stake (PoS). Less-used options, e.g., Proof-of-Space [DFKP15] or Proof-of-
Space-Time [MO19], rely on other physical resources, like storage or memory.
Following, we focus on the two major options, PoW and PoS, though a similar
analysis could identify whether fundamental differences exist for alternative
resources.

###  3.1 Proof-of-Work

PoW systems’ security is typically guaranteed if the honest parties (i.e.,
those following the protocol as prescribed) represent an aggregate majority of
computational power [GKL17]. Therefore, the _resource_ of interest is
computational power (e.g., hashes per second) and the _relevant parties_ are
the manufacturers of hardware mining products.

In theory, PoW allows anyone to participate, regardless how small an amount of
power they control. In practice, some machines are more efficient in solving
the PoW challenge than others. For example, Bitcoin mining started from
regular CPUs, but quickly migrated to GPUs and, eventually, to dedicated
devices (ASICs), which produced more hashes at lower cost. Such shift to
dedicated devices introduces various centralization tendencies. First,
producing such devices requires a high-level of expertise and is an investment
in the blockchain system itself. In addition, microchip manufacturing observes
economies of scale, since the barrier to enter the system in terms of
designing and packaging the circuits is high. Consequently, the market tends
to concentrate around few companies. Second, dedicated devices are
particularly expensive,101010As of $2022$, popular Bitcoin ASICs cost (tens
of) thousands of USD (e.g., Bitmain). but significantly more profitable than
generic hardware. ASICs are also intensive in terms of energy consumption,
heat, and noise. Therefore, mining demonstrates economies of scale and
centralization tendencies. Industrial farms host hundreds of ASICs, with
hashing power sometimes offered as a “cloud” service, resulting in a
profitability gap between ASIC and generic hardware users [KKNZ19]. This trend
has also motivated significant research in “ASIC-resistance” and the
development of PoW algorithms that attempt to facilitate better hardware
diversity [BDK16, Eth22a, RD17].

Concentration around few hardware manufacturers creates various hazards. Same-
vendor products are more susceptible to collective faults, e.g., due to
defective parts or hardware bugs. Such faults could result in sudden drops in
the network’s power, lowering the threshold for gaining a computational
majority (_safety_ and _liveness_ hazard) and slowing down block production,
at least until the PoW parameters are recalculated (_liveness_ hazard).
Manufacturers could also introduce backdoors, threatening the ledger’s
security and _stability_ , albeit such hazards can possibly be mitigated via
cryptographic techniques [AKM+18].

#### Evaluation

Centralization around specialized hardware has been documented [EBHBL16],
although no academic research could be found on mining hardware usage in real-
world systems. Interestingly, it is unclear how to even measure the usage of
hardware equipment in PoW mining via public data, as well as how to develop
PoW algorithms that promote diversity, thus future research could aim at
answering these questions. Nonetheless, there exist some reports, though they
often present conflicting assessments. In Bitcoin, between $2017-2019$ a
single mining hardware provider accounted for either $65-75$% [BG19a] or
$46-58$% [ZS20] of the network’s hashrate, with $98$% of the market controlled
by $4$ firms.

###  3.2 Proof-of-Stake

All (existing) distributed ledger systems define an internal currency (token).
PoW systems use the token only as a unit of account and a means of value
exchange. However, in PoS systems tokens replace computational power in terms
of Sybil resilience. Here, each user participates proportionally to their
owned tokens (“stake”) and/or the stake “delegated” to them. Thus, a PoS
ledger is safe and live if the honest users control the staking rights to a
majority of tokens.

Decoupling Sybil resilience from physical requirements enables PoS nodes to
run on generic hardware, e.g., even home equipment. However, in practice
portability drives PoS users to employ cloud services, which offer uptime and
connectivity guarantees that a DIY configuration cannot. This trend is
exacerbated when PoS systems apply penalties to absent users and uptime
guarantees become of utmost importance to guarantee profitability. Therefore,
the PoS _resource_ of interest is stake and the _relevant parties_ are hosting
providers.

When nodes that control a large amount of stake are hosted by the same
provider, significant hazards arise for all properties. First, the provider
has access to the users’ private keys and is able to create conflicting blocks
(_safety_ hazard) or deanonymize users’ _privacy_. Second, the provider
controls the node’s network access, so it could prohibit communication
(_liveness_ hazard). Finally, it could also tamper with the system’s
_stability_ , e.g., increasing price volatility via targeted interference or
even stealing user assets.

#### Evaluation

PoS networks have been scarcely analyzed, compared to PoW. Therefore, a
comprehensive evaluation of the centralization of PoS validators across
multiple systems, in terms of hardware hosting, and how to incentivize hosting
diversity is a promising thread of future research. Here, we consider two
examples of highly-valued PoS systems.111111Solana and Avalanche are #9 and
#14 respectively w.r.t. market capitalization. [CoinMarketCap; August 2022]
Solana’s validators predominantly operate cloud-based nodes; of the $1873$
nodes, more than half are hosted in two services, with more than $50$% and
more than $66$% of participating stake hosted by $3$ and $5$ providers
respectively.121212validators.app. [August $2022$] Avalanche observes similar
concentration issues; $731$ out of $1254$ validators, who control $71.84$% of
all stake, are hosted by a single company.131313Data obtained from
avascan.info. [August $2022$]

##  4 Software

Diverse software development and usage is a core element of stability and
safety of distributed ledgers, as it increases resilience to catastrophic bugs
in a product’s code. A vulnerability in one implementation may jeopardize a
part of the system, but if the system is sufficiently decentralized, such
vulnerabilities would not escalate to systemic threats. Following, we discuss
the development of core blockchain software components, namely transaction
validation and PoW mining (via full nodes) and management of keys and digital
assets (via wallets).141414Appendix 4.3 also explores software testing.

###  4.1 Protocol Participation

The principal type of software in blockchain systems is the _full node_. Full
nodes implement the ledger protocol by:  i) keeping a local chain;  ii)
validating new transactions;  iii) extending the local chain with new blocks;
iv) participating in the consensus mechanism to incorporate new blocks.

For the purposes of analyzing decentralization, we identify two _resources_ of
interest:  1) full nodes (as an absolute number);  2) participating power
(e.g., computational or stake) that is hosted on full nodes.  The _relevant
parties_ are full node software developers.

Relying on a handful of full node implementations introduces _safety_ ,
_liveness_ , and _stability_ hazards. A bug that fails to validate correct
transactions would hurt the system’s liveness, whereas accepting incorrect
transactions could hurt the system’s safety and stability, e.g., via a network
split or token forgery. Such bugs have been observed in Bitcoin Core and could
have resulted in Denial-of-Service (DoS) attacks [FK20] and token forgery
[Cor18]. Implementation bugs could also threaten _privacy_ , if nodes reveal
information about message origin (e.g., IP addresses). Similar threats arise
when code gets reused across different projects. Often, a new blockchain is
only a “derivative”, that is a project that started by forking an existing
codebase, including copyrighted information [RYM19]. Such projects often
remain unpatched, so bugs in the initial implementation tend to spill over
[CCA+22]. Vulnerabilities may also arise when adapting an existing
implementation in a new setting, e.g., copying Bitcoin’s code and replacing
PoW with PoS [KKLM19]. Thus, widespread usage of multiple node
implementations, developed by different teams, is a prerequisite for a secure
and reliant ecosystem.

#### Evaluation

The literature is lacking formal analyses on the usage of full node ledger
software, so a rigorous evaluation of the dynamics in software development and
usage could highlight various centralization tendencies. Various community and
commercial projects do keep track of statistics though. In most systems, a
single client software is predominantly used by the participating nodes in the
network. In Bitcoin $99$% use Bitcoin Core (aka Satoshi), in Ethereum $78$%
use geth, in Litecoin $95$% use LitecoinCore, while systems like Zcash are
completely centralized with all nodes using one software (MagicBean); a
notable exception is Bitcoin Cash, where usage is split between BCH Unlimited
($33$%), Bitcoin Cash Node ($51$%), and Bitcoin ABC ($12$%).151515Sources:
blockchair, ethernodes [August 2022]

Some projects are actively managed by a wide network of developers, e.g., more
than $200$ contribute to Ethereum [Ven21], while others are particularly
centralized. As of $2018$, $7$% of all Bitcoin Core files were written by the
same person, while $30$% of all files had a single author. In Ethereum, these
figures rise to $20$% and $55$% respectively [AMM19]. Comments observe similar
centralization patterns, with $8$ ($0.3$%) and $18$ ($0.6$%) people
contributing half of all comments in Bitcoin and Ethereum respectively
[AMM19].

###  4.2 Asset Management

The primary use of distributed ledgers is bookkeeping of digital asset
transactions. Thus, securely managing and transferring said assets is a core
necessity. Digital assets are typically managed by private keys and
represented via addresses. The software responsible for managing keys and
addresses is the wallet [Kar20] and its principal functionalities are:  i)
store the user’s keys;  ii) prove ownership of the assets (managed by the
keys);  iii) issue transactions that transfer assets to other accounts;  iv)
retrieve the user’s (keys’) balance and history information.  Therefore, the
_resource_ of interest is the set of all assets managed via the ledger and the
_relevant parties_ are, like before, software developers.

Naturally, the wallet is a major point of security consideration, so multiple
properties rely on it. A bug which e.g., corrupts the user’s keys could not
only prohibit a user from transacting with their assets (_liveness_ hazard),
but forever lose access to them (_stability_ hazard). This was demonstrated in
$2017$, when the “Parity” Ethereum wallet saw a vulnerability that allowed a
user to take ownership of multiple assets and then lock them [Her17]; as a
result, $300$m worth of Ethereum tokens were forever lost. In another example,
some Bitcoin wallets possibly displayed incorrect balance, effectively
enabling a double spending attack [Lei20]. In addition, wallets are often
lightweight, relying on third-party full nodes for ledger interactions, but
also possibly enabling the nodes’ operators to link and/or deanonymize
transactions and accounts (_privacy_ hazard). Consequently, if a few
implementations are predominantly used, a vulnerability could result in assets
being unusable or stolen. Such vulnerability could also turn into a systemic
point of failure, with the whole ledger becoming unusable.161616A prime such
example was “The DAO”, which in $2016$ attracted nearly $14$% of all Ethereum
tokens and, when hacked, instigated a change in Ethereum’s consensus layer and
a hard fork which split the network [SC+17a].

#### Evaluation

As keys and addresses are wallet agnostic, it is impossible to identify if two
addresses are generated by the same wallet implementation, unless it purposely
reveals such information. Consequently, it is unclear how to evaluate the
wallet market’s diversity and how widespread wallet usage is from public data.
To our knowledge, no rigorous investigation has been conducted on this topic,
either analyzing historical data patterns or conducting usability studies.

###  4.3 Testing

Testing is a core part of software development. In blockchains, a major means
of testing new applications or ledger features is testnets. A testnet is a
separate chain, identical to the main chain in terms of offered
functionalities. To transact, a user acquires testnet tokens for free, so the
native testnet tokens have no real-world value. Testnets offer multiple
functionalities. Users can test features without risking losing funds.
Developers test new features and applications in a scale that closely
resembles the main chain. Adversaries evaluate the efficacy of attacks [cde17]
or exploit the zero-cost nature of testnet transactions [FAD20]. Therefore,
testnets indirectly safeguard all ledger properties. Fewer testnets increase
centralization around specific full node software products, while testnets
maintained by diverse teams may collect richer data. Hence, the _resource_ is
testnets and the _relevant parties_ are their operators.

#### Evaluation

Bitcoin offers a single primary testnet; the same holds for alternative
cryptocurrencies like Zcash and Monero.171717Sources: Bitcoin Wiki, Zcash
Docs, Monero Docs [August 2022] In Ethereum, although seemingly multiple
testnets exist, most are deprecated due to the system’s transition to PoS, and
only one of the recommended networks is expected to be maintained in the long
term.181818The deprecation of Ropsten, Rinkeby, Kiln and Kovan was announced
in $2022$ [Ethereum blog]. Goerli will be maintained in the long run, while
the future of Sepolia is undecided. [ethereum.org; August 2022] PoS testnets,
e.g., in Cardano and Solana, are also highly centralized.191919Cardano and
Solana testnets are run by Input Output and the Solana Foundation resp.
[Cardano Testnets, Solana Docs; August 2022]

##  5 Network

Blockchain nodes communicate over a peer-to-peer (P2P) network. Systems often
employ a message _diffusion_ mechanism [GKL15], based on a gossip protocol
that avoids full graph connectivity, cf. [DW13]. Users predominantly rely on
the Internet, on which the P2P network is overlaid, though some attempts try
to use a more autonomous infrastructure [Coo21]. In this section, we explore
different networking aspects which present single points of failure, on the
individual user level and the network as a whole. We note that a relevant
research question that arises organically from our analysis, and touches upon
both following subsections, is how to create a P2P network that is both
permissionless and Byzantine resilient. Some recent works investigating this
direction includes [CKMR22, MNT22].

###  5.1 Peer Discovery

Joining a ledger’s network and catching up with it is termed as the
“bootstrapping” process. All real-world ledgers rely on an initial (trusted)
setup, the first (“genesis”) block. Thus, obtaining the correct genesis block
is a prerequisite for secure participation. Following, the node connects to
various peers to receive all available, possibly conflicting, chains and,
using the ledger protocol’s chain resolution mechanism, decides which chain to
adopt. At that point, the node is synchronized and ready to participate in the
consensus mechanism.

In these systems, every node maintains a list of peer connections. Crucially,
message provenance is not typically provided so no party can know the network
origin of an incoming message. Each node needs to maintain at least one
connection to an honest party to receive all messages and avoid eclipse
attacks [HKZG15]. Thus, the number and condition of a node’s peers is a
significant element of security. Consequently, the _resource_ of interest here
is the typical node’s (in and out) connections, while the _relevant parties_
are the owners of the peers that maintain said connections. We note that this
resource refers to the average node, i.e., the nodes that run the standard
ledger implementations (e.g., Bitcoin Core in Bitcoin), even though
alternative, niche node implementations could set different network
parameters. If a node connects only to few peers, then an adversary could more
easily mount an eclipse attack. However, maintaining many peer connections
comes with a tradeoff, as it jeopardizes message anonymity [NH18] and
increases bandwidth requirements.

Here, we focus on the case of low connectivity, where eclipse attacks threaten
multiple ledger properties. First, an eclipse attack can result in _safety_
violations. By preventing communication between a node and the rest of the
network, an attacker reduces the honest computational power and isolates that
node. Consequently, it becomes easier to mount a $51$% attack and,
particularly, a double spending attack against the isolated node. For
instance, the adversary may supply malicious chains and stop honest blocks,
such that the node holds a skewed view of the system state. Second, an
adversary can violate _liveness_ by blocking the “eclipsed” node’s
transactions from reaching the rest of the network. Third, an adversary that
controls all of a node’s connections can link transactions to the specific
node. Therefore, the adversary can both correlate the user’s (otherwise
distinct) addresses and associate them with real-world information, such as an
IP address, thus breaking _privacy_.

Finally, eclipse attacks may break the bootstrapping process. The genesis
block, needed for bootstrapping, can be either hardcoded, thus relying on
software, or received from peers.202020Some proposals rely on computational
assumptions instead of a trusted setup [GKP20], but their real-world
performance and applicability is still untested. However, catching up with the
other peers using only genesis (“bootstrapping from genesis”) is not always
feasible. Especially in PoS systems, an attacker can effortlessly assemble an
arbitrarily-long, seemingly correct chain [GKR18, But14, LABK17]. To counter
such attacks, most ledgers employ checkpoints [KRDO17, DGKR18, DPS19], which
are often issued centrally and, as with the genesis block, are either
hardcoded or received from the peers. Other solutions do exist, e.g.,
analyzing block density and relying on key erasures [BGK+18] or using VDFs
[BBBF18], but enforcing and/or relaxing such assumptions still poses an
interesting research problem.

#### Evaluation

Bitcoin, as the first blockchain system, has seen multiple eclipse attacks and
defenses [TCM+20, HKZG15, TSK21]. Some works attempt to increase the number of
connections without reaching prohibitive levels of bandwidth usage [NMW+19].
Bitcoin Core defines $8$ outgoing connections, selected randomly from known
identities, and up to $125$ incoming [DPS+21]. When (re)joining the network, a
node attempts to connect to previously-known identities and, if unsuccessful,
employs a (hardcoded) list of DNS seeds. Other systems, like Ethereum and
Cardano, employ more complex, DHT-based mechanisms [MM02] that require further
analysis. Interestingly, Ethereum was found vulnerable to eclipse attacks that
do not require monopolizing a node’s connections, but relied on message
propagation [WG16]. Cardano is also an interesting implementation, as it
assumes two node types:  (a) core nodes that participate in consensus, and
(b) relays that intermediate between core and edge nodes (e.g., wallets);  in
the default configuration relays are operated by only a small committee
[DPS+21].

###  5.2 Topology

Our second networking aspect focuses on the overall network’s topology.
Evaluating a real-world network’s clustering properties is a well-known
problem. The traditional methodology relies on generating random graphs and
comparing the expected with the observed values [ER+60, New03, AB02]. In our
framework, the _resource_ of interest are “bridges” (single nodes or small
cluster of nodes) that may exist between different connected components of the
network graph and their owners or operators are the _relevant parties_.
Metrics and solutions from traditional distributed networking could possibly
be emigrated to ledger systems.

In blockchains, a _distributed network_ (in the tradition of Baran [Bar64]) is
key in maintaining _safety_ and _liveness_. Under the CAP theorem [Bre12], any
networked system can satisfy at most two of the following properties:  i) a
consistent data copy;  ii) data availability;  iii) network partition
tolerance.  Ledger systems are no exception. If some parties cannot
communicate with the rest of the network, either they halt (violating
_liveness_) or produce separate ledger versions (violating _safety_).212121In
longest-chain protocols, like Bitcoin, miners keep producing blocks in
isolation, ending up with different ledger versions. In BFT-style protocols,
like Algorand, the ledger cannot be updated if a large number of block
producers become unreachable and thus do not adopt new transactions. Also, a
node that acts as a central communication hub, or hosts a single channel over
which two clusters communicate, can possibly obtain information and even
deanonymize some participants (violating _privacy_).

#### Evaluation

Bitcoin is notoriously vigilant in hiding its network topology [DBP+19,
FSD22]. Various works analyze it by inferring a node’s neighborhood [BKP14],
timing analysis [NAH16], or conflicting transaction propagation [DBP+19]. In
$2014$, it was found that more than half of Bitcoin nodes resided in $40$
autonomous systems (ASs), with $30$% in just $10$ ASs [FSW14]. In $2017$,
Bitcoin’s and Ethereum’s P2P networks observed similar sizes ($3390$ nodes for
Bitcoin, $4302$ for Ethereum). Bitcoin offered lower latency and higher
bandwidth, with nodes being closer geographically and $56$% of them hosted on
dedicated hosting services (vs. $28$% for Ethereum) [GBE+18]. In addition,
$68$% of the mining power was hosted on $10$ transit networks, while $3$
transit networks saw more than $60$% of all connections [AZV17]. In $2019$,
Ethereum’s network presented a large degree of centralization around clusters,
forming a “small world network” [GSW+19] with $10$ cloud hosting providers
accounting for $57$% of all nodes and one hosting almost a quarter [Kon19].
This was reaffirmed in $2020$, as Ethereum messages could be sent to most
nodes within $6$ hops [WZY+21]. In $2020$, Monero’s topology also observed a
high level of centralization, as $13.2$% of nodes maintained $82.86$% of all
connections [CYD+20]. No analysis of PoS systems’ networks could be found;
given their non-reliance on specialized hardware and ease of relocation, a
PoS-PoW comparison would be of interest.

##  6 Consensus

A key element of any distributed ledger is its consensus protocol. Protocols
in our context are “resource-based”, i.e., they are executed by parties
possessing units of an underlying resource (e.g., hashing power or stake). As
discussed in Section 2, the two core consensus properties are _safety_ and
_liveness_. To guarantee these properties, at least a majority (or in some
cases a supermajority of $\frac{2}{3}$) of the ledger’s participating
resources should be honestly controlled [GK20]. When a handful of actors
control enough resources, a direct point of failure arises.

A useful distinction between consensus protocols for our purposes is in terms
of whether the protocol works with direct participation from resource holders
or necessitates some form of pooling or delegation of resources.

###  6.1 Consensus with Direct Participation

This first category includes Bitcoin [GKL15], Algorand [CGMV18], Ouroboros
Praos [GKL15], and NXT [com16], among others. Such protocols enable resource
holders to engage in the protocol directly with (essentially) whatever amount
of resources they have.

An important consideration in this setting is that block producers can, even
though they do not have to, form coalitions called _pools_. In PoW, a pool
“leader” validates transactions, and organizes them in a candidate block,
while each “member” executes the PoW puzzle for the leader-made block. If a
member is successful, the leader collects the block’s reward and distributes
it, proportionately to each member’s power. In PoS, the leader has full
control over the block’s creation, while the members only pay fees to delegate
their staking rights to the leader and collect rewards. Pooling behavior is
also driven by temporal discounting [RL11], i.e., the tendency to disfavor
rare or delayed rewards. In essence, a small miner may prefer small frequent
payments, at the cost of some fee, over rare large payments, when producing a
block.

Therefore, there are two _resources_ of interest:  i) owned participating
power, e.g., computational or stake;  ii) delegated participating power,
including the power to choose a block’s content.  Correspondingly, the
_relevant parties_ are:  i) miners and stakeholders, who own hashing power and
stake respectively;  ii) pool leaders and delegates, who control how the
resources are used.  In addition to that, one could also consider the actual
people that control the nodes, instead of the nodes themselves, further
enhancing the discussion around centralization with impossibility arguments,
given the “permissionless” nature of blockchains and the absence of a central
registry to impose “Sybil” penalties [KLK+19, KKNZ19].

Gradually, as power is concentrated in fewer pools, the pools’ leaders may
become single points of failure [Kia22]. _Liveness_ can be hurt, if corrupted
leaders censor transactions from the candidate blocks. Also, if pool members
do not perform any validity checks on the candidate blocks they receive,
corrupted leaders may launch a long-range attack to violate _safety_.
Depending on the pool’s internal protocol, the leader may steal member rewards
(_stability_ hazard) and possibly link the user’s resources with information
like IP addresses (_privacy_ hazard). Finally, a threat arises due to the lack
of self-healing, i.e., the inability to recover from a temporary adversarial
takeover. In PoW, even if a majority gets corrupted, honest users can increase
their own power and, eventually, overthrow the adversary and restore the
ledger’s security [AKWW19, BGK+20]. In PoS though, power shift takes place _on
the ledger_ , by transferring stake. If an adversary temporarily obtains a
majority, they can prohibit transactions that shift power away from them, thus
retaining control indefinitely (for example, a large centralized
cryptocurrency exchange can make it hard to issue outgoing payments and
withdrawals, while enabling payments between different users of the exchange).
Consequently, a diverse stake distribution (cf. Section 7) is paramount to
protect against takeovers.

We note that the above narrative distinguishes between PoW and PoS systems,
nevertheless it is also possible to have direct participation systems that
combine different resources in the same consensus protocol for various
purposes, e.g., see [PS17], or [FWK+22].

#### Evaluation

In (game) theory, Bitcoin’s resistance to centralization has been both
supported [KDF13, KS21] and refuted [ES14, LKX+19], depending on the economic
model assumed for the participants’ utilities. In practice, mining pools have
been observed as early as $2013$ [GKCC14]. Between $2016-2020$, pools created
$98.6$% of Bitcoin blocks [LP20], with $5$ pools consistently contributing
between $65-85$% of the eventual blocks and $25$ controlling more than $94$%
of all hashing power [WCQ20, LLZC21]. Centralization has also been observed
within mining pools. Between $2017-2018$, no entity controlled more than $21$%
[GBE+18] of hashing power, but three pools controlled a majority; within these
pools, a few participants ($\leq 20$) received over $50$% of rewards [RJZH19].
Miners often participate in multiple pools at the same time, a behavior also
observed in Ethereum [ZCC+21]. Although centralization around pools is high in
(PoW-based) Ethereum (in $2020$, $4$ pools controlled a majority of mining
power [Hui20]), power within the pools is spread across hundreds of addresses
[ZCC+21], albeit some possibly owned by the same parties.

###  6.2 Consensus with Representative Participation

The second category concerns systems that require parties to delegate their
resources to a representative or “validator” node. The most relevant resource
here, beyond stake and hashing power, is the validator identities which
correspond to the cryptographic keys that participate in consensus, while the
_relevant parties_ are parties that control the validator nodes.
Representative participation is encountered mostly in PoS systems.

An important consideration in the setting of representative participation is
the “barrier to entry” for becoming an active validator. This is relevant for
understanding the distinction from the previous section. For instance, in the
case of PoS protocols, if there is no (significant) barrier to entry for
running an active validator, then the protocol is practically a direct
participation protocol, e.g., Cardano222222https://cardano.org or Algorand
essentially operate in this way. Ethereum, post the $2022$ transition to PoS,
requires $32$ ETH in order to run a validator, nevertheless third-party smart
contracts such as rocketpool232323https://rocketpool.net can minimize the
barrier to participation.

On the other hand, systems like Cosmos242424https://cosmos.network and
EOS252525https://eos.io restrict participation, either directly or by
requiring participants to control a large amount of assets. Any party without
enough stake, i.e., below the system’s threshold or less than its competitors,
is required to delegate their staking rights to a validator. At every “epoch”,
a committee of (a fixed number of) parties is elected to run the protocol
based on the resources they have delegated to them. It is worth noting here
that as the committee members are public, an adversary may choose to target
the committee that is elected, thus taking over the protocol during an epoch
if the attack is successful. This is exacerbated when the committee is small
and, combined with the lack of self-healing properties, such attacks can be
devastating for the systems’ _safety_ and _liveness_. To make matters worse,
the choice of delegates is often based on reputation, so prominent parties may
exert a large influence due to brand awareness. Depending on the system’s
internals, delegates may also control reward allocation and decision-making
(cf. Section 9), thus affecting the system’s _stability_.

#### Evaluation

The following are examples of systems with representative participation. Each
employs their own consensus protocol and defines a different number of
participants per epoch using an on-chain process:262626Sources:
hub.cosmos.network, wiki.polkadot.network, developers.eos.io,
docs.harmony.one, near.org [August $2022$] i) Cosmos: 175;  ii) Polkadot: 297;
iii) EOS: 21;  iv) Harmony: 800;  v) NEAR: 100.  In all these systems, well-
known exchanges are among the top elected validators.272727For example,
Binance is a validator in all mentioned systems. [Cosmos, Polkadot, EOS,
Harmony, NEAR; August $2022$] Interestingly, the stake controlled by the
elected validators is mostly delegated, instead of self-owned. Also,
organizations often control multiple validators, so the number of real actors
is often even smaller than the nominal number of participants (nevertheless
some systems, e.g., Polkadot, go to greater lengths to ensure the
representative participation satisfies desirable properties such as
proportionality, cf. [CS21]). Consequently, identifying the participation
distribution among _real-world users_ and the refreshment rate of the elected
committee across multiple epochs is an interesting research question.
Similarly for investigating all the desiderata of representative participation
from a social choice perspective.

##  7 Cryptocurrency Economics

A core component of ledger systems is their native token. Tokens compensate
system maintenance and accommodate value transfers. They are treated as
currency or assets by their users, thus forming a market economy. To record
data on the ledger, e.g., financial payments or interactions with
applications, users obtain tokens to pay the corresponding fees. System
maintainers get compensated in tokens to offset their costs. In this section,
we explore decentralization in blockchain-based economies, in terms of
(initial) token distribution, token ownership, and secondary markets.

###  7.1 (Initial) Token Distribution

To bootstrap the system, a blockchain protocol defines two parameters:  i) the
distribution of tokens at the system’s launch, and  ii) how new tokens are
generated and distributed as the system evolves.  Thus, the generated tokens
form the _resource_ of interest, while the _relevant parties_ are the token
holders.

As with other aspects, Bitcoin led the way and other systems explored
alternatives. In Bitcoin, no coins existed prior to its beginning, i.e., there
was no “pre-mine”. Starting from genesis, each block creates a predetermined
amount of coins, based on a rate that converges to $21$ million tokens in
existence. New coins, along with transaction fees, are awarded to the miner
that produces each block. Therefore, to acquire new tokens a user gathers
enough computing power to produce a block. In other blockchain systems, some
tokens were sold via traditional markets before the blockchain was deployed.
This approach, termed “Initial Coin Offering” (ICO), enabled funding the
project with the future proceeds of the token investment. In return, investors
acquired a pre-launch amount of tokens, which was codified in the chain’s
first block. In terms of token generation, most systems employ a variation of
Bitcoin’s mechanism, e.g., Ethereum blocks yield $2$ new tokens, while others,
like Cardano, employ elaborate mechanisms to incentivize pooling around a
target number of pools [BKKS20].

The initial token distribution is particularly important in PoS systems, where
Sybil resilience relies on it (cf. Section 6). If centralized around a few
parties, e.g., via pre-mining (or “pre-minting”), early investors have to
maintain the system in its early stages, while also receiving the early
blocks’ rewards. Fewer consensus participants during this time lowers the
threshold for adversarial takeover, threatening the system’s _safety_ and
_liveness_ , as explained above. In both PoW and PoS systems, new users are
onboarded (and can participate in consensus, in the case of PoS) if early
investors sell tokens on secondary markets. Consequently, early investors
control the system’s expansion and valuation, impacting its _stability_.

#### Evaluation

PoS systems like Cardano, NEO, and Algorand tried to reduce early-stage risks
via a two-phase launch. At first, the ledger was controlled by either the core
development company or foundation or a committee numbering a small number of
entities. After token ownership was sufficiently distributed, participation
opened widely to all stakeholders. Beyond the obvious issues in maintaining a
permissioned database, the first phase typically takes years to conclude.
Early users often tend to either not participate or transfer their tokens to
the few exchanges that support these new tokens [VRK21]. Therefore, an
interesting question is the relationship of the delay between launch and full
decentralization and the diversity of early investors.

###  7.2 Token Ownership

Diverse token ownership plays a central role in the usability and security of
a blockchain. Hence, the system’s circulating tokens are the _resource_ of
interest, while the _relevant parties_ are:  i) addresses;  ii) key managers;
iii) (legal) asset owners.  This distinction arises due to the existence of
custodians, who control assets on behalf of other stakeholders, and users
controlling multiple addresses.

If most tokens are owned by a few parties, many hazards arise. First, PoS
systems’ security, i.e., _safety_ and _liveness_ , relies directly on diverse
token ownership, which makes corrupting enough parties to control a majority
of tokens more difficult. Second, the token’s price may be manipulated, posing
a risk on the system’s _stability_ and, indirectly, security, in both PoS and
PoW systems. Specifically, participation cost, e.g., for mining equipment or
electricity, is denominated in fiat currency. However, miner income from block
rewards comes in tokens. Thus, miners need to sell part of the rewards (for
fiat) to pay for their operational costs. If the market is volatile,
profitability is more precarious and miners are possibly less inclined to
participate, which can impact the _safety_ or _liveness_ of the system by
reducing the threshold for conducting a 51% attack.

There exist various drives towards token ownership centralization. Initial
tokens are often allocated centrally (see above). System incentives, e.g.,
fixed token supply, generally favor hoarding tokens instead of spending them.
Finally, rich participants accumulate capital faster than small ones, an
inevitability in pseudonymous systems where downwards wealth redistribution is
impossible [KKNZ19].

#### Evaluation

Bitcoin’s wealth ownership and transaction graph has been analyzed since at
least $2012$ [RS13a]. Over time, it demonstrated a three-phase history of
distinct (de)centralization patterns, where $100$ addresses possess a high
centralization degree of assets and wealth flow in the network [CZLM21,
SBG21]. Similar analyses exist for Ethereum [CLZ+20], Zcash [KYMM18], and
other cryptocurrencies [MB19].

As of $2022$, cryptocurrency wealth concentration is particularly extreme
(Table 2). To establish some context, the income Gini coefficient of the $10$
lowest-performing countries ranges between $0.63-0.512$ [Ban22]. Bitcoin has a
Gini coefficient of $0.514$, considering only the $10,000$ richest addresses,
and a staggering $0.955$ w.r.t. all addresses. In the arguably deeply unequal
global real-world economy, the richest $0.01$% of individuals ($520,000$
people) hold $11$% of all wealth [Goo21]. Bitcoin manages to beat that figure,
with $100$ addresses holding $14.01$% of all tokens.

System | Addresses | Top-100 | Gini (10K) | Gini
---|---|---|---|---
Bitcoin | 42,943,534 | 14.01 % | 0.5145 | 0.956
Ethereum | 193,673,067 | 39.75 % | 0.6757 | 0.978
Dogecoin | 4,839,762 | 68.49 % | 0.8297 | 0.986
Zcash | 345,766 | 32.92 % | 0.7796 | 0.974
Bitcoin Cash | 17,123,166 | 28.4 % | 0.672 | 0.97
Litecoin | 5,442,751 | 36.8 % | 0.6757 | 0.978
Ethereum Classic | 511,491 | 41.37 % | 0.8289 | 0.988
Dash | 1,545,061 | 14.68 % | 0.6896 | 0.971
Table 2:  Cryptocurrency wealth distribution: i) addresses that control
assets; ii) percentage of wealth controlled by the top 100 wealthiest
addresses; iii, iv) Gini coefficient of 10K wealthiest and all addresses resp.
(Sources: Blockchain ETL, Google BigQuery, CoinCarp. [April 2022])

A complexity in measuring wealth decentralization in cryptocurrencies arises
due to their pseudonymous (or even anonymous) nature. Specifically, the number
of addresses often does not correspond to individual people or entities, cf.
[RS13b, MPJ+16]. A user may control multiple addresses, e.g., each with a
small balance. When interpreting the Gini coefficient, this artificially
enlarges the population and possibly biases the results towards
decentralization. In addition, an address’s assets may be owned by many users
(e.g., exchange addresses), which biases Gini towards centralization. Thus,
developing tools to compute wealth inequality in blockchain systems, without
sacrificing core features like anonymity and privacy, is a crucial problem for
exploration.

###  7.3 Secondary Markets

Distributing the tokens to a wide population is predominantly made on
secondary markets as  (a) the rate of token production is typically slow
(depending on block production), and  (b) the new tokens are often distributed
to existing users (particularly in PoS systems).  Markets take the form of
centralized operations (“exchanges”) and, at a lesser extent, face-to-face
transactions. Therefore, the tokens that are bought and sold through these
markets constitute the _resource_ of interest, when it comes to measuring the
decentralization of secondary markets, while the _relevant parties_ are  i)
the assets for which they are bought and sold (“trading pairs”), and  ii) the
exchanges that host these trades.

Many hazards arise when tokens are available on a limited number of markets.
First, exchanges typically offer little _privacy_ guarantees, exchange
operators have full access on their users’ data as required by KYC
regulations. Second, exchanges are largely _unregulated_ by financial
authorities and may engage in market manipulation. Third, few marketplaces
often result in lower liquidity. Thus, the threshold for manipulating the
token’s price by some percentage, via selling or buying tokens, also lowers.
All such events threaten the system’s _stability_ , while also, when mining
profitability drops due to the token’s devaluation, _safety_ and _liveness_
are indirectly hurt (see above).

#### Evaluation

Table 3 summarizes secondary blockchain market data across $121$ exchanges.
Many systems (Bitcoin, Ethereum, Litecoin, XRP) are traded on all but a few
small exchanges. Tether is by far the most available, in terms of market
pairs, and used, in terms of volume. Interestingly, for all systems, except
perhaps Bitcoin, the majority of volume is not of the highest
transparency.282828For “transparency” see the methodology and data of Nomics:
https://nomics.com/blog/essays/transparency-ratings. This is consistent with
reports that show market manipulation is endemic in cryptocurrency markets,
with multiple cases of wash trading, fake trading volumes, and other
fraudulent behavior [Com21, Ver20, Man19]. Market transactions are primarily
conducted in a handful of exchanges. By far the most used is Binance ($20$% of
the total daily volume),292929CoinMarketCap [August 2022] although Coinbase is
the most recognized in North America [Nom21].

System | Exchanges | Pairs | Transparent Volume
---|---|---|---
Tether | 80 | 21691 |  $$52.86$B ($44$%)
Bitcoin | 100 | 9622 |  $$41.31$B ($56$%)
Ethereum | 103 | 5680 |  $$14.24$B ($42$%)
Dogecoin | 84 | 1856 |  $$175.5$M ($29$%)
XRP | 90 | 555 |  $$551.8$M ($26$%)
Bitcoin Cash | 90 | 537 |  $$80$M ($9$%)
Litecoin | 98 | 485 |  $$210$M ($25$%)
Cardano | 78 | 437 |  $$1.03$B ($41$%)
Solana | 75 | 383 |  $$1.25$B ($39$%)
Polkadot | 77 | 378 |  $$195.26$M ($36$%)
Ethereum Classic | 67 | 350 |  $$34.7$M ($14$%)
Zcash | 59 | 320 |  $$38.6$M ($20$%)
Avalanche | 64 | 318 |  $$574.29$M ($49$%)
Monero | 41 | 101 |  $$39.9$M ($22$%)
Table 3:  Secondary market data across $121$ exchanges (June $2022$): i)
exchanges and trading pairs (_CoinMarketCap_); ii) transaction volume rated as
“transparent” by _nomics_.

##  8 API: Blockchain as a Service

To join a blockchain system, full nodes typically need to download and parse
the entire ledger, which often amounts to hundreds of GBs.303030Bitcoin: $485$
GBs; Ethereum: $819$ GBs. [bitinfocharts, Etherscan; August $2022$] The
ledger’s state, which is usually stored in memory, is also
large313131Bitcoin’s UTxO set is $4.71$ GBs. [Satoshi info; August $2022$] and
often poorly maintained, cf. [KKK21]. Consequently, maintaining a full node
requires significant computational and storage capacity and, eventually, it
seems impossible that a node will be hosted on home equipment.

This concern is well-known and ongoing research tries to resolve it via ledger
compression [KMZ17, BMRS20, KB20]. In practice though, users often employ
third-party services that offer an interface to the ledger. Given the
widespread use and variety of applications that rely on such services,
“Blockchain as a Service” is a separate layer, with the _resources_ being  (i)
tokens stored in light wallets and  (ii) light nodes,  and the _relevant
parties_ being the full node operators that service them.

Many properties are at risk by corrupted API services. By not verifying the
entire ledger, a “light” client might be duped in accepting an invalid
transaction. A possible solution is succinct verification proofs [DKKZ20,
KPZ20, KMZ17, BKLZ20], although light clients often have to parse the block
headers, so most deployed solutions have linear asymptotic complexity on the
ledger’s size. To avoid the overhead, a large portion of users rely on
intermediary services, often without receiving any correctness guarantees.
Thus, a double-spending attack (_safety_ violation), where a user accepts a
canonically invalid transaction, possibly requires corrupting only a few
parties that control such services. Also, light wallets typically rely on
external nodes for transaction processing and balance computations (cf.
Section 4.2). Thus, _liveness_ , _privacy_ , and _stability_ hazards arise if
these nodes become corrupted and can block, de-anonymize or, depending on the
implementation, divert a user’s funds and transactions. Finally, although
applications often rely on media, storing even small images on-chain is
prohibitively expensive.323232Bitcoin and Ethereum require approx. $$0.003$
and $$23$ per byte resp. [August $2022$] Blockchain applications often employ
a combination of storage types, with the logic being on-chain and files in
servers. For example, NFTs are digital images whose ownership rights are
tracked on a blockchain. Here, the ledger typically stores only a link to the
image, e.g., a hash or URL, while the file is accessible via a third-party’s
server. Naturally, if these off-chain elements become inaccessible, the
_stability_ of the application and, possibly, the underlying ledger are at
risk.

#### Evaluation

In Bitcoin, most wallets are either SPV or explorer-based [Kar20]. In the
first case, the wallet obtains the chain’s headers and, to verify that a
transaction is published, requests a proof from full nodes. Although SPV does
mitigate safety attacks, it also hurts the user’s privacy, as their
transaction information is leaked to the full node operators. Explorer-based
wallets instead rely entirely on a single explorer service and its full nodes,
which are trusted completely. In $2018$, $5-10$% of all Ethereum nodes
reportedly relied on a centralized blockchain API service, Infura [O’L18].
This reliance continued throughout the years. In $2020$, a service outage
demonstrated in practice the hazards of such centralization [Wil20]. In
$2022$, a misconfiguration on Infura’s part resulted in wallets (and, thus,
user funds) being inaccessible [Coi22]. In terms of applications, OpenSea is
the leading hosting service for NFTs. As of $2021$, it reportedly handled
$98$% of all NFT volume [You21], charging a $2.5$% commission on all sales. As
expected, an OpenSea outage in $2022$ also resulted in the NFT market being
practically unusable [FB22].

##  9 Governance

Governance in blockchain systems is a broad topic [KL22, PJBO21, BMBK18].
Here, we focus on two aspects that affect all previous layers:  i)
improvements and conflict resolution;  ii) fund allocation for research and
development (R&D).

###  9.1 Improvements and Conflict Resolution

Decision-making mainly concerns conflicts and improvement proposals. Proposals
may affect mining, e.g., changing the PoW function [Mon19] or switching to PoS
[Eth22b], the consensus protocol, e.g., changing block structure [Rei22], or
token ownership, e.g., blacklisting accounts [But16], just to name a few
aspects that are frequently contested.

In theory, anyone can propose changes in blockchain systems and respond in
some way, depending on their role. For example, PoW full nodes pick a side in
a debate by choosing which ledger version to extend. Token owners influence
decision-making directly, by operating PoS full nodes and/or participating in
voting mechanisms, or indirectly, by choosing which ledger to transact on. In
essence, full nodes assume executive, legislative, and judicial powers by
operating the ledger and choosing its rules, while other actors voice their
opinions by affecting the token’s market price [Als19]. The governance
_resource_ is decision-making power, which may take various forms, and the
_relevant parties_ are all active entities in the system.

If the other layers are centralized, governance follows suit. For instance, if
mining is concentrated around a few operators, they might force a choice by
mining on one ledger, or if a handful of investors own most tokens, they could
manipulate the market to force a choice favorable to them. If disagreement
turns into a stalemate, systems may split into distinct ledgers, that share
the same history up to a point but diverge thereupon [Pet21, But16]. These
outcomes harm the system’s _stability_ , and indirectly threaten its _safety_
and _liveness_.

An effective governance process should prevent such harmful events. However,
it is not always possible to make consistent decisions in a decentralized
manner, as demonstrated by theoretical results in social choice such as
Arrow’s impossibility theorem [Arr50].333333The theorem’s formal proof states
that no rank-order electoral system can satisfy a set of three criteria: i) if
every voter prefers X over Y, the group prefers X over Y; ii) if every voter’s
preference between X and Y remains unchanged, the group’s preference also
remains unchanged (even if voter preferences over other pairs change); iii)
there is no “dictator”, i.e., no single party can always determine the group’s
preference. This idea dates back to the late $18$th century and Condorcet’s
paradox in collective decision-making: consider three candidates $A,B,C$ and
three voters $V_{1},V_{2},V_{3}$, with (ordered) candidate preferences
$[A,B,C],[B,C,A],[C,A,B]$ resp; although each candidate’s order of preference
is consistent, the collective preference is cyclical. Additionally, when
agents act in a selfish manner, as is presumed in distributed ledgers,
efficiency can degrade (cf. “Price of Anarchy” [KP99]). Therefore,
decentralized decision-making processes face a challenge, as they need to
address various social choice theory (e.g., Arrow’s theorem) and game-
theoretic (e.g., rational ignorance [D+57]) considerations.

#### Evaluation

Most systems employ an _Improvement Proposal_ mechanism, where proposals are
posed as issues in Github, a (centralized) system that is extensively used for
software development. If a change gathers enough support, it is incorporated
in the codebase. To voice approval for proposals, miners often include encoded
messages in blocks. From early on, proposals in Bitcoin and Ethereum have been
made by a handful of developers [GKCC14, AMM19]. In the discussion phase, many
people participate but again only a few actors contribute most comments, while
in cases like Bitcoin the groups of developers and commenters largely overlap.

###  9.2 Development Funding

Funding for research and development can cover the maintenance of legacy
codebase, research in features like privacy and scalability, market
incentives, e.g., stabilizing the token’s price at times of high volatility,
and more. Thus, the _resource_ of interest here is capital and the _relevant
parties_ are the active developers in a ledger’s ecosystem.

Ledgers typically make no funding provisions, besides allocating rewards from
coin issuance and transaction fees. R&D is conducted via corporate vehicles
which rely on traditional funding models, such as venture capital. However,
since designing and implementing hardware and software for distributed ledgers
is particularly expensive, this model can lead to centralization, as discussed
in Sections 3 and 4. In addition, lack of funding or concentration around a
few teams may delay crucial updates or new features, thus hindering
_stability_.

A common alternative to traditional financing is ledger “self-funding”. Here,
the system defines a _treasury_ , i.e., a pot which collects part of each
transaction’s fee and, over time, accumulates significant amounts of (token)
funds [ABL21, ZOB19]. These funds are allocated via a voting mechanism, open
for participation to stakeholders and other relevant parties. Given the
pseudonymous nature of these systems, voting might be weighed by each
participant’s wealth, with each token granted one vote (instead of one person
one vote, as in traditional democratic processes). Presumably, if stakeholders
aim at increasing their assets’ value, they support proposals that improve the
system. However, if ownership is concentrated around a few investors (cf.
Section 7), the decisions might aim at benefiting these few parties in the
short term, at the expense of the system’s long-term benefit.

#### Evaluation

Most existing blockchain systems follow the first approach, i.e., not making
funding provisions. In many cases, funding is channeled through a few
foundations and companies.343434The first usually take the name of the token,
e.g., the {Bitcoin, Ethereum, Cardano} Foundations. Examples of the second are
the ASIC companies discussed in Section 3.1 or software companies like
Blockstream (Bitcoin), Consensys (Ethereum), Input Output (Cardano), etc.
Treasuries are present in some ledgers, like Decred, Cardano, and Dash.
Despite their potential though, widespread funding has yet to be demonstrated
for most systems.353535Decred’s treasury holds $$23.8$M, and has allocated
$\$250$K over the past year. Cardano’s treasury holds approx. $$500$M and has
distributed $$17.2$M across $939$ projects. Dash, one of the first systems to
set a treasury, allocated $$500,000$ over $2018$, but it appears non-
functional as of $2022$. [dcrdata.decred.org, cardano.ideascale.com,
dashvotetracker; August $2022$]

##  10 Geography

Geographical decentralization touches upon all dimensions covered in the
previous sections. Accordingly, it involves all resources described so far,
e.g., hashing power or tokens. Nonetheless, it constitutes a dimension on its
own, as parts of a system may be well distributed w.r.t. one dimension but
geographically concentrated or vice versa.363636For example, independent
actors may participate in mining within a single country.

The tendency to centralize in certain areas arises due to economical,
technological, or sociopolitical factors. For example, miners often set up
their operations in countries with low electricity costs, hardware companies
operate in countries with small production costs, nodes are hosted in areas
with high internet speed, and tokens are accumulated by residents of countries
with low taxes and where many exchanges operate. Geographical centralization
poses two main threats to the properties of a ledger:  i) physical hazards and
ii) legal impediments.

##### Physical safety

Physical hazards could threaten a system’s infrastructure. For instance, if
part of a system is located in a small area, failures or interruptions in the
area’s connectivity could destroy or split the ledger system in two. This
concern is particularly relevant in PoW, where equipment is hard to relocate.
All _resources_ examined above can be impacted (e.g., via drops in hashing
power or token loss when mining equipment or cold storage is damaged), while
the _relevant parties_ are the regions of resource concentration. Single
points of failure may arise when geographically-concentrated nodes act as
central hubs, harming either _safety_ or _liveness_ (cf. Section 5) and,
indirectly, _stability_ (e.g., due to increased market volatility).

##### Legal compliance

Failures possibly occur w.r.t. the legal frameworks under which the system
falls. If some layer is concentrated in a specific jurisdiction, authorities
can possibly restrict or subvert it. Again, this touches upon all _resources_
examined so far, as all are influenced by the law, with the _relevant parties_
being legal jurisdictions. Depending on the occasion, different properties of
the system are impacted. For example, if a country bans Bitcoin mining, the
power drop could decrease the threshold for controlling a majority (_safety_
hazard), while blocks are produced at a slower pace until the PoW difficulty
is recalculated (_liveness_ hazard). _Stability_ could also be hurt, if some
part of the system, e.g., mining, software access, or asset ownership is
restricted. Additionally, exchanges often adopt KYC processes to comply with
AML regulations [Mil19], linking the users’ identities to their activity and
thus compromising their _privacy_. Arguably, a system is more likely to uphold
its properties by falling under many jurisdictions, such that violating them
requires the coordinated efforts of multiple authorities.

#### Evaluation

In $2014$, $37$% of Bitcoin nodes resided in the US and China [DPH14]. In
$2018$, its testnet also showed a concentration in the USA, Central Europe,
and East Asia [DBP+19]. In $2019$, Bitcoin mining hardware was mostly located
in China (particularly Sichuan) and the US [BG19a, KP19]. Notably, the mining
pools then-located in China accounted for $68$% of all hashrate [SKG19]. As of
$2022$, a large fraction of nodes communicates over Tor,373737$46.5$% of
Bitcoin’s nodes operate over Tor. [bitnodes; August $2022$], thus analyzing
the network’s topology is often hard. Nonetheless, more than $\frac{1}{3}$ of
Bitcoin mining is presumably located in the USA, with Kazakhstan and Russia
following with $18$% and $11$% respectively [fAF22]. In terms of full nodes,
USA and Germany see roughly equivalent shares, with other countries hosting
far fewer; still, a majority communicates over Tor. Until $2021$ China hosted
as high as $70.9$% [fAF22] of Bitcoin mining power; following its ban that
year, Bitcoin’s hashrate dropped from $197$ to $68$ Ehash/s in one
month.383838bitinfocharts.com Ethereum (pre PoS) observed similar
concentration patterns; by far the most nodes are located in the USA ($37$%)
and, secondarily, Germany ($16.66$%) [Kon19]. Finally, Monero nodes are mostly
located in the US and, to a lesser extent, elsewhere [CYD+20]. Table 4 shows
various systems’ geographical distribution.

In terms of legal jurisdiction, different aspects are centralized in different
countries. In Bitcoin, the $4$ companies that predominantly produce mining
hardware393939Bitmain, MicroBT, Canaan, Ebang. are all based in China.
Regarding secondary markets, many exchanges operate in multiple countries
(Table 3); $20$ of $121$ operate in USA, thus falling under US jurisdiction,
$17$ in China, and $10$ in Japan, with the rest spread across the world.
However, only $8$ are based in the US, with most registered in the Seychelles
($13$) and other “offshore” locations. Many ICOs also exclude US investors,
following their US classification as securities [SC+17b]. Finally, an
interesting case concerns the Bitcoin Core software, which is not available
via bitcoin.org in the UK, following a related court ruling [AN21].

Bitcoin (_Total: $7670$_) | US | $2862$ |  Ethereum (_Total: $5884$_) | US | $2781$
---|---|---|---|---|---
DE | $1164$ | DE | $678$
FR | $505$ | SG | $283$
CA | $377$ | UK | $241$
NL | $309$ | FI | $236$
Bitcoin Cash (_Total: $987$_) | US | $419$ |  Dogecoin (_Total: $1096$_) | US | $475$
DE | $148$ | DE | $187$
FR | $69$ | FR | $71$
NL | $35$ | CA | $47$
CA | $35$ | CN | $33$
Zcash (_Total: $9056$_) | US | $2913$ |  Litecoin (_Total: $1182$_) | US | $330$
DE | $2539$ | DE | $221$
FR | $1164$ | FR | $149$
CA | $678$ | CA | $58$
PL | $298$ | RU | $54$
Table 4:  Geographical distribution of full nodes in various ledger systems.
(blockchair, ethernodes; June $2022$)

##  11 Case Study: Bitcoin

In this section we apply our methodology to Bitcoin. We review Bitcoin’s
status w.r.t. each identified layer. We show that it passes the Minimum
Decentralization Test (MDT) (cf. Definition 1), though possibly due to the
lack of substantial evidence within some layers.404040Note that we employ a
“decentralized until proven centralized” approach. The properties of interest
here are _safety_ and _liveness_ , i.e., the two core security properties that
a ledger should guarantee.

###  11.1 Decentralization Layers

#### Hardware

No concrete data could be found on the distribution of hashing power across
PoW mining products. Hundreds of efficient products (ASIC) are available, on
top of generic hardware (e.g., GPUs). As of $2022$, the market appears
centralized around $4$ ASIC manufacturers [ZS20]. Interestingly, only some
ASICs are profitable, so, unless the token’s price increases without an
increase in PoW difficulty, mining should be expected to concentrate around
these products.414141A profitability calculator is available at nicehash.com.

#### Software

As outlined in Section 4, $99.15$% of all Bitcoin full nodes run Bitcoin Core.
Therefore, Bitcoin is completely centralized around (different releases of)
this product. Regarding the distribution of tokens across wallets, no data
could be found.

#### Network

Section 5 offers a brief evaluation of Bitcoin’s network. Regarding peer
discovery, Bitcoin Core sets $8$ outgoing and $125$ incoming connections,
chosen randomly from known and/or hardcoded peers. Most Bitcoin nodes
communicate over Tor, making topology analyses particularly hard.424242$53.3$%
of Bitcoin’s nodes operate over Tor. [bitnodes; October $2022$] Nonetheless,
it is estimated that the network is evenly spread across multiple Autonomous
Systems, thus presenting high levels of decentralization [AZV17].

#### Consensus

On the consensus layer, Bitcoin presents mixed results regarding
decentralization (cf. Section 6). Hashing power is distributed across
thousands of machines. Although no concrete data could be found, folklore
evidence suggests that these machines are owned by a highly diverse set of
users. However, Bitcoin also observes high levels of centralization around
pools, i.e., w.r.t. block formation and the input to the PoW module;
specifically, at the time of writing, $4$ pools control more than $60$% of the
whole network’s mining power.

#### Tokenomics

At its onset, no Bitcoin tokens existed. They were generated and allocated as
the system progressed. Early participants were disproportionately favored,
with half of all tokens created within the first two years, when consensus
participation was sparse and mining was conducted by only a few parties. As
more transactions were issued, the tokens were distributed more widely, albeit
wealth is still highly centralized, compared to real-world economies (cf.
Section 7, Table 2). Specifically, approx. $43$M addresses own some amount of
tokens, with the top $100$ addresses controlling $14.01$% of all wealth.
Nonetheless, tokens are traded on more than $100$ marketplaces at volumes of
approx. $$53$B (cf. Table 3.

#### API

As discussed in Section 8, most of the available Bitcoin wallet software is
either SPV or explorer-based [Kar20]. In the first case, the wallet downloads
only the block headers, so does not validate each block’s transactions, while
in the second case the wallet relies entirely on a server. However, no data
could be found on the ownership of Bitcoin tokens w.r.t. wallet types,
therefore Bitcoin’s decentralization w.r.t. the API layer is inconclusive.

#### Governance

Deciding on improvement proposals and conflict resolution in Bitcoin is
somewhat centralized, but not entirely. Specifically, decisions, which are
made by accepting suggestions via Github, are typically taken by a small set
of developers, who are often the ones to comment during the relevant
discussions [GKCC14, AMM19] (also see Section 9). In terms of development
funding, Bitcoin makes no provisions. Therefore, the available data are
inconclusive on how many sources of funding exist, e.g., companies and
foundations, and how much influence each has.

#### Geography

As mentioned in Section 10, Tor communication between nodes makes analyzing
the network’s topology particularly hard. Nonetheless, Bitcoin miners,
although fairly well distributed with a presence in $95$ different countries,
tend to cluster in certain areas. More than $\frac{1}{3}$ of mining is located
in the USA, with Kazakhstan and Russia following with $18$% and $11$%
respectively [fAF22]. In terms of full nodes (which may not participate in
mining), USA and Germany see roughly equivalent shares, with other countries
hosting far fewer nodes (cf. Table 4), although still a majority communicates
anonymously.

###  11.2 Minimum Decentralization Test (MDT)

As of October $2022$, Bitcoin appears to pass the MDT, as no legal entity,
with the power to violate a property of interest in some layer, was
identified. Some layers are highly centralized (e.g., consensus, where only
few pools are responsible for the majority of the produced blocks), but
violating the relevant properties still appears to require the coordination of
at least two legal actors. Particularly regarding software, although almost
all nodes run the same product, Bitcoin Core, this is:  i) developed by over
$100$ monthly active core developers [Ven21];  ii) is provided under an open
source license (MIT).  Consequently, we deem that the MDT does not fail
because of it, as this product’s development and maintenance is not controlled
by a single legal entity, but rather a team of open source developers.
Finally, for some layers (hardware, network, API, geography) there is
inconclusive or no available data, so further work is needed to offer a
definitive and conclusive answer regarding them. Despite that, we find no
reason at present to believe that a single legal entity is capable of
subverting the relevant ledger properties in any of these layers.

##  12 Discussion

Our work explores how to define and measure decentralization in distributed
ledgers. Table 1 summarizes our methodology, i.e., the layers that comprise a
ledger and the relevant resources and parties that guarantee its core
properties. Evidently, removing single points of failure via a diverse
distribution of resources among relevant parties is paramount in guaranteeing
security, privacy, and stability and can also have legal implications (cf.
Definition 1).

Related Work. To the best of our knowledge, this is the first work that offers
a systematic methodology of defining and evaluating decentralization in
distributed ledgers. Our work is complementary to research of blockchain
decentralization from other perspectives, e.g., economic or social [BG19b,
BBH21]. In computer science, only a couple of works have attempted to tackle
the question of blockchain decentralization. Sai et al. [SBFG21] offer a
blockchain centralization taxonomy, based on an algorithmic literature review
and expert interviews. Like our approach, they treat ledgers as multi-layer
systems; some categories overlap, e.g., wealth concentration and geography,
while others differ. Nonetheless, our work goes beyond a standard literature
review and identifies various nuances in how ledgers operate, are organized
and how this interacts with decentralization. Also, instead of employing
various non-comparable metrics, our work proposes a unified evaluation
methodology and a directly applicable minimum decentralization test
(Definition 1). Zhang et al. [ZML22] propose a taxonomy around five facets:
consensus, network, governance, wealth, transactions. They describe an “index”
based on transactions ceteris paribus, such that “as the number of
transactions increases, the index increases, indicating greater
decentralization.” Nonetheless, it is unclear how this treats transactions of
different utility (e.g., spam) and whether it is meaningful to compare ledgers
with different transaction throughput. In comparison, we offer a holistic
treatment that not only encompasses these facets, but also offers a principled
way to measure decentralization, independent of narrow focused performance
metrics.

Measuring Decentralization. Our work offers a framework for analyzing
blockchain decentralization, but not specific metrics to quantitavely measure
it. For example, a metric could assign a single number to reflect how close a
system is to a single point of failure, given a distribution of resources over
a set of relevant parties. Here, we briefly review some metrics, at a high
level, and leave for future work the exploration of alternatives and the
computations over real-world data. A first option is Shannon entropy [Sha01].
Briefly, a random variable’s entropy measures the uncertainty of its possible
outcomes. In our setting, the more bits of entropy in the resource
distribution, the more diverse it is, thus the more decentralized the measured
component is. Min-entropy, i.e., the smallest of the Rényi family of entropies
[R+61] can be also used instead since it also offers a lower bound. An
alternative is the Gini coefficient [Ros18]. Gini expresses the percentage of
space between the $45^{o}$ line and the curve that plots the cumulative wealth
$y$ owned by the bottom $x$ of the population. Intuitively, a Gini value of
$0$ implies perfect equality, where each person owns the same amount of
resources, while $1$ reveals extreme inequality.434343Although Gini is used by
organizations like the OECD [OEC22] and the World Bank [Ban22], it has major
shortcomings. First, _what_ the metric is applied on may skew the narrative.
E.g., the Gini coefficient of real-world economies w.r.t. to income offers a
much more appealing image compared to wealth ownership, as income differences
persist and accumulate over the course of life. Second, Gini’s single value
obscures qualitative differences between economies at the same “level”. For
instance, consider the following two wealth distributions [But21]: i) one
person holds $50$% of total wealth, while all else share the rest; ii) half
the population shares equally all wealth, while the other half has none.
Although these economies are vastly different, their Gini coefficient is the
same (approx. $0.5$). Alternative metrics could also help evaluate different
aspects of decentralization. Examples from traditional economics are the Theil
[The67], Atkinson [A+70], and Herfindahl-Hirschman [Rho93] indices. Drawing
from the blockchain space, an often-used metric is the Nakamoto coefficient
[PS21], which measures the minimum number of parties that control a majority
of resources. Nonetheless, a systematic comparison of all alternatives is an
interesting question for future research.

Research Directions. Our work opens various threads for future research,
beyond evaluating metrics of decentralization.

First, off-chain “Layer 2” protocols are an important part of blockchain
ecosystems [JKLT19]. Our work does not treat such protocols as a distinct
stratum. Nonetheless, our methodology can be readily applied to a
_combination_ of Layer 1 (main chain) and Layer 2 protocols. For example, one
could apply our layering methodology on a combination of Bitcoin and the
Lightning Network [PD16] and assess the decentralization of the combined
system as a payment network. Taking it one step further, one could use our
methodology to assess “decentralized applications” (DApps) that run on
blockchains. This for instance could be used to assess the decentralization of
DeFi systems. In such an investigation, smart contract development would
naturally fall into the software layer. In summary, exploring the
decentralization of Layer 1 and 2 protocol compositions or DApps under our
methodology, and possibly identifying alternative properties and relevant
resources, is a promising thread of future research.

Second, a natural end-goal of all questions posed in this work is to produce a
single, quantitative blockchain decentralization metric or “index.”
Historically, it has been shown that increasing decentralization on one axis
coincides with, or even results in, centralization on another [Sch19].
Therefore, future work should further explore the dynamics between all layers,
resolve possibly inescapable trade-offs, determine the importance (weight)
that should be assigned to each layer, identify appropriate metrics for each
layer and efficiently combine them into an index.

## References

  * [A+70] Anthony B Atkinson et al.  On the measurement of inequality.  Journal of economic theory, 2(3):244–263, 1970.
  * [AB02] Réka Albert and Albert-László Barabási.  Statistical mechanics of complex networks.  Reviews of modern physics, 74(1):47, 2002.
  * [ABL21] Darcy WE Allen, Chris Berg, and Aaron M Lane.  Trust and governance in collective blockchain treasuries.  Available at SSRN, 2021.
  * [AKM+18] Giuseppe Ateniese, Aggelos Kiayias, Bernardo Magri, Yiannis Tselekounis, and Daniele Venturi.  Secure outsourcing of cryptographic circuits manufacturing.  In Joonsang Baek, Willy Susilo, and Jongkil Kim, editors, ProvSec 2018: 12th International Conference on Provable Security, volume 11192 of Lecture Notes in Computer Science, pages 75–93, Jeju, South Korea, October 25–28, 2018. Springer, Heidelberg, Germany.
  * [AKWW19] Georgia Avarikioti, Lukas Käppeli, Yuyi Wang, and Roger Wattenhofer.  Bitcoin security under temporary dishonest majority.  In Ian Goldberg and Tyler Moore, editors, Financial Cryptography and Data Security - 23rd International Conference, FC 2019, Frigate Bay, St. Kitts and Nevis, February 18-22, 2019, Revised Selected Papers, volume 11598 of Lecture Notes in Computer Science, pages 466–483. Springer, 2019\.
  * [Als19] Eric Alston.  Constitutions and blockchains: Competitive governance of fundamental rule sets.  Case Western Reserve Journal of Law, Technology & the Internet, 11(4), 2019.
  * [AMM19] Sarah Azouvi, Mary Maller, and Sarah Meiklejohn.  Egalitarian society or benevolent dictatorship: The state of cryptocurrency governance.  In Aviv Zohar, Ittay Eyal, Vanessa Teague, Jeremy Clark, Andrea Bracciali, Federico Pintore, and Massimiliano Sala, editors, FC 2018 Workshops, volume 10958 of Lecture Notes in Computer Science, pages 127–143, Nieuwpoort, Curaçao, March 2, 2019. Springer, Heidelberg, Germany.
  * [AN21] Osato Avan-Nomayo.  Bitcoin.org blocks access to bitcoin software download in the uk, 2021\.
  * [Ara16] Daniel Araya.  The promise of bitcoin: An interview with andreas m. antonopoulos, 2016\.
  * [Arr50] Kenneth J Arrow.  A difficulty in the concept of social welfare.  Journal of political economy, 58(4):328–346, 1950.
  * [AZV17] Maria Apostolaki, Aviv Zohar, and Laurent Vanbever.  Hijacking bitcoin: Routing attacks on cryptocurrencies.  In 2017 IEEE Symposium on Security and Privacy, pages 375–392, San Jose, CA, USA, May 22–26, 2017. IEEE Computer Society Press.
  * [Ban22] World Bank.  Gini index (world bank estimate), 2022.
  * [Bar64] Paul Baran.  On distributed communications networks.  IEEE transactions on Communications Systems, 12(1):1–9, 1964.
  * [Bas46] Frédéric Bastiat.  Popular Fallacies regarding General Interests; being a translation of the “Sophismes économiques”… With notes by GR Porter [the translator]. John Murray, 1846.
  * [BBBF18] Dan Boneh, Joseph Bonneau, Benedikt Bünz, and Ben Fisch.  Verifiable delay functions.  In Hovav Shacham and Alexandra Boldyreva, editors, Advances in Cryptology – CRYPTO 2018, Part I, volume 10991 of Lecture Notes in Computer Science, pages 757–788, Santa Barbara, CA, USA, August 19–23, 2018\. Springer, Heidelberg, Germany.
  * [BBH21] Balázs Bodó, Jaya Klara Brekke, and Jaap-Henk Hoepman.  Decentralisation: a multidisciplinary perspective.  Internet Policy Review, 10(2):1–21, 2021.
  * [BDK16] Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich.  Argon2: new generation of memory-hard functions for password hashing and other applications.  In 2016 IEEE European Symposium on Security and Privacy (EuroS&P), pages 292–302. IEEE, 2016.
  * [BG19a] C Bendiksen and S Gibbons.  The bitcoin mining network-trends, composition, average creation cost, electricity consumption & sources. coinshares research, 2019.
  * [BG19b] Balázs Bodó and Alexandra Giannopoulou.  The logics of technology decentralization–the case of distributed ledger technologies.  Blockchain and web, 3, 2019.
  * [BGK+18] Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas.  Ouroboros genesis: Composable proof-of-stake blockchains with dynamic availability.  In David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang, editors, ACM CCS 2018: 25th Conference on Computer and Communications Security, pages 913–930, Toronto, ON, Canada, October 15–19, 2018. ACM Press.
  * [BGK+20] Christian Badertscher, Peter Gaži, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas.  Consensus redux: Distributed ledgers in the face of adversarial supremacy.  Cryptology ePrint Archive, Report 2020/1021, 2020.  https://eprint.iacr.org/2020/1021.
  * [BH20] Joseph Bonneau and Nadia Heninger, editors.  FC 2020: 24th International Conference on Financial Cryptography and Data Security, volume 12059 of Lecture Notes in Computer Science, Kota Kinabalu, Malaysia, February 10–14, 2020. Springer, Heidelberg, Germany.
  * [BKKS20] Lars Brünjes, Aggelos Kiayias, Elias Koutsoupias, and Aikaterini-Panagiota Stouka.  Reward sharing schemes for stake pools.  In IEEE European Symposium on Security and Privacy, EuroS&P 2020, Genoa, Italy, September 7-11, 2020, pages 256–275. IEEE, 2020.
  * [BKLZ20] Benedikt Bünz, Lucianna Kiffer, Loi Luu, and Mahdi Zamani.  FlyClient: Super-light clients for cryptocurrencies.  In IEEE S&P 2020 [IEE20], pages 928–946.
  * [BKP14] Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov.  Deanonymisation of clients in bitcoin P2P network.  In Gail-Joon Ahn, Moti Yung, and Ninghui Li, editors, ACM CCS 2014: 21st Conference on Computer and Communications Security, pages 15–29, Scottsdale, AZ, USA, November 3–7, 2014. ACM Press.
  * [BMBK18] Roman Beck, Christoph Müller-Bloch, and John Leslie King.  Governance in the blockchain economy: A framework and research agenda.  Journal of the Association for Information Systems, 19(10):1, 2018\.
  * [BMRS20] Joseph Bonneau, Izaak Meckler, Vanishree Rao, and Evan Shapiro.  Coda: Decentralized cryptocurrency at scale.  Cryptology ePrint Archive, Report 2020/352, 2020.  https://eprint.iacr.org/2020/352.
  * [Boa18] Financial Stability Board.  Crypto-asset markets.  Potential channels for future financial stability implications, 10, 2018.
  * [Boa19] Financial Stability Board.  Decentralised financial technologies: Report on financial stability, regulatory and governance implications.  June, 6:2019, 2019.
  * [Bre12] Eric Brewer.  Cap twelve years later: How the” rules” have changed.  Computer, 45(2):23–29, 2012.
  * [But14] Vitalik Buterin.  On stake, 2014.
  * [But16] Vitalik Buterin.  Hard fork completed, 2016.
  * [But21] Vitalik Buterin.  Against overuse of the gini coefficient, 2021.
  * [CCA+22] Jusop Choi, Wonseok Choi, William Aiken, Hyoungshick Kim, Jun Ho Huh, Taesoo Kim, Yongdae Kim, and Ross Anderson.  Attack of the clones: Measuring the maintainability, originality and security of bitcoin’forks’ in the wild.  arXiv preprint arXiv:2201.08678, 2022.
  * [cde17] cdetrio.  Ropsten revival, 2017.
  * [CGMV18] Jing Chen, Sergey Gorbunov, Silvio Micali, and Georgios Vlachos.  ALGORAND AGREEMENT: Super fast and partition resilient byzantine agreement.  Cryptology ePrint Archive, Report 2018/377, 2018.  https://eprint.iacr.org/2018/377.
  * [CKMR22] Sandro Coretti, Aggelos Kiayias, Cristopher Moore, and Alexander Russell.  The generalsâ€™ scuttlebutt: Byzantine-resilient gossip protocols.  IACR Cryptol. ePrint Arch., page 541, 2022.
  * [CLZ+20] Ting Chen, Zihao Li, Yuxiao Zhu, Jiachi Chen, Xiapu Luo, John Chi-Shing Lui, Xiaodong Lin, and Xiaosong Zhang.  Understanding ethereum via graph analysis.  ACM Transactions on Internet Technology (TOIT), 20(2):1–32, 2020\.
  * [Coi22] CoinYuppie.  It’s time to formally face the centralization problem that infura brings, 2022.
  * [com16] Nxt community.  Nxt whitepaper, 2016.
  * [Com21] Commodity Futures Trading Commission.  Cftc orders coinbase inc. to pay $6.5 million for false, misleading, or inaccurate reporting and wash trading, 2021.
  * [Coo21] Chris Cook.  Introducing the blockstream satellite base station, 2021.
  * [Cor18] Bitcoin Core.  Cve-2018-17144 full disclosure, 2018.
  * [CS21] Alfonso Cevallos and Alistair Stewart.  A verifiably secure and proportional committee election rule.  In Foteini Baldimtsi and Tim Roughgarden, editors, AFT ’21: 3rd ACM Conference on Advances in Financial Technologies, Arlington, Virginia, USA, September 26 - 28, 2021, pages 29–42. ACM, 2021.
  * [CYD+20] Tong Cao, Jiangshan Yu, Jérémie Decouchant, Xiapu Luo, and Paulo Veríssimo.  Exploring the monero peer-to-peer network.  In Bonneau and Heninger [BH20], pages 578–594.
  * [CZLM21] Ling Cheng, Feida Zhu, Huiwen Liu, and Chunyan Miao.  On decentralization of bitcoin: An asset perspective, 2021.
  * [D+57] Anthony Downs et al.  An economic theory of democracy.  1957\.
  * [DBP+19] Sergi Delgado-Segura, Surya Bakshi, Cristina Pérez-Solà, James Litton, Andrew Pachulski, Andrew Miller, and Bobby Bhattacharjee.  TxProbe: Discovering bitcoin’s network topology using orphan transactions.  In Goldberg and Moore [GM19], pages 550–566.
  * [DFKP15] Stefan Dziembowski, Sebastian Faust, Vladimir Kolmogorov, and Krzysztof Pietrzak.  Proofs of space.  In Rosario Gennaro and Matthew J. B. Robshaw, editors, Advances in Cryptology – CRYPTO 2015, Part II, volume 9216 of Lecture Notes in Computer Science, pages 585–605, Santa Barbara, CA, USA, August 16–20, 2015\. Springer, Heidelberg, Germany.
  * [DGKR18] Bernardo David, Peter Gazi, Aggelos Kiayias, and Alexander Russell.  Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain.  In Jesper Buus Nielsen and Vincent Rijmen, editors, Advances in Cryptology – EUROCRYPT 2018, Part II, volume 10821 of Lecture Notes in Computer Science, pages 66–98, Tel Aviv, Israel, April 29 – May 3, 2018\. Springer, Heidelberg, Germany.
  * [DKKZ20] Stelios Daveas, Kostis Karantias, Aggelos Kiayias, and Dionysis Zindros.  A gas-efficient superlight bitcoin client in solidity.  Cryptology ePrint Archive, Report 2020/927, 2020.  https://eprint.iacr.org/2020/927.
  * [DPH14] Joan Antoni Donet Donet, Cristina Pérez-Solà, and Jordi Herrera-Joancomartí.  The bitcoin P2P network.  In Rainer Böhme, Michael Brenner, Tyler Moore, and Matthew Smith, editors, Financial Cryptography and Data Security - FC 2014 Workshops, BITCOIN and WAHC 2014, Christ Church, Barbados, March 7, 2014, Revised Selected Papers, volume 8438 of Lecture Notes in Computer Science, pages 87–102. Springer, 2014.
  * [DPS19] Phil Daian, Rafael Pass, and Elaine Shi.  Snow white: Robustly reconfigurable consensus and applications to provably secure proof of stake.  In Goldberg and Moore [GM19], pages 23–41.
  * [DPS+21] Maya Dotan, Yvonne-Anne Pignolet, Stefan Schmid, Saar Tochner, and Aviv Zohar.  Survey on blockchain networking: Context, state-of-the-art, challenges.  ACM Comput. Surv., 54(5), may 2021.
  * [DW13] Christian Decker and Roger Wattenhofer.  Information propagation in the bitcoin network.  In 13th IEEE International Conference on Peer-to-Peer Computing, IEEE P2P 2013, Trento, Italy, September 9-11, 2013, Proceedings, pages 1–10. IEEE, 2013.
  * [EBHBL16] Ariel Ekblaw, Chelsea Barabas, Jonathan Harvey-Buschel, and Andrew Lippman.  Bitcoin and the myth of decentralization: Socio-technical proposals for restoring network integrity.  In 2016 IEEE 1st international workshops on foundations and applications of self* systems (FAS* W), pages 18–23. IEEE, 2016.
  * [ER+60] Paul Erdos, Alfréd Rényi, et al.  On the evolution of random graphs.  Publ. Math. Inst. Hung. Acad. Sci, 5(1):17–60, 1960.
  * [ES14] Ittay Eyal and Emin Gün Sirer.  Majority is not enough: Bitcoin mining is vulnerable.  In Nicolas Christin and Reihaneh Safavi-Naini, editors, FC 2014: 18th International Conference on Financial Cryptography and Data Security, volume 8437 of Lecture Notes in Computer Science, pages 436–454, Christ Church, Barbados, March 3–7, 2014. Springer, Heidelberg, Germany.
  * [Eth22a] Ethereum.  Ethash, 2022.
  * [Eth22b] Ethereum.  The merge, 2022.
  * [FAD20] Federico Franzoni, Ivan Abellan, and Vanesa Daza.  Leveraging bitcoin testnet for bidirectional botnet command and control systems.  In Bonneau and Heninger [BH20], pages 3–19.
  * [fAF22] Cambridge Centre for Alternative Finance.  Cambridge bitcoin electricity consumption index (cbeci): Bitcoin mining map, 2022.
  * [FB22] Lorenzo Franceschi-Bicchierai.  People can’t see some nfts on twitter, crypto wallets after opensea goes down, 2022.
  * [FK20] Braydon Fuller and Javed Khan.  Cve-2018-17145: Bitcoin inventory out-of-memory denial-of-service attack, 2020.
  * [FSD22] Federico Franzoni, Xavier Salleras, and Vanesa Daza.  Atom: Active topology monitoring for the bitcoin peer-to-peer network.  Peer-to-Peer Networking and Applications, 15(1):408–425, 2022.
  * [FSW14] Sebastian Feld, Mirco Schönfeld, and Martin Werner.  Analyzing the deployment of bitcoin’s P2P network under an as-level perspective.  In Elhadi M. Shakshuki and Ansar-Ul-Haque Yasar, editors, Proceedings of the 5th International Conference on Ambient Systems, Networks and Technologies (ANT 2014), the 4th International Conference on Sustainable Energy Information Technology (SEIT-2014), Hasselt, Belgium, June 2-5, 2014, volume 32 of Procedia Computer Science, pages 1121–1126. Elsevier, 2014.
  * [FWK+22] Matthias Fitzi, Xuechao Wang, Sreeram Kannan, Aggelos Kiayias, Nikos Leonardos, Pramod Viswanath, and Gerui Wang.  Minotaur: Multi-resource blockchain consensus.  IACR Cryptol. ePrint Arch., page 104, 2022.
  * [GBE+18] Adem Efe Gencer, Soumya Basu, Ittay Eyal, Robbert van Renesse, and Emin Gün Sirer.  Decentralization in bitcoin and Ethereum networks.  In Sarah Meiklejohn and Kazue Sako, editors, FC 2018: 22nd International Conference on Financial Cryptography and Data Security, volume 10957 of Lecture Notes in Computer Science, pages 439–457, Nieuwpoort, Curaçao, February 26 – March 2, 2018. Springer, Heidelberg, Germany.
  * [GK20] Juan A. Garay and Aggelos Kiayias.  SoK: A consensus taxonomy in the blockchain era.  In Jarecki [Jar20], pages 284–318.
  * [GKCC14] Arthur Gervais, Ghassan O. Karame, Vedran Capkun, and Srdjan Capkun.  Is bitcoin a decentralized currency?  IEEE Secur. Priv., 12(3):54–60, 2014.
  * [GKL15] Juan A. Garay, Aggelos Kiayias, and Nikos Leonardos.  The bitcoin backbone protocol: Analysis and applications.  In Elisabeth Oswald and Marc Fischlin, editors, Advances in Cryptology – EUROCRYPT 2015, Part II, volume 9057 of Lecture Notes in Computer Science, pages 281–310, Sofia, Bulgaria, April 26–30, 2015. Springer, Heidelberg, Germany.
  * [GKL17] Juan A. Garay, Aggelos Kiayias, and Nikos Leonardos.  The bitcoin backbone protocol with chains of variable difficulty.  In Katz and Shacham [KS17], pages 291–323.
  * [GKP20] Juan A. Garay, Aggelos Kiayias, and Giorgos Panagiotakos.  Consensus from signatures of work.  In Jarecki [Jar20], pages 319–344.
  * [GKR18] Peter Gaži, Aggelos Kiayias, and Alexander Russell.  Stake-bleeding attacks on proof-of-stake blockchains.  Cryptology ePrint Archive, Report 2018/248, 2018.  https://eprint.iacr.org/2018/248.
  * [GM19] Ian Goldberg and Tyler Moore, editors.  FC 2019: 23rd International Conference on Financial Cryptography and Data Security, volume 11598 of Lecture Notes in Computer Science, Frigate Bay, St. Kitts and Nevis, February 18–22, 2019. Springer, Heidelberg, Germany.
  * [Goo21] Nicole Goodkind.  World’s richest people now own 11% of global wealth, marking the biggest leap in recent history, 2021.
  * [GSW+19] Yue Gao, Jinqiao Shi, Xuebin Wang, Qingfeng Tan, Can Zhao, and Zelin Yin.  Topology measurement and analysis on ethereum P2P network.  In 2019 IEEE Symposium on Computers and Communications, ISCC 2019, Barcelona, Spain, June 29 - July 3, 2019, pages 1–7. IEEE, 2019.
  * [Her17] Alex Hern.  $300m in cryptocurrency accidentally lost forever due to bug, 2017.
  * [Hin18] William Hinman.  Digital asset transactions: When howey met gary (plastic), 2018.
  * [HKZG15] Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg.  Eclipse attacks on bitcoin’s peer-to-peer network.  In Jaeyeon Jung and Thorsten Holz, editors, USENIX Security 2015: 24th USENIX Security Symposium, pages 129–144, Washington, DC, USA, August 12–14, 2015. USENIX Association.
  * [Hui20] Marie Huillet.  Binance launches ethereum mining pool with 0.5% fees, 2020.
  * [IEE20] 2020 IEEE Symposium on Security and Privacy, San Francisco, CA, USA, May 18–21, 2020. IEEE Computer Society Press.
  * [Jar20] Stanislaw Jarecki, editor.  Topics in Cryptology – CT-RSA 2020, volume 12006 of Lecture Notes in Computer Science, San Francisco, CA, USA, February 24–28, 2020\. Springer, Heidelberg, Germany.
  * [JKLT19] Maxim Jourenko, Kanta Kurazumi, Mario Larangeira, and Keisuke Tanaka.  SoK: A taxonomy for layer-2 scalability related protocols for cryptocurrencies.  Cryptology ePrint Archive, Report 2019/352, 2019.  https://eprint.iacr.org/2019/352.
  * [Joh99] Norman L Johnson.  Diversity in decentralized systems: Enabling self-organizing solutions.  In Decentralization II Conference, UCLA, volume 4. Citeseer, 1999\.
  * [Kar20] Kostis Karantias.  Sok: A taxonomy of cryptocurrency wallets.  Cryptology ePrint Archive, 2020.
  * [KB20] Assimakis Kattis and Joseph Bonneau.  Proof of necessary work: Succinct state verification with fairness guarantees.  Cryptology ePrint Archive, Report 2020/190, 2020.  https://eprint.iacr.org/2020/190.
  * [KDF13] Joshua A Kroll, Ian C Davey, and Edward W Felten.  The economics of bitcoin mining, or bitcoin in the presence of adversaries.  In Proceedings of WEIS, volume 2013. Washington, DC, 2013.
  * [Kia22] Aggelos Kiayias.  Decentralizing information technology: The advent of resource based systems.  In Panagiotis Kanellopoulos, Maria Kyropoulou, and Alexandros A. Voudouris, editors, Algorithmic Game Theory - 15th International Symposium, SAGT 2022, Colchester, UK, September 12-15, 2022, Proceedings, volume 13584 of Lecture Notes in Computer Science, pages 3–19. Springer, 2022.
  * [KKK21] Dimitris Karakostas, Nikos Karayannidis, and Aggelos Kiayias.  Efficient state management in distributed ledgers.  Cryptology ePrint Archive, Report 2021/183, 2021.  https://eprint.iacr.org/2021/183.
  * [KKLM19] Sanket Kanjalkar, Joseph Kuo, Yunqi Li, and Andrew Miller.  Short paper: I can’t believe it’s not stake! Resource exhaustion attacks on PoS.  In Goldberg and Moore [GM19], pages 62–69.
  * [KKNZ19] Dimitris Karakostas, Aggelos Kiayias, Christos Nasikas, and Dionysis Zindros.  Cryptocurrency egalitarianism: A quantitative approach.  In Vincent Danos, Maurice Herlihy, Maria Potop-Butucaru, Julien Prat, and Sara Tucci Piergiovanni, editors, International Conference on Blockchain Economics, Security and Protocols, Tokenomics 2019, May 6-7, 2019, Paris, France, volume 71 of OASIcs, pages 7:1–7:21. Schloss Dagstuhl \- Leibniz-Zentrum für Informatik, 2019.
  * [KL22] Aggelos Kiayias and Philip Lazos.  Sok: Blockchain governance.  CoRR, abs/2201.07188, 2022.
  * [KLK+19] Yujin Kwon, Jian Liu, Minjeong Kim, Dawn Song, and Yongdae Kim.  Impossibility of full decentralization in permissionless blockchains.  In Proceedings of the 1st ACM Conference on Advances in Financial Technologies, AFT ’19, pages 110–123, New York, NY, USA, 2019. Association for Computing Machinery.
  * [KMZ17] Aggelos Kiayias, Andrew Miller, and Dionysis Zindros.  Non-interactive proofs of proof-of-work.  Cryptology ePrint Archive, Report 2017/963, 2017.  https://eprint.iacr.org/2017/963.
  * [Kon19] Evgeny Konstantinov.  The ethereum cloud vs. on-premises nodes conundrum, 2019.
  * [KP99] Elias Koutsoupias and Christos Papadimitriou.  Worst-case equilibria.  In Annual symposium on theoretical aspects of computer science, pages 404–413. Springer, 1999.
  * [KP19] Susanne Kohler and Massimo Pizzol.  Life cycle assessment of bitcoin mining.  Environmental science & technology, 53(23):13598–13606, 2019.
  * [KPZ20] Aggelos Kiayias, Andrianna Polydouri, and Dionysis Zindros.  The velvet path to superlight blockchain clients.  Cryptology ePrint Archive, Report 2020/1122, 2020.  https://eprint.iacr.org/2020/1122.
  * [KRDO17] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov.  Ouroboros: A provably secure proof-of-stake blockchain protocol.  In Katz and Shacham [KS17], pages 357–388.
  * [KS17] Jonathan Katz and Hovav Shacham, editors.  Advances in Cryptology – CRYPTO 2017, Part I, volume 10401 of Lecture Notes in Computer Science, Santa Barbara, CA, USA, August 20–24, 2017. Springer, Heidelberg, Germany.
  * [KS21] Aggelos Kiayias and Aikaterini-Panagiota Stouka.  Coalition-safe equilibria with virtual payoffs.  In Foteini Baldimtsi and Tim Roughgarden, editors, AFT ’21: 3rd ACM Conference on Advances in Financial Technologies, Arlington, Virginia, USA, September 26 - 28, 2021, pages 71–85. ACM, 2021.
  * [KYMM18] George Kappos, Haaroon Yousaf, Mary Maller, and Sarah Meiklejohn.  An empirical analysis of anonymity in zcash.  In William Enck and Adrienne Porter Felt, editors, USENIX Security 2018: 27th USENIX Security Symposium, pages 463–477, Baltimore, MD, USA, August 15–17, 2018. USENIX Association.
  * [LABK17] Wenting Li, Sébastien Andreina, Jens-Matthias Bohli, and Ghassan Karame.  Securing proof-of-stake blockchain protocols.  In Data Privacy Management, Cryptocurrencies and Blockchain Technology, pages 297–315. Springer, 2017.
  * [Lei20] Oded Leiba.  Unveiling bigspender: Double (and multiple) spend vulnerability in major bitcoin wallets, 2020.
  * [LKX+19] Yiran Liu, Junming Ke, Qiuliang Xu, Han Jiang, and Hao Wang.  Decentralization is vulnerable under the gap game.  IEEE Access, 7:90999–91008, 2019.
  * [LLZC21] Qinwei Lin, Chao Li, Xifeng Zhao, and Xianhai Chen.  Measuring decentralization in bitcoin and ethereum using multiple metrics and granularities.  In 37th IEEE International Conference on Data Engineering Workshops, ICDE Workshops 2021, Chania, Greece, April 19-22, 2021, pages 80–87. IEEE, 2021.
  * [LP20] Chao Li and Balaji Palanisamy.  Comparison of decentralization in dpos and pow blockchains.  CoRR, abs/2002.02082, 2020.
  * [LSP82] Leslie Lamport, Robert Shostak, and Marshall Pease.  The byzantine generals problem.  ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3):382–401, 1982.
  * [Man19] Bitwise Asset Management.  Analysis of real bitcoin trade volume, 2019.
  * [MB19] Amir Pasha Motamed and Behnam Bahrak.  Quantitative analysis of cryptocurrencies transaction graph.  Applied Network Science, 4(1):1–21, 2019.
  * [Mil19] Kevin Milewski.  Cftc, fincen, and sec warn of crypto aml enforcement, 2019.
  * [MM02] Petar Maymounkov and David Mazieres.  Kademlia: A peer-to-peer information system based on the xor metric.  In International Workshop on Peer-to-Peer Systems, pages 53–65. Springer, 2002.
  * [MNT22] Christian Matt, Jesper Buus Nielsen, and Søren Eller Thomsen.  Formalizing delayed adaptive corruptions and the security of flooding networks.  In Yevgeniy Dodis and Thomas Shrimpton, editors, Advances in Cryptology - CRYPTO 2022 - 42nd Annual International Cryptology Conference, CRYPTO 2022, Santa Barbara, CA, USA, August 15-18, 2022, Proceedings, Part II, volume 13508 of Lecture Notes in Computer Science, pages 400–430. Springer, 2022.
  * [MO19] Tal Moran and Ilan Orlov.  Simple proofs of space-time and rational proofs of storage.  In Alexandra Boldyreva and Daniele Micciancio, editors, Advances in Cryptology – CRYPTO 2019, Part I, volume 11692 of Lecture Notes in Computer Science, pages 381–409, Santa Barbara, CA, USA, August 18–22, 2019\. Springer, Heidelberg, Germany.
  * [Mon19] Monero.  Network upgrade and release 0.15, 2019.
  * [MPJ+16] Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage.  A fistful of bitcoins: characterizing payments among men with no names.  Commun. ACM, 59(4):86–93, 2016.
  * [NAH16] Till Neudecker, Philipp Andelfinger, and Hannes Hartenstein.  Timing analysis for inferring the topology of the bitcoin peer-to-peer network.  In 2016 Intl IEEE Conferences on Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), pages 358–367. IEEE, 2016.
  * [Nak08] Satoshi Nakamoto.  Bitcoin: A peer-to-peer electronic cash system, 2008.
  * [New03] Mark EJ Newman.  The structure and function of complex networks.  SIAM review, 45(2):167–256, 2003.
  * [NH18] Till Neudecker and Hannes Hartenstein.  Network layer aspects of permissionless blockchains.  IEEE Communications Surveys & Tutorials, 21(1):838–857, 2018.
  * [NMW+19] Gleb Naumenko, Gregory Maxwell, Pieter Wuille, Alexandra Fedorova, and Ivan Beschastnikh.  Erlay: Efficient transaction relay for bitcoin.  In Lorenzo Cavallaro, Johannes Kinder, XiaoFeng Wang, and Jonathan Katz, editors, ACM CCS 2019: 26th Conference on Computer and Communications Security, pages 817–831. ACM Press, November 11–15, 2019.
  * [Nom21] Nomics.  Nomics’ crypto trust index - q1 2021, north america, 2021.
  * [OEC22] OECD.  Income inequality, 2022.
  * [O’L18] Rachel-Rose O’Leary.  The race is on to replace ethereum’s most centralized layer, 2018.
  * [otEU22] Council of the European Union.  Proposal for a regulation of the european parliament and of the council on markets in crypto-assets, and amending directive (eu) 2019/1937 (mica), 2022.
  * [PD16] Joseph Poon and Thaddeus Dryja.  The bitcoin lightning network: Scalable off-chain instant payments, 2016\.
  * [Pet21] Katelyn Peters.  A history of bitcoin hard forks, 2021.
  * [PJBO21] Rowan van Pelt, Slinger Jansen, Djuri Baars, and Sietse Overbeek.  Defining blockchain governance: a framework for analysis and comparison.  Information Systems Management, 38(1):21–41, 2021.
  * [PS17] Rafael Pass and Elaine Shi.  Hybrid consensus: Efficient consensus in the permissionless model.  In Andréa W. Richa, editor, 31st International Symposium on Distributed Computing, DISC 2017, October 16-20, 2017, Vienna, Austria, volume 91 of LIPIcs, pages 39:1–39:16. Schloss Dagstuhl - Leibniz-Zentrum für Informatik, 2017.
  * [PS21] Mike Platis and Bergen Sanderford.  Nakamoto coefficient, 2021.
  * [PSL80] Marshall Pease, Robert Shostak, and Leslie Lamport.  Reaching agreement in the presence of faults.  Journal of the ACM (JACM), 27(2):228–234, 1980.
  * [PSs17] Rafael Pass, Lior Seeman, and abhi shelat.  Analysis of the blockchain protocol in asynchronous networks.  In Jean-Sébastien Coron and Jesper Buus Nielsen, editors, Advances in Cryptology – EUROCRYPT 2017, Part II, volume 10211 of Lecture Notes in Computer Science, pages 643–673, Paris, France, April 30 – May 4, 2017. Springer, Heidelberg, Germany.
  * [R+61] Alfréd Rényi et al.  On measures of entropy and information.  In Proceedings of the fourth Berkeley symposium on mathematical statistics and probability, volume 1. Berkeley, California, USA, 1961.
  * [RD17] Ling Ren and Srinivas Devadas.  Bandwidth hard functions for ASIC resistance.  In Yael Kalai and Leonid Reyzin, editors, TCC 2017: 15th Theory of Cryptography Conference, Part I, volume 10677 of Lecture Notes in Computer Science, pages 466–492, Baltimore, MD, USA, November 12–15, 2017. Springer, Heidelberg, Germany.
  * [Rei22] Nathan Reiff.  All about the bitcoin cash hard fork, 2022.
  * [Rho93] Stephen A Rhoades.  The herfindahl-hirschman index.  Fed. Res. Bull., 79:188, 1993.
  * [RJZH19] Matteo Romiti, Aljosha Judmayer, Alexei Zamyatin, and Bernhard Haslhofer.  A deep dive into bitcoin mining pools: An empirical analysis of mining shares.  CoRR, abs/1905.05999, 2019.
  * [RL11] Derek D. Reed and James K. Luiselli.  Temporal Discounting, pages 1474–1474.  Springer US, Boston, MA, 2011.
  * [Ros18] David Rosenthal.  Gini coefficients of cryptocurrencies, 2018.
  * [RS13a] Dorit Ron and Adi Shamir.  Quantitative analysis of the full Bitcoin transaction graph.  In Ahmad-Reza Sadeghi, editor, FC 2013: 17th International Conference on Financial Cryptography and Data Security, volume 7859 of Lecture Notes in Computer Science, pages 6–24, Okinawa, Japan, April 1–5, 2013\. Springer, Heidelberg, Germany.
  * [RS13b] Dorit Ron and Adi Shamir.  Quantitative analysis of the full bitcoin transaction graph.  In Ahmad-Reza Sadeghi, editor, Financial Cryptography and Data Security - 17th International Conference, FC 2013, Okinawa, Japan, April 1-5, 2013, Revised Selected Papers, volume 7859 of Lecture Notes in Computer Science, pages 6–24. Springer, 2013.
  * [RYM19] Pierre Reibel, Haaroon Yousaf, and Sarah Meiklejohn.  Short paper: An exploration of code diversity in the cryptocurrency landscape.  In Goldberg and Moore [GM19], pages 73–83.
  * [SA19] European Securities and Markets Authority.  Initial coin offerings and crypto-assets.  Innovation and Products, ESMA50-157-1391, 2019.
  * [SBFG21] Ashish Rajendra Sai, Jim Buckley, Brian Fitzgerald, and Andrew Le Gear.  Taxonomy of centralization in public blockchain systems: A systematic literature review.  Inf. Process. Manag., 58(4):102584, 2021.
  * [SBG21] Ashish Rajendra Sai, Jim Buckley, and Andrew Le Gear.  Characterizing wealth inequality in cryptocurrencies.  Frontiers Blockchain, 4:730122, 2021.
  * [SC+17a] US Securities, Exchange Commission, et al.  Report of investigation pursuant to section 21(a) of the securities exchange act of 1934: The dao, 2017.
  * [SC+17b] US Securities, Exchange Commission, et al.  Sec issues investigative report concluding dao tokens, a digital asset, were securities.  July, 25:2017–131, 2017.
  * [SC+19] US Securities, Exchange Commission, et al.  Framework for ”investment contract” analysis of digital assets.  US Securities and Exchange Commission, 3, 2019.
  * [SC+20] US Securities, Exchange Commission, et al.  Securities and exchange commission against ripple labs, inc, bradley garlinghouse, christian a. larsen, 2020.
  * [Sch19] Nathan Schneider.  Decentralization: an incomplete ambition.  Journal of cultural economy, 12(4):265–285, 2019.
  * [Sha01] Claude Elwood Shannon.  A mathematical theory of communication.  ACM SIGMOBILE mobile computing and communications review, 5(1):3–55, 2001.
  * [SKG19] Christian Stoll, Lena Klaaßen, and Ulrich Gallersdörfer.  The carbon footprint of bitcoin.  Joule, 3(7):1647–1661, 2019.
  * [TCM+20] Muoi Tran, Inho Choi, Gi Jun Moon, Anh V. Vu, and Min Suk Kang.  A stealthier partitioning attack against bitcoin peer-to-peer network.  In IEEE S&P 2020 [IEE20], pages 894–909.
  * [The67] Henri Theil.  Economics and information theory.  Technical report, 1967.
  * [TSK21] Muoi Tran, Akshaye Shenoi, and Min Suk Kang.  On the routing-aware peering against network-eclipse attacks in bitcoin.  In Michael Bailey and Rachel Greenstadt, editors, USENIX Security 2021: 30th USENIX Security Symposium, pages 1253–1270. USENIX Association, August 11–13, 2021.
  * [UND99] UN UNDP.  Decentralization: A sampling of definitions.  Working Paper, 1999.
  * [Ven21] Outlier Ventures.  Blockchain development trends 2021, 2021.
  * [Ver20] BTI Verified.  2020 market data integrity report, 2020.
  * [VRK21] Friedhelm Victor, Peter Ruppel, and Axel Kupper.  A taxonomy for distributed ledger analytics.  Computer, 54(02):30–38, 2021.
  * [WCQ20] Canhui Wang, Xiaowen Chu, and Yang Qin.  Measurement and analysis of the bitcoin networks: A view from mining pools.  In 2020 6th International Conference on Big Data Computing and Communications (BIGCOM), pages 180–188, 2020.
  * [WG16] Karl Wüst and Arthur Gervais.  Ethereum eclipse attacks.  Technical report, ETH Zurich, 2016.
  * [Wil20] Chris Williams.  Infura outage sparks debate over ethereum’s decentralization, 2020.
  * [WPG+21] Sam M. Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J. Knottenbelt.  Sok: Decentralized finance (defi).  CoRR, abs/2101.08778, 2021.
  * [WZY+21] Taotao Wang, Chonghe Zhao, Qing Yang, Shengli Zhang, and Soung Chang Liew.  Ethna: Analyzing the underlying peer-to-peer network of ethereum blockchain.  IEEE Transactions on Network Science and Engineering, 8(3):2131–2146, 2021.
  * [You21] Martin Young.  Opensea’s team of 37 staff is currently handling 98% of combined nft volumes, 2021.
  * [ZCC+21] Liyi Zeng, Yang Chen, Shuo Chen, Xian Zhang, Zhongxin Guo, Wei Xu, and Thomas Moscibroda.  Characterizing ethereum’s mining power decentralization at a deeper level.  In 40th IEEE Conference on Computer Communications, INFOCOM 2021, Vancouver, BC, Canada, May 10-13, 2021, pages 1–10. IEEE, 2021.
  * [ZML22] Luyao Zhang, Xinshi Ma, and Yulin Liu.  Sok: Blockchain decentralization.  arXiv preprint arXiv:2205.04256, 2022.
  * [ZOB19] Bingsheng Zhang, Roman Oliynykov, and Hamed Balogun.  A treasury system for cryptocurrencies: Enabling better collaborative intelligence.  In ISOC Network and Distributed System Security Symposium – NDSS 2019, San Diego, CA, USA, February 24-27, 2019. The Internet Society.
  * [ZS20] Fanger Zhou and Norah Song.  2020 q2 cryptocurrency mining industry report, 2020.