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 8 Client API To join a blockchain system, full nodes need to download and parse the entire ledger, which often amounts to hundreds of GBs.[13] The ledger’s state, which is usually stored in memory, is also large[14] and often poorly maintained [98]. Consequently, maintaining a full node requires significant computational and storage capacity and, eventually, becomes impossible to host on home equipment. This concern is well-known and ongoing research tries to resolve it via ledger compression [105,26,101]. In practice though, users often employ third-party services that offer an interface to the ledger [123]. Given the widespread use and variety of applications that rely on such services, the “client API” layer can be susceptible to centralization [39]. The resources we identify in this case are tokens, which are stored in wallets without ledger verification capabilities, and the relevant parties the full node operators that service them. We note that solutions like Simplified Payment Verification (SPV) [131] or succinct verification proofs [51,106,105,30], which are not full nodes but do validate the ledger to some extent, are not considered here. Instead, we focus on wallets that rely entirely on a trusted node for access to the ledger’s content. Many properties are at risk for such wallets by corrupted full node services. For example, the service could perform a double-spending attack (safety violation), by presenting to the wallet a transaction that is not in fact published on the ledger; observe that, without any access to the ledger itself, the wallet needs to trust the data presented by the node. Similarly, since the wallet relies on the full node for transaction processing and balance computations, liveness, privacy, and stability hazards arise, as the node can block, de-anonymize or, depending on the implementation, divert a user’s funds and transactions. 9 Governance Governance in blockchain systems is a broad topic [104,142,17] and of high interest among studies of blockchain decentralization [83,11,156]. Here, we focus on two aspects: i) improvements and conflict resolution; ii) fund allocation for research and development (R&D). Improvements and Conflict Resolution. Decision-making mainly concerns conflicts that arise regarding potential blockchain modifications and improvement proposals. Proposals may affect mining, e.g., changing the PoW function [128] or switching to PoS [65], the consensus protocol, e.g., changing block structure [148], or token ownership, e.g., denylisting [32]. In theory, anyone can propose changes in blockchain systems and respond in some way, depending on their role. 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 [3]. 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 relevant 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. Where a voting mechanism is employed to reach a decision, voting power typically corresponds to each participant’s wealth, with each token granted one vote (due to the pseudonymous nature of these systems). If ownership is concentrated around a small number of stakeholders, the decisions might aim at benefiting these few parties in the short term, at the expense of the system’s long-term benefit. If a disagreement turns into a stalemate, systems may split into distinct ledgers, that share the same history up to a point but diverge thereupon [143,32]. 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 sound decisions in a decentralized manner, as demonstrated by theoretical results in social choice such as Arrow’s impossibility theorem [6]. Additionally, when agents act in a selfish manner, as is presumed in distributed ledgers, efficiency can degrade (cf. “Price of Anarchy” [112]). 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 [60]) considerations. R&D 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 researchers and 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 accumulates funds over time that are allocated for R&D [2,183]. A treasury is typically managed collectively by the ecosystem, often via an open and inclusive process where anyone can submit proposals and the system’s stakeholders vote for funding allocation. Therefore, a treasury can help nurture a diverse ecosystem of development teams, albeit it is not, on its own, a sufficient condition for decentralized R&D funding. 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. 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 8 Client API To join a blockchain system, full nodes need to download and parse the entire ledger, which often amounts to hundreds of GBs.[13] The ledger’s state, which is usually stored in memory, is also large[14] and often poorly maintained [98]. Consequently, maintaining a full node requires significant computational and storage capacity and, eventually, becomes impossible to host on home equipment. This concern is well-known and ongoing research tries to resolve it via ledger compression [105,26,101]. In practice though, users often employ third-party services that offer an interface to the ledger [123]. Given the widespread use and variety of applications that rely on such services, the “client API” layer can be susceptible to centralization [39]. The resources we identify in this case are tokens, which are stored in wallets without ledger verification capabilities, and the relevant parties the full node operators that service them. We note that solutions like Simplified Payment Verification (SPV) [131] or succinct verification proofs [51,106,105,30], which are not full nodes but do validate the ledger to some extent, are not considered here. Instead, we focus on wallets that rely entirely on a trusted node for access to the ledger’s content. Many properties are at risk for such wallets by corrupted full node services. For example, the service could perform a double-spending attack (safety violation), by presenting to the wallet a transaction that is not in fact published on the ledger; observe that, without any access to the ledger itself, the wallet needs to trust the data presented by the node. Similarly, since the wallet relies on the full node for transaction processing and balance computations, liveness, privacy, and stability hazards arise, as the node can block, de-anonymize or, depending on the implementation, divert a user’s funds and transactions. 9 Governance Governance in blockchain systems is a broad topic [104,142,17] and of high interest among studies of blockchain decentralization [83,11,156]. Here, we focus on two aspects: i) improvements and conflict resolution; ii) fund allocation for research and development (R&D). Improvements and Conflict Resolution. Decision-making mainly concerns conflicts that arise regarding potential blockchain modifications and improvement proposals. Proposals may affect mining, e.g., changing the PoW function [128] or switching to PoS [65], the consensus protocol, e.g., changing block structure [148], or token ownership, e.g., denylisting [32]. In theory, anyone can propose changes in blockchain systems and respond in some way, depending on their role. 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 [3]. The governance resource is decision-making power, which may take various forms, and the relevant parties are all active entities in the system. Improvements and Conflict Resolution. Improvements and Conflict Resolution. If the other relevant 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. Where a voting mechanism is employed to reach a decision, voting power typically corresponds to each participant’s wealth, with each token granted one vote (due to the pseudonymous nature of these systems). If ownership is concentrated around a small number of stakeholders, the decisions might aim at benefiting these few parties in the short term, at the expense of the system’s long-term benefit. If a disagreement turns into a stalemate, systems may split into distinct ledgers, that share the same history up to a point but diverge thereupon [143,32]. 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 sound decisions in a decentralized manner, as demonstrated by theoretical results in social choice such as Arrow’s impossibility theorem [6]. Additionally, when agents act in a selfish manner, as is presumed in distributed ledgers, efficiency can degrade (cf. “Price of Anarchy” [112]). 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 [60]) considerations. R&D 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 researchers and developers in a ledger’s ecosystem. R&D Funding. R&D Funding. 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 accumulates funds over time that are allocated for R&D [2,183]. A treasury is typically managed collectively by the ecosystem, often via an open and inclusive process where anyone can submit proposals and the system’s stakeholders vote for funding allocation. Therefore, a treasury can help nurture a diverse ecosystem of development teams, albeit it is not, on its own, a sufficient condition for decentralized R&D funding. 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.

How Token Ownership Shapes Blockchain Security

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

Dark-Mode

Neon Noir

Minty

HN StartUps