eth/catalyst: shouldOverrideBuilder flag

[MariusVanDerWijden]

An idea to track dropped transactions and warn the user if transactions have been reorged out twice
This PR implements the shouldOverrideBuilder flag which is specified here: ethereum/execution-apis#425
The heuristic that is currently implemented sets the flag to true if a transaction is reorged out multiple times
This change is part of the cancun spec

[holiman]

Sorry but.. what is the user supposed to do with that information?

[holiman]

Also you're measuring the wrong thing, you are picking up all txs which are in the block(s) that was removed, but you do not detect whether the same transactions are maybe also included in the new chain. I guess the intention is to detect when a series of reorgs explicitly tries to avoid certain transactions?
If so, this will give false positives

[MariusVanDerWijden]

Sorry but.. what is the user supposed to do with that information?

Thats why this is still a draft... The idea is that this could act as a circuit breaker for mev boost. E.g. if nodes detects these reorgs it can stop producing mev-boost blocks and only use the locally produced blocks

[potuz]

Just for clarity, builders have very little influence on forking and censorship by forking requires a cartel of consensus validators being involved. However, if such a cartel appears, it would benefit from the builders being part of it and these features could help in at least honest validators falling back to local execution decentralizing this aspect.

[MariusVanDerWijden]

TODO: count the times the tx got reorged

[holiman]

Triage discussion: is this block dropping really feasible? And maybe it would be easier to form an image of this by looking at the reorg events on the CL layer?

[holiman]

From @potuz via discord:

what we're asking is for geth to implement two heuristics:

1. track if some valid tx are paying highly and are not included in blocks
2. track if some transactions are being reorged when they appear in blocks.

There's an open issue in the engine API but it was deemed necessary that some EL implements some of these heuristics before opening the PR.

[rjl493456442]

I am a bit skeptical about the efficiency of this indicator.

Typically, the process of block building is

• validator sets the canonical chain by ForkChoiceUpdate event
• validator may or may not ask for a local generated payload along with ForkChoiceUpdate
• validator tells EL to process a payload locally by NewPayload event, the payload has the consensus agreement of the network

In the whole process, EL will only execute the payload given by CL in NewPayload event, and this payload can already be censored. In another word, I don't think reorg will occur in the first place, the censored transactions will just be stuck in txpool forever.

[MariusVanDerWijden]

The idea is that the CL node will stop using MEV-boost if it sees that blocks/transactions are censored. But yeah I agree the implemented metric is not really useful

[potuz]

In the whole process, EL will only execute the payload given by CL in NewPayload event, and this payload can already be censored. In another word, I don't think reorg will occur in the first place, the censored transactions will just be stuck in txpool forever.

The idea is that we want to mitigate two ways of censoring. A "soft" censoring in which simply builders won't include txs. In this case an honest proposer whose EL tells it: " we've had this high paying tx in the mempool for this long", then the CL would just send a local payload.

The other is the hard censorship in which an honest validator includes a censored tx and then the next one reorgs the block because it doesn't like that tx in. In this case I hope that honest validators get a message from the EL that says "I have seen this transaction on a payload that is no longer canonical, this has happened twice or thrice already".. and then the next honest proposer will build a local block without calling the builder.

[MariusVanDerWijden]

closed because of #28029