Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

core: gloas builder preferences duty (SignedBuilderRequestAuth aggregation)

Aperta
#4,724 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@KaloyanTanev ci sta già lavorando.

Dal 24/9/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

protocol

Summary

From the gloas fork, a proposer authorizes each execution-payload builder with a SignedBuilderRequestAuth — the proposer key signs BuilderRequestAuth{data, slot} under DOMAIN_REQUEST_AUTH (data = the builder's out-of-band identity, default its lowercase hostname; slot = the proposal slot the auth is valid for). In a distributed validator this signature is a threshold BLS signature and must be aggregated across the cluster before it is usable — no single node's partial is valid to a builder.

This is the "builder preferences signed duty" line item on the gloas epic (#4324), scoped out here after auditing the spec and all five clients.

The auth reaches the beacon node via two paths (charon must handle both)

  1. Ahead-of-time preferences submission — standardized in beacon-APIs #630 (POST /eth/v1/validator/builder_preferences, operationId submitBuilderPreferences, merged 2026-08-24; builder-side counterpart POST /eth/v1/builder/builder_preferences/{proposer_pubkey} in builder-specs #160). The VC submits a batched list of BuilderPreferencesEntry{proposer_pubkey, url, auth: SignedBuilderRequestAuth, max_execution_payment}, "MAY submit in the epoch prior to proposing". The beacon node forwards each entry to the builder. Reference implementation is Lodestar #9832.
  2. Inline at proposal time — the same SignedBuilderRequestAuth also rides in each BuilderEntry.Auth of the BuilderConfig body of produceBlockV4 (POST /eth/v4/validator/blocks/{slot}).

The auth is content-independent ({data, slot} only, both known an epoch ahead), so it is pre-signable and pre-aggregatable — it fits charon's ahead-of-slot aggregation pattern (like randao / proposer preferences), not inline-only.

Note: go-eth2-client v0.29.0-obol.4-gloas has the SignedBuilderRequestAuth/BuilderConfig types but no submitBuilderPreferences client method — the library predates beacon-APIs #630. charon either bumps the fork past #630 landing or hand-rolls the route.

Client support (as of the devnet branches audited)

Client BN /eth/v1/validator/builder_preferences endpoint VC submits preferences ahead of proposal Auth inline in produceBlockV4 BuilderConfig
Lodestar (ref impl, #9832) Yes Yes — ~8 slots ahead, current + next epoch, re-submits on reorg Yes
Prysm (#17392 / #17397) Yes Yes — pushed with proposer settings, prior epoch Yes
Lighthouse (unstable) Yes Yes — per-slot, current + next epoch Yes
Nimbus No No Inline only — auth in the produceBlockV4 BuilderConfig
Teku (glamsterdam-devnet-8) No — SSZ types only, no HTTP surface No No — produceBlockV4 still a bodyless GET

So three of five (Lodestar, Prysm, Lighthouse) drive the ahead-of-time submission path; Nimbus uses the inline path only; Teku has neither wired yet.

Proposed design (aggregate like randao, with a timeout)

  • When a VC's builder-preferences request arrives, charon extracts the partial SignedBuilderRequestAuth(s), keyed by (validator, proposal_slot, auth_data), and exchanges them with peers via ParSigEx exactly as randao partials are exchanged, aggregating into the DB.
  • The consumer (the produceBlockV4 / block-production path that must attach the aggregated auth) waits on the DB to resolve the aggregated signature, with a timeout. It must not be a blocker: on timeout charon sends an empty BuilderConfig (no builder entries), degrading to P2P / local bids rather than failing the proposal.
  • Because the VCs submit ahead of time (per-slot / prior epoch, per the table), a threshold of partials will usually already be present when the request needs the auth — so the DB resolves instantly in the common case; the timeout only guards the cold/degraded path.

Tasks

  • DutyBuilderPreferences type + DOMAIN_REQUEST_AUTH (naming per go-eth2-client: BuilderRequestAuth / SignedBuilderRequestAuth).
  • Core signed-data type for SignedBuilderRequestAuth; aggregation key (validator, proposal_slot, auth_data).
  • VAPI intake: serve POST /eth/v1/validator/builder_preferences (batched BuilderPreferencesEntry; pubshare→pubkey swap; sync-message model, non-blocking 2XX), submitting partial auths to ParSigEx.
  • ParSigDB / ParSigEx / SigAgg / AggSigDB wiring for the auths.
  • Produce-block-v4 BuilderConfig proxy: await the aggregated per-slot auth from the DB with a timeout; substitute it into BuilderEntry.Auth; on timeout send an empty BuilderConfig.
  • Handle the inline-only path (Nimbus): auths arriving in the produceBlockV4 BuilderConfig body rather than via the preferences endpoint.
  • Preserve the Eth-Builder-Url response-header round-trip (produceBlockV4 response → block publish) so the BN forwards the signed block to the winning builder.
  • Bump go-eth2-client past beacon-APIs #630 (for the submitBuilderPreferences client method) or hand-roll the route.
  • validatormock + simnet e2e.

Caveats

  • All of this tracks pre-release drafts; client PRs note OpenAPI conformance tests still skip these endpoints "until builder-specs and beacon-APIs cut a release," so route strings / type names may still shift. Pin the go-eth2-client version that first carries the submitter before building against it.
Lingua principale
Go
Stelle
223
Fork
139
Merge medio
1g 16h
PR unite (30g)
64

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ObolNetwork/charon

Tutte le issue di ObolNetwork/charon

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.