---
tags: [Anoma, MEV]
title: A path dependent topology of MEV discourse
type: slide
slideOptions:
transition: fade
#showNotes: true

# keyboard shortcuts:
# - Esc: slide overview
# - S: presenter view (only works with Slide mode link from Share menu)
---

<style>
<!-- limit height of graphviz diagrams -->
.graphviz svg { height: 300px }
</style>

# A path dependent topology of MEV discourse
(from a historical perspective)

---

## Overview

- Part 1: Path Dependence
- Part 2: Architecture-Topology Separation

---

## What is Path Dependence

- Path dependence is a concept in the social sciences, referring to processes where past events or decisions constrain later events or decisions.
- history matters
- past events or decisions affect future events or decisions in disproportionate ways

(*Wikipedia: Path Dependence*)

---

## MEV Path Dependence

- Flashboys 2.0 / Dark Forest
- MEV is Real (PGAs), Study MEV (defintions), Ethereum is a Dark Forest (Generalized front runners)
- Wat Do?
- MEV-Geth, MEV-Boost, PBS
- Control Systems
- Order Flow Auctions, Inclusion Lists, Encrypted Mempools

---

## MEV is Real

- Flashboys 2.0: an experiment that empirically proved the existance of MEV
- Priority Gas Auctions (PGAs) - Bots competitively bidding up transaction fees in order to obtain priority ordering

(*Flashboys 2.0: Daian, Goldfeder, Kell, Li, Zhao, Bentov, Breidenbach, Juels*)

---

### PGA visualized


---

### Negative externalities of PGAs

- Unnecessary peer-to-peer (P2P) networking load
- Inefficient miner and searcher coordination
- Failed bids reverted on chain
- No granular preference expression (Searchers)

---

## Study MEV, Lesson in there

- MEV, or miner-extractable value, measures the extent to which miners (*monopolists* h/t Tarun) can capture value from users through strategic placement and/or ordering of transactions.

- MEV is a superset of the front-running/arbitrage profits capturable by ordinary users or bots, because miners have strictly more power.

(*Clockwork Finance: Babel, Daian, Kelkar & Juels*)

---

## Formal Definitions
<!-- 5min -->

1. $EV(p,B,s) = \max_{(B_1, \ldots, B_k) \in B} {b(p,s_k) - b(p,s)}$

2. $k−MEV(p,s)=EV(p,validBlocks_k(p,s),s)$

(*Clockwork Finance: et al., On the Formalization of MEV: Salles*)

---

## Ethereum is a Dark Forest
- Generalized Front-runners
- Failed rescue attempt
- DeFi Summer
- High Gas Fees (Congestion & Contention)
- Failed transactions

---

## Walk in, see this, wat do?


(Spa party in Budapest)

---

## MEV-GETH

- Move PGA game out of the public mempool
- Flashbots Auction
- New transaction type Bundles
- expressivity, bundle merging, mega bundles
- Challenges
- Single client with ~ 90% Miner adoption, Not Merge ready, Social contract not enforceable (unbundling)

---

## MEV-GETH topology


---

## The MEV Supply Chain

- The MEV Supply Chain describes the chain of activity which helps users transform ***intentions*** into finalized state transitions in the presence of MEV.

(*The MEV Supply Chain: thegostep*)

---

## The Meme


---

## Centralized (Dystopia)


---

## Decentralized (Utopia)


---

## Merge Ready MEV-Boost
- Wall off Validators from MEV complexity
- Support Client Diversity
- New actors
- Builders & Relays
- Challenges
- Transaction censorship, relay attacks, missed slots, information leakage (incentive to verticalize)

---

## Unstable equilibria

- OFAC sanctions
- Relay dependency (eclipse attack, economic sustainability)
- Builder Centralziation (Beaver, Rsync, Titan)
- Timing Games

---

## Proposer Builder Seperation
- “Firewall” MEV concerns away from core protocol; validator role can remain “dumb” and not have to run complex MEV search algorithms.
- Improve access to MEV for validators who only need to accept the highest bid from a block builder.
- Push centralization to builders, leverage for efficient blocks, DAS, statelessness and extra builder services
- Possibly remove the reliance on a trusted relay

---

## PBS Flavors
- Flavors
- Single-slot, two-slot, ePBS with PTCs and with relays, Multiplicity
- PEPC, PEPC-Boost, PEPC-DVT, Diet-PEPC

---

## MEV Management
- Order Flow auctions (OFAs) - 3rd parties bid for the right to execute order flows, compensating originators for their transaction value
- There must be a seller, a buyer, and an auctioneer.
- Challenges: last look (RFQs), permissioned, centralizing
- Examples: MEV-Share, MEV-Blocker, Many others

*(Everything You Need To Know About OFAs: Monoceros)*

---

### Encrypted Mempools

- Encrypted Mempools can provide;
* Front-running protection
* Censorship resistance

---

### Encrypted Mempool Types

- In-flight - centralized, private mempool.
- TEEs - trusting the integrity of SGX.
- Threshold Decryption DKG
- Penumbra, Ferveo (Anoma), Shutter, etc.
- Delay encryption - VDFs. Not yet ready because it requires a VDF ASIC. (Fabric, cysyc, Ingo)
- Witness encryption - arbitrarily complex and flexible decryption predicates.
- Decrypt if something happens

*(MEV Roast - Encrypted Mempools: Justin Drake)*

---

### Inclusion Lists

- Proposers combat censorship by forcing inclusion of some transactions, in a way which is not bandwidth-intensive
- Allow proposers to force builders to fully utilize the available blockspace: if they cannot do so, they must use the unused space for the proposer-selected transactions

(*Forward Inclusion Lists, Fradamt*)

---

### Inclusion List proposals

- Various Proposals
- crLists
- Mev-Boost ++ (Proposer commitments)
- Forward Inclusion Lists
- No Free Lunch
- Cumulative, Non-Expiring Inclusion Lists
- EIP 7547
- Concurrent block proposers
- COMIS (committee-enforced inclusion sets)

---

## Part 2: Architecture - Topology Separation (ATS)

---

## Sponsored by Rainbow Stakerz


---

## Unbundle everything

- Architecture - Network architecture is a framework for the specification of a network's physical components and their functional organization and configuration, its operational principles and procedures, as well as communication protocols used
- Topology - Network topology is the arrangement of the elements (links, nodes, etc.) of a communication network

(*Wikipedia: Network Architecture and Topology*)

---

## ELI 5

- Thought experiment Imagine you are designing a city:
- Architecture - overall plan for the city, including where everything is supposed to be and how it all works together
- Topology - how you decide to connect everything, roads, bridges, parks, determing the best way for people to move around the city

---

## Ethereum's Architecture

- The Architecture is like the protocol stack
- Defines core components like EVM, accounts, transactions, blocks, consensus
- Specifies high-level system design principles and interactions
- Includes features like smart contract languages, EVM upgrades, EIPs

---

## Ethereum's Topology

- The topology is how it works in practice
- Describes organization and interconnections of different node types
- Outlines roles like full nodes, light nodes, miners/validators, bootnodes
- Illustrates flow of data/transactions between nodes
- Designed to support core functions like transaction propagation, consensus, execution

---

## What are intents?
- colloquial defintion: credible commitments to a preference function over a shared state space
- mathematically: atomic information flow constraints

---

## Precisely

$I :=$ $(S$ $➝$ $S)$ x $(S$ x $S$ $➝$ $U$ $⋆$ $[0,1])$

- We formulate intents as a pair consisting of a transition function and a partial weighted predicate over state transitions
- The guiding intuition for this formulation is to separate control from desire

(*Intent Machines: Goes, Hart, Reusche*)

---

## Continued...

- In the prototypical example intents will express a desire for some resource in exchange for another
- The 1st component expresses a partial state transition where the intent may create/destroy what it has control over. This aids in composing intents
- The 2nd component expresses a weighted predicate over transitions. If the transition satisfies the intent, it returns an element between 0 & 1, representing a kind of utility

---

## Warning: Intents are not Magic


---

## Claim

- In a sufficiently generalized intent-centric system ( even current Ethereum), the game theory / incentive analysis is mostly a function of the topology, not really of the architecture
- if you fix the variable of architecture, incentive structures are a function of the topology

---

## Intents decouple architecture and Topology

- Inten-centric architectures like Anoma provide a specific way of organizing subcomponents into a structure designed to serve the purpose of the overall system
- P2P routing, transaction execution

---

## P2P Routing

- Traditional architectures have P2P routing hardcoded into the core protocol (Tendermint Mempool 😱)
- Intent-centric architectures separate P2P routing into a subcomponent
- Allows different implementations prioritizing speed, programmbale disclosure, etc.

---

## Transaction execution

- Traditionally tightly coupled with consensus and data storage
- Decouple Counterparty Discovery and settlement
- Enables different execution environments (EVM, SVM, Move, ARM...)

---

## Intent-centric Topologies

- Roles and responsibilities explicitly defined based on intents
- Allows programmable configurations with dedicated nodes for routing, solving, execution, consensus, etc.
- Promotes flexibility for different users/communities to experiment with suitable topologies

---

## Thought Experiment: MEV Market Conjectures & Refutations

- Orderflow, Trust, Opacity

---

## MEV Trojan Horse


---

## Orderflow Conjecture

- Challenge: If intent execution is permissioned and the permissioned set is not chosen with care, the migration out of the public mempool threatens to centralise block production on Ethereum

---

## Orderflow Refutation
- Users monitor intent execution and switch away from bad operators by evaluating performance and credibly threatening to leave (slow game) or hold accountable (dydx slashing committee)
- Due to network effects, users must coordinate to collectively switch operators as needed; operators will try to lock in users and extract MEV

---

## Trust Challenge

- Challenge: As many solutions require trust in intermediaries, development of new intent-based architectures is hampered by high barriers to entry, implying lower rates of innovation and competition to ensure execution quality

---

## Trust Refutation
- Topology depends on what trust relationships the protocol can model
- Anoma aims to standardize the protocol to model diverse trust relations explicitly;
- users to send intents initially to friends or local community pools
- Configurable nodes for different roles;
- should lower switching costs, and making the long-term incentives transparent

---

## Opacity Conjecture

- As many intent architectures entail the user surrendering some control over their on-chain assets and permissioned mempools imply a degree of impenetrability from the outside, we risk building an opaque system in which it is unclear how or whether users’ expectations are met and threats to the ecosystem remain undetected

---

## Opacity Refutation

- Intents define their own settlement conditions, controlling what routing/disclosure happens within the network back to the user.
- Intents can require signatures from gossip nodes, or encryption of data
- Information Flow control
- precise control over information flow is table stakes for intent systems, not optional

---

## Conclusions

- MEV discourse and decision making is path dependent
- Intents decouple protocol architecture from topology;
- Architecture - Topology Seperation (ATS)
- Remove monolithic constraints
- if you fix the variable of architecture, incentive structures are a function of the topology
- User choice, monitoring, and incentivization ultimately determine system behavior

---

##


---

## Bonus

"See I know what you're thinking. Actually, I've been thinking it ever since I got here. Ethereum is an excellent settlement option for Anoma from an architectural perspective."