fix(zcashd): scope pruned block logs to sidecar peers

[p0mvn]

Motivation

PR #279 enabled an actionable diagnostic when a pruned zcashd-compat node cannot serve a requested block body. The diagnostic was configuration-gated, but the shared inbound service did not identify which connected peer sent the request, so any peer could trigger the message and consume its global rate-limit interval.

Solution

• attribute block getdata requests from operator-configured protected legacy peers with their connection source
• independently match that source against the effective zcashd_compat.block_gossip_peer_ips allowlist
• emit the pruning diagnostic only for configured legacy sidecar requests
• keep ordinary legacy, unconfigured legacy, and Zakura v2 requests on the existing notfound path without logging

Testing

• cargo fmt --all -- --check
• cargo test -p zakura-network protected_connection_attributes_inbound_block_request --lib
• cargo test -p zakura inbound_pruned_block --lib
• cargo test -p zakura pruned_block_not_found --lib
• cargo clippy -p zakura-network -p zakura --lib --tests --no-deps -- -D warnings

The connection test verifies that configured sidecar requests carry their classified source. The inbound integration test verifies that ordinary and unconfigured legacy requests do not log while the configured zcashd-compat peer does, without changing the wire notfound response. Unit coverage verifies rate limiting and IPv4-mapped IPv6 canonicalization.

Specifications & References

• Follow-up to fix(zcashd): diagnose requests for pruned blocks #279

[v12-auditor]

Note

Complete: Audit complete. V12 did not find any issues that need review.

Open the full results here.

Analyzed three files, diff 3669471...dd2d6dc.