github/upgrading-ethereum-book
1
1
Fork 0
mirror of https://github.com/benjaminion/upgrading-ethereum-book.git synced 2026-01-09 14:38:08 -05:00
Code Issues Packages Projects Releases Wiki Activity

Catalogue another fork choice issue

Browse Source
This commit is contained in:
Ben Edgington
2025-03-19 13:37:38 +00:00
parent f20580309c
commit 24dee0e315
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/book.md
View File

@@ -12544,6 +12544,8 @@ In August 2019, a "decoy flip-flop attack" on LMD GHOST [was identified](https:/
In September 2019 a "bouncing attack" on Casper FFG [was identified](https://ethresear.ch/t/analysis-of-bouncing-attack-on-ffg/6113?u=benjaminion) that can delay finalisation indefinitely. Up to the Capella spec release we had [a fix](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114?u=benjaminion) for this that only allowed the fork choice's justified checkpoint to be updated during the early part of an epoch. The fix was removed in the Capella upgrade since it adds significant complexity to the fork choice, and in any case can be [worked around](https://notes.ethereum.org/@fradamt/Sy6PzcRdt) by splitting honest validators' views. The bouncing attack is very difficult to set up and an adversary with the power to do this could probably attack the chain in more interesting ways. The bouncing attack and its original fix remain documented in the [Bellatrix edition](/../bellatrix/part3/forkchoice/phase0/#the-bouncing-attack).
Around November 2019 [it became apparent that](https://notes.ethereum.org/Fj-gVkOSTpOyUx-zkWjuwg?view), in order to properly apply Casper FFG to LMD GHOST, it is necessary to filter "unviable branches" from the fork choice. This is discussed in detail in the section, [Why prune unviable branches?](/part3/forkchoice/phase0/#why-prune-unviable-branches)
In July 2021, an edge case [was identified](https://notes.ethereum.org/@hww/fork-choice-store-inconsistency) in which (if 1/3 of validators were prepared to be slashed) the invariant that the store's justified checkpoint must be a descendant of the finalised checkpoint could become violated. [A fix](https://github.com/ethereum/consensus-specs/pull/2518) to the [`on_tick()`](/part3/forkchoice/phase0/#on_tick) handler was implemented to maintain the invariant.
In November 2021, some overly complicated logic [was identified](https://notes.ethereum.org/@djrtwo/S1ZGAXhwK) in the [`on_block()`](/part3/forkchoice/phase0/#on_block) handler that could lead to the Store retaining inconsistent finalised and justified checkpoints, which would in turn cause [`filter_block_tree()`](/part3/forkchoice/phase0/#filter_block_tree) to fail. Over one third of validators would have had to be slashed to trigger the fault, but the [resulting fix](https://github.com/ethereum/consensus-specs/pull/2727) turned out to be a nice simplification in any case.
@@ -12552,7 +12554,7 @@ In November 2021, some overly complicated logic [was identified](https://notes.e
A [new type](https://ethresear.ch/t/balancing-attack-lmd-edition/11853?u=benjaminion) of balancing attack was published in January 2022 that relies on the attacker's validators making equivocating attestations (multiple different attestations at the same slot). To counter this, a [defence against equivocating indices](https://github.com/ethereum/consensus-specs/pull/2845) was added in March 2022. We'll discuss this when we get to the [`on_attester_slashing()`](/part3/forkchoice/phase0/#equivocation_balancing_attack) handler. This defence was bolstered in the Capella spec update by excluding all slashed validators from having an influence in the fork choice.
Several issues involving "unrealised justfication" were discovered during the first half of 2022. First, an [unrealised justification reorg](https://notes.ethereum.org/@adiasg/unrealized-justification) attack that allowed the proposer of the first block of an epoch to easily fork out up to nine blocks from the end of the previous epoch. A variant of that attack was also found to be able to cause validators to make slashable attestations. Second, a [justification withholding attack](https://hackmd.io/o9tGPQL2Q4iH3Mg7Mma9wQ) that an adversary could use to reorg arbitrary numbers of blocks at the start of an epoch. These issues were addressed in the Capella spec update with the "pull up tips" and [unrealised justification logic](/part3/forkchoice/phase0/#unrealised-justification) that it introduced.
Several issues involving "unrealised justfication" were discovered during the first half of 2022, arising from the November 2019 fixes to filter viable blocks. First, an [unrealised justification reorg](https://notes.ethereum.org/@adiasg/unrealized-justification) attack that allowed the proposer of the first block of an epoch to easily fork out up to nine blocks from the end of the previous epoch. A variant of that attack was also found to be able to cause validators to make slashable attestations. Second, a [justification withholding attack](https://hackmd.io/o9tGPQL2Q4iH3Mg7Mma9wQ) that an adversary could use to reorg arbitrary numbers of blocks at the start of an epoch. These issues were addressed in the Capella spec update with the "pull up tips" and [unrealised justification logic](/part3/forkchoice/phase0/#unrealised-justification) that it introduced.
A reader might infer from this catalogue of issues that the fork choice is fiendishly difficult to reason about, and the reader would not be wrong. Some long-overdue [formal verification](/part3/forkchoice/phase0/#formal-proofs) work on the fork choice rule has recently been completed. It seeks to prove certain desirable properties, such as that an honest validator following the rules can never make slashable attestations.