feat: add mock-el (Lighthouse lcli) as an EL type

[jimmygchen]

Description

NOTE: this is useful for CL local testing, but may not fit well with the primary "cross client testing" role of this project.

Add mock-el as a new execution layer client type, wrapping Lighthouse's lcli mock-el command. This provides a mock Engine API that accepts all payloads without real block validation, enabling CL testing on live testnets like Hoodi without syncing a real EL from scratch.

Important: mock-el has no block production capability. engine_getPayload returns dummy payloads — validators paired with mock-el will not produce valid blocks. On kurtosis devnets with --all-payloads-valid true, all nodes accept dummy payloads so the chain can still progress.

How it works

• Public networks (mainnet, sepolia, holesky, hoodi): uses --network <name> for automatic fork time handling
• Custom networks (kurtosis devnets, etc.): extracts fork timestamps (shanghaiTime, cancunTime, pragueTime, osakaTime) from genesis.json via jq
• Only exposes a single port (8551) for Engine API — no P2P, WS, or metrics
• Returns empty enode/enr (no EL peering)

Usage

participants:
  - el_type: mock-el
    cl_type: lighthouse

Public network:

network_params:
  network: hoodi
participants:
  - el_type: mock-el
    cl_type: lighthouse

Additional Info

Depends on sigp/lighthouse#8864 for --jwt-secret-path. The default sigp/lcli:latest image will work once that PR is merged; until then, a custom-built image is needed.

[barnabasbusa]

how is it different from dummy el?

[barnabasbusa]

maybe we can swap out the dummy el with the lighthouse lcli image as a default, would that work ? @just

[jimmygchen]

Oh my bad, i didn't know dummy EL exists! that would probably be sufficient but I haven't tried it.

Just had a quick look, looks like dummy EL always returning SYNCING, I guess this is enough for the zk EL use case. mock-el also supports controlling the response to newPayload and forkchoiceUpdated via a --all-payloads-valid CLI flag.