Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

core: gloas builder preferences duty (SignedBuilderRequestAuth aggregation)

Abierto
#4,724 1 comentario 0 reacciones 1 asignado Ver en GitHub

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

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.
Lenguaje dominante
Go
Estrellas
223
Forks
139
Merge medio
1 d 10 h
PR fusionados (30 d)
74

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ObolNetwork/charon

Todos los issues de ObolNetwork/charon

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.