Deprecate some reorg-related CLI flags and read from spec#9177
Deprecate some reorg-related CLI flags and read from spec#9177chong-he wants to merge 25 commits intosigp:unstablefrom
reorg-related CLI flags and read from spec#9177Conversation
chong-he
left a comment
There was a problem hiding this comment.
Some self-review comments for the reviewers
| re_org_head_threshold: Some(ReOrgThreshold(20)), | ||
| re_org_parent_threshold: Some(ReOrgThreshold(160)), | ||
| re_org_max_epochs_since_finalization: Epoch::new(2), |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
I think we should actually remove these fields from the ChainConfig entirely, so that we are forced to always read them from the ChainSpec
There was a problem hiding this comment.
Thanks for the great feedback, I have revised.
| .arg( | ||
| Arg::new("proposer-reorg-cutoff") | ||
| .long("proposer-reorg-cutoff") |
There was a problem hiding this comment.
There is a proposer_reorg_cutoff_bps in the spec:
lighthouse/consensus/types/src/core/chain_spec.rs
Line 1105 in 6ab48a7
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
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Might need a new method on SlotClock for this (look at the other BPS values to see how we do it)
There was a problem hiding this comment.
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?
| } | ||
|
|
||
| /// Sets the proposer parent re-org threshold | ||
| pub fn proposer_re_org_parent_threshold(mut self, threshold: Option<ReOrgThreshold>) -> Self { |
There was a problem hiding this comment.
When we remove the chain config we will also remove these mutators (for tests we can set custom values on the spec).
There was a problem hiding this comment.
can probably inject the config values into the spec here (and can remove TTD)
There was a problem hiding this comment.
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....
| .display_order(0) | ||
| ) | ||
| .arg( | ||
| Arg::new("proposer-reorg-threshold") |
There was a problem hiding this comment.
We should maybe keep these with a deprecation warning for now, and then can remove in v9.0.0
There was a problem hiding this comment.
Added a deprecated note in the help text output
| 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); |
There was a problem hiding this comment.
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}; | |||
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
This test and the enable_proposer_re_orgs_default should stay if we keep the flag to disable-proposer-reorgs.
| Arc::make_mut(&mut spec).reorg_head_weight_threshold = None; | ||
| Arc::make_mut(&mut spec).reorg_parent_weight_threshold = None; |
There was a problem hiding this comment.
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:
- Deprecate the
disable-proposer-reorgsflag completely. Users could disable reorgs still by using--testnet-dirwith an editedconfig.yaml. - 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)
| 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); |
There was a problem hiding this comment.
Can use the same simplification as mentioned above (the slot component duration thing)
reorg-related CLI flags and read from specreorg-related CLI flags and read from spec
Issue Addressed
config.yaml#9123Additional Info
Please provide any additional information. For example, future considerations
or information useful for reviewers.