Collecting two extra timestamps in the block lifecycle

[michaelneuder]

📝 Summary

The exact timing of events is critical in MEV boost. We that relays should collect two additional timestamps

1. when a bid from a builder becomes "eligible", meaning it could win the auction, and
2. when a signed getPayload is verified, meaning the proposer is committed to that header.

⛱ Motivation and Context

Currently, the only timestamps collected by the relay are
a) when a bid is received from the builder,
b) when the bid is inserted into the DB,
c) when the delivered payload is inserted into the DB.

Since the DB writes happen off the critical path (they are deferred and happen in a separate goroutine), the accuracy of this data is relatively low. For example, you could find that the timestamp for when a delivered payload is inserted into the DB is before the timestamp for when the bid is inserted into the DB (if the bid comes right at the end of the slot and wins the auction). By collecting this additional data, we can have strong assurances about the relationship between when events occurred. For example, we can assert that the eligibility timestamp (1 above) must come before the signed timestamp (2 above), because a bid must be eligible before it can be retrieved by a call to getHeader. This also allows us to accurately determine the time between when a bit became active and when the proposer signed the header associated with that bid.

In the figure below, we are proposing collecting timestamps for bid is active and get payload (after signature verification).

📚 References

This is related to our optimistic relaying work, where we are paying close attention to the latency games associated with mev-boost. See the proposal and the roadmap. Additionally, this related to the study of latency/timing games: ROP-0

---

✅ I have run these commands

• make lint
• make test-race
• go mod tidy
• I have seen and agree to CONTRIBUTING.md

[codecov-commenter]

Codecov Report

Merging #301 (683ec9e) into main (e57a98e) will decrease coverage by 0.07%.
The diff coverage is 9.09%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##             main     #301      +/-   ##
==========================================
- Coverage   17.59%   17.53%   -0.07%     
==========================================
  Files          19       19              
  Lines        3444     3456      +12     
==========================================
  Hits          606      606              
- Misses       2761     2773      +12     
  Partials       77       77              

Flag	Coverage Δ
unittests	17.53% <9.09%> (-0.07%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
database/mockdb.go	0.00% <0.00%> (ø)
database/types.go	0.00% <ø> (ø)
services/api/service.go	13.87% <0.00%> (-0.12%)	⬇️
database/database.go	13.73% <15.38%> (-0.08%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[metachris]

that's great, thanks 👍

tested in zhejiang, merging now

[soispoke]

Hi @metachris , @michaelneuder

I was wondering if we can expect these changes to make it to Flashbots relay data?

https://flashbots-boost-relay-public.s3.us-east-2.amazonaws.com/index.html