Bouncing Attack in Proof of Stake

Published by Mario Oettler on

A bouncing attack exploits the inconsistency between the fork choice rule and the latest justified checkpoint. This attack was described for the Casper FFG mechanism of Ethereum 2.0.

More information on how Casper FFG works can be found here:

The bouncing attack is described here:

The Basic Setup

Suppose there are two branches A and B. Under the fork choice rule LMD branch A wins. But for some reason, B got 60 % of the votes. A validator that controls 7 % of the votes he withheld in a previous epoch can cause a reorg to B at any time.

How Bouncing Works

Bouncing describes the behavior that if there are two branches A and B, an attacker can influence the network that the justifiable block (or checkpoint) switches between A and B back and forth.

Suppose we have 100 voters. The attacker controls 10 of these votes. After a fork, we have the following situation: Block A1 in Branch A gets 70 votes and branch B 30. Block A1 is a justified (but not finalized) checkpoint.

The fork choice is on branch A since it has the latest justified, checkpoint and the head of the chain is block A2.

But for some reason, the votes in the following epoch are 30 votes for block A2 and 60 votes for block B2. This can be caused by a high latency in the network. The attacker can now withhold his votes.

The head A3 would now gain votes, whereas block B3 gains no votes since it is not the head of the chain.

Once A3 receives enough votes that the attacker can make this block a justified block, but not enough to be a justified block (< 2/3) the attacker publishes its votes on block B2. Since block B2 now has the supermajority, this block becomes justified and the fork choice switches to B.

Now, the process repeats. Block B3 becomes the new head of the chain and gains votes until it is just a bit short of 2/3 of all votes. Then, the attacker publishes his votes for block A3 to justify it.

This prevents the system from finalization.

Categories:

if()