Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

core: gloas builder preferences duty (SignedBuilderRequestAuth aggregation)

オープン
  • 何か問題がありますか？
#4,724 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@KaloyanTanev がすでに取り組んでいます。

2026年9月24日 から。

評価

この issue はまだ評価されていません。

説明

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.
主要言語
Go
スター
223
フォーク
139
平均マージ
1日 16時間
マージ済み PR（30日）
64

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ObolNetwork/charon のほかの issue

ObolNetwork/charon の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。