Fix: manually calculate current reward cycle ID in /v2/pox_info #4468
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
/v2/pox
invokesget-pox-info
in the current PoX contract to obtain information about the current cycle. However, the burn view of this invocation is always one block behind the current chain tip: 2.x Stacks blocks are evaluated with a burnchain view equal to their parent (because the Stacks blocks must be assembled before the burn block in which they are committed).This leads to an "off by one" situation at reward cycle boundaries. This isn't a huge problem for Stacks 2.x nodes, because the information returned from this endpoint isn't really critical during the reward cycle change-overs. For signers in Nakamoto, though, this is problematic: they must know that the reward cycle has changed because they are now responsible for signing any new blocks at the time of the change-over.
This PR addresses this problem by manually computing the current reward-cycle ID.