Feat/pon vrf integration

[blondfrogs]

PON-VRF: VRF leader election (closes the leader-election grinding vulnerability)

Summary

Replaces Proof-of-Node's grindable leader election with a verifiable random function (VRF) election that reuses the existing fluxnode operator key. Leadership is now an un-grindable, verifiable draw, and ties converge deterministically. Gated behind a new UPGRADE_PON_VRF network upgrade, so it ships inert until an activation height is scheduled.

Problem

PON leader eligibility was H(collateral, prevBlockHash, slot) ≤ target. Because that hash depends on block content the proposer controls, a proposer can grind its inputs to bias who is eligible to lead — there is no cooldown and no consensus rank check. This lets a sufficiently resourced node disproportionately influence leader selection.

Solution

• VRF eligibility: y = VRF(operator_key, H(epoch_seed ‖ slot)); eligible iff y ≤ target.
  • epoch_seed is derived from a buried block window (beyond the reorg horizon) that the current proposer could not have authored → not grindable.
  • The slot is mixed in so eligibility is a fresh draw each slot (leader rotation / liveness).
• Reuses the existing secp256k1 operator key — no new key material for operators.
• The VRF output is committed to the block hash (so it is signed and immutable); the proof is carried but excluded from the hash (self-validating against the output).
• Deterministic fork choice: at equal work/height, the lowest VRF output wins, so the network converges.

What's in this PR (by area)

• Crypto: ECVRF (ECVRF-SECP256K1-SHA256-TAI) via a vendored secp256k1-vrf module + src/crypto/ecvrf.{h,cpp}.
• Block format: PON_VRF_VERSION = 101; nodesVrfOutput (committed) + nodesVrfProof (excluded from hash).
• Consensus: UPGRADE_PON_VRF network upgrade (branch id 0x76b809bb); per-slot VRF eligibility; contextual VRF-proof verification; lowest-VRF fork-choice tie-break.
• Production / validation / relay — every site that builds, hashes, validates, relays, or reads a block header now handles the committed VRF output: CreateNewBlock, CheckBlockHeader, ReadBlockFromDisk, LoadBlockIndex, and the cmpheaders compact-header serialization.
• Networking: PROTOCOL_VERSION and UPGRADE_PON_VRF.nProtocolVersion bumped to 170022 so VRF-capable peers are distinguishable and peers below 170022 are rejected once the upgrade activates.

Testing

• 25 gtests pass — ECVRF prove/verify round-trip, output-committed/proof-excluded serialization, and fork-choice convergence.
• Live local testnet validation — confirmed fluxnodes minting v101 VRF blocks accepted under the real (unbypassed) verifier; multi-node header sync and concurrent minting validated up to ~100 nodes; orphan-rate measurements confirm the difficulty target (eligible-nodes-per-slot) is the dominant orphan lever.

Activation & deployment notes

• Ships inert: PON_VRF is NO_ACTIVATION_HEIGHT on mainnet and regtest. Testnet is set to a PLACEHOLDER (9999999) — replace with a scheduled testnet height (above the current tip) before tagging.
• Protocol-version gating ensures a clean upgrade window: nothing changes until activation, after which sub-170022 peers are dropped.

Follow-ups (not blocking testnet)

• Validate on the live testnet that the difficulty retarget keeps eligible-nodes-per-slot small at scale (the orphan driver).
• Optional networking optimization: priority-aware "announce-first" relay to further cut orphans at large N.
• Constant-time / side-channel audit of the VRF module before mainnet.

Commits (in order)

Crypto foundation

• ca735752a — Add ECVRF-secp256k1 module (vendored from aergo) + ecvrf C++ boundary

Consensus core

• 474a792ff — PON: VRF leader election (consensus) — closes leader-election grinding
• d418724fe — PON-VRF: deterministic fork choice via lowest-VRF tie-break

Tests

• 5c393c205 — PON-VRF: extract ComparePonForkChoice + gtests for fork-choice convergence
• 51a941b8c — PON-VRF: gtests for block serialization + real ECVRF prove/verify path

Completeness fixes (found via live testnet block production)

• 382c2e0e3 — populate VRF fields in CreateNewBlock so VRF blocks can be produced
• 8bcd4f1f9 — per-slot eligibility, CheckBlockHeader + compact-header VRF support
• 52f49d786 — ReadBlockFromDisk must check the VRF output, not GetPONHash
• 494486f27 — LoadBlockIndex must check the VRF output, not GetPONHash

Deployment

• 3792a6e81 — PLACEHOLDER testnet activation height — SET BEFORE TAGGING
• 73fda1b54 — bump protocol version to 170022 for VRF wire format

[MorningLightMountain713]

Correct me if I'm wrong here, but in practice, the privkey is per owner, not per node. So if I have 100 nodes, and they win the lottery (which only happens 1/100th the time relative to 100 nodes with seperate keys) you will get a block broadcast storm?

What about this:

y = VRF(operator_key, H(epoch_seed ‖ slot ‖ collateral))

[blondfrogs]

Correct me if I'm wrong here, but in practice, the privkey is per owner, not per node. So if I have 100 nodes, and they win the lottery (which only happens 1/100th the time relative to 100 nodes with seperate keys) you will get a block broadcast storm?

What about this:

y = VRF(operator_key, H(epoch_seed ‖ slot ‖ collateral))

You're are absolutely right. This is exactly why we review code. Shipping an update now.

[MorningLightMountain713]

PON-VRF — two consensus-level issues at 3acfecf9 (each confirmed with a gtest)

Reviewing this PR I hit two consensus-level issues. I wrote a gtest for each and ran it against this head — both reproduce and confirm the issue. They drop straight into src/gtest/test_pon.cpp (they reuse the existing MakeVrfHeader() / MakeVrfIndex() helpers):

make -C src flux-gtest -j$(nproc)
./src/flux-gtest --gtest_filter='PONTest.Blocker*'

🔴 Issue 1 — VRF proof dropped on the CBlockIndex round-trip → header relay breaks post-activation

getheaders rebuilds each header from CBlockIndex via GetBlockHeader(). The index stores nodesVrfOutput (committed to the hash) but not nodesVrfProof (81 bytes, excluded from the hash — see CBlockIndex(const CBlockHeader&) and GetBlockHeader() in chain.h). So every relayed v101 header carries an empty proof; the receiver's CheckPONBlockHeader hard-fails nodesVrfProof.size() != 81 → state.DoS(100) → Misbehaving(100). The honest sender is banned and headers-first sync stalls after activation. Tip-following uses full blocks (which carry the proof), which is why already-synced nodes don't surface it.

Fix: persist nodesVrfProof in CBlockIndex/CDiskBlockIndex and copy it in GetBlockHeader(), mirroring vchBlockSig (stored for exactly this reason). ~81 bytes per index entry.

// Goes RED on this head (proof comes back size 0); goes green once the proof is
// persisted in CBlockIndex/CDiskBlockIndex and copied in GetBlockHeader().
TEST_F(PONTest, Blocker1_VrfProofDroppedByIndexBreaksHeaderRelay) {
    CBlockHeader original = MakeVrfHeader();            // carries a full 81-byte proof
    ASSERT_EQ(original.nodesVrfProof.size(), 81u);

    CBlockIndex index(original);                        // what a relaying node stores
    CBlockHeader relayed = index.GetBlockHeader();      // what getheaders reconstructs and sends

    // Output survives (stored + committed to the hash) -> the loss is invisible to hash checks.
    EXPECT_EQ(relayed.nodesVrfOutput, original.nodesVrfOutput);

    // ...but the 81-byte proof is gone -> a relayed header is rejected on the size check.
    EXPECT_EQ(relayed.nodesVrfProof.size(), 81u)
        << "CBlockIndex drops nodesVrfProof -> relayed v101 headers fail CheckPONBlockHeader "
           "size()!=81 -> Misbehaving(100), header sync stalls.";
}

Observed:

[ RUN      ] PONTest.Blocker1_VrfProofDroppedByIndexBreaksHeaderRelay
      Expected: relayed.nodesVrfProof.size()  Which is: 0
      To be equal to: 81u                     Which is: 81
[  FAILED  ] PONTest.Blocker1_VrfProofDroppedByIndexBreaksHeaderRelay

The failure (proof size 0, not 81) is the confirmation: the proof does not survive the index round-trip.

🔴 Issue 2 — pre-activation v101 block with nodesVrfOutput = 0 steals fork choice

ComparePonForkChoice branches on the block version (>= PON_VRF_VERSION), not on the activation height, and trusts nodesVrfOutput. Nothing rejects a v101 block before UPGRADE_PON_VRF, and pre-activation the output is never validated. Lowest output wins and 0 is the minimum — so a legacy-eligible node can mint a block stamped nVersion = 101 / nodesVrfOutput = 0 and beat every honest v100 block in a same-height tie. No VRF key or proof required. This is live the moment the code ships, independent of any activation height.

Fix: reject nVersion >= PON_VRF_VERSION when !IsPONVRFActive(nHeight) (mirror of the version-floor check in the VRF branch of CheckPONBlockHeader). Belt-and-braces: also gate the VRF tie-break in ComparePonForkChoice on activation height. The same version-not-height asymmetry exists at the other read sites (CheckBlockHeader, ReadBlockFromDisk, LoadBlockIndexGuts).

// PASSES on this head -> the attacker wins, confirming the hole. After the fix this
// scenario can't arise; this would become an acceptance-rejection test at that point.
TEST_F(PONTest, Blocker2_PreActivationV101StealsForkChoice) {
    CBlockIndex honest;
    honest.nVersion        = CBlockHeader::PON_VERSION;          // 100 (legacy)
    honest.nHeight         = 100;
    honest.nTime           = 1700000000;
    honest.nBits           = 0x1d00ffff;
    honest.nodesCollateral = COutPoint(uint256S("0xfeedface"), 0);
    ASSERT_NE(GetPONHash(honest.GetBlockHeader()), uint256());   // real, non-zero legacy score

    // v101 block, same height, output forced to the minimum. Pre-activation nothing
    // rejects it and nothing validates the output.
    CBlockIndex attacker = MakeVrfIndex(100, uint256() /* 0x000...0 */);

    EXPECT_GT(ComparePonForkChoice(&honest, &attacker), 0)      // attacker (b) preferred
        << "v101 + nodesVrfOutput=0 steals the fork-choice tie from an honest v100 block "
           "pre-activation (comparator gated on version, not height).";
    EXPECT_LT(ComparePonForkChoice(&attacker, &honest), 0);     // wins regardless of order
}

Observed: [ OK ] PONTest.Blocker2_PreActivationV101StealsForkChoice — the v101/output=0 block wins the tie in both argument orders, confirming the issue.

Suggested fix order

1. Issue 2 — exploitable on mainnet immediately on ship.
2. Issue 1 — breaks IBD post-activation (fix before any activation height).

Both tests are confirmation tests against the current head: Issue 1's flips to green once the proof is persisted, and Issue 2's would become an acceptance-rejection test once the version/height gate is added.