Skip to content

Deprecate some reorg-related CLI flags and read from spec#9177

Open
chong-he wants to merge 25 commits intosigp:unstablefrom
chong-he:cli-flags-reconcile
Open

Deprecate some reorg-related CLI flags and read from spec#9177
chong-he wants to merge 25 commits intosigp:unstablefrom
chong-he:cli-flags-reconcile

Conversation

@chong-he
Copy link
Copy Markdown
Member

Issue Addressed

Additional Info

Please provide any additional information. For example, future considerations
or information useful for reviewers.

@chong-he chong-he marked this pull request as draft April 27, 2026 04:26
Copy link
Copy Markdown
Member Author

@chong-he chong-he left a comment

Choose a reason for hiding this comment

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

Some self-review comments for the reviewers

Comment on lines +134 to +136
re_org_head_threshold: Some(ReOrgThreshold(20)),
re_org_parent_threshold: Some(ReOrgThreshold(160)),
re_org_max_epochs_since_finalization: Epoch::new(2),
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Not sure if it is a good idea to hard code like this for the default config? The reason is I want to get rid of the definitions of DEFAULT_RE_ORG_HEAD_THRESHOLD etc, so that we can use the spec value as the single source of truth (i.e., in testing/ef_tests/src/cases/fork_choice.rs)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think we should actually remove these fields from the ChainConfig entirely, so that we are forced to always read them from the ChainSpec

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Thanks for the great feedback, I have revised.

Comment thread beacon_node/beacon_chain/src/builder.rs Outdated
Comment thread beacon_node/src/cli.rs
Comment on lines 1318 to 1320
.arg(
Arg::new("proposer-reorg-cutoff")
.long("proposer-reorg-cutoff")
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

There is a proposer_reorg_cutoff_bps in the spec:

proposer_reorg_cutoff_bps: 1667,

but I think they are referring to different things (the proposer_reorg_cutoff_bps is a pretty newly defined field in the spec) while the proposer-reorg-cutoff CLI flag in Lighthouse is something that has exited for quite some time

So I am leaving this flag unchanged

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We can get rid of this one as well. We should switch Lighthouse to using the BPS one (might need some changes to our calculations)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Might need a new method on SlotClock for this (look at the other BPS values to see how we do it)

Copy link
Copy Markdown
Member Author

@chong-he chong-he May 4, 2026

Choose a reason for hiding this comment

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

Revised.

I am not too sure about the use of: Arc::make_mut(&mut spec).reorg_head_weight_threshold to modify the spec in config.rs which requires changes the spec to mut (current it's not mutable in config.rs)

If this works, then currently Lighthouse defaults to re-org at <= 1s, but after the change, it reads from the spec which defaults to re-org at <= 2s. Might be worth mentioning in the next release notes?

@chong-he chong-he marked this pull request as ready for review April 27, 2026 12:57
@chong-he chong-he added ready-for-review The code is ready for review backwards-incompat Backwards-incompatible API change labels Apr 27, 2026
Comment thread beacon_node/beacon_chain/src/builder.rs Outdated
}

/// Sets the proposer parent re-org threshold
pub fn proposer_re_org_parent_threshold(mut self, threshold: Option<ReOrgThreshold>) -> Self {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

When we remove the chain config we will also remove these mutators (for tests we can set custom values on the spec).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Removed the function

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

can probably inject the config values into the spec here (and can remove TTD)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I found that the test already uses: let spec = ForkName::Fulu.make_genesis_spec(E::default_spec());
which is the default_spec, which will read from chain_spec.rs. So I believe this is covered by the default spec, i.e., we don't need to mut the spec and do something like: spec.reorg_xx....

@michaelsproul michaelsproul added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Apr 30, 2026
Comment thread beacon_node/src/cli.rs
.display_order(0)
)
.arg(
Arg::new("proposer-reorg-threshold")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We should maybe keep these with a deprecation warning for now, and then can remove in v9.0.0

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Added a deprecated note in the help text output

@chong-he chong-he added ready-for-review The code is ready for review and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels May 4, 2026
Comment on lines +210 to +214
let slot_duration_millis = self.spec.get_slot_duration().as_millis() as u64;
let re_org_cutoff_millis = slot_duration_millis
.saturating_mul(self.spec.proposer_reorg_cutoff_bps)
.saturating_div(BASIS_POINTS);
let re_org_cutoff_duration = Duration::from_millis(re_org_cutoff_millis);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We can use spec.compute_slot_component_duration(self.spec.proposer_reorg_cutoff_bps) to simplify this a little

@@ -3,13 +3,8 @@ pub use proto_array::{DisallowedReOrgOffsets, ReOrgThreshold};
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Should probably remove these re-exports now that they are not related to this module/config

parent_distance: u64,
/// Number of slots between head block and block proposal slot.
head_distance: u64,
re_org_threshold: u64,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It's interesting that the tests still pass after deleting these. I was thinking we could inject them into the mut spec below? Maybe we should add more tests to cover these (possibly in a separate issue)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Is it because the spec uses the default spec already:
let spec = ForkName::Fulu.make_genesis_spec(E::default_spec());
so it will read from the spec?

I added some assert_eq! to make sure they are equal to the spec in the test, but they look a bit of redundant? 2f40297

}

#[test]
fn disable_proposer_re_orgs() {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This test and the enable_proposer_re_orgs_default should stay if we keep the flag to disable-proposer-reorgs.

Comment thread beacon_node/src/config.rs Outdated
Comment on lines +744 to +745
Arc::make_mut(&mut spec).reorg_head_weight_threshold = None;
Arc::make_mut(&mut spec).reorg_parent_weight_threshold = None;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Hmm I don't think this is really the right way to do it. make_mut will only edit the spec variable in this function, not the global spec which is used elsewhere. I don't think we can easily edit the global spec at all (once it is behind the Arc).

Two options:

  1. Deprecate the disable-proposer-reorgs flag completely. Users could disable reorgs still by using --testnet-dir with an edited config.yaml.
  2. Add a boolean config on ChainConfig (where the config used to be) for controlling the enabling and disabling.

Probably the 2nd option is better. We'll need to update the code in beacon_chain to use that new flag. We can probably also update the reorg configs to be non-optional in chainspec (they can have defaults, but we can get rid of the Option<..> wrapper for simplicity)

Comment on lines +5167 to +5171
let slot_duration_millis = self.spec.get_slot_duration().as_millis() as u64;
let re_org_cutoff_millis = slot_duration_millis
.saturating_mul(self.spec.proposer_reorg_cutoff_bps)
.saturating_div(BASIS_POINTS);
let re_org_cutoff_duration = Duration::from_millis(re_org_cutoff_millis);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Can use the same simplification as mentioned above (the slot component duration thing)

@michaelsproul michaelsproul added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels May 6, 2026
@chong-he chong-he changed the title Delete some reorg-related CLI flags and read from spec Deprecate some reorg-related CLI flags and read from spec May 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backwards-incompat Backwards-incompatible API change waiting-on-author The reviewer has suggested changes and awaits thier implementation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants