Add safe block visualization from fast_confirmation event stream

[barnabasbusa]

Summary

Config to test with:

participants_matrix:
  el:
    - el_type: geth

  cl:
    - cl_type: lodestar
      cl_extra_params:
        - --chain.fastConfirmation=true
    - cl_type: nimbus
    - cl_type: grandine
      cl_image: ethpandaops/grandine:bomanaps-feature-fcr-minimal
      cl_extra_params:
        - --fast-confirmation-rule
    - cl_type: prysm
  count: 2
global_log_level: debug
network_params:
  preset: minimal

additional_services:
  - dora

Adds support for the fast_confirmation beacon event stream topic (fast confirmation rule, see ethereum/beacon-APIs#616) and visualizes the resulting safe block in the UI.

Backend

• Subscribes to the fast_confirmation topic as an optional ancillary SSE stream per beacon node. Nodes that don't support the topic reject the subscription with a 4xx response, in which case the stream silently gives up — so the feature auto-activates only on FCR-enabled nodes, with no config needed.
• Parses the event payload (block, slot, and the optional current_slot added by beacon-APIs#616) with a local type, since the pinned go-eth2-client doesn't carry current_slot yet.
• Tracks the most recent fast confirmed (safe) block per client (Client.GetLastFastConfirmation()) and network-wide in the chain state (ChainState.GetFastConfirmedBlock(), monotonic by slot), plus a per-client SubscribeFastConfirmationEvent() dispatcher for future consumers.

Frontend

• Index page: the network overview shows the safe slot next to the current slot (with a shield indicator), and canonical slots at/below the safe slot get a shield marker in the recent slots list. Both update live via the existing /index/data polling.
• Consensus clients page: new sortable "Safe Slot" column showing each node's last fast confirmed block (linked to the slot page). The column only appears when at least one node reports fast confirmations; nodes without FCR show a dash.
• API: /v1/clients/consensus now includes fcr_enabled, safe_slot and safe_root per client, and a new dedicated /api/v1/network/fast_confirmation endpoint returns the network-wide safe block (slot, root, epoch, last confirmation time) plus per-client fast confirmation status.

The UI additions are hidden entirely on networks where no node emits fast confirmation events.

[qu0b-reviewer]

🤖 qu0b-reviewer

Confirmed: for offset = 2^64-1, offset+32 wraps to 31, which fails the > len(data) guard, so execution proceeds to data[offset : offset+32] with the original huge offset → panic (slice bounds out of range). This is reachable from an untrusted RPC response and would crash the ENS worker (restarting every 10s in a panic loop).

Summary

The PR adds safe-block shield icons (driven by GetFastConfirmedBlock) plus a new ENS resolver service that swaps rendered addresses for primary ENS names. The safe-block logic and most of the ENS plumbing look correct. One robustness bug exists in the ABI string decoder: a crafted/erroneous eth_call return can panic the resolver worker.

Issues

• 🟡 services/ensresolver_ens.go:316 — decodeENSString guards with offset+32 > uint64(len(data)) and offset+32+length > uint64(len(data)), but offset/length are uint64 taken from raw return bytes. A value near 2^64 makes offset+32 wrap (e.g. 2^64-1+32 == 31), bypassing the guard, then data[offset : offset+32] indexes out of range and panics. Since runUpdaterLoop runs this in the ENS worker (and re-enqueues on error but not on panic), a single bad/malicious RPC response puts the resolver into a 10s panic-restart loop. Compare against data length with overflow-safe checks, e.g. offset <= uint64(len(data))-32 && length <= uint64(len(data))-(offset+32), or reject offset/length exceeding len(data).

Suggestions

• services/ensresolver_ens.go:316 — clamp/validate offset and length with big.Int.Cmp against the actual byte length before slicing to avoid the unsigned-overflow wrap.

---

_{Reviewed @ af9d539b
"If your only tool is a hammer, every problem looks like a microservice."}