[spec proposal] Default BidTrace Updated to Support Timestamp and ExtraData

[boz1]

Context:

Currently, the relay/v1/data/bidtraces/proposer_payload_delivered endpoint returns a BidTraceV2 object that does not include a timestamp. This becomes a problem when one tries to analyze the impact of time on block proposals. As discussed in [1] and [2], time impacts proposers' incentives, and correct analysis can help us better understand how the game is played.

I'm currently working on finding the unrealized value (UNREV) in payloads delivered through mev-boost. Since it is not always the case that proposers pick the (latest-delivered -> as only the latest submitted block of each builder matters) most valuable block available in any relay, UNREV emerges.

Although one reason for UNREV can be a proposer being irrational (in the sense that not always aiming to maximize his utility, e.g., because he only wants to work with a specific relay), another reason is the timing/availability of blocks. It is highly possible that a proposer had accepted a block too early, exposing UNREV. For example, in slot 4,849,684, the delivered payload paid 0.06 ETH. One second later, a block offered 465 ETH (0x18ce78328850d8de2f9d4c6f3fbafdd3ae143b97a9860f8b8b78ad5ac7606167).

With the current endpoints (proposer_payload_delivered and builder_blocks_received), one cannot do a complete UNREV analysis for each block as:

• builder_blocks_received only returns a subset of blocks received. If every relay offers their complete block data like Flashbots does, then this issue can be resolved.
• proposer_payload_delivered returns a BidTraceV2 object that does not include a timestamp (unlike BidTraceV2WithTimestamp). One can try to find the same block through builder_blocks_received endpoint and use the timestamp there but I'm not sure if the timestamp of the delivered payload would be the same as the submitted builder block's.

Changes:

1. Introduces BidTraceV3 which inherits from BidTraceV2WithTimestamp and adds an extra_data field as proposed by @metachris .
2. relay/v1/data/bidtraces/proposer_payload_delivered and relay/v1/data/bidtraces/builder_blocks_received endpoints both return a BidTraceV3 now. However, it is open to discussion whether both should return the same timestamp for a given block.

[metachris]

To summarize, the proposal is this?

1. Add timestamp to the payload_delivered data API
2. Add extra_data to both the payload_delivered and builder_blocks_received data API

I am in favor of these changes, they seem to make the data API more useful, without downsides. And it seems fairly easy to implement.

[rajivpo]

Out of curiosity, is timestamp still up for inclusion on payload_delivered? Saw that #260 ended up being closed out as opposed to merged.

[metachris]

Totally up, just never got around to do the remaining work, and needed some database updates too. Open to contributions, or might get around to this at a later date.

[sambacha]

This issue was implemented I believe here: https://github.com/flashbots/relay-specs/commit/adae2d4da726db7aa34f62d1588effea69299f27 and referenced as the discussion for https://github.com/flashbots/relay-specs/pull/7

So this can be closed now.

[metachris]

Merging https://github.com/flashbots/relay-specs/pull/7 has been reverted ub https://github.com/flashbots/relay-specs/pull/18, because the relay is not yet exposing these fields.

[sambacha]

Merging https://github.com/flashbots/relay-specs/pull/7 has been reverted ub https://github.com/flashbots/relay-specs/pull/18, because the relay is not yet exposing these fields.

Will make sure our relay does so as well, thanks for the update.