Eclipse Attacks, Network Clusters & DNS Seeding

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

5 Network

Blockchain nodes communicate over a peer-to-peer (P2P) network, the decentralization properties of which have been of great interest to researchers [134,4,82,76]. Systems often implement a message diffusion mechanism [78] via a gossip protocol that avoids full graph connectivity [54]. Users typically use the Internet to access the P2P overlay, though some efforts try to introduce an independent infrastructure [47]. Here we explore networking aspects which present single points of failure, in terms of topology and bootstrapping. A notable research question that arises organically from our analysis, and touches upon both following subsections, is creating a P2P network that is both permissionless and Byzantine resilient, e.g., as explored in [49,124].

Topology. The first networking aspect of interest is the network’s topology. Evaluating a real-world network’s clustering properties is a well-known problem, traditionally done by generating random graphs and comparing the expected with the observed values [63,135,1]. In blockchain systems, every node maintains a list of peer connections. Crucially, message provenance is not typically provided, so no party can know the network origin of an incoming message. Therefore, the resource of interest are “bridges” (single nodes or small cluster of nodes) between the network graph’s components and the relevant parties are the bridges’ owners or operators. Here, a component is a single node or a cluster of tightly interconnected nodes.

A distributed network, in the tradition of Baran [15], is key in maintaining safety and liveness. Under the CAP theorem [27], any networked system can satisfy at most two of the following properties: i) a consistent data copy; ii) data availability; iii) network partition tolerance. Ledger systems are no exception. Each node needs to maintain at least one connection to an honest party to receive all messages and avoid eclipse attacks [87].

If some parties cannot communicate with the rest of the network, either they halt and any transactions they submit are dropped (violating liveness) or they produce separate ledger versions (violating safety).[9] By preventing communication between a node and the rest of the network, an attacker reduces the honest computational power and isolates that node, making a 51% or a double spending attack (against the isolated node) easier to deploy. Additionally, an adversary can violate liveness by blocking the node’s transactions from reaching the rest of the network. Third, an adversary that controls all of a node’s connections can link transactions to the specific node, correlate the user’s addresses, and associate them with real-world information, such as an IP address, thus compromising privacy[10]. This also holds on a macroscopic level, i.e., a node that acts as a central communication hub between two clusters can obtain information and even deanonymize some participants (violating privacy).

Node Bootstrapping and Peer Discovery. Joining a ledger’s network and synchronizing with it is the so-called “bootstrapping” process. All real-world ledgers rely on an initial (trusted) setup, the first (“genesis”) block.[11] Obtaining the correct genesis block is done in an out-of-band, typically secure mechanism, since it is often well-known and easy to validate from various sources.

Initially, the node needs to connect to some peers and receive all available chains. Therefore, the resource here is bootstrapping nodes and the relevant parties are these nodes’ operators. Then, using the ledger protocol’s chain resolution mechanism, it decides which chain to adopt. There are two points of interest here.

First, it should be guaranteed that the node connects to at least one honest peer, to retrieve all available information and avoid getting eclipsed. As explained above, if nodes gets eclipsed, the system’s liveness, safety and privacy properties may get compromised. However, connecting to honest peers is not straightforward, given that the node has no knowledge about the network participants, a standard problem in P2P networks [57]. Blockchain systems predominantly use either hardcoded peer lists or DNS seeding [120], although both techniques are censorship-prone. Notably, [120] showed that more secure alternatives, such as ZMap [61], cannot be feasibly used in existing blockchain systems.

Second, even if the node connects to some honest peers, catching up by using only genesis (“bootstrapping from genesis”) is not always feasible. Especially in PoS systems, an attacker can effortlessly assemble an arbitrarily-long, seemingly correct chain (violating safety) [81,31,118]. To counter such attacks, some ledgers employ checkpoints [107,52,50], which are often issued centrally and are either hardcoded or received from the peers. Other solutions do exist, e.g., analyzing block density and relying on key erasures [12] or using VDFs [24,53], but enforcing and/or relaxing such assumptions still poses an interesting research problem.

[9] In longest-chain protocols, like Bitcoin, miners keep producing blocks in isolation, ending up with different ledger versions. In BFT-style protocols, like Algorand, the ledger cannot be updated if a large number of block producers become unreachable and thus do not adopt new transactions.

[10] Note that protecting privacy in the network layer can be a particularly challenging problem, even in the setting where no single adversary controls all of a node’s connections.

[11] Some proposals rely on computational assumptions instead of a trusted setup [80], but their real-world performance and applicability is still untested.