Skip to content

fix(consensus): scope emergency shard-0 quorum power - #17

Open
Frozen wants to merge 1 commit into
mainfrom
fix/emergency-shard0-effective-quorum
Open

fix(consensus): scope emergency shard-0 quorum power#17
Frozen wants to merge 1 commit into
mainfrom
fix/emergency-shard0-effective-quorum

Conversation

@Frozen

@Frozen Frozen commented Aug 20, 2026

Copy link
Copy Markdown
Owner

Summary

This is a coordinated consensus hard fork for the stalled mainnet shard-0 boundary at the end of epoch 3002.

  • Preserves the canonical 197 committee slots and every BLS bitmap index.
  • Assigns zero effective consensus voting power to the exact 41-key recovery manifest.
  • Deterministically renormalizes the remaining 156 slots to total voting power exactly 1.
  • Applies identical effective-roster semantics to live VIEWCHANGE, PREPARE, and COMMIT quorum paths and to block/cross-link certificate verification.
  • Includes the voting-power context in the verified-signature cache key, including exact bitmap length.
  • Refreshes live consensus after the retained parent is committed, so activation does not depend solely on an epoch transition or a restart at the exact boundary.

Exact activation boundary

The override applies only when all of the following match:

network:             mainnet
shard:               0
epoch:               3002
signed block height: 92733439
parent block height: 92733438
parent hash:         0xcbaceb7635b4e2d612c21b34fe24f308076e25b02d6379be17150f77b86f8f32

A candidate context at signed height 92733439 with a different parent hash fails closed. Historical and all other out-of-scope certificates use the original roster and voting power.

Certificate boundary:

block 92733439 carries the certificate for signed block 92733438
block 92733440 carries the certificate for signed block 92733439

The override therefore sunsets after the certificate for signed block 92733439; epoch 3003 uses the canonical roster.

Manifest attestation

Immediately before publication, two independent production shard-0 nodes agreed on:

head:                     92733438
head hash:                0xcbaceb7635b4e2d612c21b34fe24f308076e25b02d6379be17150f77b86f8f32
committee slots:          197
manifest keys found:      41/41
manifest keys missing:    0
canonical manifest power: 0.190719138817442899

Ordered manifest integrity:

count: 41
SHA-256: c287ca243feb79036ddc55fcefa6fcc8de3e97b4b9d9aeeeb2750d3cfc12f799

This attests exact membership and serialization against the retained committee. It does not claim key ownership or future availability.

Consensus/state isolation

This patch does not change:

  • physical committee membership;
  • bitmap ordering or indices;
  • staking, rewards, election state, or chain state;
  • leader rotation;
  • global votepower.Compute behavior.

Only context-scoped consensus voting power is transformed. An excluded leader can still cause a timeout; the following view change can reach quorum under the same effective roster.

Rollout risks and requirements

  • This must be deployed as a coordinated hard fork to every consensus-critical validator and verifier before producing or accepting the emergency certificate.
  • Old binaries do not apply the transformed roster and can reject the emergency certificate.
  • Operators must attest the retained head number/hash and the 41/41 manifest match before enabling consensus.
  • Do not proceed on a node with a different parent hash or committee; activation is intentionally fail closed.
  • A partial rollout can split certificate acceptance. Rollout and restart sequencing must be coordinated across shard-0 validators and downstream verifiers.
  • After an emergency certificate is accepted, rolling an individual verifier back to an old binary can make it reject the canonical chain.

Verification

git diff --check
PASS

go test -mod=readonly ./consensus/quorum ./consensus ./internal/chain -count=1
PASS

go vet ./consensus/quorum ./consensus ./internal/chain
PASS

go test -mod=readonly ./consensus/... ./node/harmony -run '^$' -count=1
PASS

go test -mod=readonly -race ./consensus/quorum ./internal/chain \
  -run 'TestEmergency|TestNormalizeVotingPower|TestStakedDeciderUsesEmergencyVotingPowerContext|TestStakeVerifierUsesSignedBlockContext|TestVerifiedSignatureCacheKeyIncludesVotingPowerContext|TestPayloadArgsFromCrossLinkRecoversParentHash|TestPayloadArgsFromHeaderCarriesEmergencyQuorumContext' \
  -count=1
PASS

make test was not used because this repository target runs kill_node.sh, pulls the floating harmonyone/localnet-test image, and mounts the active checkout. Native package tests and compile checks above avoid those side effects and the unpinned image.

Preserve all committee bitmap positions while assigning zero effective consensus power to the 41-key recovery manifest for the exact mainnet shard-0 block 92733439 certificate context. Apply the same roster semantics to live consensus and certificate verification, including context-safe caching and fail-closed parent-hash activation.
@greptile-apps

greptile-apps Bot commented Aug 20, 2026

Copy link
Copy Markdown

Greptile Summary

This coordinated consensus change scopes an emergency shard-0 voting-power roster to the final block of mainnet epoch 3002 while preserving committee membership and bitmap positions.

  • Excludes the specified 41-key manifest from effective quorum power and deterministically renormalizes the remaining power.
  • Applies the same context-sensitive roster to live consensus and block, header, and cross-link certificate verification.
  • Extends signature-cache identity with the complete voting-power context and bitmap length.
  • Refreshes the live decider after the retained parent is committed and returns to the canonical epoch-3003 roster after the boundary.

Confidence Score: 5/5

The PR appears safe to merge as a coordinated hard fork, with no concrete changed-code defect identified in the scoped quorum activation or verification paths.

Live consensus and certificate verification consistently identify signed block 92733439 by mainnet chain, shard, epoch, height, and retained parent hash, fail closed on boundary mismatches, preserve bitmap ordering, and restore the canonical roster for epoch 3003.

Important Files Changed

Filename Overview
consensus/quorum/emergency.go Defines the exact activation boundary, validates the manifest and roster, and creates a copied, normalized effective voting-power roster without changing bitmap ordering.
consensus/quorum/one-node-staked-vote.go Adds context-aware voter initialization so live prepare, commit, and view-change tallies use the emergency effective roster.
consensus/quorum/verifier.go Applies the same context-sensitive effective roster while verifying certificate bitmaps and fails closed on an invalid activation context.
consensus/consensus_service.go Builds the next signed block's voting-power context from the retained current header when updating the live decider.
consensus/consensus_v2.go Refreshes consensus immediately after committing the retained parent so emergency activation does not depend on restart or epoch transition.
internal/chain/engine.go Propagates signed-block context through certificate verification, recovers cross-link parent hashes when available, and scopes verified-signature cache entries to all quorum-relevant inputs.

Sequence Diagram

sequenceDiagram
    participant C as Consensus
    participant D as Live Decider
    participant E as Chain Engine
    participant V as Quorum Verifier
    C->>D: Commit retained parent 92733438
    C->>D: Refresh for signed block 92733439
    D->>D: Exclude 41 keys and renormalize 156 slots
    C->>D: Form VIEWCHANGE/PREPARE/COMMIT quorum
    E->>V: Verify certificate with chain, epoch, height, parent hash
    V->>V: Apply identical emergency effective roster
    C->>D: Commit epoch-final block 92733439
    C->>D: Refresh canonical epoch-3003 roster
Loading

Reviews (1): Last reviewed commit: "fix(consensus): scope emergency shard-0 ..." | Re-trigger Greptile

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