How Token Ownership Shapes Blockchain Security

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.