Introduction to Blockchain
Part 3: Network

his article is the third post in a multi-part series describing how blockchain works and some of the security assumptions associated with it. Each article will describe a different level of how the blockchain’s distributed ledger operates, starting with the fundamentals.

The blockchain is designed to store a trusted, shared distributed ledger. This ledger represents the history of the blockchain network, so the network level is an important one when discussing the blockchain ecosystem.

In the previous post, we discussed the nodes and how they each maintain their own copy of the distributed ledger. Since the blockchain is designed to be trustless, no other node is going to implicitly trust any other node’s copy. They need a way to agree on the state of the ledger (consensus), and, for that, they need a way to communicate: the network.

The Blockchain Peer-to-Peer Network

Blockchains use a different network architecture than most of the web services that we’re used to. These services use a client-server architecture, where the server acts as a single source of ground truth, and the clients connect directly to it to upload or download application data. For example, when you use a webmail client like Gmail, your email doesn’t go directly from your computer to the recipient’s. Instead, you upload it to the Gmail servers and the recipient downloads it from a Gmail server to read.

This system is simple and effective, yet it relies on the Gmail server to be a trusted middleman in the process. Blockchain isn’t big on trusted middlemen, so it uses a peer-to-peer network, where each node in the network communicates directly with other nodes. Most blockchain networks use a broadcast system where, if a node has five peers, every message that is received from one is sent to the other four. This way, messages percolate across the network over many paths, and no one has complete control over communications.

The main implication of the peer-to-peer model for blockchain networking is that the underlying network needs to be able to support it. Since every peer needs to be capable of connecting to every other peer, you can’t effectively have a blockchain network distributed across a network with varying trust levels without compromising either blockchain or network security.

Also, the “broadcast” communication style of the blockchain means that it requires a large amount of bandwidth to function properly. The inability to support this can have negative impacts on blockchain security and effectiveness.

Attacking the Blockchain Network

Many of the best-known attacks against blockchain systems are at the network level. Many people know that private key management is a problem and that smart contract vulnerabilities exist, but they’d be hard-pressed to even name the top ten most common smart contract vulnerabilities. On the other hand, Sybil attacks and 51% attacks are commonly mentioned in blockchain security-related posts.

In this section, we’ll discuss three network-level attacks on the blockchain: Denial of Service (DoS), Eclipse, and Sybil attacks. A 51% attack can also be considered a network-level attack, but we’ll talk about it in the next post since it’s most closely related to consensus.

Denial of Service Attacks

Blockchains are distributed, decentralized networks, so it seems like Denial of Service (DoS) attacks should be impossible. DoS attacks target a single point of failure (like a webserver) or a bottleneck in a system and attempt to overwhelm it in order to degrade the operations of the system. Since blockchain (theoretically) has no single points of failure, DoS attacks shouldn’t be an issue. In practice, DoS attacks against the blockchain exist, but they attack temporary single points of failure or system bottlenecks.

One such bottleneck is the transaction capacity of the blockchain. Most blockchains create blocks with a fixed maximum size at a fixed rate. An attacker can create a large number of spam transactions and transmit them to the network (similar to a DoS attack on a webserver). If the network can’t reliably identify them as spam transactions and ignore them, they’ll be added to the blockchain, taking up space that could have been used by legitimate transactions. Worse, blockchains are “forever”, so these spam transactions that make it onto the blockchain can take up storage space on nodes for the life of the blockchain.

An example of a temporary single point of failure is the creator of a given block. Different blockchains have different methods of choosing this person, but in the end, one node puts a block together, signs it, and transmits it to the network. In some schemes (like Proof of Stake), if a block creator misses their “slot” for creating a block, they forfeit it. If you can force someone to forfeit a block (i.e. by a traditional DoS attack), that block is never created and the network loses some of its potential capacity.

Eclipse/Routing Attacks

Eclipse and Routing attacks are two names for essentially the same attack. In an Eclipse attack, an attacker isolates a single node from the rest of the network by controlling all of its peer connections. In a Routing attack, the network is split up into two or more isolated groups. Both attacks can be used to facilitate a double-spend attack (by sending a different transaction to each isolated individual/group) or a 51% attack (by filtering the victim’s view of the network state so that they mine a version of history that’s in the attacker’s favor).

Eclipse and routing attacks can be performed by a variety of different means. External to the blockchain ecosystem, an attacker can control a node’s connection to the network using malware or any other traditional means of performing a Man-in-the-Middle (MitM) attack. A study found that Bitcoin is especially vulnerable to BGP routing attacks, where the attacker convinces computers that the best route from A to B is through them.

Internal to the blockchain ecosystem, an attacker can perform these attacks by controlling all of a node’s connections to their peers. Since blockchain networks are not fully connected (nodes only connect to a small number of other nodes), it’s possible that a node can only be connected to peers controlled by an attacker.

It doesn’t matter how the attacker controls the node’s connection to the blockchain network as long as control is absolute. If this is true, the attacker may be able to selectively drop packets from other users or send mutually exclusive versions of transactions from their own addresses to drive the isolated groups’ versions of history apart. When the attack is completed, the longest block rule means that whichever version of the blockchain is shorter will be discarded (which is perfect for a double-spend attack).

Sybil Attacks

A Sybil attack is a simple network-level attack used to facilitate other attacks. In a Sybil attack, the attacker creates and maintains a large number of accounts on the blockchain network. This can be useful when performing an Eclipse/Routing attack since, if the attacker controls most of the nodes accepting connections when a node is looking for one, there is a high probability that the node will only choose attacker-controlled connections.

Up Next: Consensus

Up to this point, we’ve talked about the fundamentals of the blockchain protocol and how it works and is attacked at a node and network level. In the next post, we’ll be discussing consensus: the way that these distributed and decentralized networks of nodes agree on their shared history.