The eclipse attack is a relatively simple basic attack that an attacker can use to interfere with nodes on the network. As the name suggests, this attack can prevent the attacked node in the peer-to-peer network from obtaining effective information, thereby causing network interruption or preparing for more complex attacks.
On the surface, the Eclipse Attack is similar to the Sybil Attack. Although they share some similarities (an attacker disrupts the network by attacking nodes), their ultimate attack goals are different. Eclipse attacks target a single node (for reasons explained below), while Sybil attacks target the entire network and aim to tamper with the reputation of network protocols.
This concept is discussed in detail in the 2015 paper "Eclipse Attacks on the Bitcoin Peer-to-Peer Network" from Boston University and Hebrew University 's researchers reported the results of their experiments conducting eclipse attacks, as well as preventive measures to combat them.
Bitcoin miners Specialized equipment is required to generate and verify new blocks, but non-mining (or full) nodes require very little computing power to operate. In this way, anyone can operate a node on cheap equipment, which also contributes to Bitcoin’s decentralization. The software program maintains a transaction database that is synchronized with peers to stay in sync with the network.
The limiting factor for large number of node connections is bandwidth. Therefore, although there are a large number of devices that can run the program, there is a limit on the number of connections set in the Bitcoin network (a maximum of 125 connections), and ordinary devices cannot directly interconnect with other devices.
In an eclipse attack, the attacker ensures that all connections to the target are established on nodes controlled by the attacker. The attacker will first send a flood from their own IP address to the target address, and the victim may connect to the attacker's IP address when the program restarts. You can force a restart (i.e. perform a DDoS attack on the target), or just wait for the program to automatically restart.
If this happens, unsuspecting victims are at the mercy of malicious nodes, and the attacker feeds them false data that they cannot obtain from the real network.
If the attacker consumes the network node's resources that can separate them from the network, then they have an incentive to carry out such attacks. If a node is isolated, an attacker can carry out several consecutive attacks.
If an independent node accepts an unconfirmed transaction, the risk of "double spending" will occur. If the transaction that occurred may have been broadcast before entering the block (submitting to the blockchain), then the sender can easily make a new transaction elsewhere and spend the same amount as the previous transaction. If the newly generated transaction fee is higher, the miners will prioritize the transaction and consider it to be the first transaction, causing the first transaction to be invalid.
Some merchants and individuals accept these 0-confirmation transactions. Consider Bob, a businessman who sells high-end cars. He didn't know that Alice had launched an eclipse attack on his node, and he didn't have any suspicion after seeing her order for a luxury sports car. Alice creates the transaction, and Bob broadcasts it to the network. After seeing that the payment message was about to be confirmed, he felt very satisfied and handed the car keys to Alice, who drove away at a speed.
In fact, the transaction was not broadcast to the network. Bob just passed the transaction to Alice's malicious node, and the malicious node controlled by Alice would not pass the transaction. to the real node. Therefore, the transaction will be considered invalid. At this time, Alice pays the same amount on the (real) network, either to herself or to someone else. Even if the initial transaction with Bob is finally seen on the real network, the transaction cannot be verified because the funds in Alice's account have been used up.
"Double Spending" that requires N confirmations is similar to "Double Spending" that does not require confirmation, but involves more preparation work. Many merchants prefer to wait for a certain number of confirmations before a payment is marked as valid. To solve the problem, an attacker would have to subject both miner and merchant nodes to an eclipse attack. If an attacker establishes an order with a merchant, they broadcast the transaction to the miners. Merchants can see transactions confirmed in the blockchain network, but because the networks where miners and merchants are located are isolated, the blockchain is not witnessed by most real nodes.
The attacker sends the false blockchain network information to the merchant. After the merchant sees that the transaction has been confirmed, he hands over the goods. When these nodes that suffered an eclipse attack rejoin the real network, the real blockchain network will consider these nodes to be invalid and isolate these nodes (this is similar to a 51% attack).
Suffer Nodes attacked by an eclipse will continue to run and will not be affected by being isolated from the network. Miners will continue to verify blocks within the rules specified by the protocol, but added blocks will be discarded in the process of passing through real network nodes.
Theoretically, a large-scale eclipse attack on a large portion of miners could be used to facilitate a 51% attack. As it stands, the cost for even the most resourceful attacker to take over the majority of Bitcoin’s computing power (approximately 80TH/s) is too high, and the attacker would need to at least attempt with more than 40TH/s.
We assume that this computing power is distributed among 10 participants (each participant has approximately 8TH/s). An attacker can remove these participants from the network Isolation, greatly reducing the requirements for 51% attacks. If 5 of the nodes suffer an eclipse attack, the attacker can reduce the computing power by 40TH/s to find the next block, and the attacker now only needs to increase the computing power by 20TH/s to achieve the goal of attacking the node. control.
Other destructive activities that can be achieved by performing eclipse attacks on targets include manipulating nodes to conduct illegal mining activities, or taking advantage of computing power competition among miners to obtain the next block.
If you have enough IP addresses, An attacker can then perform an eclipse attack on any node. The most direct way to prevent this from happening is to block unauthorized access by nodes and only establish outbound connections to specific nodes (such as IPs that have been whitelisted by other nodes in the peer-to-peer network). However, as the research paper points out, this is not a solution that can be implemented at scale, and if all participants take these measures, new nodes will not be able to join the network.
The author has proposed some adjustments to the Bitcoin program, and some of them were integrated into the Bitcoin program after the white paper was released. By making small changes to the code, such as randomly selecting new connections and boosting address storage, these measures make eclipse attacks increasingly costly.
The eclipse attack is conducted on a peer-to-peer network. As a stand-alone means of attack deployment, they can be annoying. The real purpose of conducting an eclipse attack is actually to implement other attacks that can have a greater impact, or to provide the attacker with an advantage in mining.
Generally speaking, eclipse attacks have not had a serious impact, and despite the preventive measures deployed in blockchain networks, the threat still exists. Eclipse attacks, like most attacks faced by Bitcoin and most other cryptocurrencies, the best defense is to make it unprofitable for malicious attackers.