-
Notifications
You must be signed in to change notification settings - Fork 86
Staked Builder API for Glamsterdam #138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
74b53c1
0c55646
278df30
1577ba9
a3db7f7
df52176
6e1a777
80974bc
a242d3b
4ab5a0f
9901fdc
6959fda
e752694
d5773ac
68c1f21
373493a
b0d9542
77be521
56a5ec9
dd644e5
80dbeb0
3a9640a
8962cc3
2cdc29c
5ab4d6d
f4a9e04
35fb5a7
e33dfed
8aaa3b5
3625f54
66c15dc
31dc1d4
0644e07
b02106f
dbce4d6
b0e3d0c
e7d4321
37c8e87
3b5735b
19c272f
18ca2ed
c1f2af3
48c6ad8
3d53d8d
d125dea
5a618ae
6429ef9
9d4a18d
fbc4747
7bd4ea1
75ea726
8a51c81
9ec931e
1e26b71
8bf1bee
1ac301a
b573714
cd89786
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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 (202) indicates that the signed beacon block was | ||
| valid. If the signed beacon block was invalid, then the builder | ||
| must return an error response (400) with a description of the validation | ||
| failure. | ||
|
|
||
| After receiving 202, the proposer takes no further action on the block; the | ||
| builder is responsible for publishing the execution payload envelope. | ||
|
|
||
| This API is applicable from Gloas fork onwards. | ||
| tags: | ||
| - Builder | ||
| parameters: | ||
| - in: header | ||
| schema: | ||
| $ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion" | ||
| required: true | ||
| name: Eth-Consensus-Version | ||
| description: "The active consensus version to which the block being submitted belongs." | ||
| requestBody: | ||
| description: A `SignedBeaconBlock`. | ||
| required: true | ||
| content: | ||
| application/json: | ||
| schema: | ||
| $ref: "../../beacon-apis/types/gloas/block.yaml#/Gloas/SignedBeaconBlock" | ||
| 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" | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,86 @@ | ||
| post: | ||
| operationId: "submitBuilderPreferences" | ||
| summary: Submit builder preferences for a proposer. | ||
| description: | | ||
| Submits a proposer's `BuilderPreferencesRequestV1` to the builder, including | ||
| the `max_execution_payment` that the proposer is willing to accept from this | ||
| builder, authenticated via a `SignedRequestAuthV1`. | ||
|
|
||
| Validators MAY call this endpoint in the epoch prior to the epoch in | ||
| which they will be proposing, as determined from `state.proposer_lookahead`, so that | ||
| builders have the preferences before the bid request arrives. | ||
|
|
||
| The builder MUST verify the BLS signature in `auth` against | ||
| `validator_pubkey`, and check that `auth.message.data` | ||
| matches its own URL. If the signature check fails, the builder MUST | ||
| return a 401 response. If the URL or slot check fails, the builder MUST | ||
| return a 400 response. | ||
|
|
||
| A success response (202) indicates that the preferences were accepted. If | ||
| the preferences are 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: | ||
| - name: validator_pubkey | ||
| in: path | ||
| required: true | ||
| description: "The BLS public key of the validator expressing these preferences." | ||
| schema: | ||
| $ref: "../../beacon-apis/types/primitive.yaml#/Pubkey" | ||
| - name: Eth-Consensus-Version | ||
| in: header | ||
| required: true | ||
| description: "The active consensus version to which the request body belongs. Required if the request body is SSZ encoded." | ||
| schema: | ||
| $ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion" | ||
| requestBody: | ||
| description: A `BuilderPreferencesRequestV1` containing the proposer's preferences and a `SignedRequestAuthV1` for authentication. | ||
| required: true | ||
| content: | ||
| application/json: | ||
| schema: | ||
| $ref: "../../types/gloas/builder_preferences.yaml#/Gloas/BuilderPreferencesRequestV1" | ||
| examples: | ||
| BuilderPreferencesRequestV1: | ||
| $ref: "../../builder-oapi.yaml#/components/examples/Gloas.BuilderPreferencesRequestV1" | ||
| application/octet-stream: | ||
| schema: | ||
| description: "SSZ serialized `BuilderPreferencesRequestV1` 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" | ||
| examples: | ||
| SlotMismatch: | ||
| value: | ||
| code: 400 | ||
| message: "Invalid SignedRequestAuthV1: auth.message.slot does not match the requested slot" | ||
| WrongBuilder: | ||
| value: | ||
| code: 400 | ||
| message: "auth.message.data does not match this builder's URL" | ||
| InvalidPreferences: | ||
| value: | ||
| code: 400 | ||
| message: "Invalid builder preferences: max_execution_payment malformed" | ||
| "401": | ||
| description: Authentication required. | ||
| content: | ||
| application/json: | ||
| schema: | ||
| $ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage" | ||
| examples: | ||
| SignatureVerificationFailed: | ||
| value: | ||
| code: 401 | ||
| message: "Invalid SignedRequestAuthV1: signature verification failed" | ||
| "500": | ||
| $ref: "../../builder-oapi.yaml#/components/responses/InternalError" |
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,171 @@ | ||||||||||||||||||||||||||
| post: | ||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what is the reason of using
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||||||||||||||||||||||||||
| - Optionally, a `SignedRequestAuthV1` in the request body that | ||||||||||||||||||||||||||
| authenticates the request. The body MAY be encoded as JSON or SSZ. | ||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
| The proposer's `max_execution_payment` is communicated exclusively via the | ||||||||||||||||||||||||||
| `submitBuilderPreferences` endpoint. If no `BuilderPreferencesV1` have been | ||||||||||||||||||||||||||
| submitted for the proposer, the builder MUST treat `max_execution_payment` as `0` | ||||||||||||||||||||||||||
| and MUST NOT include an execution layer payment in the bid. | ||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
| The `SignedRequestAuthV1` body is optional. If it is present but malformed | ||||||||||||||||||||||||||
| or fails signature verification, the builder MAY return a 401 response. | ||||||||||||||||||||||||||
| If it is absent, the builder MAY still serve a bid, but builders MAY | ||||||||||||||||||||||||||
| use the presence and validity of the `SignedRequestAuthV1` 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: | ||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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_pubkey | ||||||||||||||||||||||||||
| in: path | ||||||||||||||||||||||||||
| required: true | ||||||||||||||||||||||||||
| description: BLS public key of the proposer. | ||||||||||||||||||||||||||
| schema: | ||||||||||||||||||||||||||
| $ref: "../../beacon-apis/types/primitive.yaml#/Pubkey" | ||||||||||||||||||||||||||
| - 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 | ||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be nice if clients agreed NOT to make this configurable.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We ideally don't want people to be able to abuse the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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...
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Tend to agree with this. |
||||||||||||||||||||||||||
| in: header | ||||||||||||||||||||||||||
| required: false | ||||||||||||||||||||||||||
| description: | | ||||||||||||||||||||||||||
| Optional header containing the proposer's timeout for the request in milliseconds. | ||||||||||||||||||||||||||
| schema: | ||||||||||||||||||||||||||
| type: integer | ||||||||||||||||||||||||||
| format: int64 | ||||||||||||||||||||||||||
| example: 10000 | ||||||||||||||||||||||||||
|
Comment on lines
+80
to
+82
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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...
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is already part of current builder-specs/apis/builder/header.yaml Lines 46 to 57 in 1bf8f49
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: true | ||||||||||||||||||||||||||
| description: | | ||||||||||||||||||||||||||
| The active consensus version to which the `SignedRequestAuthV1` in the | ||||||||||||||||||||||||||
| request body belongs. Required if the request body is SSZ encoded. | ||||||||||||||||||||||||||
| schema: | ||||||||||||||||||||||||||
| $ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion" | ||||||||||||||||||||||||||
| requestBody: | ||||||||||||||||||||||||||
| description: | | ||||||||||||||||||||||||||
| Optional `SignedRequestAuthV1` authenticating the request. If provided, | ||||||||||||||||||||||||||
| the builder MAY verify the BLS signature against the validator pubkey | ||||||||||||||||||||||||||
| resolved from the `proposer_pubkey` path parameter, and check that | ||||||||||||||||||||||||||
| `data` matches its own URL 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/SignedRequestAuthV1" | ||||||||||||||||||||||||||
| application/octet-stream: | ||||||||||||||||||||||||||
| schema: | ||||||||||||||||||||||||||
| description: "SSZ serialized `SignedRequestAuthV1` bytes. Use Content-Type header to indicate that SSZ data is contained in the request body." | ||||||||||||||||||||||||||
| responses: | ||||||||||||||||||||||||||
| "200": | ||||||||||||||||||||||||||
| description: Success response. | ||||||||||||||||||||||||||
| headers: | ||||||||||||||||||||||||||
| Eth-Consensus-Version: | ||||||||||||||||||||||||||
| $ref: "../../builder-oapi.yaml#/components/headers/Eth-Consensus-Version" | ||||||||||||||||||||||||||
| required: true | ||||||||||||||||||||||||||
| 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" | ||||||||||||||||||||||||||
| SlotMismatch: | ||||||||||||||||||||||||||
| value: | ||||||||||||||||||||||||||
| code: 400 | ||||||||||||||||||||||||||
| message: "Invalid SignedRequestAuthV1: auth.message.slot does not match the requested slot" | ||||||||||||||||||||||||||
| WrongBuilder: | ||||||||||||||||||||||||||
| value: | ||||||||||||||||||||||||||
| code: 400 | ||||||||||||||||||||||||||
| message: "Invalid SignedRequestAuthV1: auth.message.data does not match this builder's URL" | ||||||||||||||||||||||||||
| "401": | ||||||||||||||||||||||||||
| description: Authentication required. | ||||||||||||||||||||||||||
| content: | ||||||||||||||||||||||||||
| application/json: | ||||||||||||||||||||||||||
| schema: | ||||||||||||||||||||||||||
| $ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage" | ||||||||||||||||||||||||||
| examples: | ||||||||||||||||||||||||||
| MissingAuth: | ||||||||||||||||||||||||||
| value: | ||||||||||||||||||||||||||
| code: 401 | ||||||||||||||||||||||||||
| message: "Missing SignedRequestAuthV1: this builder requires authenticated requests" | ||||||||||||||||||||||||||
| InvalidAuth: | ||||||||||||||||||||||||||
| value: | ||||||||||||||||||||||||||
| code: 401 | ||||||||||||||||||||||||||
| message: "Invalid SignedRequestAuthV1: signature verification failed" | ||||||||||||||||||||||||||
| "406": | ||||||||||||||||||||||||||
| $ref: "../../builder-oapi.yaml#/components/responses/NotAcceptable" | ||||||||||||||||||||||||||
| "415": | ||||||||||||||||||||||||||
| $ref: "../../builder-oapi.yaml#/components/responses/UnsupportedMediaType" | ||||||||||||||||||||||||||
| "500": | ||||||||||||||||||||||||||
| $ref: "../../builder-oapi.yaml#/components/responses/InternalError" | ||||||||||||||||||||||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| { | ||
| "value": { | ||
| "max_execution_payment": "1000000000" | ||
| } | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| { | ||
| "value": { | ||
| "preferences": { | ||
| "max_execution_payment": "1000000000" | ||
| }, | ||
| "auth": { | ||
| "message": { | ||
| "data": "0x68747470733a2f2f6275696c6465722e6578616d706c652e636f6d", | ||
| "slot": "1" | ||
| }, | ||
| "signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505" | ||
| } | ||
| } | ||
| } |
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. usually we also have a ssz example, see https://github.com/ethereum/builder-specs/tree/main/examples/bellatrix
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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": { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
| "message": { | ||
| "data": "0x68747470733a2f2f6275696c6465722e6578616d706c652e636f6d", | ||
| "slot": "1" | ||
| }, | ||
| "signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505" | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the proposer expected to do after 202? Wait for gossip envelope? Publish itself? Assume the block will be published?
Is the recommendation on what the proposer should do best after getting the 202 documented somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its the builders responsibility to publish the envelope in ePBS. The proposer has no way to build the envelope since the payload is with the builder. The proposer has actually nothing to do post this as the publishing of envelope is completely on the builder.
The proposer can listen to the PTC votes to see if it was revealed in a timely fashion or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, makes sense. Could the spec itself capture this? Something along the lines of:
Currently, it makes sense for builder-API clients to race relays for unblinding; therefore, this new clear responsibility switch is a significant control-flow change for any current builder-API client worth highlighting if we prefer being explicit.