perf(votes): add attestation caching

[MatusKysel]

Description

In the original flamegraph (run before any caching), reth_bsc::node::evm::pre_execution::verify_vote_attestation accounted for 5.49 % of total samples and the BLST Signature::fast_aggregate_verify underneath it took another 5.32 %.

[will-2012]

SNAPSHOT_FINGERPRINT_CACHE / BLS_PUBKEY_CACHE: Are there memory issues if the instance runs for an extended period of time?

[Copilot]

Pull request overview

This PR adds caching to attestation verification to improve performance. According to the flamegraph analysis, verify_vote_attestation and the underlying BLST signature verification were consuming over 10% of total execution time. The changes introduce three new caches to avoid redundant cryptographic operations and validator set processing.

• Adds attestation verification result caching to skip expensive BLS signature verification for already-validated attestations
• Implements snapshot fingerprinting and BLS public key caching to reuse parsed cryptographic objects
• Refactors validator address derivation into a dedicated method to eliminate code duplication

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/node/evm/pre_execution.rs	Adds three new caches (attestation verification, snapshot fingerprint, BLS public keys) and integrates them into the attestation verification flow. Includes unit tests for cache behavior.
src/node/miner/config.rs	Refactors validator address derivation logic into the new derive_validator_address_from_keys() method and updates tests to use shared helper functions.
src/rpc/mev.rs	Simplifies MEV API initialization by removing inline key derivation logic and relying solely on the configured validator address.
src/main.rs	Adds explicit error handling for validator address derivation during mining configuration setup.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[galaio]

Hi, I have a question here. Since the attestation is different in each block, the vote height will definitely be different, and the same block will only be synchronized once.

Then caching is meaningless. But why does your description suggest that adding cache reduces verify CPU usage?

Also, the latest version adds code to exclude the issue of duplicate imports of the same block. Is this caused by duplicate imports of the same block?

[MatusKysel]

• Attestation reuse vs cache value: even though each block height advances, multiple attestations can reference the same snapshot/block (e.g., several votes for a given height or retries across peers). In
  that case:
  • The snapshot fingerprint is reused across all attestations for that block, so caching avoids re-hashing validator sets repeatedly.
  • The BLS pubkey cache is reused across all attestations from the same validator set; validator pubkeys don’t change every block, so this cache definitely saves work.
    If your workload truly never reuses the same snapshot or pubkey (one attestation per block, no repeats), the fingerprint cache gives little benefit. The pubkey cache remains useful because validators
    persist.
• Duplicate block imports: the recent dedupe changes were on transaction ingress/pending-imports and recovered-tx caching, not on block import. If you’ve added code upstream to drop duplicate block imports,
  that’s orthogonal. The cache work here is to reduce repeated signature recovery/attestation validation when the same items arrive multiple times (from different peers or retries), not to fix block reimports.