Gloas (ePBS) support in helix-simulator

[0w3n-d]

Status

helix-simulator's ValidationApi (crates/simulator/src/validation/mod.rs) validates builder submissions by reconstructing a full execution block from the payload and executing it against reth (validateBuilderSubmissionV4/V5). It has no Gloas (ePBS) awareness. Until this lands, helix-relay's SimulatorClient::sim_request_builder returns None for Gloas submissions and they're dropped with BlockSimError::UnsupportedFork (see #517) -- a deliberate stopgap, not support.

Why

Gloas moves the execution payload out of the beacon block and into a separately-bid/revealed envelope (see #489), but a builder still submits a full execution payload to helix for value competition -- helix's own builder-facing wire shape is unchanged for Gloas (#514). That submission still needs EL-side validation (does it execute cleanly, does it pay the proposer the promised value) before helix accepts the bid. Today that validation is delegated entirely to reth, and reth doesn't understand Gloas payloads yet.

Investigated: reth is pinned to a tagged release (v2.4.1) with zero Amsterdam/Gloas awareness anywhere in its execution/consensus/chainspec code. However:

• alloy-rpc-types-beacon (pulled in transitively at the same version) already defines SignedBidSubmissionV6/BuilderBlockValidationRequestV6 for this, including a conversion into alloy_rpc_types_engine::ExecutionData -- the wire types have landed ahead of reth's own execution-layer support.
• reth has an active devnet branch, glamsterdam-devnet-8 -- the same devnet round already used to pin lighthouse in Gloas (ePBS) builder-API support #489's step 0.

This mirrors that step almost exactly: pin to the devnet branch, see what actually compiles and what reth's own block-execution/consensus code still doesn't implement, before committing to a design for the rest.

Affected surface

File	Role today	Gloas impact
crates/simulator/src/validation/mod.rs	ValidationApi::validate_builder_submission_v4/v5, executes payload via reth	Needs a validate_builder_submission_v6 path once reth can construct/execute an Amsterdam block
crates/relay/src/simulator/client.rs::sim_request_builder	picks v4 vs v5 RPC method by fork	Currently returns None for Gloas (#517); needs a v6 arm once step 0 below lands
Cargo.toml (reth-* deps)	pinned to tag v2.4.1	Needs (at least temporarily) glamsterdam-devnet-8, mirroring lighthouse's pin in #489

Steps (each becomes one PR)

• Step 0: Pin reth-* crates to glamsterdam-devnet-8, resolve resulting compile breakage, and assess what Amsterdam/ePBS EL-side validation reth's devnet branch actually implements vs. only defines types for (tests: ) (PR: )
• Step 1+: TBD once step 0 reveals reth's actual devnet-branch support -- likely a validate_builder_submission_v6 path in ValidationApi plus wiring sim_request_builder's Gloas arm to it, but the real shape depends on what step 0 finds.

Open questions

• Does reth's glamsterdam-devnet-8 branch implement Amsterdam block execution/consensus rules, or only the wire/RPC types (mirroring how alloy-rpc-types-beacon shipped V6 types ahead of any execution logic)? Answered by step 0.
• Re-verify this against whatever CL/EL devnet round is actually current once Gloas/Amsterdam nears a release tag rather than a devnet branch (same caveat as Gloas (ePBS) builder-API support #489).

[0w3n-d]

Related: #576 splits the merging role's Gloas gap out of #561, for the same reason this issue is open — the type shapes exist but the layer underneath doesn't carry Amsterdam yet. #561 now ends at documentation, so relay + ethrex simulator + ethrex builder can be tested on a Gloas testnet without either of these.