Skip to content
Merged
Show file tree
Hide file tree
Changes from 49 commits
Commits
Show all changes
58 commits
Select commit Hold shift + click to select a range
74b53c1
initial builder-api for gloas
bharath-123 Dec 17, 2025
0c55646
updates
bharath-123 Dec 12, 2025
278df30
pass in params while querying execution payload bid
bharath-123 Dec 12, 2025
1577ba9
introduce validator registrations v2
bharath-123 Dec 16, 2025
a3db7f7
run doctoc
bharath-123 Dec 17, 2025
df52176
update validator registration v2
bharath-123 Dec 17, 2025
6e1a777
add more specs
bharath-123 Dec 17, 2025
80974bc
run lint
bharath-123 Dec 17, 2025
a242d3b
updates
bharath-123 Dec 17, 2025
4ab5a0f
abstract execution_payment_accepted to a BuilderPreferences struct
bharath-123 Dec 18, 2025
9901fdc
minor fixes
bharath-123 Dec 18, 2025
6959fda
run doctoc
bharath-123 Dec 18, 2025
e752694
use correct method to check if builder is active
bharath-123 Dec 19, 2025
d5773ac
save
bharath-123 Dec 23, 2025
68c1f21
updates
bharath-123 Dec 23, 2025
373493a
add information for bidding
bharath-123 Dec 23, 2025
b0d9542
update
bharath-123 Dec 23, 2025
77be521
add bid request auth
bharath-123 Jan 6, 2026
56a5ec9
remove builder index from validator registration
bharath-123 Jan 6, 2026
dd644e5
add validator registration type
bharath-123 Jan 6, 2026
80dbeb0
link to api calls
bharath-123 Jan 7, 2026
3a9640a
add some notes
bharath-123 Jan 7, 2026
8962cc3
fix return type of execution_payload_bid.yaml
bharath-123 Jan 7, 2026
2cdc29c
use max_trusted_bid in builder preferences
bharath-123 Jan 7, 2026
5ab4d6d
run linter
bharath-123 Jan 8, 2026
f4a9e04
fix spellchecker
bharath-123 Jan 8, 2026
35fb5a7
update bid request auth according to feedback
bharath-123 Jan 8, 2026
e33dfed
minor updates
bharath-123 Jan 8, 2026
8aaa3b5
use a salt in the bid request auth
bharath-123 Jan 9, 2026
3625f54
correctly render constants table
bharath-123 Jan 9, 2026
66c15dc
address feedback
bharath-123 Jan 9, 2026
31dc1d4
update bid request auth to request auth
bharath-123 Jan 14, 2026
0644e07
fix typo
bharath-123 Jan 20, 2026
b02106f
use salt instead of url
bharath-123 Jan 23, 2026
dbce4d6
use get-upcoming-proposal-slots
bharath-123 Jan 27, 2026
b0e3d0c
Update liveness failsafe section
bharath-123 Feb 6, 2026
e7d4321
update RequestAuth types
bharath-123 Feb 6, 2026
37c8e87
deprecate validator registrations in favour of proposer preferences
bharath-123 Mar 9, 2026
3b5735b
updates to api
bharath-123 Mar 12, 2026
19c272f
run lint
bharath-123 Mar 12, 2026
18ca2ed
remove description of proposer preferences
bharath-123 Mar 16, 2026
c1f2af3
add validator pubkey in builder preferences and request auth
bharath-123 Mar 30, 2026
48c6ad8
specify setting fee reicpient in execution payload bid
bharath-123 Apr 25, 2026
3d53d8d
updates to epbs
bharath-123 Apr 30, 2026
d125dea
updates
bharath-123 May 8, 2026
5a618ae
minor updates
bharath-123 May 8, 2026
6429ef9
address feedback
bharath-123 May 8, 2026
9d4a18d
minor updates
bharath-123 May 11, 2026
fbc4747
add an error type for missing auth request
bharath-123 May 12, 2026
7bd4ea1
Endpoint to submit builder preferences (#160)
bharath-123 May 22, 2026
75ea726
Gloas Builder-API spec updates (#161)
bharath-123 Jun 1, 2026
8a51c81
address justins + AntiD2ta feedback
bharath-123 Jun 2, 2026
9ec931e
make the request auth more generic
bharath-123 Jun 8, 2026
1e26b71
rename MAX_URL_BYTES to MAX_DATA_BYTES
bharath-123 Jun 8, 2026
8bf1bee
remove unecessary specification
bharath-123 Jun 9, 2026
1ac301a
update spec to use auth.data instead of auth.builder_url
bharath-123 Jun 9, 2026
b573714
address feedback and add examples
bharath-123 Jun 11, 2026
cd89786
add ssz examples
bharath-123 Jun 11, 2026
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions apis/builder/beacon_block.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
post:
operationId: "submitSignedBeaconBlock"
summary: Submit a signed beacon block with the execution payload bid.
description: |
Submits a `SignedBeaconBlock` to the builder, binding the proposer to the block.

A success response (200) indicates that the signed beacon block was

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Below in responses, it says 202

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah my bad, i ll fix this

valid. If the signed beacon block was invalid, then the builder
must return an error response (400) with a description of the validation
failure.
tags:
- Builder
parameters:
- in: header
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion"
required: false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should make this required, or how exactly do you determine the consensus type otherwise?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes agreed, i was not sure if we should make it required because we don't do it in the previous apis. But I see no harm in making it required. A builder can use the header when they need to.

name: Eth-Consensus-Version
description: "The active consensus version to which the block being submitted belongs. Required if request is SSZ encoded."
requestBody:
description: A `SignedBeaconBlock`.
required: true
content:
application/json:
schema:
type: object
required: [data]
properties:
data:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we usually don't use a data container in the request body

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ll remove that!

$ref: "../../beacon-apis/types/gloas/block.yaml#/Gloas/SignedBeaconBlock"
description: "The signed beacon block."
application/octet-stream:
schema:
description: "SSZ serialized `SignedBeaconBlock` bytes. Use content type header to indicate that SSZ data is contained in the request body."
responses:
"202":
description: Success response.
"400":
description: Error response.
content:
application/json:
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage"
example:
code: 400
message: "Invalid signed beacon block: missing signature"
"415":
$ref: "../../builder-oapi.yaml#/components/responses/UnsupportedMediaType"
"500":
$ref: "../../builder-oapi.yaml#/components/responses/InternalError"
188 changes: 188 additions & 0 deletions apis/builder/execution_payload_bid.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,188 @@
post:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the reason of using POST for a get operation? if POST request is required, what is the reason for putting those 4 params in the path segments, rather than in request body?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used a post cause we are sending the request auth in the body. I put the params in the path segments cause it was what we are doing previously. Let me think more on whether we should put the params in path segments or request body. This point was raised by a builder too

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just pass the signature in the request header? because builder must know its own pubkey and slot is already passed in the path segments, so builder can construct the message, and verify with the signature in the header

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If in the future, we update the request auth the builder would probably need to try multiple structs to verify the signature. Just sending the full body with the signature seems much easier to me to avoid this issue?

operationId: "getExecutionPayloadBid"
summary: Get an execution payload bid.
description: |
Requests a builder node to produce a valid execution payload bid, which
can be integrated into a beacon block and signed.

The proposer sends a POST request to the builder with the following information:
- The slot for which the block should be proposed.
- The hash of the execution layer block the proposer will build on.
- The root of the beacon block the proposer will build on.
- The index of the proposer.
- The `X-Eth-Max-Trusted-Bid` header carrying the proposer's

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a big fan of the X-Eth-Max-Trusted-Bid. If we already have the builder preference flow, why do we need this header? If a validator hasnt submitted builder preference I think we should just assume max trusted bid is u64::max.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I agree with not having the header. If the validator has not submitted the preference, I think we should just assume max trusted bid is 0 and all payments are trustless? But I have a PR to remove the header here: https://github.com/ethereum/builder-specs/pull/161/changes#diff-a186f4bbbe96e38c7699013ced6e58643ff9a03dddbc4fd7584c817920f5ef41L99

`max_trusted_bid` (decimal `uint64`, in Gwei) for this request.
- Optionally, a `SignedRequestAuth` in the request body that
authenticates the request. The body MAY be encoded as JSON
(`Content-Type: application/json`) or SSZ
(`Content-Type: application/octet-stream`).

The `X-Eth-Max-Trusted-Bid` header is required. If it is missing or

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this a header rather than just another field in the body?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not too opinianated on this. We can revisit these aspects.

malformed, the builder MUST NOT serve a bid for the proposer and MUST
return a 400 response.

The `SignedRequestAuth` body is optional. If it is present but malformed
or fails signature verification, the builder MAY return a 400 response.
If it is absent, the builder MAY still serve a bid, but builders MAY
use the presence and validity of the `SignedRequestAuth` to apply
per-validator policy (e.g. rate-limiting, prioritization, or refusing
unauthenticated requests).

The builder responds with a 200 response containing an execution payload bid if it can provide one.

If the builder is unable to produce a valid execution payload bid, then
the builder MUST return a 204 response. If the request is invalid, then the
builder MUST return an error response (400) with a description of the
validation failure.

This API is applicable from Gloas fork onwards.
tags:
- Builder
parameters:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the existing api the query params make sense as it's a GET, but this new one is a POST with a mix of query params, a body, and headers that contain application data rather than just meta data.

Shouldn't it all just be in the body if it's a POST?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I am unopinianated on this. We can discuss this again.

- name: slot
in: path
required: true
description: The slot for which the block should be proposed.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/Uint64"
- name: parent_hash
in: path
required: true
description: Hash of execution layer block the proposer will build on.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/Root"
- name: parent_root
in: path
required: true
description: Root of the beacon block the proposer will build on.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/Root"
- name: proposer_index

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we stick with the proposer pubkey or use proposer index?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could just stick with proposer_index. its much easier to read.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are ideas around reusing the proposer index, whereas the proposer pubkey is more in the custody of the proposer (rather than easily changeable with a protocol change).
Thus, pubkey might be preferable if it doesn't add any complexity.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we use pubkey in the existing getPayloadHeader so maybe for consistency we should stick to pubkey?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This call is in the hot path I don't see any reason to send extra bytes. The slot is signed so index reuse is irrelevant. But this is a soft take. I think getting the index is always cheaper than the pubkey at the point of the call, but I empathize with @eserilev's comment that perhaps the caller code needs to be changed less if we stick to pubkey

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In favour of simplifying client implementation by sticking to pubkeys

@bharath-123 bharath-123 May 27, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in: path
required: true
description: Index of the proposer.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/Uint64"
- name: Date-Milliseconds
in: header
required: false
description: |
Optional header containing a Unix timestamp in milliseconds representing
the point-in-time the request was sent. This header can be used to measure
latency.
schema:
type: integer
format: int64
example: 1710338135000
- name: X-Timeout-Ms

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice if clients agreed NOT to make this configurable.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the advantage in not making it configurable? Would it be incentive compatible?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We ideally don't want people to be able to abuse the X-Timeout-Ms to play timing games and risk orphaning out blocks. As blob counts become higher with upcoming BPOs, timing games can degrade attestation performance.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

refer to https://ethpandaops.io/posts/fusaka-more-blobs-less-votes/ for an analysis on the relation between timing games and attestation performance degradation as blob count increases with BPOs.

@ltitanb ltitanb Jan 16, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my view the tradeoff is that if something is not incentive compatible for the proposer the outcome is just that a subset of "sophisticated" proposers will fork clients, which is undesirable

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it was configurable there'd want to be strict sanity limits imo, but i think it really does open up some degenerate behaviour to have it available potentially... Probably just not having it settable is the better option than the guards it'd need...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it was configurable there'd want to be strict sanity limits imo, but i think it really does open up some degenerate behaviour to have it available potentially... Probably just not having it settable is the better option than the guards it'd need...

Tend to agree with this.

in: header
required: false
description: |
Optional header containing the proposer's timeout for the request in milliseconds.
Builders should use this header to adjust the amount of time by which they delay the
requests to maximise block rewards. Otherwise, requests will timeout and the proposer

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this even specified?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was something added to MEV-Boost by Obol here: flashbots/mev-boost#817 , it made sense to specify it in the builder-spec.

We specify it today too: https://github.com/ethereum/builder-specs/blob/main/apis/builder/header.yaml#L46

This is also a completely optional header which clients don't have to send.

will not receive the header in time.
schema:
type: integer
format: int64
example: 10000
Comment on lines +80 to +82

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

int64 would need to be a string format because of limitations over 54? bits in javascirpt iirc.. @nflaig knows better than me on this though... its the reason most of beacon-api numbers being contained in string anyway...
Not sure if that's a problem here specifically, but figured its worth talking about

@bharath-123 bharath-123 Jun 9, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The header is sent as ASCII bytes over the wire anyways. I think specifying it as int64 here is good to clarify the type of the header value for the servers parsing the header.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is already part of current getHeader

- name: X-Timeout-Ms
in: header
required: false
description: |
Optional header containing the proposer's timeout for the request in milliseconds.
Relays should use this header to adjust the amount of time by which they delay getHeader
requests to maximise block rewards. Otherwise, getHeader requests will timeout and the proposer
will not receive the header in time.
schema:
type: integer
format: int64
example: 10000

I don't think it matters as @bharath-123 already noted as this is not transmitted via json

- name: Eth-Consensus-Version
in: header
required: false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this header not required? if we change SignedRequestAuth in the future it has to be present

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noted this before, I think this header should be required

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah clients should it send it regardless of SSZ or JSON encoding, it seems useful to have in general

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes please 🙏

description: |
The active consensus version to which the `SignedRequestAuth` in the
request body belongs. Required if the request body is SSZ encoded.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion"
- name: X-Eth-Max-Trusted-Bid

@nflaig nflaig May 12, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this rather be a query param, usually we only sent metadata in headers, could also consider making this optional, and omitting it means only trustless bids are accepted, same as setting to 0

in: header
required: true
description: |
Decimal `uint64` (in Gwei) carrying the proposer's `max_trusted_bid`
for this request. `bid.execution_payment` MUST NOT exceed this value.
A value of `0` indicates that the proposer does not accept any
trusted payments from this builder. A value of `2**64 - 1`
(`MAX_TRUSTED_BID`) indicates that the proposer accepts any trusted
payment amount. If the header is missing or malformed, the builder
MUST return a 400 response.
schema:
type: integer
format: uint64
example: 1000000000
requestBody:
description: |
Optional `SignedRequestAuth` authenticating the request. If provided,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for this dumb question, how can a proposer learn about builder_pubkey to construct the RequestAuth?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not at all a dumb question. A builder should advertise their builder_pubkey along with their URL similar to how we know the relay pubkey today along with the url. like:

https://0xa15b52576bcbf1072f4a011c0f99f9fb6c66f3e1ff321f11f461d15e31b1cb359caa092c71bbded0bae5b5ea401aab7e@aestus.live

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if there is an endpoint say GET /eth/v1/builder/identity or any suitable one to return the builder_pubkey as well as a field to indicate whether the builder require SignedRequestAuth from proposer to request payload bid?

@bharath-123 bharath-123 May 27, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An identity endpoint makes a lot of sense and is better than embedding this info into the status endpoint. I will spec this endpoint.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool! when will we have a last call to get this PR sort out? It's been a while now, I'm still hesitate to implement since there is still stuff moving around

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure yet about the last call for this PR haha, will raise it in ACDC this week!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I wouldn't recommend to start implementation on this as of now yet.

the builder MAY verify the BLS signature against the validator pubkey
resolved from the `proposer_index` path parameter, and check that
`builder_pubkey` matches its own identity and that `slot` matches the
requested slot. If absent, the builder MAY still serve a bid subject
to its own policy.
required: false
content:
application/json:
schema:
$ref: "../../types/gloas/request_auth.yaml#/Gloas/SignedRequestAuth"
application/octet-stream:
schema:
description: "SSZ serialized `SignedRequestAuth` bytes. Use Content-Type header to indicate that SSZ data is contained in the request body. The `Eth-Consensus-Version` header MUST also be set."
responses:
"200":
description: Success response.
headers:
Eth-Consensus-Version:
$ref: "../../builder-oapi.yaml#/components/headers/Eth-Consensus-Version"
required: false
content:
application/json:
schema:
title: GetExecutionPayloadBidResponse
type: object
required: [version, data]
properties:
version:
type: string
enum: [ gloas ]
example: "gloas"
data:
$ref: "../../beacon-apis/types/gloas/execution_payload_bid.yaml#/Gloas/SignedExecutionPayloadBid"
application/octet-stream:
schema:
description: "SSZ serialized `SignedExecutionPayloadBid` bytes. Use Accept header to choose this response type"
"204":
description: No bid is available.
"400":
description: Error response.
content:
application/json:
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage"
examples:
InvalidHash:
value:
code: 400
message: "Unknown hash: missing parent hash"
InvalidAuth:
value:
code: 400
message: "Invalid SignedRequestAuth: signature verification failed"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be 401 as well no?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

401 is if the authorization fails or is not valid. I think this makes sense to be a 401.

MissingMaxTrustedBid:
value:
code: 400
message: "Missing X-Eth-Max-Trusted-Bid header"
"401":
description: Authentication required.
content:
application/json:
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage"
examples:
MissingAuth:
value:
code: 401
message: "Missing SignedRequestAuth: this builder requires authenticated requests"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if SignedRequestAuth is optional, why there is error for missing it?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that it is optional for the proposer to send the request with a SignedRequestAuth, but the spec also says that if it is absent, the builder MAY still serve a bid.

Shall we also include a 403 error for the case where the signature was provided, but the signature is invalid, and the builder requires auth?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some builders might require it, in that case they could send an error back instead of sending a bid back.
The intention of this error code is to offer a standard error code and message for these builders to return if they indeed require the auth.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about an error code to explicitly state that the signature is invalid?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that does make sense to have! I will add that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"406":
$ref: "../../builder-oapi.yaml#/components/responses/NotAcceptable"
"415":
$ref: "../../builder-oapi.yaml#/components/responses/UnsupportedMediaType"
"500":
$ref: "../../builder-oapi.yaml#/components/responses/InternalError"
14 changes: 12 additions & 2 deletions builder-oapi.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,10 @@ paths:
$ref: "./apis/builder/validators.yaml"
/eth/v1/builder/header/{slot}/{parent_hash}/{pubkey}:
$ref: "./apis/builder/header.yaml"
/eth/v1/builder/execution_payload_bid/{slot}/{parent_hash}/{parent_root}/{proposer_index}:
$ref: "./apis/builder/execution_payload_bid.yaml"
/eth/v1/builder/beacon_block:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty sure plural is more correct here, see previous /eth/v2/builder/blinded_blocks

Suggested change
/eth/v1/builder/beacon_block:
/eth/v1/builder/beacon_blocks:

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not too opinionated, we only send back 1 beacon block hahaha. But I am fine with this change

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but this is common REST naming convention, we also call it /eth/v2/beacon/blocks on the beacon-api

$ref: "./apis/builder/beacon_block.yaml"
/eth/v1/builder/blinded_blocks:
$ref: "./apis/builder/blinded_blocks.yaml"
/eth/v2/builder/blinded_blocks:
Expand All @@ -72,7 +76,7 @@ components:
$ref: "./beacon-apis/types/http.yaml#/ErrorMessage"
ConsensusVersion:
$ref: "./beacon-apis/beacon-node-oapi.yaml#/components/schemas/ConsensusVersion"
enum: [bellatrix, capella, deneb, electra, fulu]
enum: [bellatrix, capella, deneb, electra, fulu, gloas]
example: "bellatrix"
Bellatrix.ExecutionPayload:
$ref: "./beacon-apis/types/bellatrix/execution_payload.yaml#/Bellatrix/ExecutionPayload"
Expand Down Expand Up @@ -102,7 +106,11 @@ components:
$ref: "./types/fulu/blobs_bundle.yaml#/Fulu/BlobsBundle"
Fulu.ExecutionPayloadAndBlobsBundle:
$ref: "./types/fulu/execution_payload_and_blobs_bundle.yaml#/Fulu/ExecutionPayloadAndBlobsBundle"

Gloas.RequestAuth:
$ref: "./types/gloas/request_auth.yaml#/Gloas/RequestAuth"
Gloas.SignedRequestAuth:
$ref: "./types/gloas/request_auth.yaml#/Gloas/SignedRequestAuth"

responses:
InternalError:
$ref: "./types/http.yaml#/InternalError"
Expand Down Expand Up @@ -151,3 +159,5 @@ components:
$ref: "./examples/fulu/signed_blinded_beacon_block.json"
Fulu.SignedBuilderBid:
$ref: "./examples/fulu/signed_builder_bid.json"
Gloas.SignedRequestAuth:
$ref: "./examples/gloas/signed_request_auth.json"
9 changes: 9 additions & 0 deletions examples/gloas/signed_request_auth.json

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I will add the SSZ examples. I was considering adding them in a follow up PR.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude was able to get the ssz examples from the json correctly without any issues!

Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
{
"value": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this "value" needed? Shouldn't is just be message and signature?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems to be the common pattern in writing examples in the builder-specs. To encapsulate them in value. I am not too opinionated on this honestly, we can revisit this nit later.

"message": {
"builder_pubkey": "0x93247f2209abcacf57b75a51dafae777f9dd38bc7053d1af526f220a7489a6d3a2753e5f3e8b1cfe39b56f43611df74a",
"slot": "1"
},
"signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"
}
}
Loading
Loading