Improve peer selection for syncing

[jframe]

Enhance peer selection to utilize the performance metrics added in the peer performance metrics ticket. Currently, snap sync uses basic peer selection without considering transfer speed or latency.

Potential areas for investigation and improvement:

• Latency-based selection: Consider whether snap sync account/storage/trie requests (which involve many small requests) would benefit from prioritizing low-latency peers over other criteria.

• Context-aware selection: Explore implementing context-aware peer selection that chooses optimal peers based on request type, potentially using different selection strategies for different phases of world state sync.

• Selection comparators: Investigate adding peer selection comparators like BY_LOW_LATENCY or BY_TRANSFER_SPEED for world state operations to complement existing comparators.

• RequestDataStep integration: Review how RequestDataStep in snap sync could be updated to leverage performance-based peer selection once metrics are available.

The goal is to route requests to the most suitable peers based on their historical performance characteristics to improve overall world state sync performance.

[bcoste]

Hi,

I’d like to work on this issue.

Background: I’m a senior Java backend developer, currently ramping up on Ethereum L1 (scaling/statelessness) and looking to contribute to Besu’s sync performance.

Proposed plan:

• Introduce peer performance metrics in EthPeer and EthPeerImmutableAttributes (latency, throughput).
• Capture latency and throughput in AbstractPeerRequestTask so that world state requests record meaningful performance data.
• Add performance-based comparators to EthPeers (e.g. by low latency / by transfer speed) to complement existing selection strategies.
• Update AbstractRetryingSwitchingPeerTask to support custom comparators so retries can leverage the new performance-based strategies.
• Integrate performance-based selection into Snap Sync tasks and RequestDataStep, using the metrics when available while keeping current behavior safe.
• Add unit tests for peer selection and metrics capturing to verify the new comparators and ensure no regression in existing selection logic.

If this approach looks good, I’ll start and open a draft PR once I have the initial implementation.