Conversation
lightclient
force-pushed
the
add-builder-api
branch
from
82c68ea to
e28576a
Compare
Co-authored-by: Alex Stokes <[email protected]>
Co-authored-by: Chris Hager <[email protected]>
|
Still waiting to get a proper domain carved out for |
Co-authored-by: Chris Hager <[email protected]>
Co-authored-by: Alex Stokes <[email protected]>
Co-authored-by: Enrico Del Fante <[email protected]>
Co-authored-by: Enrico Del Fante <[email protected]>
| 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.
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.
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)
pubkeys 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.
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.
the thing w/
validatorIndexis 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.
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.
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.
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.
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.
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.
| 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 |
10 participants
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.