feat(core): add height-gated consensus ruleset engine - #447
Open
rickyrombo wants to merge 1 commit into
Open
Conversation
This was referenced Aug 6, 2026
Consensus rules can never simply be replaced: a node syncing from genesis must apply to each block exactly the rules that were live when it was produced. This introduces the engine for that — an UpgradeSchedule per chain ID mapping named upgrades to activation heights, resolved once per block into a flat Rules struct so height comparisons live in exactly one place and call sites branch on behavior, never on height. The first named upgrade, AuthEnforcementHeight, ships inert: no network schedules it here. The enforcement change later in this stack schedules it on the ephemeral networks and wires it into transaction validation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
rickyrombo
force-pushed
the
feat/consensus-ruleset-engine
branch
from
August 6, 2026 08:26
bdcb1c0 to
404831c
Compare
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
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.
What
Introduces a height-gated consensus ruleset engine: a per-chain-ID
UpgradeSchedulemapping named upgrades to activation heights, resolved per block into a flatRulesstruct (pkg/core/config/upgrades.go).The contract:
RulesetAt). Call sites branch on resolved behavior, never on height.0= never active. Unknown chain IDs resolve to an empty schedule.RulesetAt(currentHeight + 1), since the mempool admits txs for the next block.The first named upgrade,
AuthEnforcementHeight, ships inert — no network schedules it in this PR. The enforcement change at the top of this stack schedules it on the ephemeral networks and wires it into transaction validation, so the engine's first consumer arrives with the stack rather than as dead code. Its doc comment carries the scheduling constraint that matters: enforcement must never activate on a persistent network earlier than the height auth-state tracking began.Follow-ups
Stacked PRs build on this: consensus-side auth state tracking (#448), then height-gated authorization enforcement (#450).
Testing
upgrades_test.go: activation boundary (H-1/H/H+1), zero-means-never, nil-schedule safety, per-network schedules, unknown-chain isolation.go test ./pkg/core/config/green.🤖 Generated with Claude Code