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

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

Internet Computer

Dfinity

Blockchain’s Hardware Problem

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps