A solution to the problem of eclipse attack in Ethereum

(Image courtesy of Constantin Popp, Unsplash)

What is an Eclipse Attack?

Eclipse Attack is an attack type for a peer-to-peer (or peer-to-peer) network: an attacker completely controls a particular node's access to information by disabling the node from the entire network.

In popular peer-to-peer networks (such as Bitcoin and Ethereum), an attacker can perform eclipse by ensuring that the victim node no longer receives the correct information from the rest of the network, but only the information manipulated by the attacker. Attack (Eclipse Attack).

• The world influence of Libra and China's countermeasures
• Research report | Bitcoin bull market really came? In fact, FOMO emotions are far from being ignited.
• Market Analysis: BTC continues to triumph

In other words, such attacks occur when most of the peer nodes on the network are malicious and are controlling the connections of a particular node. An attacker who controls such a connection can ensure that this particular node is surrounded by a malicious node.

In addition, in eclipse attacks, the attacker does not attack the entire network as it does in the Sybil attack, but instead focuses on isolating and targeting a particular node. Such attacks typically result in the victim node receiving a manipulated, forged blockchain view.

"A malicious node uses its fake blockchain to prevent the victim node from viewing the real blockchain. Therefore, as one of the main threats to blockchain security, its name is called a solar eclipse attack."

According to a paper published by Heilman et al. in 2015, a key implication of the Eclipse Attack is that this attack may be a useful building basis for other types of attacks. For example, once an attack is implemented, one of the bad things an attacker can do is to launch a 51% attack with 51% of the computing power of the entire network.

This may result in a change in the history of online transactions seen by the victim, which may result in economic losses for the victim.

What are the conditions for a successful eclipse attack on Ethereum?

It is worth noting that there are not many conditions for a malicious party to successfully perform a solar eclipse attack. A paper published by Heilman et al. in 2018 shows that only a few machines are needed to perform a solar eclipse attack on the Ethereum network.

The researchers pointed out that in order to complete the eclipse attack on Ethereum, the malicious party only needs to control two machines, each machine has only one IP address, to monopolize the connection with the victim node, and finally the victim node and Other peer nodes in the network are isolated.

However, in most cases, the eclipse attack is still difficult to start because the attacker must select a target node or a group of nodes, establish a botnet of the host node, disconnect the target from each node connected to it, and Adjacent nodes of the target are continually experimented to connect them to the attacker's nodes. The attacker must then wait for the next victim node to log out and rejoin the network.

During the reset process, the attacker forces the connection to be redirected to a new set of nodes, giving complete control over all connections to the victim. This is not a simple task, but it is feasible. So far, we have not seen any examples of eclipse attacks; however, recent research has shown that this should not be ignored.

Eclipse attack against IoT devices

What about eclipse attacks in the IoT environment? The risks posed by IoT devices will increase significantly. In the common scenario of data center mining nodes, an attacker needs several machines to successfully perform a solar eclipse attack. In data center scenarios, eclipse attacks are difficult to accomplish because they typically involve attacking multiple independent uplinks.

On the other hand, in an IoT environment scenario, an attacker can more easily perform a solar eclipse attack. IoT devices are targets that attackers can easily attack, mainly because of eclipse attacks on IoT devices, and only involve attacking a single point of failure, for example, attacking a meshed 3G uplink.

If an attacker wants to launch an eclipse attack on an IoT device, it can first initiate a man-in-the-middle attack by targeting the gateway of the IoT device. Once the gateway is attacked, the attacker will fully control the data of the victim's IoT device, such as a block sync request, thus forcing the victim to connect to the malicious node.

“IoT devices are isolated from the rest of the network, so the real blockchain network cannot be viewed. Since then, eclipse attacks against IoT devices have been completed.”

So how to mitigate the eclipse attack?

In a eclipse attack scenario in a Workload Proof (POW) network, an attacker exploited this vulnerability to force a node to accept a chain that is longer and less difficult than the main chain. Since the total difficulty reported by the attacker is higher than that of the honest node, when the victim node rejoins the network, it will receive a chain that is longer than the effective chain but less difficult.

Therefore, what happens is that the victim node can no longer synchronize with the active chain. So what is the way to alleviate this problem?

Fortunately, important proposals are emerging quickly. Just last month, German blockchain researcher Dominic Letz proposed BlockQuick, an ultralight client protocol for solving eclipse attacks.

As Letz wrote in the paper " BlockQuick: Super-Light Client Protocol for Blockchain Validation on Constrained Devices ": "BlockQuick can prevent eclipse attacks, because when verifying blocks, it doesn't just rely on proof of effort ( POW) Choose the longest chain with the greatest difficulty on the network."

The longest chain and the most difficult features are critical in blockchain protocols, as well as popular light clients (such as Ethereum Geth), but without proper protection, an attacker could abuse these features. In order to provide a secure, light client protocol, the security policy must use a consensus reputation table when validating blocks.

As he explained in the paper: “In each new block, the device verifies the miner’s cryptographic signature and compares it to the known miner’s identity in the consensus reputation table. Only when a block of consensus When the score is greater than 50%, the client will accept it. Receiving a chain with a lower total score will result in a suspension."

The client will see how the device iterates over these blocks and will run a slow update mechanism. The idea is that BlockQuick will run a reputation check to ensure that the client only accepts blocks with a reputation score greater than 50%, rather than following the longest chain rule.

in conclusion

In this article, we describe what the eclipse attack is, discuss some of the implications of eclipse attacks, and explore how the ultralight client protocol solves this problem. As blockchain technology continues to evolve, understanding current and future developments is important to the blockchain community.

The original author is Yahsin Huang, a Taipei technology author.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!