Fix/4826 #4840
Fix/4826 #4840
Conversation
…kamoto-epoch reward set from the Nakamoto chain state, except for the first-ever Nakamoto reward set which is necessarily a preprocessed reward set. Also, remove all calls to load a preprocessed sortition DB reward set from the Nakamoto coordinator
…oto test infrastructure, instead of loading it from a preprocessed reward set in the sortition DB
…Network to reference the reward cycle and its reward set
…he Nakamoto reward set from the Nakamoto chainstate instead of the sortition DB. Update the caching logic as well to key each cached reward set by anchor block ID
…t when validating a block to be relayed
…akamoto reward set from Nakamoto chainstate
There was a problem hiding this comment.
This mostly looks good to me, my biggest comment is around the burn_height parameter: I think its kind of dangerous the way its currently used, and I'd much prefer at least the provider interface being more explicit about the reward cycle its fetching, but potentially all of the interfaces being more explicit as well (or, perhaps eliminating the parameter in load_nakamoto_reward_set and just using the sortition_tip to lookup the snapshot?)
… on the *given* block height's reward cycle
…) or the block ID (nakamoto)
|
ping @obycode |
kantai
dismissed stale reviews from obycode and themself
The base branch was changed.
| let reward_cycle = self | ||
| .burnchain | ||
| .pox_constants | ||
| .block_height_to_reward_cycle( | ||
| self.burnchain.first_block_height, | ||
| self.burn_block.block_height, | ||
| ) | ||
| .ok_or_else(|| { | ||
| NakamotoNodeError::SigningCoordinatorFailure( | ||
| "Building on a burn block that is before the first burn block".into(), | ||
| ) | ||
| })?; |
There was a problem hiding this comment.
I know this is already merged, but I just noticed that this reward_cycle is unused and wanted to make sure that was intentional. It seems correct to me using the method below to get the cycle.
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This fixes #4826 by consolidating the way in which the code loads a Nakamoto-epoch reward set. It now will load it from the Nakamoto chain state, where it is keyed to the PoX anchor block selected in the given burnchain fork, with one exception: the first-ever Nakamoto reward set must be loaded from the sortition DB, since that'll be the only place where it is available.