feat: add fulu fork support

[mattevans]

Summary

Add support for Fulu fork changes with BPO support.

Changes

• Add FetchAndSetBlobSchedule() to fetch and configure BPO schedule from beacon node, ensuring correct fork digest calculation.
• Introduce version-aware wrapper types (StatusHolder, MetadataHolder) to handle multiple protocol versions.
• Add StatusV2 and MetadataV3 (returns MetaDataV2 type) RPC handlers with proper protocol registration.
• Implement fork-aware initialisation of local metadata (V0/V1/V2) based on active fork epoch.
• Add fork-aware status setting that selects StatusV1 or StatusV2 based on Fulu fork activation.
• Adds separate SetStatusV1/SetStatusV2 and SetMetaDataV2 methods.
• Remove reliance on network/forks import, removed upstream in Prysm.
• Replace removed ETH2Key constant with hardcoded "eth2" string for ENR entries, removed upstream in Prysm.

Testing:

Kurtosis Config (fusaka.yaml)

participants_matrix:
  el:
    - el_type: nethermind
      el_image: ethpandaops/nethermind:master
  cl:
    - cl_type: prysm
      cl_image: ethpandaops/prysm-beacon-chain:develop
      cl_extra_params:
        - --subscribe-all-subnets
        - --subscribe-all-data-subnets
      supernode: true
      vc_type: prysm
      vc_image: ethpandaops/prysm-validator:develop
    - cl_type: teku
      cl_image: ethpandaops/teku:master
      supernode: true
    - cl_type: lodestar
      cl_image: ethpandaops/lodestar:fusaka-devnet-3
      supernode: true
    - cl_type: lighthouse
      cl_image: ethpandaops/lighthouse:getBlobs-flag-d3c0634
      supernode: true
    - cl_type: lighthouse
      cl_image: ethpandaops/lighthouse:getBlobs-flag-d3c0634
      supernode: true
global_log_level: info
ethereum_metrics_exporter_enabled: true
snooper_enabled: true
keymanager_enabled: true
additional_services:
  - dora
  - spamoor
  - apache
spamoor_params:
  image: ethpandaops/spamoor:latest
  max_mem: 4000
  spammers:
    - scenario: eoatx
      config:
        throughput: 200
    - scenario: blobs
      config:
        throughput: 20
ethereum_genesis_generator_params:
  image: pk910/dev-images:egg-fulu
network_params:
  fulu_fork_epoch: 1
  bpo_1_epoch: 1
  bpo_1_max_blobs: 9
  bpo_1_target_blobs: 6
  bpo_2_epoch: 2
  bpo_2_max_blobs: 18
  bpo_2_target_blobs: 12
  bpo_3_epoch: 3
  bpo_3_max_blobs: 9
  bpo_3_target_blobs: 6
  bpo_4_epoch: 4
  bpo_4_max_blobs: 18
  bpo_4_target_blobs: 12
  bpo_5_epoch: 5
  bpo_5_max_blobs: 9
  bpo_5_target_blobs: 6
  withdrawal_type: "0x02"
  min_validator_withdrawability_delay: 1
  shard_committee_period: 1
  churn_limit_quotient: 16
  genesis_delay: 60
apache_port: 40000
port_publisher:
  nat_exit_ip: YOUR_IP_HERE
  cl:
    enabled: true
    public_port_start: 43000
  el:
    enabled: false
    public_port_start: 42000

Run cmd

go run ./cmd/hermes \
    --data.stream.type=output \
    --log.level=warn \
    eth \
    --chain=devnet \
    --prysm.host=127.0.0.1 \
    --prysm.port.grpc=43005 \
    --prysm.port.http=43001 \
    --libp2p.host=0.0.0.0 \
    --genesis.ssz.url=http://127.0.0.1:40000/network-configs/genesis.ssz \
    --config.yaml.url=http://127.0.0.1:40000/network-configs/config.yaml \
    --bootnodes.yaml.url=http://127.0.0.1:40000/network-configs/boot_enr.yaml \
    --deposit-contract-block.txt.url=http://127.0.0.1:40000/network-configs/deposit_contract_block.txt

Note

Updates prysm dep to latest develop commit. They are actively working on merging fulu support into their develop branch. We can probably wait for them to cut an official release before we update the dep and merge.

[cortze]

It looks really good on my end. Thanks, @mattevans, for the hard work and for contributing upstream!

The only thing that I'm slightly worried about is the peer discovery:

• We set the fork_digest right at the beginning of running the discovery service with: discovery.Serve(). However, this doesn't seem to be aware of the BPO upgrade. (here)
• It wasn't an issue before, as we generally had to upgrade Hermes on each hard fork, computing the new fork-digest. However, given that we are filtering by fork-digest here, it seems likely to generate connectivity issues after each BPO.

// line 192
if !bytes.Equal(forkEntry.CurrentForkDigest, digest[:]) {
	// irrelevant network
	continue
}

Let's coordinate on this. I'm also happy to give a hand here

[cortze]

Closing this in favour of #79