-
Notifications
You must be signed in to change notification settings - Fork 998
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fork choice upgrade #3290
Fork choice upgrade #3290
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very nice! I mainly had some minor input on style and comments
Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome! great work
## Issue Addressed NA ## Proposed Changes - Implements ethereum/consensus-specs#3290 - Bumps `ef-tests` to [v1.3.0-rc.4](https://github.com/ethereum/consensus-spec-tests/releases/tag/v1.3.0-rc.4). The `CountRealizedFull` concept has been removed and the `--count-unrealized-full` and `--count-unrealized` BN flags now do nothing but log a `WARN` when used. ## Database Migration Debt This PR removes the `best_justified_checkpoint` from fork choice. This field is persisted on-disk and the correct way to go about this would be to make a DB migration to remove the field. However, in this PR I've simply stubbed out the value with a junk value. I've taken this approach because if we're going to do a DB migration I'd love to remove the `Option`s around the justified and finalized checkpoints on `ProtoNode` whilst we're at it. Those options were added in #2822 which was included in Lighthouse v2.1.0. The options were only put there to handle the migration and they've been set to `Some` ever since v2.1.0. There's no reason to keep them as options anymore. I started adding the DB migration to this branch but I started to feel like I was bloating this rather critical PR with nice-to-haves. I've kept the partially-complete migration [over in my repo](https://github.com/paulhauner/lighthouse/tree/fc-pr-18-migration) so we can pick it up after this PR is merged.
The `SAFE_SLOTS_TO_UPDATE_JUSTIFIED` constant is no longer used as the bouncing attack fix was removed: ethereum/consensus-specs#3290 Note: Some test networks still define the constant, ignoring the config constant for now until it is no longer used.
The `SAFE_SLOTS_TO_UPDATE_JUSTIFIED` constant is no longer used as the bouncing attack fix was removed: ethereum/consensus-specs#3290 Note: Some test networks still define the constant, ignoring the config constant for now until it is no longer used.
The `SAFE_SLOTS_TO_UPDATE_JUSTIFIED` constant is no longer used as the bouncing attack fix was removed: ethereum/consensus-specs#3290
The `SAFE_SLOTS_TO_UPDATE_JUSTIFIED` constant is no longer used as the bouncing attack fix was removed: ethereum/consensus-specs#3290 Note: Some test networks still define the constant, ignoring the config constant for now until it is no longer used.
The `SAFE_SLOTS_TO_UPDATE_JUSTIFIED` constant is no longer used as the bouncing attack fix was removed: ethereum/consensus-specs#3290
The `SAFE_SLOTS_TO_UPDATE_JUSTIFIED` constant is no longer used as the bouncing attack fix was removed: ethereum/consensus-specs#3290
) | ||
|
||
# If the previous epoch is justified, the block should be pulled-up. In this case, check that unrealized | ||
# justification is higher than the store and that the voting source is not more than two epochs ago |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you help explain this a bit more? I'm curious about the intuition behind it.
It seems to me that this contradict to the HLMD-GHOST in https://arxiv.org/pdf/2003.03052.pdf
L′ ← set of leaf blocks Bl in G such that (Bj , j) ∈ J(ffgview(Bl))
NA - Implements ethereum/consensus-specs#3290 - Bumps `ef-tests` to [v1.3.0-rc.4](https://github.com/ethereum/consensus-spec-tests/releases/tag/v1.3.0-rc.4). The `CountRealizedFull` concept has been removed and the `--count-unrealized-full` and `--count-unrealized` BN flags now do nothing but log a `WARN` when used. This PR removes the `best_justified_checkpoint` from fork choice. This field is persisted on-disk and the correct way to go about this would be to make a DB migration to remove the field. However, in this PR I've simply stubbed out the value with a junk value. I've taken this approach because if we're going to do a DB migration I'd love to remove the `Option`s around the justified and finalized checkpoints on `ProtoNode` whilst we're at it. Those options were added in sigp#2822 which was included in Lighthouse v2.1.0. The options were only put there to handle the migration and they've been set to `Some` ever since v2.1.0. There's no reason to keep them as options anymore. I started adding the DB migration to this branch but I started to feel like I was bloating this rather critical PR with nice-to-haves. I've kept the partially-complete migration [over in my repo](https://github.com/paulhauner/lighthouse/tree/fc-pr-18-migration) so we can pick it up after this PR is merged.
This PR proposes a large fork choice upgrade, including:
SAFE_SLOTS_TO_UPDATE_JUSTIFIED
mark. A detailed explanation of the issue by @fradamt is attached here. We remove the earlier fix, i.e.,Store.best_justified_checkpoint
andSAFE_SLOTS_TO_UPDATE_JUSTIFIED
, leading to a massive simplification of the fork choice spec.AttesterSlashing
is received. We strengthen this by also censoring validators who are slashed in the state of theStore.justified_checkpoint
.Fork choice test vectors: