MEV is a hot topic right now. I’ve been learning as much as I can and trying to stay up to date on the discussion of solutions and the various problems with their implementations. This is a fun problem space to think about and obviously is critical to the success of permissionless blockchain systems in the long run.

The 8 hour MEV.WTF summit and panel during HackMoney was fascinating but honestly a lot to digest and I needed to go back to it. The intern notes for podcasts that have been passed around twitter recently have been great, and this is an attempt to serve that purpose for a longer form and more technical source and distill it into something accessible.

A few terms related to encryption I think it would be useful to define are SGX, timelock encryption, and threshold decryption (sometimes called threshold encryption, interchangeably). SGX stands for Software Guard eXtensions and is a set of instructions that offers hardware-based memory encryption. Specific code and data are isolated in ‘enclaves’ where they can run without being exposed to outside code. Timelock encryption is the idea of encrypting something until a certain timestamp, where it is then able to be unlocked.Threshold decryption is a mechanism where a message is decrypted after a certain threshold of actors with shares of the key sign it.

At the end I’m going to talk about the key takeaways I gleaned from the content, but from the (START TALKS) tag down to the (END TALKS) tag nothing is representative of my own opinion and only pertains to the speaker’s opinion and the content of their talk. All images come directly from the slides posted at https://hackmd.io/ivUzk3piQEG8ALzCGbxlag.

Conceptual Summary

MEV is the profit that block producers/proposers are able to harvest through the use of powers unique to their role within the network.

We are living with MEV now and whether we like it or not, it’s not going away. Permissionless blockchain systems, particularly with complex state spaces affected by smart contract operations, require some amount of MEV to work correctly. A recurring theme in the talks below is that we should minimize the MEV that is not fundamental to the system and democratize the rest of it.

The job of minimization and democratization falls both on system and application developers. System developers cannot move as quickly in experimentation but do need to give application developers the tools to deal with MEV onchain.

(START TALKS)

Part 1: The Evolution of MEV:

Charlie Noyes (Paradigm) - WTF is MEV

MEV is a measure of the profit a block producer can harvest by reordering or censoring transactions. It exists in any system that cannot demonstrate its own consistency. It was first brought up by pmcgoohan in 2014 but popularized by Phil Daian with the Flasboys 2.0 paper in 2019.

Now, we live in the era of MEV. What does this mean? Miners may end up colluding to their heart’s content, application design must change with MEV in mind, some systems will fail, and it’s likely that short term re-orgs increase in frequency due to time bandit attacks. These are reorgs of the blockchain that harvest MEV for the actor that implements the attack.

Phil Daian (Flashbots) - When cryptoeconomics breaks?

Flashbots is aware of the problem with the centralization point that they bring to the ecosystem and believes that the solution is a decentralized “fair, real-time marketplace” where fairness is defined with the characteristics of: pre-trade privacy (which currently relies on trust in miners and flashbots), spam resistance (which currently relies on trust in flashbots), and that the incentives remain aligned with the stability of the Ethereum network. Flashbots can be upgraded by removing these elements of trust but there remains the question of what is good enough decentralization? It’s always a tradeoff, but a good framework is that it is: robust to system shocks for miners, bots, and users, it is robust to byzantine (malicious) operators up to a certain threshold, and it is robust to rationally self-interested operators up to a higher threshold.

In a post-relay world, we must be aware of the risks of a trust collapse/spiral, a cat+mouse game forming with deniable attacks, a need for constant data/policing, a major centralization point in the Eth stack, and vampire tokens (attacks) from relay providers.

Alejo Salles (Flashbots) - MEV after EIP-1559

Miner incentivization - Will miners be incentivized to extract more MEV? But first, will they “switch lanes”?

|

One auction, many auctions - 1559 design was done without considerations towards MEV, it assumes that users bid for transaction inclusion when in reality we now bid for ordering, privacy, etc.

Using a framework for desired characteristics of a network change, we look at Myopic Miner Incentive Compatibility (that the system is robust to rational miners within the span of one block), User Incentive Compatibility (that users express their true preference for inclusion without needing to speculate on the actions of other users), and Off Chain Agreement Proofness (that users and miners cannot circumvent transaction fees by agreeing to inclusion offchain). This framework will be used to evaluate 1559 and a tipless model that only uses the base fee. 1559 only checks the UIC box outside periods of high demand, due to needing to speculate on other users’ tip fees. This property is part of a tradeoff with the OCA-proofness property. The tipless model solves this issue but is only OCA-proof outside of periods of high demand.

Flashbots Ethics - 85% of hashrate currently runs MEV-geth, introducing a new point of corruption and centralization to the system. What if flashbots fills size only up to s0(1-e) (slightly smaller than target block size)? What is the number of underfilled blocks needed to return a profit?

Panel - MEV and interoperability: Rollups, Cross-L2, and Cross-Chain

Panelists:

• John Adler (Celestia)
• Eli Ben-Sasson (Starkware)
• Ed Felten (Arbitrum)
• Ben Jones (Optimism)
• Zaki Manian (iqlusion)

How is cross domain communication handled in implementation?

Ben: L1 is the source of truth so it does the communication for inter-chain operations. Optimism uses a Lower-L1 model where a smart contract or account on L1 specifies data, target, and gas limit to eventually be included in the rollup. On the L2 there is an opcode that lets you access who on the L1 sent that. You can be out of gas on L2 and not know it on L1 so the additional level of messaging exposed to devs allows atomicity of a guarantee that it will get accepted eventually.

Eli: All communication is also done through L1. We’re working on something else but I can’t talk about it yet.

Ed: We have a general purpose mechanism to send contract calls from one domain to another. You know the call will run but can’t know the result because the domains are asynchronous. Asynchrony is necessary to rollups because of complexity of synchronicity across domains.

John: Celestia is about general purpose data availability throughput and doesn’t execute transactions so there are no bridges because there are no transactions or VMs. Applications define their own mechanism for cross domain communication.

Zaki: IBC is an asynchronous packet messaging system for blockchains with fast finality that has general tolerance for failure of intermediaries with regards to chain or relayer liveness.

Are there any apps besides token bridges using crossdomain communication?

• Applications that want to exist on multiple chains, even L1 and L2
• Running computation off-chain to open up the dapp design space
• Interchain accounts where entire blockchains can have accounts on another chain

Are there specific ways crossdomain MEV differs?

• Combinatorial explosion of arbitrage opportunities
• Interplays between different ordering mechanisms
• Intra-L2 comms don’t depend on L1 state and finality so can be less restrictive, opening up new MEV
• MEV isn’t destroyed, rather it’s moved and fractionalized to different layers (some disagreement over this)

Whose job is it to reduce MEV, system or applications developers?

• Everyone agrees it’s both parties’ jobs, despite admitting that this is a philosophical question
• System designs require universality of fairness assumptions and thus cannot cover everything
• Not all dapp developers have the network’s best interest at heart. Their job is to make money.
• System developers need to give the application developers the tools to use in designing their dapps around MEV

Part 2: Framing the MEV Problem:

Sunny Agarwal (Osmosis) - Classifying MEV and identifying potential solutions

MEV comes from unique powers that a block proposer can single-handedly execute. These are classically seen as inclusion and ordering of transactions but now include reading submitted transactions thanks to the Flashbots relay.

It can also include timestamp manipulation, for example a lottery that uses block timestamps as a source of randomness. A way around this is BFT time, where block time is a weighted median of validator-proposed timestamps.

A solution is that transactions could be encrypted in the mempool and decrypted after finality is reached in ordering. This can be done with trusted hardware such as SGX, timelock encryption, and threshold encryption. Threshold encryption appears to offer the least tradeoffs.

The solution to the inclusion issue could be Joint Proposals, where validators vote for inclusion of transactions and the block producer/sequencer must include the list voted on.

The key takeaway is that we need to decentralize the powers given to block producers and be aware of the tradeoffs between different mitigations.

|

Hasu (Paradigm, Uncommon Core, Deribit Insights) - Mapping the MEV solution space

MEV is a blanket term for permissionless incentives in blockchains, extractable on a first come first serve basis. Some MEV, such as liquidation of undercollateralized positions on lending platforms or backrunning arbitrage on AMMs, is good for the ecosystem. Other MEV, such as frontrunning and sandwich attacks, are negatives and should be minimized.

The primary impact of MEV so far has been financial loss to users of the Ethereum network. 70% of gas on Ethereum is used for dex trades, which created much higher transaction costs due to bidding wars for MEV in priority gas auctions. Additionally, dex traders receive worse prices as a result of sandwich attacks.

The goal should be to minimize as much MEV as possible while democratizing what we can’t. Minimizing can be done in every layer of the stack. In the consensus layer, fair ordering and privacy implementations can attempt to minimize. In the P2P layer there are the mitigations of gasless transactions (gas is dependent on inclusion in a block) and mempool segregation (sending tx to private mempools that accept conditions such as no frontrunning for a fee). In the application layer there are dex aggregators (which lowers profitability of sandwich attacks and doesn’t create a backrun arb), backrunning as a service (auctioning off the right to backrun your trade and getting a cut), and offchain ordering (submitting to an offchain sequencer that submits to L1 in “fair order”).

A couple of general improvements that can be made are more concentrated liquidity and higher use of dex aggregators, but these aren’t enough. Another idea is an AMM pool that auctions off the right to each arb and returns it to liquidity providers or users. Generally we should democratize markets for flashbots bundle and block templates in an open and permissionless way.

The key takeaway is that the question of MEV democratization vs minimization is a flawed way of thinking. We need to minimize what we can and democratize what is fundamental to the network and dapps. The innovation that leads to this must happen on all layers of the stack because MEV is in all layers of the stack.

Lakshman Sankar (Ethereum Foundation) - Is MEV a problem to be solved or a reality to be lived with?

The title of the talk is a rhetorical question, it is obviously both. Reality is too nuanced for bipartisan systems of belief, as is the future. Synchronous blockspace is a scarce resource and chains will choose to deal with MEV in different ways so a multichain world is inevitable, as is inter-chain MEV.

Inter-chain MEV is probabilistic rather than deterministic due to the time delay between blocks of different chains in asynchronous sets of blockchains. Different chains will also have different fairness criteria as they have (and sometimes are created because of) differences in tradeoff preferences.

These tradeoffs are present in all mitigation techniques. Fair ordering adds assumptions in a trusted oracle or on-chain source of randomness and timelock encryption adds latency to the protocol layer. Different tradeoffs may be optimal for different sets of applications and thus different chains.

(END TALKS)

Alright I think that’s about enough for now. There’s actually still a lot to go and I don’t want to overload people. This is a good introduction to some of the later discussion, which starts to get a bit more technical.

I’d like to preface everything that’s about to follow with a clarification that my stance is NOT an authoritative one. I have not written a searcher and I have never written blockchain client code. That being said, I have a technical background and surround myself with bright people. Learning in the open is a symbiotic arrangement. I am confident in my ability to find my feet in this space. This is an effort to help others gain something from my journey while simultaneously gaining a level of accountability that I cannot achieve on my own to push me forward. I will get things wrong, so take everything I say with a grain of salt.

Takeaways

There are some key takeaways that I gathered from these first two parts of the summit. The first of which is that there is a recurring theme that some MEV is fundamental to the network and we need to realize that we have to both minimize and democratize. The other is that every mitigation technique has idiosyncratic tradeoffs and implementation challenges.

If transaction content is timelock encrypted until it is probabilistically reasonable to assume that ordering finality has been reached, then transactions can’t be frontrun. This introduces network latency at the time window of that assumption though, and encrypted mempool transactions in general don’t solve re-org MEV.

Threshold decryption could be implemented with the idea of non-block producer validators voting on txs that have to be included, where content is decrypted when the threshold of validators is the same for decryption and inclusion finality.

Reflections

At some point Sunny Agarwal literally said “and then some magic happens” regarding encrypted transactions in the mempool that are later decrypted. I don’t like the magical wand view of encryption. Implementation details are crucial to these systems, for an example read about the Ping Reject attack for deanonymizing Zcash transactions (https://crypto.stanford.edu/timings/). The takeaway is that the timing and behavior of the implementations of these solutions can open up vulnerabilities that we aren’t aware of until the details are figured out.

Conclusion

All in all I learned a lot from watching this 3 times, looking up what I didn’t understand, and writing this to structure my thoughts on it. I’ll be doing another part (maybe two, there’s a lot to unpack here) in the near future as well as a general unpacking of these past few crazy months for me.

If you have any questions you can reach me at @CryptoNymph on twitter. I stay busy building my empire so apologies if I don’t get back quickly but I do try to get back. Many thanks to the Zero Knowledge podcast, Uncommon Core, Paradigm’s Dark Forest series, and MEV Senpai for helping me build the foundation to be able to understand this space enough to find my hunger for it. As always, thanks to the crew at Femboy Capital. They help in everything I do and I wouldn’t be where I am today without their support.

About Femboy Capital

Evolving from a simple joke, Femboy Capital is an autonomous cooperative incubator and DeFi accelerator that ideates, develops, and shepherds products, protocols, and initiatives within the DeFi space. Feel free to reach out if you want to know more, we are always incubating project ideas and looking for collaborators to help further them. You can get in touch through my twitter account or the official @femboy_capital account.