core: gloas builder preferences duty (SignedBuilderRequestAuth aggregation)
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
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)
- Ahead-of-time preferences submission — standardized in beacon-APIs #630 (
POST /eth/v1/validator/builder_preferences, operationIdsubmitBuilderPreferences, merged 2026-08-24; builder-side counterpartPOST /eth/v1/builder/builder_preferences/{proposer_pubkey}in builder-specs #160). The VC submits a batched list ofBuilderPreferencesEntry{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. - Inline at proposal time — the same
SignedBuilderRequestAuthalso rides in eachBuilderEntry.Authof theBuilderConfigbody ofproduceBlockV4(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
-
DutyBuilderPreferencestype +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(batchedBuilderPreferencesEntry; 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
BuilderConfigproxy: await the aggregated per-slot auth from the DB with a timeout; substitute it intoBuilderEntry.Auth; on timeout send an emptyBuilderConfig. - Handle the inline-only path (Nimbus): auths arriving in the produceBlockV4
BuilderConfigbody rather than via the preferences endpoint. - Preserve the
Eth-Builder-Urlresponse-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
submitBuilderPreferencesclient 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
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ObolNetwork/charon
-
protocol
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
ObolNetwork/charon#4766 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
core/infosync: remove dead proposal topicForse già presa @KaloyanTanev l’ha presa 24 giorni fa. Apertaenhancement protocol
ObolNetwork/charon#4728 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
bug protocol
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
ObolNetwork/charon#4711 ·
I maintainer di solito rispondono entro 1 giorno
-
protocol
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
ObolNetwork/charon#4710 ·
I maintainer di solito rispondono entro 1 giorno
-
exit: charon exit sign --all skips validators with pending deposits not yet on the beacon chainApertaprotocol
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
ObolNetwork/charon#4701 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di ObolNetwork/charon
Issue simili
-
native
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
prime-radiant-inc/evener#4839 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
521xueweihan/HelloGitHub#4073 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
goharbor/terraform-provider-harbor#655 · 1 commento ·