fix(p2p)!: fix BLOCK_TXS response under proposer equivocation

[fcarreiro]

Summary

Fixes A-1070: a malicious proposer who sends two different proposals with the same archive root but different tx sets could make two honest nodes fail the BLOCK_TXS exchange and penalize each other.

In the BLOCK_TXS protocol the requester asks for txs by their index within a block (proposal), identified only by its archive root. If an equivocating proposer gives node A and node B two proposals that share an archive root but differ in their tx list, then:

• Node A (requester) asks node B for txs at indices [i, j, …] of "the block with this archive root".
• Node B (responder) resolves those indices against its version of the proposal and returns txs that, from A's perspective, are not part of the block.
• A's validateRequestedBlockTxsConsistency rejects the response and penalizes B — an honest node punished for honest behavior.

Fix

The request now carries a commitment to the full set of block tx hashes (blockTxHashesCommitment, a SHA-256 over the serialized tx hashes) alongside the archive root. The responder only serves txs by index (and advertises availability via the bitvector) when its own block's tx-hash commitment matches the request's. Otherwise it treats the request as "I don't have that block" — returning an empty bitvector and only servicing any explicitly-requested tx hashes — so neither side is penalized for an equivocation it didn't cause.

This closes the gap that the archive root alone could not: identical archive roots no longer imply identical tx sets.

Why not use proposal hash?

That would work when the BLOCK_TXS request is from a proposal, but it cannot be used when it's done from a block (e.g., in the prover node).

Changes

• BlockTxsRequest gains a blockTxHashesCommitment field and a computeBlockTxHashesCommitment helper; serialization and fromTxsSourceAndMissingTxs updated accordingly.
• reqRespBlockTxsHandler verifies the commitment before serving txs by index; on mismatch it falls back to the "block not available" path instead of returning indexed txs.
• reqRespBlockTxsHandler no longer returns NOT_FOUND. It always services what it can — explicitly-requested tx hashes, plus index-based txs when the commitment matches — and signals that it does not have the block via an empty bitvector. Requesters detect this through BlockTxsResponse.peerHasBlock(). Duplicate requested hashes (by index and by explicit hash) are de-duplicated before the pool lookup.
• BatchTxRequester: a peer that lacks the block (empty bitvector) is demoted to dumb without penalty. handleFailResponseFromPeer now penalizes NOT_FOUND along with FAILURE/UNKNOWN (since NOT_FOUND is no longer a legitimate response), while still demoting-without-penalty on INTERNAL_ERROR (consistency-validation failure). extractHashesPeerHasFromResponse is simplified to map bitvector indices directly to block tx hashes.
• This builds on the preceding BLOCK_TXS validation revamp commit (consistency checks on the requester side, response no longer echoes the archive root).
• Tests adapted across block_txs, block_txs_handler, batch_tx_requester, libp2p_service, and the integration suite: the "no block" case now expects an empty, block-less SUCCESS response instead of NOT_FOUND; the obsolete "demote on NOT_FOUND without penalizing" test was removed (legitimate demotion is now the empty-bitvector path). Added a handler test covering the equivocation case (different proposal under the same archive root → responder refuses to serve by index) and one asserting no duplicate txs are served when the same tx is requested by index and by repeated explicit hash.

Closes https://linear.app/aztec-labs/issue/A-1070/malicious-proposer-can-make-honest-nodes-to-fail-tx-validation .

[spalladino]

Shouldn't we check if requestedTxHashes is non-empty before this, and if it is, return NOT_FOUND?

[fcarreiro]

For simplicity I'm choosing to always try to service and return a response. NOT_FOUND is not a valid response anymore. The requester can now derive if the peer has the block from the bit vector (or better, using peerHasBlock(), and then can look at the array to see what the peer was able to return.

The only concern I see is that the "nothing found" path would be slightly bigger on the network, but still sth like 2 bytes (instead of possibly 1).