-
Notifications
You must be signed in to change notification settings - Fork 175
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 validator registration #206
Add validator registration #206
Conversation
I wanted to better understand the intended behavior here, what is supposed to happen with this optional set of information? for example, if I call the prepare beacon proposer api with the optional information then call it afterward without the optional information it's supposed to override as empty? |
Would these be optional? mev-boost forwards them to the relays/builders (so they know which (basically the payload of |
I'm a bit new to these apis/development, just to clarify the proposal you made. so now we would like the array of objects to include this message object ( which includes the previous fee recipient to validator index, now with added pubkey and timestamp?) and a signature of that message object? I wanted to ask what that expected timestamp represents ( maybe this is a dumb question 😓 sorry). I also wanted to ask I guess we would have to internally support this new signing request but also remote signers like web3signer would ideally have this new request to sign this message object too? |
It would be good to get some more detail on what the If the timestamp means the message expires at some point we need to consider the load we could be putting on signer components by having to sign additional messages regularly. We've already seen issues caused by the need for all validators to sign the epoch number to determine if they're validating as it leads to a huge number of requests being sent to the signer at the start of each epoch (which can fortunately be spread out). Adding the new to also sign these validator registrations could introduce significant additional load depending on how often the need to be signed. |
The timestamp is used for replay protection, that older messages cannot override later ones (eg. that a malicious actor couldn't resend an old message and override a newer feeRecipient for a given validator). The message doesn't expire itself, it would only be replaced (by a newer one with a different feeRecipient and newer timestamp). @djrtwo I recall you had strong opinions on using a timestamp over a sequence number here, would be great it you could you add your thoughts too 🙏 (cc/ @ralexstokes) |
I definitely recall agreeing on this being included in the message for
I'm not sure the best way to convey this, but
Each object in the array would have it's own signature and relevant data to verify the signature (e.g.
Right, so a reason timestamp was chosen was that in potential future where As a general note, I'm not sure how much detail to give in this endpoint on
This is why I believe |
I see two other free parameters in the execution payload that validators may want to be able to set (and so we will update the registration here and in the builder API)
there is no way for a validator to signal if they have a preference on the gas limit for blocks when using remote builders, extending this registration will let them. the semantics are up in the air -- it could be a suggestion or it could be "required" with the understanding that if a builder returns a deviation they can take a reputation hit extra data is less interesting imo as validators have the beacon block graffiti and it may still be useful for builders to put their own data into this part of the block edit: imo this should be a separate API method and not overloaded onto an existing thing, and esp. if we add these 1 or 2 things then it will start to diverge even more |
Could the validator client not overwrite the extra data and gas limit fields when it receives the execution payload (or header) from either the beacon node or the builder prior to signing it and returning the signed block proposal? Or do these have an impact on the following state information, such that the values are required to be part of the execution of the payload? |
they could overwrite the extra data although then I would question why we have builders sign over it in the first place. it may seem small but I'd say if we are going to have an actor commit to some data via signature then no one downstream should be able to change it. as a policy, this facilitates the implementation of fraud proof-like games which will help when we decentralize the overall architecture down the line. and this may be a reach but you could imagine extra data ends up being a vector for MEV and we don't want any agent in the system to have unilateral control over some data beyond what is absolutely required. there are a few issues w/ the gas limit: you don't want a validator grieving builders by lowering the gas limit just below what they have assembled (which is easily doable when the block is full) and then crying wolf that they were slighted by the relay/builder as an attack on that pair's reputation. I also think putting the gas limit in the hands of a small cartel of builders is a bad idea as it makes it easier to coordinate to raise it against the best interests of keeping a lean, decentralized protocol -- this imo goes strongly against ethereum's values so we need a way for validators to at least signal to builders their intention. if there is a "hostile" take-over on this front, we will at least be able to provide proof of foul play from builders edit: oh and we can almost certainly imagine the gas limit having an impact on MEV extraction so something we want to keep "constrained" in a similar sense to what I described above. each player should only have a few choices during each turn |
From my point of view, it proves that a given builder supplied a given execution payload with expectation of funds. As to if the validator wants to sign that given payload, that's up to the validator. I'm not sure where the control of block gas limit should be, but I'm inclined for the execution layer to handle it and as such not have the validator involved. Extra data is a different item, but feels like it fits as a field in |
@mcdee the issue is that when using an external block builder, there is only communication between the CL and the external builder. At no point does the EL have an opportunity to chime in. Furthermore, since choosing the gas limit is on the critical path to block production (hard to build a block if you don't know how big it will be), I think it makes sense to also include a gas target in the validator registration phase of the Builder API. |
@lightclient Does the builder not need to talk to the EL to understand the current block gas limit when building the block? If not, from where does it obtain this information? It feels to me that adding the gas target in the validator registration is overloading the purpose of validator registration. I think it would make more sense for the builder or execution node to control this value separate from the validator, which also seems closer to how it works today. |
Note that builders want to start the building process already before this call is happening, to have a block ready to deliver immediately. |
Does the lack of extra data at this time matter? As far as I can see, the builder can build the block, then slot in the extra data and sign it when it receives the |
@mcdee this diagram is a good illustration of communication paths:
The lack of extra data probably matters the least, because recalculating the block is relatively trivial -- just slot in the value, re-hash. The others, |
The relay/builder setup will probably look like this, where builders submit both header and payload to the relay, which acts as escrow of sorts, and verifies that the feeRecipient received the correct value. This also means the header must be signed as received, and can't easily be updated without another roundtrip to the builder (which might add a new layer to the issue of withholding). In this setup, the relay is trusted, and guarantees to the validator that it is already in possession of the payload. |
f70c94b
to
3c89262
Compare
The two main questions that still need to be resolved:
|
@lightclient help me remember the outputs of the conversation in devconnect. I believe that there was a desire to split this a a separate endpoint to (1) decouple it from critical operation endpoint and (2) becaus this message is likely to be on a different rhythm from the message for beacon proposer registration. I find (1) very compelling. I dont want to have to upgrade what is a critical operation endpoint in the event that MEV boost iterates/changes. It's nice for core validator signing to be left generally unchanged as much as possible now and in future iterations. Were there other reasons to decouple worth mentioning? |
Closing as there has been no opposition to moving forward with #209. |
One requirement of the Builder API is in
builder_registerValidatorV1
, the validator must sign a message to authenticate its registration. This is to ensure only the person who controls the validator can set itsfee_recipient
, even in a multi-party environment.Registering currently entails signing over a
timestamp
,pubkey
, andfee_recipient
. The new, optionalvalidator_registration
object onprepare_beacon_proposer
includes the minimal additional values (timestamp
andsignature
) needed to satisfy the registration. If preferred, I could expandvalidator_registration
to all required fields to verify the signature -- this would lead to duplication offee_recipient
and a new valuepubkey
which is already specified byvalidator_index
.This is my first PR to the beacon API so please let me know what I'm missing 🙏