You need an Ethereum wallet to use Bithoven

Connect to one of our available wallet providers or create a new one

Don't have a crypto wallet yet?

How to connect
MetaMask Polygon (MATIC) Ankr (ANKR) DASH (Dash) Solana (SOL) Cosmos (ATOM) Cardano (ADA) Polkadot (DOT) Avalanche (AVAX) Everscale (EVER) PoW and PoS Algorand (ALGO) Metaverse Stablecoins Monero (XMR) Litecoin (LTC) Tron (TRX) DeFi Zcash (ZEC) Введение в ИИ Ethereum (ETH) Tezos (XTZ) Ripple (XRP) Bithoven Guide CBDC Uniswap (UNI) Web3 ИИ The Graph (GRT) Chainlink (LINK) Icon (ICX) BTH-keys CEX and DEX Stellar (XLM) Qtum (QTUM) Sharding Blockchain Bitcoin Compound (COMP) Introduction to Blockchain EVM not EVM network L2E NEAR Protocol (NEAR)
Bithoven company logo
Bithoven company logo
Link successfully copied!

Introduction to Blockchain: Network (Part 3)

Blockchain networks

Blockchain is designed for storing a reliable shared distributed ledger. This ledger represents the history of the blockchain network, so the network layer is important when discussing the blockchain ecosystem.

In the previous article, we discussed nodes and how each of them maintains its own copy of the distributed ledger. Since blockchain is designed in such a way that no other node will unconditionally trust the copy of any other node, they need a way to agree on the state of the ledger (consensus), and for this, they need a means of communication: the network.

Peer-to-peer blockchain network

Blockchains use a different network architecture than most of the other web services we are used to. These services use a client-server architecture, where the server acts as a single source of trusted information and clients connect directly to it to download application data. For example, when you use a webmail client such as Gmail, your email doesn't go directly from your computer to the recipient's computer. Instead, you download it to the Gmail servers, and the recipient downloads it from the Gmail server to read.

This system is simple and efficient, but the Gmail server acts as a trusted intermediary. Blockchain does not have many trusted intermediaries, 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 in which, if a node has five peer-to-peer nodes, every message received from one is sent to the other four. In this way, messages spread across the network through many paths, and no one has complete control over the communications.

The main significance of the peer-to-peer model for blockchain networks is that the underlying network must support it. Because each peer-to-peer node must be able to connect to any other peer-to-peer node, you cannot effectively distribute a blockchain network across a network with different levels of trust without compromising the security of the blockchain or the network. In addition, the "broadcast" style of blockchain communication means that it requires a lot of bandwidth to work properly. Failure to maintain this can have negative consequences for blockchain security and efficiency.

Attack on the blockchain network

Many of the most notorious attacks on blockchain systems occur at the network level. Many people know that private key management is a problem and that there are smart contract vulnerabilities, but they would have a hard time even naming the top 10 most common smart contract vulnerabilities. On the other hand, Sybil and 51% attacks are often mentioned in blockchain security-related communications.

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

Denial of Service (DoS) attack

Blockchains are distributed, decentralized networks, so it seems that Denial of Service (DoS) attacks should be impossible. DoS attacks target a single point of failure (e.g., a web server) or bottleneck in a system and try to overload it to degrade system performance. Since blockchain (in theory) has no single point of failure, DoS attacks should not be a problem. In practice, DoS attacks on blockchain exist, but they attack temporary points of failure or bottlenecks in the system.

One such bottleneck is the transactional 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 web server). If the network cannot reliably identify them as spam transactions and ignore them, they will be added to the blockchain, taking up space that could have been used by legitimate transactions. Worse, blockchains are "forever," so these spam transactions hitting 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 ways of selecting this person, but ultimately one node assembles the block, signs it, and transmits it to the network. In some schemes (e.g., Proof of Stake), if the block creator misses his "slot" to create the block, he loses it. If you can force someone to give up a block (i.e. with a traditional DoS attack), that block will never be created, and the network will lose some of its potential bandwidth.

Eclipse/Routing attacks

Eclipse and Routing attacks are two names for the same attack. In an Eclipse attack, the attacker isolates one node from the rest of the network, controlling all peer-to-peer connections. In a Routing attack, the network is split into two or more isolated groups. Both attacks can be used to facilitate double-spending attacks (by sending a separate transaction to each isolated party/group) or 51% attacks (by filtering the victim's view of the network state so they mine a version of the history that favors the attacker).

Eclipse and Routing attacks can be executed in a variety of ways. Outside the blockchain ecosystem, an attacker can control a node's connection to the network using malware or any other traditional means of executing a Man-in-the-middle (MITM) attack. Research has shown that Bitcoin is especially vulnerable to BGP routing attacks, where an attacker convinces computers that the best route from A to B goes through them.

Inside the blockchain ecosystem, an attacker can execute these attacks by controlling all of a node's connections to its partners. Because blockchain networks are not fully connected (nodes only connect to a small number of other nodes), it is possible that a node can only be connected to nodes controlled by an attacker.

It does not matter how an attacker controls a node's connection to the blockchain network, as long as the control is absolute. If this is true, the attacker could selectively discard packets from other users or send mutually exclusive versions of transactions from their own addresses to separate versions of isolated group histories. When the attack is complete, the longest block rule means that the shortest version of the blockchain will be discarded (which is ideal for the "double-spending" type of attack).

Sibylle's Attack

Sybil attacks are 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, because if the attacker controls most of the nodes accepting connections when a node looks for them, there is a high probability that the node will only select connections controlled by the attacker.

Next: consensus

Up to this point, we've talked about the basics of the blockchain protocol, how it works, and how it is attacked at the node and network level. In the next post, we will discuss consensus: the way these distributed and decentralized node networks reconcile their shared history.

Read Part 4 - Consensus

You may be interested