fix(p2p): fall back to archiver in BLOCK_TXS response validation

[mrzeszutko]

Summary

Libp2pService.validateRequestedBlockTxsConsistency rejects every BLOCK_TXS reqresp response for any block whose proposal is not in the local attestation pool. The responder handler already falls back to the archiver in this case, the validator did not. So any node that doesn't have the proposal locally — but does know the block from the archiver — cannot collect its missing txs, and instead storms its peers until it is rate-limited and disconnected.

This PR teaches the validator the same proposal-or-archiver fallback the handler already uses, breaking the storm at its source.

The defect: validator/handler asymmetry

To verify that a peer's BLOCK_TXS response matches the block, the validator needs the canonical tx-hash list for the block. Until this PR it consulted only the attestation pool:

// yarn-project/p2p/src/services/libp2p/libp2p_service.ts (pre-fix)
const proposal = await this.mempools.attestationPool.getBlockProposalByArchive(...);
if (proposal) { /* check membership/order */ } else { return false; }

The responder handler (p2p/src/services/reqresp/protocols/block_txs/block_txs_handler.ts:40-45) already serves from either source:

let txHashes = (await attestationPool.getBlockProposalByArchive(...))?.txHashes;
if (!txHashes) {
  txHashes = (await archiver.getBlock({ archive: request.archiveRoot }))?.body.txEffects.map(e => e.txHash);
}

So peers can produce valid responses for blocks that are only known via the archiver, but the validator at the other end rejects them.

When this fires

Any p2p-enabled node subscribes to block_proposal gossip (libp2p_service.ts:575) and stores received proposals into its attestation pool (validateAndStoreBlockProposal at libp2p_service.ts:1236, calling tryAddBlockProposal at line 1252). Neither subscription nor storage is gated by disableValidator — that flag only controls the validator-client (attestation signing). So in the steady state, a node that was online when a proposal was gossiped does have it locally.

The validator's lookup fails whenever the node lacks the proposal in its local attestation pool, yet still needs to collect the block's txs over reqresp. The real-world triggers we've seen and can describe:

• A node joins the mesh late and misses the proposal gossip for blocks that were proposed before it arrived. This was originally noticed during an e2e run where mesh formation was slower than usual, and it's the scenario the e2e test in this PR reproduces.
• A prover-node calling ProverNode.gatherTxs (prover-node/src/prover-node.ts:330) → TxProvider.getTxsForBlock → TxCollection.collectFastFor({type:'block', ...}) → BatchTxRequester for any block whose proposal it doesn't happen to hold: prover restart, gossip drop, mesh churn during the epoch, etc.

In every case the prover (or any node) has the mined block in its archiver but no proposal in its attestation pool. Until this PR the validator only consulted the attestation pool, so every otherwise-valid response was rejected.

The self-inflicted ban-storm

In BatchTxRequester (p2p/src/services/reqresp/batch-tx-requester/batch_tx_requester.ts):

// line 432-438: every response gets rejected because validation has no way to validate it
const isValid = await this.p2pService.validateRequestedBlockTxsConsistency(...);
if (!isValid) {
  this.handleFailResponseFromPeer(peerId, ReqRespStatus.INTERNAL_ERROR);
  return;
}

// line 461-481: INTERNAL_ERROR correctly does not penalize the peer, but
// also does not back off — the dumb worker loop just rotates to the next peer:
if (responseStatus === ReqRespStatus.NOT_FOUND || responseStatus === ReqRespStatus.INTERNAL_ERROR) {
  this.peers.markPeerDumb(peerId);
  this.txsMetadata.clearPeerData(peerId);
  return;
}

The dumb worker loop (batch_tx_requester.ts:261-304) has no inter-iteration sleep and ten parallel workers (dumbParallelWorkerCount: 10) round-robin the peers. Per-peer in-flight de-duplication caps it at one request in flight per peer, but the steady-state hit-rate per peer easily exceeds the responder's per-peer GCRA cap.

The penalty arrives from the responder side, on the requester:

// rate_limiter.ts:214-225
if (rateLimitStatus === RateLimitStatus.DeniedPeer) {
  this.peerScoring.penalizePeer(peerId, PeerErrorSeverity.HighToleranceError);
}

BLOCK_TXS per-peer cap : 10 req / 1000 ms   (rate_limits.ts:55-65)
HighToleranceError     : -2 score points    (peer_scoring.ts:34-36)
disconnect threshold   : -50                (peer_scoring.ts:57)
ban threshold          : -100               (peer_scoring.ts:56)

With ~1 GCRA denial per second per peer, the prover loses 2 points/sec at each responder. The first responder hits -50 in ~25 s and goodbyes the prover via peer_manager.ts:601-603 pruneUnhealthyPeers (GoodByeReason.LOW_SCORE); -100 in ~50 s would ban.

Fix

A four-line change in yarn-project/p2p/src/services/libp2p/libp2p_service.ts: fall back to the archiver after the attestation-pool lookup, mirroring the responder handler. If neither source has the block we still return falsewithout penalising the peer (it really is unverifiable locally).

const proposal = await this.mempools.attestationPool.getBlockProposalByArchive(...);
const blockTxHashes =
  proposal?.txHashes ??
  (await this.archiver.getBlock({ archive: request.archiveRoot }))?.body.txEffects.map(e => e.txHash);

if (blockTxHashes) { /* existing membership/order check, against blockTxHashes */ }
else               { /* unchanged: log warn, return false, no penalty */ }

The validator's other checks (archive-root match, bitvector length, no dupes, size bounds, subset-membership, ordering) are unchanged.

Tests

Unit anchor — p2p/src/services/libp2p/libp2p_service.test.ts

• New test: "should accept when the proposal is missing but the block is known via the archiver" — verified red before the fix (Expected: true, Received: false) and green after.
• Existing test renamed and tightened to "should reject without penalising when the block is unknown (no proposal and not in the archiver)" — covers the still-correct rejection path.
• All 46 tests in the file pass.

End-to-end — end-to-end/src/e2e_p2p/late_prover_tx_collection.test.ts

Validators form a mesh and mine a block carrying real txs; a prover joins after the block is mined, so it has the block in its archiver but never received the proposal or txs over gossip. The test then drives the exact production path the prover would take to gather txs for proving:

const txCollection = (proverNode as ...).p2pClient.txCollection;
const collected = await txCollection.collectFastForBlock(minedBlock, blockTxHashes, { deadline });
expect(collected.map(t => t.getTxHash().toString()).sort())
  .toEqual(blockTxHashes.map(h => h.toString()).sort());

• Red on the unfixed source: collected.length === 0 (validation rejects every response, dumb loop runs until the deadline), assertion fails.
• Green with the fix: all of block.body.txEffects's txs are collected.