Four types of censorship attacks on smart contracts: forking, evasion, interference, and quick attacks

Original title: "Viewpoint | How to prevent censorship attacks on smart contracts?"

Original author: Ed Felten

Original translation: IAN LIU & Ajian, Ethereum enthusiasts

In the design of smart contract systems, a common pattern is to require the client to take certain actions before a certain time point; if the client does not respond after this time point (for example, a certain block height), the smart contract will take some alternative actions, which are usually unfavorable to the overdue client.

In this article, my focus is on a similar pattern used in interactive Rollup protocols - one party makes an "assertion", and if others think the assertion is problematic, they can challenge it within the "challenge window"; if no one raises any challenge during the challenge period, the assertion will be considered valid.

The problem this design pattern encounters in practice is censorship attack - the attacker prevents others from making challenges within the time window. In an interactive Rollup protocol, an attacker may make a false "assertion" while preventing others from making challenges during the window period, which ultimately leads to the false assertion becoming legal.

We also assume that the attacker must first invest a sum of money, and once the attack fails, he will lose this money; in this way, we do not need to make the probability of a successful attack on the system zero, but as long as the probability of a successful attack is small enough, no one will be willing to try to attack the entire system.

Below, I will summarize what we know about censorship attacks, how to combat them, and finally give my thoughts on this risk.

Types of censorship attacks

There are four main types of censorship attacks:

Fork: Miners collude (or are bribed) to discard blocks containing normal challenges and, through forking, another blockchain is accepted that does not contain any challenges.

Dodging: Miners conspire (or are bribed) to not include normal challenges in their block creation.

Interference: The attacker uses a traditional denial of service (DoS) attack to make it impossible for others to make challenges (cannot issue transactions containing challenges).

Speed ​​Attack: The attacker makes a large number of on-chain assertions in a short period of time, making it too late for others to check and challenge all of them within the time window.

Let’s discuss them one by one.

Fork Attack

A fork attack occurs when an attacker gains a majority of mining power on a proof-of-work (PoW) blockchain and uses that power to orphan blocks containing challenges as needed.

Because this type of attack requires the attacker to control the majority of the computing power, it is difficult to launch - if the attacker can easily obtain most of the computing power, it means that there is a big problem with the blockchain itself. Or to think from another perspective, a cartel that can control most of the mining computing power will not only cause people to distrust the blockchain they are in, but also may have ways to squeeze money out of the system faster than censorship attacks.

You might say, wait a minute! The computing power monopoly may not make a high-profile announcement, but just conduct censorship secretly; if the attacker has the ability to do so, they may conduct a censorship attack through a fork without damaging the credibility of the entire blockchain.

This leads to the first question: Is the censorship attack easy for an observer to detect? To prove that the fork attack is obvious, I simulated a fork. Assuming that the attacker controls 60% of the computing power, in the first thirty blocks, three forked chains appear, with lengths of 1, 6, and 5 respectively; this is completely different from the general blockchain. I did another simulation, this time the attacker controls 55% of the computing power, and then an earlier fork can be as long as 48 blocks. According to the simple mathematical model, when the computing power is monopolized by 60%, a fork will occur every 2.5 blocks, and the average length of the orphan chain caused by the fork is 5; when the computing power is monopolized by 55%, a fork will occur every 2.2 blocks, and the average length of the orphan chain caused by the fork is 10.

As we can see, as the computing power of the monopoly decreases, the frequency of forks and the length of orphan chains increase. However, no matter how long the forks are, they all have one thing in common (the commonality of the first block): the first block on the isolated branch must contain a valid challenge, and the branch that eventually becomes the main chain will never contain this challenge - the person who proposed the challenge will definitely find this out! (The attacker may try to fork further away to avoid the commonality of the first block, but this will cause the branch to be too long, and the isolated branch will still contain the challenge.) So once a censorship attack occurs, it will definitely be discovered.

I don't know what you think, but if I find that there is a monopoly of computing power in the blockchain, and the monopolist uses computing power to interfere with the application layer protocol from time to time, I will be very worried. If other people have such doubts, the entire blockchain will no longer be trusted by users - any 51% computing power attack will lead to this result.

In other words, the problem with this attack is not that someone will censor your application-layer transactions, but that there is a computing power monopoly in your blockchain, which can break the rules without restraint for the sake of profit. For any blockchain application, regardless of whether it adopts the window period design mode, as long as this computing power monopoly appears, it is a devastating blow.

If the blockchain you are on is at risk of a fork attack, you should consider moving to another blockchain.

Dodge Attack

If the computing power monopolist does not use the easily discovered fork attack, what other tricks does it have? Yes, it is the evasion attack. The malicious miner only needs to refuse to package the transaction containing the challenge when generating a block; as long as it ensures that the blocks generated within the challenge window period are all produced by the malicious miner, the attack will succeed.

How likely is it that a dodge attack will succeed? This can be explained as follows: when the monopolist controls a percentage of computing power of f and the challenge window is n blocks, the success rate of the attack is fn. For example, if the monopolist controls 90% of the computing power and the challenge window is 50 blocks, the success rate of the attack is 0.5% (if the monopolist controls 95% of the computing power and the attack success rate is maintained at 0.5%, the window period will increase to 100 blocks). If attackers have to pay a large fine for failed attacks - as the rolluo protocol is designed to do - they will not attack recklessly; and if the fines can be returned to the victims, everyone will be happy to see these failed attacks.

Therefore, the way to deal with dodge attacks is to ensure that the challenge window is long enough so that the probability of attack success is low enough to be acceptable to users; assuming that the attack success rate you can accept is r, and the attacker can control at most f computing power, then the safe challenge window is log(r)/log(f) blocks.

This suggestion is also reasonable in reality; assuming that the attacker can monopolize 99% of the computing power, to ensure that the attack success rate is as low as 0.1%, the challenge window period must be at least equal to log(0.001)/log(0.99) = 687 blocks, which only takes less than three hours for Ethereum.

Interference Attack

In the case of a jamming attack, the attacker uses a traditional denial of service attack to prevent others from issuing challenges; that is, a censorship attack using DoS.

The problem with interference attacks is that the attacker must block "all" possible participants who may submit challenges. If there are enough of these participants, then interference attacks are difficult to succeed. Another bad news for attackers is that other stakeholders may secretly hire monitors - an intermediary who secretly observes the operation of the protocol, intervenes when participants are too late or difficult to issue challenges, and challenges invalid assertions. Attackers have no way to identify these potential monitors and cannot launch DoS against them.

In summary, interference attacks do not seem to be a good choice for attackers.

Quick Attack

A rapid attack is when an attacker publishes so many assertions that others do not have time to check all of them within the challenge window.

Any Rollup protocol needs to have a mechanism to defend against rapid attacks. One way to do this is to limit the frequency of assertions to ensure that at any point in time within the set challenge window, the entire network has sufficient capacity to check pending assertions or challenges.

This type of mechanism will implement a "speed limit" on the processing capacity of smart contracts on a Rollup blockchain - even if there is someone who can make a large number of assertions quickly, he will eventually have to slow down to ensure that other normal participants can keep up.

Therefore, to measure the scalability of a Rollup system, one of the important indicators is its maximum speed limit while ensuring security; the speed limit refers to the rate at which a system can safely process transactions, rather than the maximum rate at which a participant can produce assertions.

Summarize

In summary, there are three types of censorship attacks that can be avoided through reasonable design or practice.

Prevent evasion attacks: Assess the attacker's resources and risk tolerance, and set a reasonable challenge window. Prevent interference attacks: Hire potential monitors yourself (or through a trusted authority) who can challenge you when you make a mistake. Prevent quick attacks: Design the Rollup protocol more carefully.

Censorship attacks on forks are more difficult to analyze because, to some extent, a successful fork attack will leave clear evidence that there is a computing power monopoly on the chain, and these computing power monopolies will be more willing to take other attacks that will gain benefits faster - such as double spending. Any blockchain with computing power monopoly is already terminally ill, so why worry about censorship attacks in this case?

Original URL: https://mp.weixin.qq.com/s/ScOM8pR61p98MolokOFlpA