A path dependent topology of MEV discourse

A Path dependant topology

Path dependence explains how past events or decisions constrain future events or decisions.

The evolution of MEV discourse has been path-dependent, influenced by events like priority gas auctions, the "Ethereum is a Dark Forest" article, and the development of MEV-Geth, MEV-Boost, and proposer-builder separation.

The Flashboys 2.0 paper empirically proved the existence of MEV, particularly priority gas auctions (PGAs)

Negative externalities of priority gas auctions included unnecessary networking load, inefficient miner-searcher coordination, failed transactions, and poor user experience.

Researchers studied and formalized the concept of MEV, as seen in the Clockwork Finance paper and the "Ethereum is a Dark Forest" article.

The MEV Supply chain

It highlighted the risk of a centralized dystopia where each role in the supply chain is verticalized by a single entity. So we needed to decentralize block building

MEV-Boost aimed to wall off validators from MEV complexity, support client diversity, and introduce new actors (builders and relays).

Challenges included :

• Transaction censorship
• Relay attacks
• Missed slots
• Information leakage
• An unstable equilibria due to factors like OFAC sanctions, relay dependency, builder centralization, and timing games.

MEV Management Solutions

Various MEV management solutions have been proposed, such as :

• Order flow auctions
• Encrypted mempools (for frontrunning protection and censorship resistance),
• Inclusion lists (allowing proposers to force builders to utilize available block space).

Research on inclusion lists has evolved from CR lists to MEV-Boost + forward inclusion lists, no free lunch, cumulative non-expiring inclusion lists, EIP-7547 (concurrent block proposers), and committee-enforced inclusion sets.

Architecture - Topology Separation (ATS)

• Architecture refers to the overall framework, components, and operational principles of a system.
• Topology refers to the arrangement and interconnections of elements within the system.

Separating architecture and topology allows for flexibility and experimentation with different configurations.

Ethereum's architecture is core components (EVM, accounts, blocks...) and the topology is how it works in practice (flow of data transactions between nodes...)

What are intents ?

The key idea is to separate control from desire. But intents should not be overhyped, and skepticism is encouraged.

In a sufficiently generalized intent-centric system, the incentive analysis is mostly a function of the topology, not the architecture.

Intents decouple architecture and topology, enabling flexibility in organizing subcomponents like peer-to-peer routing and transaction execution.

Intent-Centric Roles and Responsibilities

Intent-centric architectures allow for explicitly defined roles and responsibilities based on intents.

Concerns are raised about order flow centralization, trust in intermediaries, and opacity in intent-based architectures.

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

Potential refutations are offered, such as user monitoring and switching away from bad operators.

The problem is, 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

Conclusions

MEV discourse and decision making is path dependant

Intents decouple protocol architecture from topology. They remove monolithic constraints and allow incentive structures to be a function of topology.

User choice, monitoring, and incentivization ultimately determine system behavior.

Hence, the Anoma architecture is suggested with Ethereum settlement