Table of Links
Abstract and 1. Introduction
2 Methodology
3 Hardware
4 Software
5 Network
6 Consensus
7 Cryptocurrency Economics
8 Client API
9 Governance
10 Geography
11 Case Studies
12 Discussion and References
A. Decentralization and Policymaking
B. Software Testing
C. Brief Evaluations per Layer
D. Measuring decentralization
E. Fault Tolerance and Decentralization
3 Hardware
The role of hardware in the potential decentralization of blockchain systems has been reported in various research works [187,43]. To be specific, by “hardware”, we refer to the machines that host and/or support the consensus software, which can be anything from personal computers to purpose-built devices. In many cases, the hardware is also provided as a service from cloud providers to consensus participants. To account for all possibilities, we segment this layer into two categories, namely “physical” and “virtual” hardware.
Physical hardware. This category covers all hardware that is used directly by consensus participants. Bitcoin mining, and that of other Proof-of-Work (PoW)
ledgers, started from regular CPUs, but quickly migrated to GPUs and, eventually, to dedicated devices (ASICs), which produce more hashes at a lower cost [163]. In the case of Proof-of-Stake (PoS) blockchains, participation is typically performed through generic hardware, although there are systems with particular requirements, which may restrict the compatible hardware options (an example such blockchain is The Internet Computer by Dfinity [56]). Some alternative schemes, such as certain forms of Proof-of-Useful-Work (PoUW) or Proof-of-Elapsed-Time (PoET) also Trusted Execution Environments (TEEs) to guarantee higher security or efficiency levels [14].
When analyzing decentralization on this layer, the resource of interest is participating power (e.g., hashes per second or stake) and the relevant parties are the manufacturers of hardware products that are used for participating. That is, we consider a system to be decentralized in the hardware layer if the participating power is distributed across various pieces of equipment, manufactured by different entities.
As demonstrated by the evolution of Bitcoin mining, one pathway to hardware centralization is the development and adoption of specialized machines that outperform generic equipment and provide an advantage to their operators. Nowadays, an overwhelming majority of block production in PoW blockchains comes from specialized hardware, despite the fact that PoW does not require specialized hardware in theory [163]. Notably, this trend has motivated significant research in “ASIC-resistance” and the development of PoW algorithms that attempt to facilitate better hardware diversity [19,64,149]. In other cases, strict or “non-typical” protocol requirements (e.g., the requirement for trusted hardware) reduce the pool of possible manufacturers that can support those systems, potentially leading to increased centralization.
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 [7].
Virtual hardware. The emergence of mining data centers allowed for hashing power to be offered as a “cloud” service, effectively enabling miners to participate in block production without possessing their own hardware [121,165]. The advent of PoS protocols reinforced this trend towards “virtual” hardware, by decoupling Sybil resilience from physical requirements. In theory, this enables PoS nodes to run on generic hardware, e.g., even home equipment, but in practice, convenience often drives PoS users to employ cloud services, which offer uptime and connectivity guarantees that a DIY configuration cannot. This is exacerbated when PoS systems apply penalties to absent users and uptime guarantees become of utmost importance to guarantee profitability. Therefore, the resource of interest in this category is again participating power (either in the form of hashing power or stake) and the relevant parties are cloud providers.
When nodes that control significant participating power are hosted by the same provider, significant hazards arise for all properties. First, the provider may have access to private keys and hence is able to create conflicting blocks (safety hazard) or deanonymize users (compromising 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 rewards.
