Targeting Zero MEV - A Content Layer Solution

[pmcgoohan]

I certainly don’t want to throw hurdles up against it being adopted on mainnet. Things to consider though…

Doesn’t rando produce a new seed every block rather than intra block, or is that not the case? If every block it would mean block length content chunks and an n+1 block delay I think (although it takes most txs far longer than this to go through).

When random ordering we would need to carefully assess potential tx bloat issues…

@pmcgoohan

Essentially with random ordering an attacker can give themselves a better chance of a good outcome by adding n txs.

However if another attacker does the same thing, they end up with no better chance and higher tx fees.

If a third (or more) attacker does the same thing, they all end up losing big.

If the would be victim also splits their tx into multiple txs they can protect themselves again.

So Alex fixes inequality, but at the cost of increasing the tx rate (by approx: extra tx count = arb value / failed tx cost)

I don’t think the community is ready for a solution which leads to this level of tx bloat, and I’m not sure I’d want to be responsible for it.

That’s what got me thinking about encrypted mempool/fair ordering variants of Alex.

What finally turned me off random ordering (for L1- it could still work on L2) was being shown this issue #21350 where Geth randomly ordered txs with the same gas price.
Apparently it led to tx bloat from backrunning attacks, so is quite a good real world proxy for the kind of issues random ordering systems may have