fix: If the PoX anchor block is a shadow block, then none of its grandchildren tenures' block-commits will be valid#6985
Open
jcnelson wants to merge 11 commits intostacks-network:developfrom
Conversation
…heir anchor block. This is necessary in the special case where the PoX anchor block is a shadow block, and the block-commit being considered is the grandchild of the block-commit. Before, this and subsequent commits would be incorrectly rejected since the descend_from() check would fail for them (since the shadow block has no sortition). With this change, such block-commits would be accepted because their parent (a block-commit in the same reward cycle whose parent is a shadow block and the PoX anchor block) would have been accepted (on the count that it is the immediate child of the anchor block).
jcnelson
changed the title
jacinta-stacks
approved these changes
Mar 16, 2026
Contributor
jacinta-stacks
left a comment
jacinta-stacks
left a comment
There was a problem hiding this comment.
LGTM. Thanks for looking into this. I just have the nits, but I think you may need to pull develop and add a changelog entry now given the merging of Brice's changelog PR.
Codecov Report❌ Patch coverage is ❌ Your project check has failed because the head coverage (84.12%) is below the adjusted base coverage (84.17%). You can increase the head coverage or adjust the Removed Code Behavior. Additional details and impacted files@@ Coverage Diff @@
## develop #6985 +/- ##
===========================================
- Coverage 84.96% 84.92% -0.05%
===========================================
Files 412 412
Lines 219113 219264 +151
Branches 338 338
===========================================
+ Hits 186172 186202 +30
- Misses 32941 33062 +121
... and 43 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Contributor
cylewitruk-stacks
left a comment
cylewitruk-stacks
left a comment
There was a problem hiding this comment.
Code-wise this LGTM, but I don't feel familiar enough with the actual underlying issue/domain to give an approve - so maybe @aaronb-stacks or @brice-stacks could make a quick pass and give their ✅ ?
Coverage Report for CI Build 24680395267Coverage decreased (-0.02%) to 85.695%Details
Uncovered Changes
Coverage Regressions3239 previously-covered lines in 83 files lost coverage.
Coverage Stats
💛 - Coveralls |
brice-stacks
reviewed
Apr 7, 2026
Contributor
brice-stacks
left a comment
brice-stacks
left a comment
There was a problem hiding this comment.
This looks good, I just have a question about the default for the new column.
Contributor
|
@jcnelson please wrap up this PR. |
…jcnelson/stacks-core into fix/shadow-block-pox-descendant
…-block-pox-descendant
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
This fixes the flaky integration test
test_shadow_recoveryby means of fixing a legitimate bug: if a PoX anchor block happens to be a shadow block, it's immediate child commit can be accepted, but not its grandchild commit nor its descendants. This is because we have a special case check to treat a block-commit as having descended from the anchor block if it happens to be a child of the anchor block (as determined by itsparent_block_ptrandparent_vtxindexfields), but theSortitionHandle::descends_from()check will fail for any block that descends from a shadow PoX anchor block on the count of the fact that shadow blocks have no sortition (it instead has a "phony" block-commit atvtxindex = 0, which is impossible).The fix here is to add a field
descends_from_anchor_blocktoLeaderBlockCommitOp, which is set totrueon a call tocheck_pox()if the block does indeed descend from the anchor block, andfalseotherwise. Then, to determine if a given block-commit descends from a parent block-commit in the same reward cycle, we perform the same checks today as well as consider the parent commit'sdescends_from_anchor_blockvalue. So, if a block-commit is a grandchild of a shadow PoX anchor block phony block-commit, it will be treated as having descended from the anchor block because its parent did as long as the parent is in the same reward cycle (which it must be; otherwise block processing will have halted before this commit could have been processed).This PR adds a
descends_from_anchor_blockcolumn toblock_commitsinSortitionDBto track this field. It isNULLby default, since it will never be needed until we actually to produce a shadow block. This does not affect correctness since subsequent block-commits stored with this new schema will automatically havedescends_from_anchor_blockset to the correct value on insertion.