A disclaimer and a note:

• Info compression is difficult
• This talk will necessarily be structured at a schematic level
• I am new to the MEV discourse and may not know all the right terms
• Thank you to Niketa and Alejo and Justin Drake for discussions in the past few days

Research question:

Which kinds of MEV are possible, and which kinds can be mitigated, in principle, from an information-theoretic perspective?

Information theoretic taxonomy of MEV

• State of the blockchain advances in local time
• State of the world advances in "real"* time
• Two classes of actors:
  • Transaction authors (users)
  • Transaction orderers/groupers (proposers, builders, sequencers, etc.)

*"there is no such thing" - Einstein <paraphrased>

Diagram

Two events in question (part 1)

1. Event of transaction authorship

• Author has access to blockchain state at time b_t
• Author has access to world state at time w_t (let's say)

2. Event of transaction ordering & block creation

• Orderer has access to more info about blockchain state
  • Perhaps updated blockchain state b_t+k
  • Set of possible transactions to include
• Orderer has access to more info about world state
  • i.e. the cross-domain MEV problem
• MEV is the information asymmetry between these two actors/events

• Can we reduce the information asymmetry about the blockchain state?
  • Yes, with cryptography (ordering decisions made without information about tx contents)
• Can we reduce the information asymmetry about the world state?
  • No. Only by reducing latency from event (1) to event (2).
  • We can also craft algorithms to combine transactions within a quantised time period (batching)

Using cryptography to reduce asymmetry (a)

• Basic setup
  • Proof-of-stake with BFT finality
  • Threshold key (e.g. same shares as PoS validator set)
• Order of operations
  1. All transactions are encrypted to the threshold key
  2. Proposer commits to ordering
  3. Block finalised
  4. Transactions are threshold decrypted, then executed

• Change in info asymmetry
  • Proposer knows no more about blockchain state than tx author*
• https://github.com/anoma/ferveo for spec/code

*except gas limits (next slide)

The problem: block computation limits

• Transaction gas limits leak information
• Can choose granularity, tradeoff between packing efficiency/info asymmetry
• ZKPs do not help directly
• Only way to avoid: all transactions have identical (encrypted) sizes and execution costs
• (still much better than status quo)

Frontrunning cross-domain MEV (if we can)

• Cross-domain is like information in the world (prior diagram)
• Quantize time (artifical latency) by a shared clock
• Synchronise encryption-ordering-decryption
• What doesn't this do: cross-domain messages
  • Pre-encrypt if you know ahead of time
  • Chain encrypt if you have state dependence (hard)

Conclusory notes

• For the basic approach, we don't need to agree on the specific encryption scheme or keyset or DA layer or execution layer - we just need to agree on the clock!
• Cross-domain message passing MEV is hard ™, but this is a concurrency problem, not a security problem (unless your bridges break)
  • Rollups will have the same architectural challenges

Conclusory notes part II

• Nothing to be done about world-MEV, but physical change is slow
  • In the limit case (no CEX), this is a non-problem
• In the non-compliant cross-domain case, real-world latency matters

Thank you!

Standards are good :)

More questions?

• Twitter @cwgoes
• Email cwgoes@heliax.dev