Skip to content

feat(app): wire priority + infosync into the node - #574

Open
varex83agent wants to merge 1 commit into
mainfrom
feat/wire-priority-infosync
Open

feat(app): wire priority + infosync into the node#574
varex83agent wants to merge 1 commit into
mainfrom
feat/wire-priority-infosync

Conversation

@varex83agent

Copy link
Copy Markdown
Collaborator

What

Wires the priority protocol behaviour and infosync component into the running node, and triggers a cluster-wide priority exchange on the last slot of each epoch.

Previously both crates were implemented and tested but never mounted (crates/app/src/node/mod.rs carried a TODO(#402 part B)), so a pluto node neither advertised charon/priority/2.0.0 nor proposed into the info_sync QBFT round. In a mixed cluster this made Charon peers log protocols not supported: [charon/priority/2.0.0] and Priority protocol consensus: consensus timeout every epoch.

Scope — participation only ("A")

This is the participation half of #402 part B:

  • CoreBehaviour gains a priority field, constructed via pluto_priority::new_component on the shared p2p_context and riding the existing Arc<qbft::Consensus> (priority uses raw QBFT, matching Charon's wirePrioritise).
  • infosync::Component is built with version::SUPPORTED, the concatenated protocols() of consensus/parsigex/peerinfo/priority, and [Builder?]+Full proposal types.
  • A per-epoch trigger is registered as a scheduler slot subscriber, guarded by Slot::last_in_epoch() (6s exchange timeout, min_required = cluster threshold — both matching Charon).

Deferred (TODO(#402 part B)): consuming the decided result — routing the duty path through ConsensusController and registering the protocol-switch subscriber (set_current_consensus_for_protocol). That is a functional no-op while QBFTv2 is the only consensus protocol, so it is intentionally left out. This PR does not wire proposals() into the fetcher, because Charon does not either (its Proposals()/Protocols() accessors are dead code; full-vs-blinded is decided by --builder-api).

Verification

  • cargo +nightly fmt --all --check, cargo clippy --workspace --all-targets --all-features -- -D warnings, cargo test --workspace --all-features all pass.
  • End-to-end on a 2-charon + 2-pluto kurtosis cluster: at the epoch boundary all four nodes reach byte-identical info_sync results (e.g. protocol: qbft=4000, parsigex=3996, peerinfo=3992, priority=3988), proving pluto's calculateResult is deterministic-equivalent to Charon's. Charon's protocols not supported and consensus timeout warnings stop; regular duties are unaffected.

🤖 Generated with Claude Code

Mount the priority protocol behaviour and construct the infosync
component in the node's P2P wiring, and trigger a cluster-wide priority
exchange on the last slot of each epoch. The priority component rides the
existing QBFT consensus and shares the node-wide P2P context; infosync
advertises this node's supported versions, protocols, and proposal types.

This is the participation half of #402 part B ("A"): it makes pluto take
part in the per-epoch priority/QBFT info_sync round so mixed clusters with
Charon reach quorum. Consuming the decided result (routing the duty path
through ConsensusController and registering the protocol-switch
subscriber) is a functional no-op while QBFTv2 is the only consensus
protocol and is left as a TODO(#402 part B).

Verified on a 2-charon + 2-pluto kurtosis cluster: all four nodes reach
identical info_sync results, and Charon's "protocols not supported:
[charon/priority/2.0.0]" and priority "consensus timeout" warnings stop.

Co-Authored-By: Claude Opus 4.8 (1M context) <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