Skip to content

Commit dd86b77

Browse files
CRC: use the prepare phase start to determine if Epoch 2.5 or Epoch 3.0 reward set calculation rules apply
Signed-off-by: Jacinta Ferrant <jacinta@stackslabs.com>
1 parent 779315b commit dd86b77

File tree

2 files changed

+11
-47
lines changed
  • stacks-common/src/types
  • stackslib/src/chainstate/nakamoto/coordinator

2 files changed

+11
-47
lines changed

stacks-common/src/types/mod.rs

Lines changed: 0 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -663,31 +663,6 @@ impl StacksEpochId {
663663
self >= &StacksEpochId::Epoch30
664664
}
665665

666-
/// Does this epoch use the nakamoto reward set, or the epoch2 reward set?
667-
/// We use the epoch2 reward set in all pre-3.0 epochs.
668-
/// We also use the epoch2 reward set in the first 3.0 reward cycle.
669-
/// After that, we use the nakamoto reward set.
670-
pub fn uses_nakamoto_reward_set(
671-
&self,
672-
cur_reward_cycle: u64,
673-
first_epoch30_reward_cycle: u64,
674-
) -> bool {
675-
match self {
676-
StacksEpochId::Epoch10
677-
| StacksEpochId::Epoch20
678-
| StacksEpochId::Epoch2_05
679-
| StacksEpochId::Epoch21
680-
| StacksEpochId::Epoch22
681-
| StacksEpochId::Epoch23
682-
| StacksEpochId::Epoch24
683-
| StacksEpochId::Epoch25 => false,
684-
StacksEpochId::Epoch30
685-
| StacksEpochId::Epoch31
686-
| StacksEpochId::Epoch32
687-
| StacksEpochId::Epoch33 => cur_reward_cycle > first_epoch30_reward_cycle,
688-
}
689-
}
690-
691666
/// What is the coinbase (in uSTX) to award for the given burnchain height?
692667
/// Applies prior to SIP-029
693668
fn coinbase_reward_pre_sip029(

stackslib/src/chainstate/nakamoto/coordinator/mod.rs

Lines changed: 11 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -363,35 +363,24 @@ pub fn load_nakamoto_reward_set<U: RewardSetProvider>(
363363
provider: &U,
364364
) -> Result<Option<(RewardCycleInfo, StacksHeaderInfo)>, Error> {
365365
let cycle_start_height = burnchain.nakamoto_first_block_of_cycle(reward_cycle);
366-
let epoch_at_height = SortitionDB::get_stacks_epoch(sort_db.conn(), cycle_start_height)?
367-
.unwrap_or_else(|| panic!("FATAL: no epoch defined for burn height {cycle_start_height}"));
368-
let is_pre_naka_epoch = if epoch_at_height.epoch_id < StacksEpochId::Epoch30 {
369-
true
370-
} else {
371-
let epoch_30 =
372-
SortitionDB::get_stacks_epoch_by_epoch_id(sort_db.conn(), &StacksEpochId::Epoch30)?
373-
.unwrap_or_else(|| panic!("FATAL: no Nakamoto epoch defined"));
374-
// Find the first Stacks block in this reward cycle's preceding prepare phase.
375-
// This block will have invoked `.signers.stackerdb-set-signer-slots()` with the reward set.
376-
// Note that we may not have processed it yet. But, if we do find it, then it's
377-
// unique (and since Nakamoto Stacks blocks are processed in order, the anchor block
378-
// cannot change later).
379-
let first_epoch30_reward_cycle = burnchain
380-
.block_height_to_reward_cycle(epoch_30.start_height)
381-
.expect("FATAL: no reward cycle for epoch 3.0 start height");
382-
!epoch_at_height
383-
.epoch_id
384-
.uses_nakamoto_reward_set(reward_cycle, first_epoch30_reward_cycle)
385-
};
386-
if is_pre_naka_epoch {
366+
// We need the prepare pahse start of the current reward cycle which is calculated in the PRIOR reward cycle
367+
// hence subtracting one. If the prepare phase started in pre-Nakamoto, it should be using Epoch 2.5 reward
368+
// set calculation rules.
369+
let prior_reward_cycle = reward_cycle.saturating_sub(1);
370+
let prepare_phase_start = burnchain
371+
.pox_constants
372+
.prepare_phase_start(burnchain.first_block_height, prior_reward_cycle);
373+
let epoch_at_height = SortitionDB::get_stacks_epoch(sort_db.conn(), prepare_phase_start)?
374+
.unwrap_or_else(|| panic!("FATAL: no epoch defined for burn height {prepare_phase_start}"));
375+
if epoch_at_height.epoch_id < StacksEpochId::Epoch30 {
387376
// 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.
388377
// The nakamoto chain-processing rules aren't active yet, so we can't look for the reward
389378
// cycle info in the nakamoto chain state.
390379
let Some(prepare_end_sortition_id) =
391380
get_ancestor_sort_id(&sort_db.index_conn(), cycle_start_height, sortition_tip)?
392381
else {
393382
// reward cycle is too far in the future
394-
warn!("Requested reward cycle start ancestor sortition ID for cycle {} prepare-end height {}, but tip is {}", reward_cycle, cycle_start_height, sortition_tip);
383+
warn!("Requested reward cycle start ancestor sortition ID for cycle {reward_cycle} prepare-end height {cycle_start_height}, but tip is {sortition_tip}");
395384
return Ok(None);
396385
};
397386

0 commit comments

Comments
 (0)