Abstract
We present a liveness attack on the Ethereum protocol that the adversary can build the canonical chain that includes only blocks from the adversary, which cause liveness failure. In the attack, the adversary can controls the proposer duty of each epoch by carefully constructing RANDAO.
Details of attack
Assumption.
We assume that the epoch of latest justified checkpoint is epoch 0. The proposer in the first slot of epoch 1 and epoch 2 is Byzantine. The stake of adversary is one-third of the total stake. We assume the attestations from Byzantine validators are withheld and never broadcast.
Epoch 1.
- At the first slot of epoch 1, the Byzantine proposer delays its block b_1 for 8 seconds. As a result, the target of the attestations from honest validators in the first slot is not b_1. All Byzantine attestors in the first slot vote for the delayed block b_1. As a result, the delayed block will not be reorganized by an honest validator even the honest reorg mechanism exists. In the rest slots of epoch 1, block b_1 is in the canonical chain. The target of the attestations from honest validators in the rest slots of epoch 1 is block b_1. As a results, the number of attestations from honest validators with the same target and source is least than two-thirds. This means, as the attestations from Byzantine attestors are all withheld, the canonical chain can includes enough attestations to justify epoch 1.
- The blocks from adversary extends block b_1 and build a private chain. The private chain includes the attestations from honest attestors and Byzantine attestors. Therefore, once the private chain is released, the private chain can update justified epoch to epoch 1.
Epoch 2.
- At the first slot of epoch 2, the adversary conducts the same actions as step 1 in epoch 1. As a result, the canonical chain can not includes enough attestations to justify epoch 2.
- The blocks from adversary extends the private chain. Comparing with step 2 in epoch 1, the adversary carefully selects blocks from the adversary that extends the private chain. The RANDAO of the private chain at the end of epoch 2 must guarantee that the proposer in the first slot of epoch 4 is adversary. This is easy since there are \lfloor2^{32/3}\rfloor possible RANDAOs and the probability that the proposer in the first slot of epoch 4 is adversary is 1/3.
Epoch 3.
- The blocks from adversary extends the private chain. The block selection rule is the same as step 2 in epoch 2.
- At the beginning of the last slot, the adversary released the private chain. As the attestations from the honest attestors in the last slot of epoch 3 is not released, the canonical chain can not includes enough attestations to justify epoch 3. Therefore, the justified epoch in canonical chain is epoch 0. After the private chain is released, the epoch of latest justified checkpoint is updated to 1. According to the filtering rule, the canonical chain is pruned, and the private chain becomes the new canonical chain.
# The voting source should be either at the same height as the store's justified checkpoint or
# not more than two epochs ago
correct_justified = (
store.justified_checkpoint.epoch == GENESIS_EPOCH
or voting_source.epoch == store.justified_checkpoint.epoch
or voting_source.epoch + 2 >= current_epoch
)
Epoch 4.
The RANDAO of the private chain at the end of epoch 2 guarantees that the proposer in the first slot of epoch 4 is adversary. The adversary can conducts the same steps as epoch 1.
Epoch 5.
Same as epoch 4, the RANDAO of the private chain at the end of epoch 3 guarantees that the proposer in the first slot of epoch 5 is adversary. The adversary can conducts the same steps as epoch 2.
Epoch 6…
Repeat steps in epochs 3,4,5.
Analysis
Once the attack starts, the adversary create a canonical chain that only includes the blocks from Byzantine validators. That means, the adversary can choose which transactions can be included in the canonical chain, which violates the liveness property.
Mitigation
As the liveness attack is one kind of reorganization attack, the attack can be fully prevented using AA, which is a reorg-resilient solution for Ethereum PoS. Our approach is accepted in USENIX Security 2025 (eprint).