feat(subnet-splitting): do not validate certifications of other subnet - #10970
Draft
pierugo-dfinity wants to merge 1 commit into
Draft
feat(subnet-splitting): do not validate certifications of other subnet#10970pierugo-dfinity wants to merge 1 commit into
pierugo-dfinity wants to merge 1 commit into
Conversation
pull Bot
pushed a commit
to bit-cook/ic
that referenced
this pull request
Aug 3, 2026
…finity#10936) This PR implements the halting logic of subnet splitting by adapting Consensus' `get_status` function, used by block making, block validation, and batch delivery. On a `Scheduled` subnet split summary, replicas will halt as they are about to skip the whole interval and create CUPs for the next summary height directly. On a `PostSplit` subnet split summary, the split is done. As a replica's subnet ID is determined at startup, the source subnet will have it correct and can continue creating blocks. Though for a short amount of time, the destination subnet will still have the configured source subnet ID while the summary indicates the destination subnet ID. In that case, do not create new blocks (i.e. halt) until the orchestrator observes this `PostSplit` CUP and restarts the replica (with the correct destination subnet ID). After they restarted, replicas' subnet ID will match the one in the summary and should create blocks. Note: as the two subnets are still connected under the same P2P network after the split but have different halting conditions, it is expected to receive artifact invalidation during that time: the destination subnet will receive non-empty blocks from the source subnet. Note 2: again, because the two subnets are still connected under the same P2P network after the split, the source subnet will broadcast certifications/certification shares for heights above the post-split summary. These should be ignored by the destination subnet: coming later in a [separate PR](dfinity#10970). P.S.: the PR also finds the last summary block at one single place and passes it around during block making and validation, allowing to remove some error variants and avoid panics. --------- Co-authored-by: IDX GitHub Automation <infra+github-automation@dfinity.org>
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
1 participant
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.
After a subnet split, nodes are still connected under the same P2P network and share the same pools of artifacts. It is only after the orchestrator detects that the split has happened (sees a
PostSplitCUP for a different subnet) that it restarts the destination replicas and then the two subnets are strictly separated.During that short window of time, the source subnet actually executes messages and it is important for the destination nodes not to create/validate any certifications/certification shares during that time.