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 6 Consensus Protocols like Bitcoin [78], Algorand [40], or Ouroboros Praos [78], enable resource holders to engage in the protocol directly with (essentially) whatever amount of resources they have. In these protocols, block producers can, even though they do not have to, form coalitions called pools. In PoW, a pool “leader” validates transactions, and organizes them in a candidate block, while each “member” executes the PoW puzzle for the leader-made block. If a member is successful, the leader collects the block’s reward and distributes it, proportionately to each member’s power. In PoS, the leader has full control over the block’s creation, while the members only pay fees to delegate their staking rights to the leader and collect rewards. Pooling behavior is also driven by temporal discounting [146], i.e., the tendency to disfavor rare or delayed rewards. In essence, a small miner may prefer small frequent payments, at the cost of some fee, over rare large payments, when producing a block. Other systems, like Cosmos [114] and EOS [92], impose restrictions on which parties can participate in consensus and require the rest to delegate their resources to a representative or “validator” node. This “barrier to entry” means that any party without enough stake, i.e., below the system’s threshold or less than its competitors, is required to delegate their staking rights to a validator. At every “epoch”, a committee of (a fixed number of) parties is elected to run the protocol. The election mechanism is voting-based, with resource delegation acting as the voting process. In both types of systems, there are two resources of interest: i) owned participating power, e.g., computational or stake; ii) delegated participating power, including the power to choose a block’s content. Accordingly, the relevant parties are: i) miners and stakeholders, who own hashing power and stake respectively; ii) pool leaders and delegates, who control how the resources are used. Typically, the security of a ledger is guaranteed if the parties that represent an aggregate majority of the participating power are honest (i.e., they follow the protocol as prescribed) [78]. Therefore, the concentration of participating power around few entities poses a threat to the system. This hazard is well-known and blockchain users and participants have actively tried to avoid it since at least 2014 [86]. Those controlling a power majority can hurt liveness, by refusing to publish or accept certain transactions, as well as safety by launching a long-range attack. Both types of attacks also indirectly hurt stability, since the system’s trustworthiness is challenged. A second concern revolves around block proposers. A proposer is a party that maintains a mempool and chooses which transactions are added to a block and in what order. Initially, a single party acted as both block proposer and builder. With the increase in hardware requirements needed to run a full node and the formation of pools, the two roles of proposer and builder were separated. In PoW ledgers, the leader of the pool typically proposes the block’s content, whereas the pool members only run the PoW algorithm. Therefore, pool members are not involved in a block’s construction and often do not even validate its contents. Therefore, the leader may censor transactions (liveness hazard), steal member rewards (stability hazard), or possibly link the user’s resources with information like IP addresses (privacy hazard). In addition, smart contracts enable MEV-type attacks [186], which might hurt stability. Here, block builders have the ability to observe transactions before publication and choose their order in a block, which they can exploit to extract value from honest transactions. A countermeasure that has been introduced is the proposer-builder separation (PBS) model, wherein a trusted party maintains a mempool and proposes a block, whereas validators sign it without ever observing its content (thus not being able to exploit its MEV) [33]. Still, the current implementation of PBS in Ethereum has been criticized for facilitating censorship and centralization, hence its usefulness remains unclear [88]. Finally, a threat arises due to the lack of self-healing, i.e., the inability to recover from a temporary adversarial takeover. In PoW, even if a majority gets corrupted, honest users can increase their own power and, eventually, overthrow the adversary and restore the ledger’s security [10,13]. In PoS though, power shift takes place on the ledger, by transferring stake. If an adversary temporarily obtains a majority, they can prohibit transactions that shift power away from them, thus retaining control indefinitely (for example, a large centralized cryptocurrency exchange can make it hard to issue outgoing payments and withdrawals, while enabling payments between different users of the exchange). Consequently, a diverse stake distribution (cf. Section 7) is vital to protect against takeovers. 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.

Can Blockchain Stay Fair for the Long Haul?

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