DKG/TPKE for fair ordering and a proposal to (try to) frontrun (some) cross-chain MEV
Christopher Goes
---
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 (tm), 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