Gloas hardfork

🎯 Problem to be solved

Prepare Charon for gloas hardfork

🛠️ Proposed solution

• Gloas groundwork
  • Spec-driven per-fork slot timing (#4617)
  • Migrate SSZ from fastssz to dynssz (#4652)
  • Bump go-eth2-client to gloas types + transport (v0.29.0-obol.2-gloas)
  • Gloas in the fork schedule (#4659)
• PTC (payload attestation) duty
  • DutyPayloadAttestation duty type + PTC signing domain (#4618)
  • Core types: PayloadAttestationData, SignedPayloadAttestationMessage (#4653)
  • DutyDB support (#4656)
  • VC endpoints: payload_attestation_data + pool submission (#4657)
  • Adopt go-eth2-client payload attestation interfaces (#4658)
  • Scheduler duty resolution (#4659)
  • Fetcher: fetch data, handle 204 no-block-seen (#4667)
  • Versioned payload attestation data + message types (#4663, #4668)
  • Bcast: submit aggregated messages (#4668)
  • Serve duties/ptc from charon with pubshare mapping (#4669)
  • validatormock support + e2e simnet test (#4670)
• Fork readiness observability
  • Readiness metrics for charon/BN/VC/EL (#4660)
  • Populate per-fork minimum client versions once fork-ready releases exist
  • Fork-aware proposer deadline, SSE thresholds, quarter-slot buckets (#4676)
  • Retitle Grafana Charon Overview v3 "%% of Blocks Processed after 4s" panel to 3s after gloas activation
• Attestations
  • Accept gloas-versioned attestations (#4671)
  • Optional deprecated committee_index query param (#4672)
  • data.index payload-status bit: no handling needed, BN sets it and charon agrees on data opaquely; regression test (#4671)
• Block production (ePBS)
  • Produce block v4 with include_payload — now POST /eth/v4/validator/blocks/{slot} with a required BuilderConfig body (beacon-APIs#630, client support in attestantio/go-eth2-client#323)
    • Proxy the BuilderConfig body: substitute threshold-aggregated SignedBuilderRequestAuths for the VC's partial ones before forwarding to the BN (partial auths are useless to builders)
    • Watch beacon-APIs#627 produceBlockV4WithBid — explicitly motivated by multi-BN/DV setups, may become the preferred DV flow
  • Execution payload envelope publishing
  • Proposer preferences signed duty — supersedes prepare_beacon_proposer + register_validator (#4691)
    • Adopt go-eth2-client proposer-preferences interfaces (gated on attestantio/go-eth2-client#316)
    • DutyProposerPreferences type + DOMAIN_PROPOSER_PREFERENCES
    • Core (Versioned)ProposerPreferences + partial-signed type
    • Serve v2 proposer duties with the E-2 shuffling dependent_root
    • SubmitProposerPreferences intake (sync-message model, non-blocking 2XX)
    • ParSigDB/ParSigEx/SigAgg + Bcast; key by (validator, proposal_slot, dependent_root); gossip ahead of slot
    • Warn + metric on fee_recipient / gas_limit mismatch vs lock
    • validatormock + simnet e2e
  • Builder preferences signed duty — SignedBuilderRequestAuth aggregation (builder-specs gloas/validator.md)
    • Mechanics: the proposer key signs BuilderRequestAuth{data, slot} under DOMAIN_BUILDER_REQUEST_AUTH — data is out-of-band bytes per builder (default: UTF-8 of the builder's advertised URL, byte-exact), slot is the proposal slot. One signature per (builder, proposal_slot) authenticates both submitBuilderPreferences and getExecutionPayloadBid. max_execution_payment is NOT signed (rides beside the auth). No timestamp / dependent_root → partials aggregate iff all VCs carry byte-identical builder url/auth_data (config alignment via #4692). Submitted the epoch before the proposal (state.proposer_lookahead).
    • DutyBuilderPreferences type + DOMAIN_BUILDER_REQUEST_AUTH
    • Core signed data type for SignedBuilderRequestAuth; aggregation key (validator, proposal_slot, auth data)
    • VAPI intake: POST /eth/v1/validator/builder_preferences (batched BuilderPreferencesEntry; sync-message model, non-blocking 2XX; pubshare→pubkey swap; deterministic cluster max_execution_payment alongside the aggregated auth)
    • ParSigDB/ParSigEx/SigAgg + Bcast: forward aggregated entries to the BN ahead of the proposal (gated on go-eth2-client builder-preferences support)
    • Reuse the aggregated auths in the produce-block-v4 BuilderConfig proxy (see above)
    • validatormock + simnet e2e
  • Distribute cluster fee recipient / gas limit to VCs — charon-generated file, VC restart to apply; no keymanager API (#4692)
    • Extend to builder config: byte-identical builder url/auth_data (signed into the auth) + min_bid/builder_boost_factor/max_execution_payment across nodes (Prysm proposer-settings v2 extends the same file charon generates) (#4704)
  • Fork-gate legacy --builder-api behaviors at the gloas epoch — the flag's jobs all belong to the mev-boost architecture and dissolve post-gloas (participation becomes the granular --builder-* values; "enabled" ≈ non-empty builder URLs)
    • Scheduler: stop submitting validator registrations from the fork epoch (registrations are deprecated, superseded by the proposer preferences duty; nothing consumes them post-fork)
    • Fetcher/router: builder_boost_factor=MaxUint64 override only applies to produceBlockV3 (v4 takes it from the BuilderConfig body)
    • Infosync: builder vs full proposal-type negotiation is meaningless for v4 proposals (no blinded/full split)
    • Proposer config file: v1 builder.enabled is ignored by v2 consumers; keep emitting for pre-gloas VCs only
    • Deprecate the flag once pre-gloas support is dropped
• Testing
  • e2e duty timing migration test, thirds to quarters (#4670)
  • Devnet testing

🔗 References

• Consensus spec (gloas)
• Beacon API