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 ![](https://hackmd.io/_uploads/rks8eJlHq.png) --- 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 --- ![](https://hackmd.io/_uploads/ryKmAWxrq.png =x600) --- - 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**) --- ![](https://hackmd.io/_uploads/Byevzzxr5.png) --- 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
{}
    185 views
   owned this note