Detailed explanation of modular MEV: How to achieve fair transaction ordering?
Original author: Maven 11
Original compilation: Luffy, Foresight News
In the first two parts of this series of papers, we focused on the technical issues that arise when splitting the stack, and the improvements needed for a modular world. We have introduced a number of work advances to address problems that naturally arise in cross-domain settings. However, in the final part of the series, we want to focus more on user experience. We wanted to examine how modularity, customization, and specialization can help create better applications. The final chapter in this series looks at the exciting and unique creativity and possibilities in modularity for developers to create Web2 user experiences with Web3 provability.
The reason behind building modularity should not be just to fit a narrative, nor just for the sake of being modular, but because it allows us to build better, more efficient, and more customizable applications. When building modular and purpose-built systems, many unique features arise. Some of these are obvious, while others are less obvious. Therefore, our goal is to provide an overview of modular system capabilities that you didnt know existed, such as scalability.
We believe that one of the capabilities that modularity provides developers is the ability to build highly customizable professional applications that provide a better experience for end users. We have previously discussed the ability to set rules or reorder transaction execution.
Verifiable sorting rules (hereinafter referred to as VSRs) are one of the interesting opportunities provided by controlled ordering, especially for developers interested in building fairer trading systems in terms of execution. Obviously, how liquidity provider losses relate to rebalancing (LVR) is beyond the scope of this article, so we will avoid touching too much on this aspect. Keep in mind that the setup we are about to explain is primarily for the AMM and not the order book model. Additionally, CLOBs (and even CEX) would greatly benefit from leveraging verifiable collations appropriate for their specific settings. In an off-chain setting, there is a clear need for some concept of zero-knowledge or optimistic execution backed by cryptoeconomic security.
VSR is particularly interesting when we consider the fact that most retail investors have not yet (or are unlikely to) adopt conservation methods. Most wallets/DEXs also dont implement private mempools, RPC or similar methods. Most transactions are submitted directly through the front-end (either an aggregator or a DEXs front-end). Therefore, unless the application directly interferes with their processes and the way orders are processed, the execution results achieved by end users are likely to be less than ideal.
The role of VSR becomes apparent when we consider where transactional supply chain sequencing occurs. It is located where professional players order (or contain) transactions, usually based on some auction or base fee. This ordering is very important as it determines which transactions are executed and when. Essentially, those with ranking rights have the ability to withdraw MEV, usually in the form of priority fees (or tips).
Therefore, it might be interesting to write rules on how ordering is handled in order to provide fairer trade execution (in a DEX setting) to end users. However, if you are building a general-purpose network, you should try to avoid following such rules.
In addition, there are some MEVs that are important, such as arbitrage, liquidation, etc. One idea is to create a “highway” channel at the top of the block, specifically targeting whitelisted arbitrageurs and liquidators, who pay higher fees and share part of the revenue with the protocol.
In the paper Trusted decentralized exchange design through verifiable ordering rules”, Matheus V., In cases where the set rules are not followed, observers can generate proofs of failure (or since the constraints are mathematically verifiable, you can also imagine a ZK circuit with these constraints, which uses ZKP as a proof of validity). The main idea is essentially to provide the end user (the trader) with an execution price guarantee. This guarantee ensures that a trade is executed at a price as good as the only trade in the block (obviously, there is some degree of latency involved here if we assume a buy/sell/buy/sell ordering based on first come, first served) ). The basic idea of the proposal in the paper is that these ordering rules will restrict the builder (in a PBS scenario) or orderer to only include transactions in the same direction if they execute at a better price than the price available at the top of the block (e.g. sell/sell). Additionally, if there is a situation where you make a sell at the end of a series of buys, then the sell will not be executed (e.g. buy, buy, buy, sell), which may indicate that the searcher (or builder) /sorter) use these purchases to push prices in their favor. This essentially means that the protocol rules guarantee that users will not be used to give others better prices (i.e. MEV), or have prices slip due to priority fees. Obviously, the drawback to the rule here (in the case of more sells than buys, or vice versa) is that you may get relatively poor long-tail prices.
For a general smart contract platform, it is almost impossible to treat these rules as pure on-chain construction rules, because you have no control over execution and ordering. At the same time, you are competing with many others, so trying to force those at the top of the block to pay priority fees would be unnecessarily expensive. One of the features of a modular setup is that it allows application developers to customize how their execution environment should behave. Whether thats collation, using a different VM, or making custom changes to an existing VM (such as adding new opcodes or changing gas limits), its really up to the developer, and up to their product.
In the case of a Rollup using data availability, consensus layer, and liquidity settlement layer, the possible settings are as follows:
Another possible idea is deal splitting. Imagine you have a trading pool, how do you execute large order trades (which result in a lot of slippage)? Is this fair to the end user if this transaction is executed across consecutive blocks (or at the end of the block if VSR compliant)?
If an end user is concerned about latency, then that user may not want his order to be split. However, this is less common and optimizing trade splitting for larger orders will likely result in more efficient execution for the vast majority of users. Regardless, one concern is that MEV searchers may become aware of these consecutive trades and attempt to position their own trades before or after the traders mentioned above. However, due to smaller split transactions over a series of blocks, the total value of MEV extracted may be much smaller.
Another interesting idea we mentioned in a previous post is using the technology pioneered by the legendary Eric Budish and his colleaguesFrequent Batch Auction (FBA), processing transactions in a batch auction rather than a serial manner. This is to help identify overlaps of demand (CoW) and incorporate arbitrage opportunities into market mechanism design. This also helps against latency games in consecutive block builds (or priority fee wars in serial blocks). Thanks to Michael Jordan (DBA) for bringing this paper to our attention and for his work on easing Latency Roast. Implementing it as part of Rollups fork selection and ordering rules is also an interesting feature that developers can use. setup, we have seen it gain significant traction over the past year, especially with Penumbra and CoWSwap. One possible setup looks like this:
In this setup, there are no first-come, first-served or priority gas wars, but rather block-end batch auctions based on cumulative orders in the time between each block.
Generally speaking, in a world where most trading has moved to non-custodial on-chain, FBA may be one of the more efficient ways of real price discovery, depending on the block time. Leveraging FBA also means that there is significantly less front-running since all bulk orders are in bulk and not revealed until the auction ends (assuming some encryption is set up). A uniform settlement price is key here, as there is no point in reordering the trades.
It’s also worth pointing out that a design similar to the one we just introduced was discussed on the Ethresear.ch forum back in 2018 (See here). In the post, they mentioned two papers that provide a batch auction mechanism on Plasma (sort of a prequel to modern Rollup), where each batch accepts orders to buy other ERC 20 tokens at some maximum limit price . These orders are collected at certain intervals and provide a uniform settlement price for all token trading pairs. The general idea behind this model is that it will help eliminate the front-running phenomenon common in popular AMMs.
Another important thing to note is that in these settings the sequencer may need some incentive to enforce (and enforce) the above rules. This is often overlooked, but much of the infrastructure of blockchain networks is run by professional companies, whose costs are completely different from ordinary home participants. In general, incentives are an important component of security infrastructure implementation. Sequencers and builders are also more likely to exert greater effort where incentives are aligned with the rules being enforced. This means there should be an active market for these settings as well. Clearly, such markets are becoming more centralized, as the cost of capital for specialization can be high. Therefore, the smartest (and richest) are likely to consolidate and specialize to capture as much value as possible. Here, exclusive order flow may be an arrow in the knee for some players, leading to increased centralization. A general benchmark fee might be enough, but it doesnt really push sequencing players toward specialization. Therefore, you may want to introduce some concepts that keep traders satisfied with the results through incentives that fit your specific situation.
This should be obvious to most people, but still needs to be mentioned when discussing rollup level sequencing. If you can control the ordering, you can more easily extract the value of the protocol. This is because you control the power to reorder transactions, which is usually based on priority fees on most L1s (MEV-boost-esque setup). It gives you priority fees paid by complex participants who extract value on the chain. These players are often willing to pay considerable sums (until it no longer provides value). However, most rollups currently adopt a first-come, first-served mechanism. Most MEV extraction occurs via delay wars, which puts severe strain on the Rollup infrastructure. For the above reasons, we may see more and more Rollups start to implement ranking structures with a priority fee concept (such as Arbitrums time enhancement mechanism).
Another example we like is Uniswap. Currently, Uniswap as a protocol “creates” a lot of inefficiencies. These inefficiencies are exploited by participants seeking to extract MEV (arbitrage, at the expense of liquidity providers). At the same time, these participants paid significant fees to extract value, but none of that value ended up in the hands of the Uniswap protocol, nor its token holders. Instead, a large portion of this extracted value is paid via MEV-Boost to Ethereum proposers (validators) for the right to be included in a block that allows value to be captured at some point. Therefore, while there are numerous MEV opportunities in Uniswap order flow, none are captured by Uniswap.
If Uniswap were able to control ordering within the protocol (and the ability to extract priority fees from searchers), it could achieve commercialization and perhaps even pay some of those profits to token holders, liquidity providers, or others. With changes to Uniswap (e.g. UniswapX etc.) moving towards off-chain execution (and Ethereum as a settlement layer), this mechanism looks increasingly likely.
If we assume a Rollup with a partial PBS mechanism, the order flow and commercialization process may be as follows:
From this, the commercialization of Rollup orderers and proposers may follow the following formula:
Circulation volume (PoS) + fee income (+priority) - cost of DA, state pub, storage
A good way to see how much value is currently being extracted on Ethereum (especially arbitrage) can be found at Mevboost.pics which gives a good overview of how much value can actually be extracted from inefficiencies.
Additionally, decoupling priority fee gas wars from off-chain structures can help contain supply chain disruptions by isolating MEV extraction into the execution environment. However, considering that if the leader election happens on Rollup, most MEV will be extracted on Rollup, which leaves little room for the underlying structure unless the DA layer is included, the priority fees of the settlement layer come from liquidity integration or other economies of scale.
To clarify, many of these structures can function as purely off-chain structures without any validation bridges or strong security guarantees. However, there are some trade-offs that must be made there. Were starting to see more of these popping up, both existing and invisible. One thing I want to point out is that a modular setup doesnt necessarily mean a rollup.
The above ordering rules represent an example where fine-tuning the infrastructure can drastically improve the applications built on top of it.
