Research on Layer 2 protocol review attack, Vitalik claims to synchronize 99% fault-tolerant consensus or solution

Translator's Foreword: Recently, blockchain researcher Ryuya Nakamura and others proposed a censorship attack strategy for the Layer 2 protocol. They believe that this attack is difficult to identify, and even if users recover through a soft fork, they cannot. Punish attackers without punishing honest verifiers.

Other researchers from the Ethereum research community have suggested that the theoretical cost of implementing this attack is very high, so it is not realistic to implement it. In this regard, Ethereum founder Vitalik also expressed his views.

(Picture from: pexels.com)

• Opinion ｜ Do n’t forget the “initial intention” of the blockchain, we have widely adopted “always”
• Zhu Jiaming: The biggest area of ​​blockchain application is finance, which will bring significant innovation to double-entry bookkeeping
• The market has suddenly risen sharply. Is it a staged rebound at the bottom?

The following is the specific content of the attack strategy and the discussions among researchers:

Ryuya Nakamura: We have proposed an attack strategy that reviews specific transactions (such as the fraud proof in the Layer 2 protocol), and it can be difficult to identify the attacker.

Even if the user can recover from the attack through a community-coordinated soft / hard fork, we cannot punish the attacker without punishing the honest verifier.

background

The security of Layer 2 protocols based on fraud proofs (such as Plasma, Optimistic Rollup, and status channels) depends on the following assumptions: If the operator / participant claims invalid out-of-chain status, the fraud proof can be submitted to the chain within a predefined period And include it in the chain (footnote 1). Recently, the security of these protocols was suggested by @ gluk64 and then discussed on Twitter and ethresear.ch .

Roughly speaking, an attacker can use 51% attacks in such a Layer 2 structure to review fraud proofs in order to achieve profit, making the entire system (including Layer 1) incompatible with incentives, especially because the rewards in the agreement compensate for Cost of an attacker running a validator (footnote 2)

The main countermeasures are:

1. We can increase the cost of such censorship attacks through " anti-DoS attacks ". (See comment by @adlerjohn)

TL; DR: In Ethereum's smart contract model, if you don't actually execute the transaction, you don't know which contracts were called when the transaction was executed, so you can send a bunch of transactions to the attacker to conduct a DoS attack on the review;

2. We can recover from the attack through a soft fork, or we can "eliminate" the attacker's rights in the PoS chain. (See @ vbuterin's comment )

In this article, we describe a new censorship attack strategy. None of the above strategies can solve this attack. This strategy is applicable to any transaction other than the fraud proof in the Layer 2 protocol.

Description of the attack

We assume a PoS system, such as the Ethereum 2.0 beacon chain (footnote 3), where the block proposer creates a block, and the validator committee votes for a block in each slot cycle (6 seconds). Interpreted as Casper FFG vote to determine block. We expect similar strategies to apply to other consensus protocols or PoW systems.

Attacker's ability

In this article, we assume that an attacker controls most of the equity (for example, 55%). Because such an attacker controls more than 1/3 of the votes, Casper FFG cannot complete the blocks that the attacker does not like.

Attacker's strategy

1. If the main chain does not contain proof of fraud, the attacker will vote for the main chain .

2. If the main chain contains a fraud certificate, the attacker will create a conflict chain and vote for it to fork the fraud certificate .

2.1 A few validators of the attacker will vote for the chain containing the fraud proof . (These are actually "alibi votes" , which make the attacker's validator behave like an honest validator. In addition, the number of "fake votes" must be small enough (such as 5% of the number of slot votes) ), So that the block cannot win in the fork choice)

An attacker chooses one of the following with a certain probability when creating a block.

3. Create a block without fraud proof, which is full of transactions made by the attacker (for example, transactions that transfer tokens between accounts controlled by the attacker) (footnote 4)

4. Create a block containing proof of fraud and self-made transactions .

4.1 The attacker will publish this block immediately after the next block is released, so that most honest validators will not vote for the block; 4. 2 The attacker will post a "disguise" vote for the block (Such as 40% of slot votes);

In addition, attackers have a strategy that encourages honest validators to create blocks without proof of fraud.

5. Attackers often broadcast their self-made transactions at high fees ;

Why attackers are safe

Resisting "Anti-DoS Attacks"

When an attacker creates a block, he does not include any transactions created by others. Therefore, the attacker only verifies the transactions contained in the honest verifier block (requires a full node), so the attacker will not suffer the above-mentioned DoS attack.

Undetectability of attacks

In the strategies mentioned above, the attacker does not generate vague or invalid messages. The difference between an attacker and an honest verifier is simply how they create, publish, and vote for a block that contains fraud proofs . To reduce the difference in vote rates for creating blocks with fraudulent proofs, the attackers added "masquerading" (policies 2.1 and 4.2) and reduced the number of honest verifiers voting on fraudulent proofs created by the attackers (policy 4.1).

In addition, strategies 2 and 4.1 take advantage of the characteristics of distributed systems, that is, liveness failures cannot be fundamentally distinguished from network failures. In addition, there will be various network layer attacks through which the attacker can delay the blocks and votes of the honest verifier, making the honest verifier look similar to the attacker.

Therefore, although we must improve our strategy (for example, by parameterizing the attacker's stake, network conditions) to make these arguments more formal, we speculate that it is difficult to identify the attacker's without making false accusations. Validator.

Punish attackers with soft and hard forks

If users coordinate a soft fork to recover from a review transaction, the attacker can quickly join the new chain to avoid being detected or suffering any penalty for failure to liveness. Because it is difficult for the user to determine who the attacker is, what we can do is to use a concept similar to "penalize both parties" to punish honest questioners while punishing all suspicious ones.

mortgage

One way to ensure that only the attacker is punished is to force anyone to make a deposit to become the operator or participating channel of Plasma / Opistic Rollup, and to confiscate the collateral by fraudulent certification.

If we assume that a community-coordinated soft fork is likely to succeed and that the collateral is sufficient, then such a Layer 2 protocol may achieve incentive compatibility while weighing higher barriers to entry. If we want to avoid excessive penalties for fraud due to honest mistakes , in which case fraud proofs can be submitted without review, we can limit the default amount of punishment, and In situations, we can use hard forks to punish attackers heavily.

footnote

1. OTOH, fraudulent proof of invalid state root in shard invalidates the chain and is not included in the chain. This article presents a clever trick;
2. Note that an attacker can benefit not only from a single Layer 2 construct, but also from multiple Layer 2 constructs simultaneously. This is why setting an upper limit on the value of off-chain assets does not solve this problem;
3. In Ethereum 2.0, the Layer 2 system will be deployed on the shard chain instead of the beacon chain, so the best attack strategy may be different. We leave it for later discussion;
4. The cost of such self-made transactions will be owned by the attacker;

Discussion in the Ethereum Research Community

Regarding the attack strategy proposed by nrryuya, John Adler, a ConsenSys blockchain researcher and optimistic rollup creator, replied:

"First, the cost of such an attack is not zero.

By estimation, to implement such a protocol attack, the attacker needs to have about 3 million ETH, or about 450 million US dollars.

Secondly (and more importantly), your voting strategy is wrong. Creating a block is not part of the voting strategy, but part of the block creation strategy. The leader (block proposer) of each slot is known, at least in Casper 2.0. It is not possible to have multiple block proposers in a slot, so the attacker's block will be easily discarded.

" Subsequently, Alex Gluchowski (gluk64), a partner of Matter Labs, replied:

"Yes, this strategy may not work because fraud proof gas prices can be set incredibly high. However, this kind of attack is feasible without subsidizing fraud proof blocks, which is the most Important. All an attacker needs is "disguise."

The ability to disguise is the most important result of this research.

Miners are selfish and proactive, and once they realize that blocks with fraudulent proof are always rejected, many people will naturally introduce censorship policies to avoid losses. Especially if this behavior is a) imperceptible (with camouflage) and b) incentivized by swag futures.

" Soon, this discussion also caught the attention of Ethereum founder Vitalik Buterin, who replied:

"I know @vladzamfir is working on a subjective 'CBC review detection' system that proposes a synchrony hypothesis (all review detections obviously have to rely on synchronization because review is indistinguishable from a sufficiently high latency), which allows The validator detects who is reviewing and forms a cluster, where if most people are reviewing, a few can find each other and build on each other's block. I wonder if it ends up similar to https://vitalik.ca/ general / 2018/08/07 / 99_fault_tolerance.html ; it is possible that technology similar to Lamport's synchronous 99% fault-tolerant consensus will eventually become a mandatory solution for automatic rejection of the censorship chain. "

For more discussion, readers can visit the original post: https://ethresear.ch/t/undetectable-censorship-attack-on-fraud-proof-based-layer2-protocols/6492

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