Optimistic relaying v2: header only parsing.

[michaelneuder]

📝 Summary

v2 of the optimistic relaying roadmap, which does optimistic header only parsing of an SSZ encoded bid and marks the bid eligible immediately.

NOTE: the overall approach of this change was to not touch the handleSubmitNewBlock path at all. Since that logic is already relatively stable at this point, I thought it would be best to leave it alone and not try to refactor it into functions that can be used with the handleSubmitNewBlockV2 path. This results in some amount of copied code, which I cite in the change log below. As v2 optimistic relaying gets tested and starts running in prod, we can start refactoring to reduce duplicate code.

change log:

1. common/types.go –– Adding the SubmitBlockRequest type to the common package. This type is was discussed in Create v2.SubmitBlockRequest type. attestantio/go-builder-client#8. The first three fields are enough to construct the getHeaderResponse and thus qualify the bid for the auction. The last two fields (txns and withdrawals) are needed to construct the full ExecutionPayload that is part of the getPayloadResponse. This type has the normal SSZ methods, but also includes the UnmarshalSSZHeaderOnly function, which parses only the first three fields of the type (with the offsets).
2. common/types_spec.go –– Adding the BuildGetHeaderResponseHeaderOnly function which builds the getHeaderResponse using the full header that is passed in (not using the txn slice to construct the txn root).
3. datastore/redis.go –– Modify SaveBidAndUpdateTopBid to only save the ExecutionPayload if the getPayloadResponse is not nil. This allows us to use that function as is to save only the getHeader response and avoid code duplication in that path.
4. services/api/service.go ––

• handleSubmitNewBlockV2
  • [lines 1940-1985] copied from handleSubmitNewBlock
  • [lines 1987-2008] header only parsing of the message
  • [lines 2028-2062] rearranged from handleSubmitNewBlock to check signature and optimistic eligibility
  • [lines 2028-2062] rearranged from handleSubmitNewBlock to check signature and optimistic eligibility
  • [lines 2064-2150] prechecks copied from handleSubmitNewBlock
  • [lines 2152-2211] saving the getHeaderResponse before finishing reading the request
  • [lines 2214-2234] reading the rest of the message and calling the optimisticV2SlowPath function
• optimisticV2SlowPath
  • [lines 2258-2279] decode entire body and update the transactions and withdrawals field of the ExecutionPayload.
  • [lines 2281-2299] saving the getPayloadResponse to redis. this is a critical step! now the bid is active and we have the payload.
  • [lines 2309-2351] mostly copied from handleSubmitNewBlock to save the entry and simulate the block. We don't do the floor checking because we want all optimistic blocks to be simulated.

⛱ Motivation and Context

This change represents the next phase of optimistic relaying, which is an iterative approach of evolving mev-boost to look more like enshrined PBS. See this post for more context.

📚 References

Why enshrine proposer builder separation?
roadmap
optimistic relays and where to find them

---

✅ I have run these commands

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

[metachris]

interesting, thanks for the PR. it's a lot of code and will take some time to review.

tests and linter are currently failing btw.

[metachris]

This PR was presented and discussed in more detail in mev-boost community call #4 on 2023-06-15 -- recording linked in the page.

[metachris]

Optimisation-wise this is pretty cool.

I want to note that I'm concerned about this significantly increasing colocation pressure, since such v2 submissions with would have a significantly increased risk for builders to cause missed slots if they don't get the data to the relay very quickly, which would not cause missed slots in v1 submissions.

---

For some additional data: 50% of builder submissions to the Flashbots relay are read+decoded in <10ms, which seems to be the median time this would shave off the overall submission latency.