Before we delve deeper, it is advisable to understand the different components of a blockchain.
- Consensus engine
- Scripting and virtual execution environment
- Transactions, block and chain logics
- Peer-to-peer network
It is these four parts of the blockchain that makeup what it is.
The security properties of a blockchain actually rely on the peer-to-peer network. Exclusive research on eclipse attack was started by a group consisting of Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg way back in 2015. Their research illustrated the first attack against Bitcoin’s peer-to-peer network by controlling hundreds of nodes, which is modeled as an unstructured random graph in their research paper. Another interesting research paper titled “Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network” illustrated the feasibility of launching eclipse attacks against Ethereum’s P2P network layer (which is usually modeled as a structured graph like Kademlia DHT) using only two machines. Eclipse attacks hammered home the need for cross-layer design when one builds a complicated P2P system.
So what allows an Eclipse attack?
Design flaw 1:
Peer’s Identity
Peers in the Ethereum network are identified by their node IDs, which are 64-byte cryptographic ECDSA public keys that can be generated. Multiple Ethereum nodes, each with a different node ID, is run on a single machine that has a single IP address. Due to this weak definition of a “peer”, the hacker can easily generate a large set of Ethereum peers, hosts them on one single machine with the same single IP address, and coordinates them strategically to block any incoming and outgoing communication to and from the victim node.
Design Flaw 2:
The strategy to select Peer
Instead of using a random peer selection strategy, Ethereum uses Kademlia for selecting new peers. In a Kademlia network, each item of content is associated with a key and is stored only at those peers whose node ID is “close” to its associated key. “Closeness” is defined as the binary Hamming distance between the key and the node ID. Each Kademlia node has b distinct buckets, where bucket I store k peers information at distance i.
Design Flaw 3:
Inbound vs Outbound Connections
From a peer’s point of view, there are two types of connections — inbound (if it was initiated by another peer) and outbound (if it was initiated by this peer) connections. Ethereum puts a limit, known as max peers (25 by default), on the total number of inbound and outbound connections but does not set a limit for each of them. A victim node could max out the maxpeer limit with 100% inbound connections coming from the hacker.
A veritable cap has to be put in place to overcome this challenge.