-
Notifications
You must be signed in to change notification settings - Fork 342
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
Add Builder API #209
Add Builder API #209
Conversation
82c68ea
to
e28576a
Compare
Co-authored-by: Chris Hager <chris@linuxuser.at>
Still waiting to get a proper domain carved out for |
Co-authored-by: Chris Hager <chris@linuxuser.at>
Co-authored-by: Alex Stokes <r.alex.stokes@gmail.com>
Co-authored-by: Enrico Del Fante <enrico.delfante@gmail.com>
Co-authored-by: Enrico Del Fante <enrico.delfante@gmail.com>
1. `feeRecipient`: `DATA`, 20 Bytes - Address of account which should receive fees. | ||
2. `gasLimit`: `QUANTITY`, 64 bits - Target gas limit for block. | ||
3. `timestamp`: `QUANTITY`, 64 bits - Unix timestamp of announcement. | ||
4. `pubkey`: `DATA`, 48 Bytes - BLS public key of validator. |
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.
Sidenote: Depending on ethereum/beacon-APIs#206, pubkey
might be replaced with validatorIndex
. This can be changed in a follow-up PR when needed.
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.
the thing w/ validatorIndex
is that we would like the option to re-use indices in the future (we aren't anywhere near that yet but where possible designing new feature to be forwards compatible w/ this possibility)
pubkey
s will always uniquely identify a validator, there could be a world where index
does not
for this use case, it would always be clear who the index refers to but it is something to keep in mind in the event there are knock-on effects down the road to software in this stack
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.
I think we can expect builders look up the pubkey
by index shortly before block construction. If we want to have pubkey
be part of this call, we might need to it to ethereum/beacon-APIs#206 as well.
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.
the thing w/
validatorIndex
is that we would like the option to re-use indices in the future (we aren't anywhere near that yet but where possible designing new feature to be forwards compatible w/ this possibility)
Good point. As long as registration request validity is restricted to 10s
or any other small amount of time this shouldn't be an issue. I admit that relying on timeout as a replay protection in this case may lead to unpredictable consequences if timeout for some reason will be removed in the future. If it isn't difficult for implementations to add pubkey
to BN api request then we better have pubkey
, furthermore, beacon API supports querying validators by pubkey
which can be utilised by builders to verify that such validator exists in a validator set.
- `message`: `object` | ||
- `header`: [`ExecutionPayloadHeaderV1`](#executionpayloadheaderv1). | ||
- `value`: `QUANTITY`, 256 Bits - Payment in wei that will be paid to the `feeRecipient` account. | ||
- `pubkey`: `DATA`, 48 Bytes - BLS public key associated with the builder. |
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.
Sidenote: this might actually be the pubkey of the relay, or we might want signatures by both builder and relay. Definitely need the relay signature if the validator wants to whitelist a specific relay and require it to sign this.
- `proposerSlashings`: `Array`, [`ProposerSlashingV1`](#proposerslashingv1) | ||
- `attesterSlashings`: `Array`, [`AttesterSlashingV1`](#attesterslashingv1) | ||
- `attestations`: `Array`, [`AttestationV1`](#attestationv1) | ||
- `deposits`: `Array`, [`DespositV1`](#depositv1) |
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.
There's a typo in De**s**positV1
, right ?
- `proposerSlashings`: `Array`, [`ProposerSlashingV1`](#proposerslashingv1) | ||
- `attesterSlashings`: `Array`, [`AttesterSlashingV1`](#attesterslashingv1) | ||
- `attestations`: `Array`, [`AttestationV1`](#attestationv1) | ||
- `deposits`: `Array`, [`DespositV1`](#depositv1) |
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.
nice catch, here is a button light client can click to fix
- `deposits`: `Array`, [`DespositV1`](#depositv1) | |
- `deposits`: `Array`, [`DepositV1`](#depositv1) |
- `signature`: `DATA`, 96 Bytes - BLS signature over [`BuilderBidV1`](#builderbidv1). | ||
- error: code and message set in case an exception happens while getting the header. | ||
|
||
#### Specification |
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.
Should there be a restriction to disallow requests where input slot
is in the future?
I'm not 100% sure if that's necessary, but I wonder what would be the intended behavior if anyone calls builder_getHeaderV1
earlier than the assigned slot. Curious to hear ppl's thoughts
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.
The relay/builder should perhaps just return an error, or nothing at all. Seems similar to the situation where a relay does not (yet) have a block for the requested parentHash.
- error: code and message set in case an exception happens while proposing the payload. | ||
|
||
#### Specification | ||
1. Builder software **MUST** be able to un-blind the [`ExecutionPayloadHeaderV1`](#executionpayloadheaderv1) in `message`, otherwise the return `-32004: Unknown block`. |
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.
1. Builder software **MUST** be able to un-blind the [`ExecutionPayloadHeaderV1`](#executionpayloadheaderv1) in `message`, otherwise the return `-32004: Unknown block`. | |
1. Builder software **MUST** be able to un-blind the [`ExecutionPayloadHeaderV1`](#executionpayloadheaderv1) in `message`, otherwise return the error `-32004: Unknown block`. |
Maybe we should close this, in favor of ethereum/builder-specs#2 |
The Builder API developed separately until now in close proximity with
mev-boost
, but now that the design is becoming more stable and we're soliciting feedback from a wider audience, it makes sense to bring to a more open forum.The Builder API will be implemented by EL clients that wish to participate in a builder network. It's not likely that this will be a standard feature supported by ELs out of the box -- more likely this will be implemented by third-party software such as
mev-boost
,mev-geth
, etc. However, because a large number of validators will rely on this interface it is important that all CLs integrate this specification. If a client were to not adopt this, it could affect their network share negatively as validators will seek other software with better economics.With respect to the "external builder network" there are two phases to consider:
mev-boost
-- shortly after the Builder API is stabilized, we should define a p2p protocol for sharing builder network messages. This is for a few reasons, but most poignant is the need to maintain validator privacy. This requireThe current specification tries to be forward looking to minimize the number of changes to go from the direct communication phase to the p2p communication phase.