Perspective | How to prevent censorship attacks on smart contracts?

In the design of smart contract systems, a common pattern is to require the client to take certain actions before a certain time node; if the client does not respond beyond this time point (for example, a block height), the smart contract Some alternative actions are taken, and are generally detrimental to clients who are out of time. In this article, my focus is on a similar pattern used in interactive rollup protocols- "assertion" is raised by one party, and if others find the assertion problematic, they can raise a challenge within the "challenge window period"; This assertion is considered valid if no challenge is raised during the challenge period.

The problem with this design pattern in practice is censorship attack-the attacker obstructs others from challenging within a time window. In an interactive rollup protocol, an attacker may make false "assertions" while preventing others from launching a challenge during the window period, eventually causing false assertions to become legitimate.

We also assume that the attacker must invest a certain amount of money. Once the attack fails, it will lose the money. In this way, we don't need to make the probability of the system being successfully attacked to zero. No one wants to try to attack the entire system.

In the following, I will summarize my knowledge about censorship attacks and how to combat censorship attacks, and finally give my views on this risk.

Review types of attacks

There are four main types of censorship attacks:

• Online! Wanxiang blockchain public welfare hackathon, waiting for you to solve these real post-epidemic social needs together
• Bitcoin developer: 21 million supply cap is a "religious" belief, we may implement a hard fork of inflation
• Read the Bitcoin Lightning Network Mechanism, Progress and Challenges in One Article

1. Forking: Miners colluded (or were bribed) to abandon the block containing normal challenges, and through fork, made another blockchain that did not contain any challenges accepted.
2. Dodge: The miner conspired (or was bribed) to not pack a normal challenge when producing a block.
3. Disruption: Through traditional denial-of-service attacks (DoS), attackers make it impossible for others to challenge (cannot issue a transaction containing the challenge).
4. Quick Attack: Attackers make a large number of on-chain assertions in a short period of time, leaving others too late to check and challenge all assertions within a time window.

We discuss each one individually.

Fork attack

Fork attacks refer to the proof-of-work (PoW) blockchain, where the attacker obtains most of the mining computing power and uses these computing power to isolate the block containing the challenge as required.

Because this type of attack requires the attacker to control most of the computing power, it is difficult to launch-if the attacker can easily obtain most of the computing power, it means that the blockchain itself has a big problem. Or, to put it another way, a cartel that can control most of the mining power will cause everyone to distrust the blockchain they are on.On the other hand, there may be faster access to the system than censorship attacks Squeeze out the oil and water.

You might say, slow! The computing power monopolist may not make a high-profile publicity, but only sneakily conduct censorship; if the attackers have the ability to do so, they may conduct censorship attacks by forking on the premise of avoiding damage to the reputation of the entire blockchain.

Here comes the first question: Is the censorship attack easy to detect for onlookers? To prove that a fork attack is obvious, I simulated a fork. Assume that the attacker controls 60% of the computing power. In the first thirty blocks, there are three fork chains with lengths of 1, 6, and 5, respectively; this is completely different from ordinary blockchains. I did another simulation. This time the attacker controlled 55% of the hash power. At this time, an earlier fork can be as long as 48 blocks. According to a simple mathematical model prediction, when 60% of the computing power is monopolized, a fork will occur every 2.5 blocks, and the average length of the lone chain caused by the fork is 5; when 55% of the computing power is monopolized, it will be 2.2 blocks. A fork will occur once, and the average length of the isolated chain caused by the fork is 10.

It can be seen that as the computing power of the monopoly decreases, the frequency of forks and the length of the lone chain increase. However, regardless of the length of the forks, they have in common : (the first commonality ): the first on an isolated branch The block must contain a valid challenge, and the branch that eventually becomes the main chain will definitely not contain this challenge-the person who raised the challenge will definitely find it! (Attackers may try to fork further away to avoid the first commonality, but this will cause the branch to be too long, and the final isolated branch still contains 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 computing power monopoly in the blockchain, and the monopolist will use computing power to interfere with the application layer protocol from time to time, I will be very worried. If other people also have such doubts, the entire blockchain will no longer be trusted by users-any 51% hashrate attack will cause this result.

In other words, the problem with this attack is not that someone will review your application-layer transactions, but that the blockchain in which you are located has a monopoly on computing power, and it can break the rules unconstrained for the benefit. For any blockchain application, regardless of whether the TA adopts a window design model, as long as this computing power monopoly appears, it is a devastating blow.

If your blockchain is likely to experience a fork attack, you should consider moving to another blockchain.

Dodge attack

If the computing power monopolist does not use a fork attack that is easy to find, is there any other trick? Some are dodge attacks. As long as the malicious miner refuses to package the transaction that contains the challenge when the block is produced, as long as the block produced during the challenge window is produced by the malicious miner, the attack can be successful.

How likely is a dodge attack to succeed? It can be explained as follows: when the proportion of computing power controlled by the monopolist is f and the challenge window period is n blocks, the attack success rate is f ⁿ . For example, if the monopolist controls 90% of the computing power and the challenge window period is 50 blocks, the attack success rate is 0.5% (if 95% of the computing power is controlled, the attack success rate will remain at 0.5%. The window period is increased to 100 blocks). If attackers pay large penalties for failed attacks–as designed by the rolluo protocol–they will not attack recklessly; and if the fined money is returned to the victims, everyone will be happy to see these attempted attacks.

So the solution to the dodge attack is to ensure that the challenge window period is long enough so that the probability of successful attack is low to a range acceptable to the user; assuming that your acceptable attack success rate is r and the attacker can control the computing power of f at most, it is safe The challenge window period 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 districts Blocks take less than three hours for Ethereum.

Jamming attack

In the case of an interference attack, the attacker uses "traditional denial of service attacks" to stop others from challenging; that is, "censorship attacks with DoS."

The problem with jamming attacks is that the attacker must block " all " the parties who may submit a challenge, and if there are enough of these parties, the jamming attack will be difficult to succeed.

The bad news for an attacker is that other stakeholders may secretly hire a watcher-an intermediary who secretly observes the operation of the protocol, intervenes when participants are too late or difficult to challenge, and challenges invalid assertions. . Attackers have no way to identify these latent monitors, and no way to launch DoS against them.

In summary, for attackers, jamming attacks does not seem to be a good choice.

Quick attack

Quick attack means that the attacker issues a large number of assertions, making it too late for others to check all the assertions during the challenge window.

Any rollup protocol needs a defense against fast attack. One of the methods is to limit the frequency of assertions to ensure that the protocol has sufficient capacity to check the network at any time during the set challenge window period. Assertion or challenge handled.

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

So to measure the scalability of a rollup system, one of the very important indicators is its maximum speed limit under the premise of ensuring security; the speed limit refers to the rate at which a system can safely process transactions, not a participant Ability to produce asserted limit rates.

to sum up

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

• Prevent dodging attacks: Assess the resources and risk tolerance of the attackers and develop a reasonable challenge window.
• Prevent jamming attacks: Employ (or hire through a trusted authority) latent monitors. These monitors can challenge you when you travel.
• Guard against quick breaks: Design rollup protocols in more detail.

Censorship attacks on fork types are difficult to analyze; because to a certain extent, successful fork attacks leave clear evidence that there are computing power monopolies on the chain, and these computing power monopolies will be more willing Take other attacks that pay off faster-such as double spend. Any blockchain with a computing power monopoly is already ill, so why bother with censorship attacks in this case?

(Finish)

Original link: https://medium.com/offchainlabs/fighting-censorship-attacks-on-smart-contracts-c026a7c0ff02 Author: Ed Felten translation & proofreading: IAN LIU & A sword

This article was authored by the author for translation and republishing by EthFans.

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