Map BFT peer addresses by finalizer key

[Zk-nd3r]

PR Draft: Map BFT peer addresses by finalizer key

Target branch: s1_dev

Summary

This patch fixes BFT peer address construction so configured addresses are matched by derived BFT key instead of startup roster index.

It also removes the fake loopback fallback addresses from FinalizerPeerAddress construction. Unknown roster members stay in the consensus roster, but are omitted from the static peer-address list until discovered by transport/attestation.

What Changed

• Canonicalize the local reversed roster key to the node public key before building the Tenderlink roster.
• Build FinalizerPeerAddress after PoS-store replay so it uses the current/dynamic roster view.
• Derive configured peer keys from bft_peers and map addresses by key, not by stale roster index.
• Advertise the configured public_address for the local signer.
• Stop fabricating 127.0.0.1:<derived> peer targets for unknown roster members.

Live Test Datapoint

Running on one finalizer since 2026-07-09 with the s1_dev base. Before the patch/config cutover, the node emitted repeated loopback hole-punch requests against fake local BFT addresses. After cutover, telemetry shows cfg_loopback=0 and loopback_hp=0; the node remains synced, signs its local NIL prevote, and has more direct BFT peer visibility. Finality remains stalled because quorum participation is still missing; this patch improves local transport/addressing, not quorum by itself.

Notes

This is separate from the bandwidth/OOM fixes in the recent PRs. It targets a roster/transport addressing defect class: stale index mapping plus fake loopback seed targets.

[pmttavara]

This is really interesting! Can you explain what prompted you to draft this PR? Can I get more info about the problem that this is solving, e.g., a motivating example case of the bad UX / technical issue? It seems like an important problem, but I can't quite wrap my head around it.

[Zk-nd3r]

Yes. This came from trying to separate my local transport/config issue from the wider finality stall.

Motivating case: my node had the current roster, but only a few configured public BFT peers. The old path could line peer addresses up by roster position, then invent 127.0.0.1:<derived> fallbacks for unknown roster entries. That produced bogus loopback hole-punch noise and made it harder to tell whether I was missing real BFT traffic.

This PR keys configured peers by derived finalizer key and stops inventing loopback addresses. Unknown roster members stay in consensus, just without fake static addresses.

Live datapoint: after cutover, cfg_loopback=0, loopback_hp=0, node stayed stable, and peer visibility improved. Still stalled at 5597.0 with only my NIL prevote, so this is not the quorum fix. It just removes a bad local transport/addressing failure mode while finalizer participation is still being debugged.