Recently proposed blocks

[avsetsin]

I'd like to discuss the idea of adding a method to relay API that returns blocks that have recently been proposed using relay.

Goal

The goal is to understand whether MEV-Boost was used to build a particular block and which relay was used for it. This is useful for participants such as staking pools to organize monitoring after validators that are operated by a third party.

Proposed solution

The goal can be achieved by adding a method that returns a block if it has been proposed using the current relay. Blocks can be stored in memory, and the stored number can be limited. Data for the last 32 slots should be enough for a third-party service to collect data about the last proposed blocks. All necessary data can be collected after a successful call to relay_proposeBlindedBlockV1 method.

relay_getProposedBlindedBlockV1

Request

• method: relay_getProposedBlindedBlockV1
• params:
  1. slot: slot number

Response

• result: ProposedBlock
• error: code and message set in case an exception happens while performing the request.

Types

ProposedBlock

• block: SignedBlindedBeaconBlock - the beacon block signed and proposed by a validator.
• payloadHeader: SignedMEVPayloadHeader - the payload header signed by the relay.

Specification

• Relay software MUST return proposed block if it has been proposed using the relay in the last 32 slots, otherwise return -32004: Unknown block.

Alternatives

This may not be the best solution, and I suggest discuss how to achieve the goal. Since Flashbots has a centralized API (blocks.flashbots.net) and probably want to support it after the Merge, I assume you may have a vision of collecting such data.

[metachris]

Just to clarify - mev-boost could return a block for a given slot if it has received one from the relay, but it has no knowledge what was actually proposed by the validator.

[Ruteri]

Some notes:

• You cannot ask validator-side mev-boost for this information, as it could be faked
• Relay could save the blocks for which validator has signed the header, since this is what the validator committed to, and this cannot be faked (validator would get slashed)

[avsetsin]

Perhaps, it would be better to collect the suggested payloads instead of the proposed blocks. It's still enough to know whether the MEV-Boost is used to create the block, since we can compare transactions_roots. But it allows to compare the value in the block against what all relays offer:

• Check whether the validator gives preference to some relays;
• Exclude from the suspicious cases where a local payload with more value than the relays suggest is selected.

This method might look like this:

relay_getSuggestedPayloadHeadersV1

The method returns an array of suggested SignedMEVPayloadHeader by slot. Headers can be stored in memory, and the stored number can be limited.

Request

• method: relay_getSuggestedPayloadHeadersV1
• params:
  1. slot: slot number

Response

• payloadHeaders: Array of SignedMEVPayloadHeader

[metachris]

That makes sense, and we can add that to mev-boost. I guess in REST terms, similar to the builder spec, that might be looking like this:

GET /boost/v1/builder/recent_header/slot/{slot}

[ralexstokes]

edit: I was talking w/ @metachris about the roles b/t builders, relays and proposers and some of what I wrote below may need to be adjusted, I'd suggest just holding tight on this for now

@avsetsin welcome! I agree we should be able to track which builders and/or relays were involved in a given proposal.

I'll assume when you say "MEV-Boost" you are referring to the overall pipeline and not that you are trying to identify that the particular relay mux software mev-boost is being used or not

and from there I have a clarifying question for the issue: do we really care if we can identify the specific relay? or just that we want to attribute a proposal to a specific builder? some of this comes down to where we are today (just flashbots as the ~single builder/relay) and where I would like to see us head with a robust, healthy decentralized builder ecosystem with multiple competing players.

if we want to build towards this wider world, then I think the critical thing is to expose SignedBuilderBids (the builder can do this, the relay can provide as a service, there can be "data availability" DAOs that do this as part of a service, etc.) so that we can tie a given proposal on-chain (or even off-chain if you are collecting orphan blocks) to a given builder.

if we want relay attributability as well (I personally haven't thought about this yet) then we will want to extend the https://github.com/ethereum/builder-specs so that relays sign over the SignedBuilderBids

either way, to bridge from here to then, I could see the flashbots relay exposing an endpoint for all of the SignedBuilderBids they offer to proposers. Then anyone can compare which transactions end up in blocks against what the relay provides.

I would structure this as part of the "relay APIs" or even just flashbots-specific APIs for now and would not add this concern into the https://github.com/ethereum/builder-specs

[avsetsin]

I'll assume when you say "MEV-Boost" you are referring to the overall pipeline and not that you are trying to identify that the particular relay mux software mev-boost is being used or not

and from there I have a clarifying question for the issue: do we really care if we can identify the specific relay? or just that we want to attribute a proposal to a specific builder?

Let's consider a scenario where the DAO controlling a stacking pool adopts a policy that MEV must be extracted by all validators to a single vault. In this case, the policy may include some restrictions about the source of payloads, otherwise a validator is tempted to build blocks on its own and take some of MEV directly to itself.

The current MEV-Boost design expects a whitelist of relays (but not builders), which can be used by DAO to limit the sources of payloads. And if DAO uses the whitelist, then there would need to be a mechanism for attributing a specific relay to a specific block, so that the community can make sure that all validators are following the adopted policy.

In a simple scheme where we have only flashbots with single relay and single builder, this would not be a problem tp identify the source, but in a scheme with multiple builders and relays this important to identify the entity whose choice can be controlled.

either way, to bridge from here to then, I could see the flashbots relay exposing an endpoint for all of the SignedBuilderBids they offer to proposers. Then anyone can compare which transactions end up in blocks against what the relay provides.

That would be perfect. It would likely need more effort on your part, since it would require storing data for all slots. I originally suggested limiting the ability to fetch data in time, so that you could do without storage and only keep the latest data in memory, in the hope that this could be implemented in the short term and we would have time to test it before the Merge.

[ralexstokes]

yeah I can see the use case (and there are many others!) being valuable

I opened this issue to see what the appetite is for how attributable we want each message to be to which actors

ethereum/builder-specs#23

[metachris]

I'm close to finishing the relay API spec that will expose this data, and others. Would it still be useful then to expose the headers in mev-boost too?

[avsetsin]

I'm close to finishing the relay API spec that will expose this data, and others.

🚀 🎉 🥳

Would it still be useful then to expose the headers in mev-boost too?

I can't find a good way to use this on the MEV-Boost side for validators pool monitoring. But perhaps there are some scenarios where it would be useful for people who have their own set of validators

[metachris]

The relay API spec draft, for reference: https://flashbots.notion.site/Relay-API-Spec-5fb0819366954962bc02e81cb33840f5

[metachris]

Closing this because implemented in the relay API. Please reopen or comment again if needed.

[avsetsin]

Closing this because implemented in the relay API

In the spec or is it already implemented in the code? I couldn't find an implementation, would be grateful if you might share a link to the code