Ethereum Glamsterdam & Hegota Fork Readiness Assessment #894

Activity

1. techgangboss commented on Feb 23, 2026

   

   techgangboss

   on Feb 23, 2026

   Author

   More actions

   Execution Client Update (primev/erigon)

   Status: Low risk — no immediate action required.

   The mev-commit chain runs on a fork of Erigon (primev/erigon, branch primev/patches), based on Erigon v3.0.5. The fork has only 4 functional modifications:

   1. Fee routing to coinbase — all fees (tip + base + blob) to coinbase instead of burn; zero-fee addresses get refunds
   2. Zero-fee address whitelist — --zerofee.tx.list CLI flag
   3. BLS precompile at 0xF0 — custom BLS12-381 signature verification (cloudflare/circl, Prague activation, 50k+5/byte gas)
   4. Txpool empty block fix — prevents blocking when external CL produces empty blocks

   All Glamsterdam features (EIP-7928 BALs, EIP-8007 gas repricing, Engine API V5, new opcodes) will come with the upstream Erigon rebase — no custom implementation needed. The rebase itself is straightforward given the minimal 8-commit diff. The main conflict point will be core/state_transition.go (fee routing patch).

   ePBS (EIP-7732) does not affect the sidechain execution client — that impact is entirely on the oracle side (covered above in this issue).

   Action

   A full Erigon fork readiness assessment will be done when upstream Erigon ships their Glamsterdam-compatible release. Until then, the only pre-work is:

   • Extract the 4 patches into documented, replayable diffs to make the rebase mechanical
   • Resolve BLS precompile interface inconsistency between the legacy geth fork (primev/mev-commit-geth) and the active Erigon fork (primev/erigon) — different input formats, gas costs, and output formats at the same 0xF0 address
2. techgangboss commented on Feb 23, 2026

   

   techgangboss

   on Feb 23, 2026

   Author

   More actions

   Oracle Builder Attribution: Deep Dive

   How It Works Today

   The oracle (oracle/pkg/l1Listener/l1Listener.go) determines the winning builder for each L1 block exclusively via MEV-Boost relay APIs:

   1. Polls L1 every 2s, lagging 10 blocks behind tip (MEV_ORACLE_LAGGERD_MODE)
   2. For each block, fans out concurrent GET requests to all configured relays:

      GET {relay_url}/relay/v1/data/bidtraces/proposer_payload_delivered?block_number={n}
      

   3. Matches response on block_number AND block_hash — first relay match wins
   4. Extracts builder_pubkey (BLS key) from the relay response
   5. Calls BlockTracker.recordL1Block(blockNum, blsKey) → resolves BLS key to EOA via ProviderRegistry.getEoaFromBLSKey()
   6. Fallback: If no relay returns a match → logs "out of PBS block", records address(0) as winner → no commitments for that block are settled (neither slashed nor rewarded)

   Default relays: Aestus, Titan, Bloxroute Max Profit, Flashbots, Bloxroute Regulated (MEV_ORACLE_RELAY_URLS)

   Can Builder Identity Be Derived Without Relays Today?

   No — not with cryptographic certainty. Every alternative is heuristic and spoofable:

   Method	In block?	Reliable?	Problem
   extra_data (execution header, 32 bytes)	Yes	No	Voluntary, trivially spoofable. Codebase has blockBuilderNameToAddress in BlockTracker but not used in main oracle flow
   fee_recipient / coinbase	Yes	No	Set to the proposer's address, not the builder's. Builder pays proposer via the last tx
   Beacon block body	Yes	No	Contains proposer_index only. No builder field in the consensus protocol
   Beacon graffiti	Yes	No	Set by the proposer/validator, not the builder

   The relay API is the only authoritative source today. The relay verified the builder's BLS signature before forwarding the block to the proposer — that's the chain of trust.

   Post-ePBS (EIP-7732): Builder Attribution Becomes Protocol-Native

   Under ePBS, builders become staked, first-class protocol entities with a 0x03 withdrawal prefix and a persistent builder_index in the beacon state:

   class Builder(Container):
       pubkey: BLSPubkey
       version: uint8
       execution_address: ExecutionAddress
       balance: Gwei
       deposit_epoch: Epoch
       withdrawable_epoch: Epoch

   The BeaconBlockBody replaces ExecutionPayload with SignedExecutionPayloadBid:

   class ExecutionPayloadBid(Container):
       parent_block_hash: Hash32
       parent_block_root: Root
       block_hash: Hash32
       builder_index: BuilderIndex      # ← BUILDER IDENTITY
       slot: Slot
       value: Gwei
       execution_payment: Gwei
       ...

   The bid is BLS-signed by the builder — cryptographically authenticated, non-spoofable. Self-built blocks use builder_index == UINT64_MAX (BUILDER_INDEX_SELF_BUILD).

   Post-ePBS oracle attribution (pseudocode):

   builder_index = beacon_block.body.signed_execution_payload_bid.message.builder_index
   
   if builder_index == UINT64_MAX:
       # Proposer self-built, no external builder → equivalent to "out of PBS block"
   else:
       builder = beacon_state.validators[builder_index]
       builder_pubkey = builder.pubkey
       builder_address = builder.withdrawal_credentials[12:]  # last 20 bytes
   

   Available via standard beacon chain APIs. No relay dependency.

   Migration Path

   Phase	Attribution Source	Relay Dependency
   Now → pre-Glamsterdam	Relay API (builder_pubkey from bidtraces)	Required
   Post-Glamsterdam (transition)	Beacon chain primary (builder_index), relay fallback	Optional
   Steady state	Beacon chain only	Eliminated

   Oracle Action Items (updated)

   • Pre-ePBS (now): No relay-free alternative exists. Current architecture is correct.
   • Pre-ePBS (resilience): Consider adding extra_data heuristic as a secondary signal for monitoring/alerting (not settlement), to detect relay downtime vs actual out-of-PBS blocks
   • Post-ePBS: Rewrite L1Listener to read builder_index from beacon block body via beacon API (/eth/v2/beacon/blocks/{slot}), then look up builder pubkey/address from beacon state
   • Post-ePBS: Update BlockTracker.recordL1Block() to accept builder_index in addition to or instead of BLS key — the ePBS builder_index maps to a pubkey in the beacon state, not the relay-registered BLS key. The ProviderRegistry BLS key mapping needs to align with ePBS builder registration.
   • Post-ePBS: Handle BUILDER_INDEX_SELF_BUILD (UINT64_MAX) — equivalent to current "out of PBS block" behavior
   • Transition: Implement dual-mode oracle that tries beacon chain first, falls back to relay API during the overlap period
   • Prototype on devnet: Use the epbs-devnet-0 infrastructure (ethpandaops) to prototype beacon chain-native attribution

   References

   • EIP-7732: Enshrined PBS
   • Consensus Specs - Builder (ePBS)
   • Flashbots Relay Specs
   • Titan Builder: Builders and Relays in ePBS
   • Strong Builder Identity (ethresear.ch)
   • Beacon API Specification
3. techgangboss commented on Feb 23, 2026

   

   techgangboss

   on Feb 23, 2026

   Author

   More actions

   Post-ePBS Oracle Strategy: Beacon-Only Attribution

   Decision: Beacon chain primary, relay as short-term fallback only — then deprecate relays entirely.

   Post-ePBS, every block built by an external builder will have builder_index in the beacon block body regardless of whether a relay was involved. The beacon path covers 100% of externally-built blocks. The relay path adds no data that the beacon path doesn't already provide.

   The beacon chain source is also strictly superior in trust model — builder_index is cryptographically authenticated via BLS signature and enforced by the consensus protocol. Relay data is just a trusted API response from a third party.

   Why relays become unnecessary for the oracle

   • ePBS replaces the relay's core function (trusted intermediary) with protocol-level mechanisms: the Payload Timeliness Committee and unconditional builder payments at the consensus layer
   • Builder identity is embedded in every beacon block body — no external API call needed
   • Self-built blocks are explicitly flagged (BUILDER_INDEX_SELF_BUILD = UINT64_MAX), replacing the current heuristic of "not found in any relay = out of PBS block"
   • Prysm has already indicated they won't maintain MEV-Boost compatibility post-ePBS

   Rollout plan

   Phase	Duration	Oracle behavior
   Pre-fork	Now → Glamsterdam activation	Relay-only (current)
   Transition	First ~2 weeks post-fork	Beacon chain primary, relay fallback for operational safety
   Steady state	After transition stabilizes	Beacon-only, relay code deprecated and removed

   No investment in long-term dual-mode maintenance — the relay path becomes dead code after transition.
4. techgangboss commented on Feb 23, 2026

   

   techgangboss

   on Feb 23, 2026

   Author

   More actions

   5. Reference Implementation: ePBS Builder Bid Filtering (mev-commit-builder-filter)

   Problem

   Today, mev-commit-relay enforces a critical security invariant: only builders registered in ProviderRegistry (with sufficient stake) can win opted-in slots. The relay filters incoming bids by checking builder BLS keys against the on-chain registry before forwarding to proposers.

   In ePBS (EIP-7732), builders submit SignedExecutionPayloadBids directly to the protocol — no relay in the path. Without a replacement for this filtering, non-registered builders without stake could win opted-in slots, voiding preconfirmation guarantees.

   Solution: mev-commit-builder-filter Go Library

   A Go package that validators import into their consensus client to filter ePBS bids. This is the primary integration path — minimal overhead, no extra processes, no external dependencies.

   Core Components

   1. Registry Sync Client

   • Connects to mev-commit chain RPC
   • Reads ProviderRegistry contract for registered builder BLS pubkeys + stake status
   • Polls every epoch (~6.4 min) or subscribes to registry events (ProviderRegistered, ProviderDeregistered)
   • Maintains in-memory set: map[BLSPubkey]RegistrationInfo

   2. Builder Index Resolver

   • Connects to local beacon node API
   • Maps ePBS builder_index → BLS pubkey via beacon state (builders are staked entities in EIP-7732 with pubkey, execution_address, balance in the Builder container)
   • Caches index→pubkey mappings (stable once assigned)
   • Fetches on cache miss

   3. Bid Filter Engine

   • Resolves builder_index from incoming SignedExecutionPayloadBid → BLS pubkey
   • Checks pubkey against registry set
   • Returns accept/reject

   // Core interface — validators hook this into their bid selection logic
   type BidFilter interface {
       // IsEligible returns true if the builder at this index is registered 
       // in mev-commit ProviderRegistry with sufficient stake
       IsEligible(builderIndex uint64) (bool, error)
       
       // FilterBids returns only bids from registered builders
       FilterBids(bids []SignedExecutionPayloadBid) []SignedExecutionPayloadBid
   }
   
   // Config for the filter
   type Config struct {
       MevCommitRPC   string        // mev-commit chain RPC endpoint
       BeaconAPI      string        // local beacon node API
       RegistryAddr   common.Address // ProviderRegistry contract address
       SyncInterval   time.Duration  // registry refresh interval (default: 1 epoch)
   }

   Integration Point

   Validators add a few lines to their CL client's proposer bid selection:

   filter, _ := mevcommitfilter.New(mevcommitfilter.Config{
       MevCommitRPC: "https://chainrpc.mev-commit.xyz",
       BeaconAPI:    "http://localhost:5052",
       RegistryAddr: common.HexToAddress("0x..."),
   })
   
   // In proposer's bid selection loop:
   eligibleBids := filter.FilterBids(incomingBids)
   // Select best bid from eligibleBids only

   Optional: Commit-Boost Module

   For validators already running Commit-Boost (v0.9.x, audited by Sigma Prime), the same core library can be wrapped as a Commit-Boost CommitModule. This provides the filtering as a single config line addition — no CL client changes needed. This is a convenience path, not a requirement.

   Build Phases

   Phase	What	When
   Phase 1 (now)	Core library: registry sync + BidFilter interface + unit tests	Can start immediately — independent of ePBS client implementations
   Phase 2 (ePBS devnets)	Builder index resolver (depends on CL client beacon API for builder_index → pubkey resolution) + integration tests	When any CL client ships ePBS devnet support
   Phase 3 (optional)	Commit-Boost module wrapper	After Phase 2, for validators who prefer module-based integration

   Open Dependencies

   • ePBS beacon API: The exact endpoint to resolve builder_index → pubkey depends on CL client implementations of EIP-7732 (not yet shipped). The BidFilter interface is stable regardless — only the resolver internals will need updating.
   • CL client bid selection hooks: Each CL client (Lighthouse, Prysm, Teku, Lodestar, Nimbus) exposes proposer bid selection differently. The Go library approach is the most portable — validators import it wherever their client handles bid ranking.

   Enforcement Model (Post-ePBS)

   Two complementary enforcement layers replace the relay's current role:

   1. Proposer-side filtering (this library) — Opted-in validators only consider bids from registered builders. Prevents non-registered builders from winning opted-in slots.
   2. Validator slashing (existing) — If an opted-in validator accepts a bid from a non-registered builder, they can be slashed via PreconfManager. This is the backstop that makes filtering economically enforceable even if a validator doesn't run the filter.

   Together these provide the same security guarantee as the current relay filtering + slashing model, without requiring a centralized relay in the bid path.
5. techgangboss commented on Feb 27, 2026

   

   techgangboss

   on Feb 27, 2026

   Author

   More actions

   Trustless Attribution & Post-ePBS Filtering Architecture

   Following internal discussion, here's a refined approach that eliminates the oracle entirely for builder attribution and maintains relay-based filtering alongside newer enforcement points.

   ---

   Builder Attribution: SSZ Proofs Against EIP-4788 Beacon Roots

   Post-ePBS, builder identity is embedded in the beacon block body as SignedExecutionPayloadHeader at a known SSZ generalized index. EIP-4788 (live since Dencun) exposes parent beacon block roots in the EVM via the BEACON_ROOTS precompile (0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02).

   This enables a fully trustless proof path:

   beacon_root (EIP-4788, on L1)
     → SSZ Merkle proof through BeaconBlockBody
       → SignedExecutionPayloadHeader
         → builder_pubkey
   

   How it works:

   • A verifier contract validates the SSZ Merkle proof on-chain against the beacon root for a given slot
   • BlockTracker.recordL1Block becomes permissionless — any party submits slot number + builder pubkey + proof, the contract verifies
   • No trusted oracle needed. Any party can construct and submit proofs, incentivized by settlement rewards
   • mev-commit chain needs access to L1 beacon roots via the bridge or by mirroring the BEACON_ROOTS precompile

   Considerations:

   • SSZ proof verification is SHA256-heavy (~15-20 tree levels) — gas cost is bounded but non-trivial
   • EIP-4788 stores the parent beacon root, so proofs are available one slot behind — acceptable for settlement which already operates within a window
   • The generalized index for the builder pubkey in the post-ePBS BeaconBlockBody needs to be pinned once the spec stabilizes

   The oracle should be fully deprecated. Rather than keeping it as a speed layer, a clean break removes a trusted dependency and simplifies the architecture. The proof submission path is fast enough for settlement purposes, and removing the oracle eliminates an entire class of trust assumptions and operational overhead.

   ---

   BLS Key Filtering: Three Concurrent Enforcement Points

   Filtering — ensuring only blocks from registered mev-commit providers are accepted when a proposer is opted-in — is a real-time decision at block construction time and can't be solved with proofs. Three enforcement methods should operate concurrently:

   1. Relay (existing, maintained)

   The mev-commit-relay fork's ValidatorOptInRouter filtering remains a valid enforcement point. Many validators will continue using relays post-ePBS — relays may evolve into submission/routing layers even if they're no longer architecturally required for PBS. The relay fork should be maintained as an opt-in filtering method for validators who prefer this path. This is the lowest-friction option for existing mev-commit validators.

   2. Commit-Boost sidecar (new, recommended)

   A Commit-Boost module that intercepts builder submissions and checks ProviderRegistry / ValidatorOptInRouter before the proposer signs. Validators running mev-commit already run extra infra; a Commit-Boost module is incremental. This aligns with the ecosystem direction and works regardless of whether the validator uses a relay.

   3. Consensus layer modification (new, tightest integration)

   Embed the opt-in check directly in the mev-commit CL fork. The CL already has custom logic in cl/blockbuilder/ — extending it to filter based on provider registration status gives the tightest control and lowest latency. More invasive to maintain across upstream CL rebases but offers the strongest guarantees.

   ---

   Target Architecture

   Function	Current	Post-ePBS
   Attribution (settlement)	Trusted oracle polling relay API	SSZ proof against EIP-4788 beacon root (trustless, permissionless)
   Filtering (block production)	Relay fork only	Relay fork + Commit-Boost module + CL mod (concurrent)
   Oracle	Required, trusted	Deprecated

   Updated Action Items

   • Spike: SSZ proof verifier contract — implement Merkle proof validation against BEACON_ROOTS for builder pubkey extraction
   • Determine the SSZ generalized index for builder pubkey in post-ePBS BeaconBlockBody (track spec as it stabilizes on devnet-2)
   • Design the bridge mechanism for L1 beacon roots to be accessible on mev-commit chain
   • Implement permissionless BlockTracker.recordL1Block that accepts proof submissions instead of oracle calls
   • Build Commit-Boost module for ValidatorOptInRouter / ProviderRegistry filtering
   • Extend CL fork (cl/blockbuilder/) with provider registration filtering
   • Maintain relay fork filtering as a concurrent method — update relay to work with ePBS submission flow if relay APIs evolve
   • Plan oracle deprecation timeline: dual-mode during transition, full removal post-ePBS mainnet activation