core: gloas builder preferences duty (SignedBuilderRequestAuth aggregation)

Đang mở
  • Có gì không ổn?
#4,724 1 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@KaloyanTanev đang làm issue này rồi.

Từ ngày 24/9/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

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 (#4786, #4787).
  • Bump go-eth2-client past beacon-APIs #630 (for the submitBuilderPreferences client method) or hand-roll the route.
  • validatormock + simnet e2e.

Implemented in #4783 (go-eth2-client v0.30.1-obol.1-gloas), ahead-of-time and inline auths both aggregated.

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.
Ngôn ngữ chính
Go
Star
223
Fork
139
Merge trung bình
1 ngày 3 giờ
Pull request đã merge (30 ngày)
63

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ObolNetwork/charon

Tất cả issue của ObolNetwork/charon

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.