Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains a security fix for the finality delay attack outlined in this paper.
Finality Delay Attack
The execution of the attack involves temporary block withholding by the first few proposers in the epoch. At the end of the last withholding proposer's slot, all blocks are released. During slots in which blocks were withheld, honest attesters make FFG target votes for the last block of the previous epoch (which is "pulled up" to serve as the FFG checkpoint for the current epoch). After the blocks have been released, honest attesters make FFG target votes for the first block of the current epoch.
During each slot,
1 / SLOTS_PER_EPOCH
(= 3.125%
) fraction of stake is attesting. So a 25% attacker needs to control the first 3 slots (= ceil((33.33 - 25) / 3.125)
) of an epoch to successfully delay finality at the end of that epoch.A brief description from the original paper:
The attack is possible because the fork choice allows for updating the head block, without any reorgs, in the following situation:
This happens because the fork choice only calculates the LMD GHOST winner based on the support for each individual block. This PR prevents the attack by changing the block tree structure, and by also taking into account the support for the FFG target pointed to by each block.
For example, the below block hierarchy will be transformed into a block tree in the following manner:
Summary of Changes
BlockTreeNode
&add_block_tree_node
)LatestMessage
AccountingLatestMessage
in the spirit of the attack fix. (Refer:get_latest_attesting_balance
)on_block
&on_attestation
functions.