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
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.
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.
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]
[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].
