Skip to content

Implement weak subjectivity safety checks #7347

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

Open
wants to merge 8 commits into
base: unstable
Choose a base branch
from

Conversation

eserilev
Copy link
Collaborator

Issue Addressed

Closes #7273

Proposed Changes

ethereum/consensus-specs#4179

@eserilev
Copy link
Collaborator Author

hey @dapplion when you have a chance, could you take a look at what I have so far?

The general flow is

  • user sets the weak subjectivity period checkpoint via the existing wss-checkpoint flag
  • on startup, we make the weak subjectivity calculation, using the user provided ws checkpoint, the head snapshot and the most recent finalized checkpoint

If the user doesn't set a weak subjectivity checkpoint, what are we supposed to do here?

@eserilev eserilev added electra Required for the Electra/Prague fork enhancement New feature or request work-in-progress PR is a work-in-progress labels Apr 22, 2025
}

let Ok(ws_period) = finalized_state.compute_weak_subjectivity_period(&self.spec) else {
// TODO(ws) failed to calculate ws period, log and continue?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this should never fail propagate the error and abort start

let Ok(finalized_block) = fork_choice.get_finalized_block() else {
panic!("TODO(ws)")
};
if !store.is_within_weak_subjectivity_period(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just use the head_snapshot.beacon_state to compute the weak subjectivity period. You don't need to fetch the head state's finalize state. For WS sync, the head state = the weak subjectivity checkpoint state. You don't need to fetch any more data:

  • compute ws_period from head state
  • get current epoch from clock
  • check current_epoch <= head_state.epoch + ws_period

No need to involve the store here

.safe_div(balance_churn_limit.safe_mul(200)?)?;
let weak_subjectivity_period = spec
.min_validator_withdrawability_delay
.safe_mul(epochs_for_validator_set_churn)?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

@eserilev eserilev Apr 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm using the updated forumla for electra

https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/weak-subjectivity.md#modified-compute_weak_subjectivity_period

I think the calc is simpler now that top ups are part of activation churn

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, please link it

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah but we probably need to support the pre-electra calculation as well

@dapplion
Copy link
Collaborator

If the user doesn't set a weak subjectivity checkpoint, what are we supposed to do here?

We should assert that the initial state is within the weak subjectivity period on any type of start.

We should also offer a flag such that

  • If flag set and starting from outside weak subjectivity period: big warn log, continue start
  • If flag not set and starting from outside weak subjectivity period: error, abort start

}
return Err(
"The current head state is outside the weak subjectivity period. It is highly recommended to purge your db and \
checkpoint sync. Alternatively you can accept the risks and ignore this error with the --ignore-ws-check flag.".to_string()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should either summarize "the risks" or link to some resource of our own. Otherwise it's quite opaque to the users.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i've summarized the risks and linked to a blog post by vitalik

@eserilev eserilev added ready-for-review The code is ready for review and removed work-in-progress PR is a work-in-progress labels Apr 24, 2025
@eserilev
Copy link
Collaborator Author

Thanks for all the help Lion. I've made changes based on your feedback and added additional test coverage

Copy link
Collaborator

@dapplion dapplion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
electra Required for the Electra/Prague fork enhancement New feature or request ready-for-review The code is ready for review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants