core: gloas builder preferences duty (SignedBuilderRequestAuth aggregation)
Los mantenedores suelen responder en 1 día
@KaloyanTanev ya está trabajando en esto.
Desde el 24/9/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
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.
- Lenguaje dominante
- Go
- Estrellas
- 223
- Forks
- 139
- Merge medio
- 1 d 10 h
- PR fusionados (30 d)
- 74
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ObolNetwork/charon
-
execution client version blankAbiertoprotocol
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
ObolNetwork/charon#4766 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
core/infosync: remove dead proposal topicQuizá libre de nuevo @KaloyanTanev la tomó hace 28 días y no hay ningún pull request abierto. Abiertoenhancement protocol
ObolNetwork/charon#4728 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
bug protocol
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
ObolNetwork/charon#4711 ·
Los mantenedores suelen responder en 1 día
-
protocol
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
ObolNetwork/charon#4710 ·
Los mantenedores suelen responder en 1 día
-
exit: charon exit sign --all skips validators with pending deposits not yet on the beacon chainAbiertoprotocol
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
ObolNetwork/charon#4701 ·
Los mantenedores suelen responder en 1 día
Todos los issues de ObolNetwork/charon
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
area/frontend/library-panels automated-triage type/bug type/ux
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
microsoft/azure-linux-image-tools#954 ·
Los mantenedores suelen responder en 1 día
-
panic "time: missing Location in call to Time.In" on MySQL via aws_rds since v0.8.0Posiblemente ocupada @tylertechgraves la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
open-policy-agent/opa-control-plane#452 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[bug bash] Actor logs are controlled by Kubernetes RBAC on the pool namespace, not atespace rolesAbiertoarea/cli area/security bug-bash kind/docs
Dificultad 1/5 1-3 horas Aptitud para principiantes 80/100
agent-substrate/substrate#3242 ·
Los mantenedores suelen responder en 1 día