-
Notifications
You must be signed in to change notification settings - Fork 712
Support abritrary epochs in TestChainstate #6619
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
base: develop
Are you sure you want to change the base?
Changes from 11 commits
1eb48de
59c48ea
0d2e5fa
9f8c670
ed30abc
eafad79
3650058
7500516
13659d1
d7c728a
84306cd
c37946e
76edefd
74e94fc
14e13e2
0e71860
6069c36
0a44f6c
779315b
a7c544d
3ea9d35
381398d
e4e5ab6
7fec308
6da8514
395fe95
1ea1f63
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -363,28 +363,27 @@ pub fn load_nakamoto_reward_set<U: RewardSetProvider>( | |
| provider: &U, | ||
| ) -> Result<Option<(RewardCycleInfo, StacksHeaderInfo)>, Error> { | ||
| let cycle_start_height = burnchain.nakamoto_first_block_of_cycle(reward_cycle); | ||
|
|
||
| let epoch_at_height = SortitionDB::get_stacks_epoch(sort_db.conn(), cycle_start_height)? | ||
| .unwrap_or_else(|| { | ||
| panic!( | ||
| "FATAL: no epoch defined for burn height {}", | ||
| cycle_start_height | ||
| ) | ||
| }); | ||
|
|
||
| // Find the first Stacks block in this reward cycle's preceding prepare phase. | ||
| // This block will have invoked `.signers.stackerdb-set-signer-slots()` with the reward set. | ||
| // Note that we may not have processed it yet. But, if we do find it, then it's | ||
| // unique (and since Nakamoto Stacks blocks are processed in order, the anchor block | ||
| // cannot change later). | ||
| let first_epoch30_reward_cycle = burnchain | ||
| .block_height_to_reward_cycle(epoch_at_height.start_height) | ||
| .expect("FATAL: no reward cycle for epoch 3.0 start height"); | ||
|
|
||
| if !epoch_at_height | ||
| .epoch_id | ||
| .uses_nakamoto_reward_set(reward_cycle, first_epoch30_reward_cycle) | ||
| { | ||
| .unwrap_or_else(|| panic!("FATAL: no epoch defined for burn height {cycle_start_height}")); | ||
| let is_pre_naka_epoch = if epoch_at_height.epoch_id < StacksEpochId::Epoch30 { | ||
| true | ||
| } else { | ||
| let epoch_30 = | ||
| SortitionDB::get_stacks_epoch_by_epoch_id(sort_db.conn(), &StacksEpochId::Epoch30)? | ||
| .unwrap_or_else(|| panic!("FATAL: no Nakamoto epoch defined")); | ||
| // Find the first Stacks block in this reward cycle's preceding prepare phase. | ||
| // This block will have invoked `.signers.stackerdb-set-signer-slots()` with the reward set. | ||
| // Note that we may not have processed it yet. But, if we do find it, then it's | ||
| // unique (and since Nakamoto Stacks blocks are processed in order, the anchor block | ||
| // cannot change later). | ||
| let first_epoch30_reward_cycle = burnchain | ||
| .block_height_to_reward_cycle(epoch_30.start_height) | ||
| .expect("FATAL: no reward cycle for epoch 3.0 start height"); | ||
| !epoch_at_height | ||
| .epoch_id | ||
| .uses_nakamoto_reward_set(reward_cycle, first_epoch30_reward_cycle) | ||
| }; | ||
| if is_pre_naka_epoch { | ||
|
Comment on lines
+367
to
+386
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am pretty sure that this check could just be simplified to something like: // if this reward cycle started before 3.0, we need to lookup the
// reward set using 2.x rules.
if epoch_at_height.epoch_id < StacksEpochId::Epoch3_0 {There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we not use the pre-naka reward set calculation in the FIRST epoch 3.0 reward set? Specifically see this comment: /// Does this epoch use the nakamoto reward set, or the epoch2 reward set?
/// We use the epoch2 reward set in all pre-3.0 epochs.
/// We also use the epoch2 reward set in the first 3.0 reward cycle.
/// After that, we use the nakamoto reward set.
pub fn uses_nakamoto_reward_set(
&self,
cur_reward_cycle: u64,
first_epoch30_reward_cycle: u64,
) -> bool {
match self {
StacksEpochId::Epoch10
| StacksEpochId::Epoch20
| StacksEpochId::Epoch2_05
| StacksEpochId::Epoch21
| StacksEpochId::Epoch22
| StacksEpochId::Epoch23
| StacksEpochId::Epoch24
| StacksEpochId::Epoch25 => false,
StacksEpochId::Epoch30
| StacksEpochId::Epoch31
| StacksEpochId::Epoch32
| StacksEpochId::Epoch33 => cur_reward_cycle > first_epoch30_reward_cycle,
}
}There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep -- but that would be the case because the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think that is necessarily true though no? I mean the epoch at height 3.0 activation...is epoch 3.0. However...its prepare phase actually happens in Epoch 2.5 meaning by epoch 2.5 reward set calculation standards. So that means it would need to use this specialty function, no? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh -- yes, this is kind of weird. What matters here is the active epoch during the reward cycle calculations. These actually occur at different times in 2.x and 3.x. In 2.x rules, the reward cycle is calculated at the reward cycle start height. In 3.x rules, its calculated during the prepare phase. This one of the reasons that 3.0 shouldn't start exactly on a reward cycle boundary. The reason that checking the start height of the reward cycle "works" if the 3.0 epoch doesn't start at a reward cycle boundary is basically the following: Because Epoch 3.0 doesn't start at the reward cycle boundary, it's first cycle (N) has a start height which is in Epoch 2.5. That's why 2.x rules need to be used to calculate that reward cycle. Now, if Epoch 3.0 actually starts on a reward cycle boundary, that's when things go topsy-turvy. But I think that should just be forbidden? Or alternatively, rather than using the cycle start height to check for the epoch, we could use the prepare-phase start height of the cycle (i.e., cycle start height - prepare length) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Very hard for me to grok this but I think I understand XD I am not sure where to enforce Epoch 3.0 not starting on a boundary. I enforce it in my ConsensusTest and I mean I suppose since Epoch 3.0 has already started no place in mainnet to enforce. Looking into PoxConstants definition and where it is used with Epoch list to see if I can enforce that Epoch 3.0 never starts on a reward cycle boundary in all tests cause I assume this could cause confusion to a test writer. EDIT: done prepare phase change in a7c544d There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm this broke some unit tests. Taking a look now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reverted. So this broke a few tests because a few of them seem to activate Epoch 3.0 and Epoch 2.5 in the same reward cycle. For e.g. test reward_cycle_length = 5
prepare_length = 3
Therefore we have one nakamoto tenure at block height 39 which uses the pre computed reward set for reward cycle 3. But then a new nakmaoto tenure starts at 40 which is now in reward cycle 4. But it no longer is the first Epoch 3.0 reward cycle BUT its prepare phase does occur in Epoch 2.5...so it goes to find the preprocessed reward set using Epoch 2.5 rules for reward cycle 4. However, it never processed this using Epoch 2.5 rules because it already had a reward cycle with Epoch 3.0 activated therefore it uses Epoch 3.0 rules. It therefore fails to find the pre processed reward set and should really be using Epoch 3.0 rules. |
||
| // in epoch 2.5, and in the first reward cycle of epoch 3.0, the reward set can *only* be found in the sortition DB. | ||
| // The nakamoto chain-processing rules aren't active yet, so we can't look for the reward | ||
| // cycle info in the nakamoto chain state. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.