Skip to content

feat(core): add height-gated consensus ruleset engine - #447

Open
rickyrombo wants to merge 1 commit into
mainfrom
feat/consensus-ruleset-engine
Open

feat(core): add height-gated consensus ruleset engine#447
rickyrombo wants to merge 1 commit into
mainfrom
feat/consensus-ruleset-engine

Conversation

@rickyrombo

@rickyrombo rickyrombo commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

What

Introduces a height-gated consensus ruleset engine: a per-chain-ID UpgradeSchedule mapping named upgrades to activation heights, resolved per block into a flat Rules struct (pkg/core/config/upgrades.go).

The contract:

  • Height comparisons live in exactly one function (RulesetAt). Call sites branch on resolved behavior, never on height.
  • Activation height 0 = never active. Unknown chain IDs resolve to an empty schedule.
  • A rule that has governed even one block on a persistent network is permanent — superseding it means adding a new entry at a new height, since a node syncing from genesis must replay every historical block under the rules that were live when it was produced.
  • Mempool-time callers must resolve 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

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant