search

flashbots / relay-specs

MEV-Boost Relay API Specs
https://flashbots.github.io/relay-specs
Creative Commons Zero v1.0 Universal
28 stars 12 forks source link

API endpoint for last_registered_epoch (or similar) #6

Open infosecual opened 1 year ago

infosecual commented 1 year ago

Is your feature request related to a problem? Please describe.

Currently, there is no way to check that a validator is active via the relay API. You can see if an initial registration was successful via the relay/v1/data/validator_registration API call but if a validator goes inactive after registering there is no easy way to tell.

For example, this goerli validator is inactive at the time of this query:

API call:

https://0xafa4c6985aa049fb79dd37010438cfebeb0f2bd42b115b89dd678dab0670c1de38da0c4e9138c9290a398ecd9a0b3110@boost-relay-goerli.flashbots.net/relay/v1/data/validator_registration?pubkey=0xaa0508f2cbd370a6e92fc37ef12709dab2b2a6d8d267db4e7e3828d2b4485c2ff6c83875b5bb93eca8867c390c0100b8

Response:

{
  "message": {
    "fee_recipient": "0x6a7aa9b882d50bb7bc5da1a244719c99f12f06a3",
    "gas_limit": "30000000",
    "timestamp": "1664138161",
    "pubkey": "0xaa0508f2cbd370a6e92fc37ef12709dab2b2a6d8d267db4e7e3828d2b4485c2ff6c83875b5bb93eca8867c390c0100b8"
  },
  "signature": "0x8bd041544e396108730e9796f76ab74a643bda3d5cb9927d76b7f686ed94e2fac359ba9fd9211834069ed9686b6d1d961457c385c011b2515b3eddcec2a8f635315d7c3732e42eae34deb802caaf5d721a4720e7bf0c86f9a39017765979b996"
}

The timestamp in the message is cached for good reason (new signatures+verification every Epoch does not make sense). This makes it impossible to see if a new registration was successful because the timestamp will not change without changing the fee_recipient or some other data.

Describe the solution you'd like

It would be nice to have a last_active_epoch data point that is either returned from this API call (must be ourside of the "message" since that carries a signature) or a separate, new endpoint (possibly something like /relay/v1/data/validator_last_active_epoch or /relay/v1/data/validator_last_registered_epoch). This metric would have significantly less overhead than updating the timestamp but would still need to be tracked internally by validators.

Describe alternatives you've considered

Updating the timestamp to the most recent epoch for which the validator registered. This does not make since because the message is signed by the validator which currently cache the message to prevent 400K signature verifications by the relay on each Epoch.

Additional context

If there is consensus on the correct path forward I am happy to implement the changes.

jtraglia commented 1 year ago

Hey @infosecual thanks for bringing this up. I agree that registration endpoint could be more user friendly. The timestamp in the registration is a bit misleading because it's cached. Another solution could be to prune inactive registrations.

I'm not sure what the correct thing to do is. But if we decide to update the existing endpoint and include a new field in the response, I think it would make sense to do it at the same time as #1 since that changes the response structure.

jtraglia commented 1 year ago

@metachris what's your opinion on this?