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 4 Software Software development is another dimension of distributed ledgers that has been associated with potential centralization [44,147,11]. 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).[7] 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. To analyze decentralization, we identify two resources of interest: 1) (number of) full nodes; 2) participating power (e.g., computational or stake) that is hosted on full nodes. The relevant parties are: 1) full node software implementations; 2) full node software developers. Protocol Participation. Protocol Participation. 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 [75] and token forgery [48]. 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 [147]. Such projects often remain unpatched, so bugs in the initial implementation tend to spill over [44]. Vulnerabilities may also arise when adapting an existing implementation in a new setting, e.g., copying Bitcoin’s code and replacing PoW with PoS [96]. Thus, widespread usage of multiple node implementations, developed by different teams, is a hallmark of a secure and reliant ecosystem. Asset Management. Distributed ledgers are mostly used for bookkeeping of digital asset transactions, so securely managing and transferring 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 [100] 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, accordingly: i) wallet implementations; ii) developers of wallet software. Asset Management. Asset Management. 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 [89]; as a result, 300m worth of Ethereum tokens were forever lost. In another example, some Bitcoin wallets possibly displayed incorrect balance, effectively enabling a double spending attack [116]. 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.[8] 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 [7] Appendix B also explores software testing. [8] A 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 [169].

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

Eclipse Attacks, Network Clusters & DNS Seeding

Blockchain’s Hardware Problem

Blockchainize.TECH

Too Long; Didn't Read

Download free Tech Leaders Productivity Report!

Blockchain’s Single Point of Failure? The Software Running It

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

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

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

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps