at what level should cancellations be allowed, if at all?

[obadiaa]

Description:
Cancellations are a useful feature that allow individuals to cancel transactions they submitted before they land on chain. This feature is particularly useful for people executing cross-domain arbitrage.

There are 2 possible 'types' of cancellations:

• searchers cancelling their bundles to the builder
• the builder cancelling their block to the relay/proposer

The former is introduced by the builder, in which case this doesn't affect mev-boost code. The latter would concern mev-boost. We focus on this second case.

Naturally, no cancellation is possible after a header has been signed upon by the proposer - aside from a 'brute-force cancellation' where a relay does not reveal the body of a block.

Questions

• Does allowing cancellations at the mev-boost level opens up a DoS vector for the relay?
  • The DoS here would be a builder submitting blocks, relay checking validity and then receiving cancellation request for it. There is a likely asymmetry between compute needed to cancel a body and re-submit a new one vs checking the validity of a body
• Does allowing cancellations mean bidding is now messed up? please refer to issue auction - should (header,bid) messages be publicly accessible during the message passing period? #112 for more details here.
  • In particular, I worry this means someone could bid very high, scare other builders from participating in a round then cancel right before the end. This feel pretty harmless though but I would like to surface the concern.

[abog854]

I have a related but very specific proposal at the relay level: always use latest block sent by each builder.

Let's look at block templates that come within a single slot, and how the relay handles them to decide what to forward to proposers:

Currently, it seems like relays will use the most profitable block sent by each builder. This is a proposal to use the latest block sent by each builder, instead.

Why? This would allow for builders for more sophisticated strategies, where they can decide to not propose a transaction anymore in their blocks.

Nothing else changes. The relay still simulate every block templates that it receive, etc.

Pros:

• It's makes the design space for builders bigger as they are not locked in old block templates that may contain transactions they don't want to submit anymore.
• Lowers the DoS risk a little: you could imagine builder spamming the relay and relying on it to simulate every block, and select the most profitable one. This is impossible if the relay only keeps the last block sent.

Cons:

• If a builder sent a less profitable or invalid block, their previous more profitable block is dropped. However this has no reason to happen, apart from a software bug in the builder: a well-behaved builder should only sent more profitable block templates to relays than their previous one (in the duration of a single slot).