51% of attacks will increase the value of ETH? See how Vitalik explains the security of Casper FFG

In response to the security of the Casper FFG Consensus Agreement, Ethereum co-founder Vitalik wrote:

“(Note: After the application of the Casper FFG Consensus Agreement in Ethereum), in either case, 51% of the attacks are a happy moment for the (Ethereum) community, because it wants to cause 1 day or 1 week of damage, The ETH that the attacker is consuming will be at the expense of total annual production, which in turn will increase the value of ETH, making future attacks more expensive."

The following is the translation:

• How much does Tether make?
• Report Extract | CICC Research: Blockchain has entered the 3.0 era
• Getting started with blockchain | How many people hold or use cryptocurrencies?

The cost of performing a 51% attack on a consensus system is large, but it is not unlimited, so the risk of a 51% attack is always there. In addition, if the attack is successful, it is very difficult and often impossible to achieve recovery within the "protocol." In a Proof of Work (PoW) system, a successful 51% attack is profitable, so attacks can be looped indefinitely, and attacks against ASIC Work Proof (PoW) systems can become cheaper. In a Proof of Entitlement (PoS) system, a successful 51% attack can block new deposits.

These facts tell us that there must be a coherent strategy to deal with 51% of attacks, so that the chain can resume normal operation. This strategy is not used often, and its existence may be sufficient to stop the attack, so its existence is needed. As we will see, deposit-based PoS is highly secure to a certain extent, because any 51% of attacks will result in extremely high economic losses for attackers.

Final deterministic reversal attack

Finality reversion is by far the most talked about 51% of attacks, and in PoS systems, this is the most vulnerable type of attack.

The reason that is easy to handle is that it is the original intention of the Casper FFG's “economic finality” mechanism: the whole point of BFT's final certainty is that to finalize two conflicting blocks, there must be an a ≥ 1/ 3 ∗ |V| Intersecting the set of interpreters ( |V| as the size of the active verifier set) signed two conflicting messages, so slash operations can be performed on both chains.

Note that the client-implemented fork selection rule prevents reversal of completed blocks. Therefore, if in the above scenario, the above chain is completed before the chain below, the online client will stay on the chain above. Only the offline client will see two alternative chains when it returns online. Therefore, the offline client needs to contact the community (or " social layer " or " additional protocol recovery ") to ask which chain is legal. We call this a minor extra-protocol burden : online nodes have a natural and correct choice, and only a few nodes need to ask for consensus.

The more difficult situation is that both chains are completed at the same time: unless the attacker can seriously manipulate the network (of course it is possible!), a successful attack needs to control more than 1/3 ∗ |V|, at least 1/2 ∗ |V| It may even take 2/3 ∗ |V| to make it less likely. In addition, the client waits for 1 minute after a block is completed, and then displays the transactions in the block as completed, which will greatly reduce the usefulness of such attacks in actually performing a double-flower attack. However, this double-final attack can still be used to cause confusion.

The easiest way to recover from this attack: the user chooses a chain that supports the LMD GHOST fork rule, considering only the certifiers who are not penalized. However, in a boundary case, Chain A wins the LMD GHOST fork selection rule, but Chain B is completed earlier, which leads to the inability to determine which chain should dominate.

Therefore, an attacker who is willing and able to complete both chains at the same time can ask the community to come together and choose one chain or another chain (we can call it a major extra-protocol burden ). , although the cost is very high for the attacker.

In either case, the verifier that the attacker was fined should be ≥ 1/3 ∗ |V|, which would result in penalties for millions of Ethereum. As a result, an attacker could interrupt a transaction and ask the community to negotiate and let the user manually update its client, but the cost would be extremely high, making this type of attack very difficult and rare.

Certifier review attack

Another, more difficult 51% attack is to review the attack. Transaction review is not a big deal because we assume that eventually a friendly verifier will package any given transaction into a block. Instead, we are more concerned with the review of the verifier. The certifier's review may have many reasons, and the two most likely reasons are (i) reviewing the certifiers who refused to cooperate, and (ii) discoragement attacks .

The review is even more tricky because there is no “no penalty condition” to detect it: the essence of the review is that it does not contain the behavior you want to contain information. In fact, from the perspective of any certifier or client that is not online, A reviews B, and B is not indistinguishable from A conversations (this is sometimes referred to as speaker-observer fault equivalent), to learn about For more information on this, please see https://vitalik.ca/general/2017/07/16/triangle_of_harm.html

However, online nodes can detect censorship, so the challenge we face is to deal with “border conditions” and to determine when the review is bad enough to intervene outside the agreement and address the challenges of inevitable boundary conditions. is worth it.

Let us distinguish between two cases: first, the review set is greater than 1/3 ∗ |V|, that is, between 1/2 and 2/3 certifiers are reviewing another part, and these certifiers cannot include it The place where the message is created establishes a chain. Because less than 2/3 of the verifiers are on the same chain, no blocks will be finalized. In the attacker's chain, the attacker does not lose any money (but does not receive any return), but the victim will lose. Most of their deposits.

The victim’s only channel of help is a “minority soft fork” , which then blacklists the censorship chain and continues to work on its own chain. This "minority soft fork" can be automated: if a chain does not accept your proof, its priority will be automatically canceled in the fork selection, and eventually it will no longer appear to be dominant.

The attacker will not be able to join the two chains, because in each epoch cycle, each verifier can only choose one chain to participate, otherwise they will be fined. Eventually, both fork chains will complete a block and return to normal, and on a few chains, the attacker will lose a large portion (at least half) of its deposit.

A clever minority group can even wait until the attacker's chain proves a new block. Then, the minority can start building their own chain. If they do, the attacker will not accept the NO_SURROUND condition. Unable to join the minority chain.

And if the attacker does not join the minority chain, they will lose about half of the deposit.

Now let's consider the second case, which will be milder. The attacker needs to control the 2/3 ∗ |V| verifier set and review the remaining <1/3 ∗ |V| certifier set, or the attacker performs the above attack, but in a more modest manner (every ten zones) The block completes an attack). In this case, there are two solutions. First, try to coordinate external token holders to join and unpack the certifier. If the attack chain rejects their deposit, then this fact will be visible to everyone and will collapse into the same scenario as the previous case. Second, the minority soft fork can still be coordinated to prevent attackers from using the above techniques to join the minority chain.

Please note that both techniques rely on some form of coordination between honestly few people to determine what the chain is worth pulling. One can simply rely on the social layer to achieve this, even if the community layer makes decisions that are not conducive to the attacker, the cost of the attack in the expectation will become high.

In addition, we can imagine creating tools to assist in coordination. A simple example is the 99% fault-tolerant consensus proposal presented here: https://vitalik.ca/general/2018/08/07/99_fault_tolerant.html, which creates a consensus between online nodes with fairly low network latency.

to sum up

In the event of a final deterministic reversal attack, we already know that an attacker may be fined, so an attack can be very expensive (the penalty will be millions of ETHs). Attempts to control the creation of blocks in order to continue the additional protocol coordination attacks on which chain after the attack are even more costly. In contrast, reviewing attacks can be more challenging, because if the community doesn't respond, they will “default” success and cause harm (although the client can implement a chain of refusals that seem to be excessive), and the attack can be negotiated. Outside the "minority soft fork" consensus resolved, the "minority soft fork" cleverly used the NO_SURROUND condition, focusing on the chain that the attacker could not legally join.

In either case, the 51% attack is a happy time for the (Ethereum) community, because the ETH that will be consumed by the attacker will be at the cost of the total annual output because of the one or one week of damage. This, in turn, increases the value of ETH, making future attacks more expensive. In addition, this can be resolved by a soft fork or fork selection rule function without the need for a hard fork to manually remove the attacker's currency.

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