SUAVE: Entering the New MEV Decade

Jiawei

Published in

IOSG Ventures

11 min readFeb 8, 2023

Author: Jiawei, IOSG Ventures

tl;dr

To address the builder centralization issue, Flashbots has proposed SUAVE, an EVM-compatible blockchain that acts as a unified sequencing layer for multiple chains.
The infrastructure can be seen gradually transitioning from a generic layer to a specialized layer. The “whole to be greater than the sum of its parts” is made possible by the increased functional modularity and specialization.
From PBS to SUAVE, the trend is to keep introducing competitive diversity and ensuring balanced competitive conditions.
We envision a new decade of MEV: competition rather than monopoly; sharing rather than exclusivity; co-rule rather than dictatorship.

What have we got?

Almost a year after The Merge, we have a fairly well-defined MEV supply chain and workflow. The entire process has been highly specialized.

In the late 2020s, during the DeFi summer, MEV first started to emerge along with the sharp increase in on-chain financial activity. At the time, there was almost no direct channel of communication between MEV searchers and miners; instead, searchers had to simply pay higher gas in order to have their transactions included. This resulted in a series of instabilities, such as network congestion and fluctuating gas, which had negative externalities on Ethereum network.

Based on the auction mechanism, Flashbots Auction establishes a communication channel between miners and searchers, with the former selling block space and the latter capturing arbitrage opportunities, allowing block space to be marketized.

However, a new issue arose, which is the disparity between the ability of large validation pools and individual validators to capture MEVs, and the former already has a higher probability of being chosen as a proposer, which will gradually lead to the centralization of Ethereum validator set. To create a more level playing field, PBS was proposed, which means that both large validation pools and individual validators outsource block building to those professional block builders.

MEV-Boost, as a PBS implementation that comes before in-protocol PBS, maintains the auction mechanism while mitigating the problem of validator centralization at the MEV level.

What else is required, then?

Decentralization of block builders is still required.

It’s easy to overlook the fact that the role of builders remains highly centralized for a longer period of time following The Merge. Only four builders have built 79.1% of MEV-Boost blocks in the last 14 days. Censorship and extortion, regulatory level pressure and system vulnerability, and other undesirable outcomes are brought about by centralization (especially when block building is the core infrastructure).

The reasons for the centralization of builders are primarily due to the two factors listed below.

Exclusive Orderflow (EOF)

As we know, there are three main sources of orderflow for builders: mempool, private transaction channels, and bundles submitted by MEV searchers; the ultimate goal of builders is to build the most profitable block. Orderflows are the most basic means of production in block building, and the more orderflows one has, the more chances one has of expressing MEV. Even with a good strategy, if the builder cannot obtain enough orderflows, it is nearly impossible to win in the fierce competition of block building.

The network effect of the OF-advantaged party is very visible in this regard. On the one hand, they have a better chance of expressing MEV, which means they are more likely to build the most profitable block; on the other hand, if the OF-disadvantaged party is late in winning the block, the transactions submitted by their orderflow owners are also delayed in being confirmed. After a while, these orderflow owners will turn to the builder, who can confirm transactions more quickly. The gap between the two parties will quickly widen, and eventually the underdog will have to withdraw from the contest.

Builders have the flexibility to use a variety of approaches to get as much orderflow as possible: similar to the PFOF (Pay for Order Flow) seen in traditional brokerages, builders can pay rebates to wallets, RPC service providers, and dApps to get their orderflow. Wallets can do this easily by modifying the default RPC endpoint, and most users don’t care or be aware of whether their transactions are sent to a public mempool or a private relay.

To entice users to submit transactions to them, builders can offer additional services such as sandwich protection, pre-confirmation of transactions, subsidizing users’ gas, and so on.

The diagram above depicts the vicious circle that EOF can bring: EOF gives builders more freedom and room to maneuver in how to express MEV and thus build blocks with higher value; over time, these builders take a larger market share of block building, justifying exclusivity agreements of EOF; and this becomes an incentive for builders to further optimize and drive EOF.

According to Rated, 529,633 addresses in blocks built by builder0x69 in 14 days were not in the blocks of other builders; i.e. the order flow originating from 32.7% of these addresses was unique to them. As can be seen, EOF has captured a sizable portion of the top builders.

Cross-domain MEV

*Source: apriori, odos.xyz, A Formalization for Cross-domain MEV*

Cross-domain MEV is the other problem that could centralize builders.

The background of cross-domain MEV is more closely related to Vitalik’s Rollup-centric Roadmap. Multiple Rollups will host the majority of the Ethereum L1 activities in the coming years, with Ethereum L1 serving only as the DA and security layer. According to this vision, a large amount of financial activity will frequently occur between and across Rollups, resulting in more complex cross-domain arbitrage opportunities.

Intuitively, builders of multiple domains have a better chance of capturing cross-domain MEV than builders of a single domain, and thus gradually dominating block production in each domain.

SUAVE

Flashbots proposes SUAVE as a solution to the problem stated above.

High-level speaking, SUAVE is an EVM-compatible blockchain that serves as a unified mempool and block builder network for all blockchains, as well as a decentralized sequencing layer.

SUAVE can be divided into the following three parts.

Preference Environment

Preference environment corresponds to cross-domain MEV.

Preferences are defined relatively broadly: for a user, customizing the parameters of a swap is an example of a preference; for a MEV searcher, specifying the position or state of a transaction, or proposing a particular sequence of transactions (for example, a bundle), is also an example of a preference. Simple transactions within a single domain and complex sequences of events spanning multiple domains are both examples of preferences. Users pay for their preferences, and the fee is released once the preference is met.

Technically, the preference environment is a public multi-chain mempool that aggregates as many preferences as it can at the same layer. Users’ preferences are ultimately reflected in the mempool in the form of transactions.

Why is the cross-domain MEV problem solvable by preference environments? As we mentioned above in the problem statement, a multi-chain builder will have an advantage over a single-chain builder in cross-domain MEV because the multi-chain builder can see and seize more MEV opportunities.

While SUAVE itself is a unified sequencing layer for multiple chains, the preference environment is like placing multiple chains’ user preferences in the same layer, so that user preferences are accessible and transparent to both multi-chain and single-chain builders. As a result, the advantage brought on by the information gap is eliminated.

Execution Market

Execution market corresponds to EOF.

The user preferences above are already reflected in SUAVE mempool. Then the role of executor is introduced at this point in the execution market, where they compete to provide the best execution for the user’s preferences. Executors are abstract concepts; builders, RPC service providers, wallets — anyone can be an executor for the various user preferences.

First, the user’s transactions produce MEV. Second, the executors compete with one another to meet the user’s preferences. When the same best execution is offered, the price reflects the competition, allowing the user to receive the most MEV possible. Because of this, the execution market achieves “Minimizes MEV for users”.

The preference environment described in the preceding section makes all users’ preferences open and transparent. The execution market solves the EOF problem by putting these preferences in an open market and allowing all executors to fulfill users’ preferences by bidding on them, rather than having individual builders satisfy them exclusively.

Decentralized Building

Finally, a complete block is built by a network of builders working together, rather than by a single builder, by integrating the output of preference environment and execution market. This step requires builders to share the information without revealing orderflow and bundle content, and security solutions such as SGX will be introduced later in the SUAVE roadmap to meet this requirement.

Thoughts

Part #1

If we set aside MEV for a moment and consider SUAVE solely from a blockchain standpoint, we can deduce the following development trend and narrative logic of blockchain.

First, Bitcoin uses blockchain, which offers the most fundamental level of trust as a financial infrastructure, to achieve value transfer without the need for any trusted third party.

Following that, the L1s represented by Ethereum as the dApp’s execution environment emerged. They can be further subdivided into the general execution environment represented by general purpose Alt-L1/Rollup and the application-specific execution environment represented by Appchain/App-rollup. We abstract out the components such as network and consensus into a whole, and they serve as the soil in which the dApp can grow.

Although the Rollup can be considered as the execution layer, carrying a portion of the workload of Ethereum L1, the execution environment is still primarily monolithic. Celestia disassembles the execution environment’s components. The DA layer also serves as the blockchain, but it is no longer the “execution environment,” and consensus among nodes is only required for the Data Blob to achieve consistency. At this point, the blockchain is introduced as a trust unit in order to increase DA’s trust level.

SUAVE further abstracts Mempool and Sequencing from multiple execution layers to serve as a unified coordination layer, and SUAVE’s design of transaction types and fee structures can be customized and adapted to express MEV without having to be identical to those previous blockchain designs. The blockchain functions more as a coordination layer in multi-chain and multi-party collaboration scenarios.

The infrastructure can be seen gradually transitioning from a generic layer to a specialized layer. The “whole to be greater than the sum of its parts” is made possible by the increased functional modularity and specialization. For example, we can achieve better composability on the generic settlement layer and express and capture more MEV on the generic sequencing layer.

Part #2

We discussed the general design of SUAVE in the middle of this article, which is still in the early stages of R&D and its detailed implementation is not yet available in the public domain. I would like to share two potential challenges for SUAVE here.

Sequencing

The current centralization of the sequencer is still unresolved. For example, Optimism’s and Arbitrum’s sequencer is managed by teams and is completely centralized. Decentralized sequencing is a topic that cannot be avoided. Several Rollups have mentioned this plan in their roadmaps. Optimism, for example, proposes rotating sequencer from both economic and governance mechanisms, while Arbitrum proposes their Fair Ordering scheme.

In his article An Incomplete Guide to Rollups, Vitalik mentioned several approaches, including sequencer auctions, random selection from PoS set, and DPoS voting. Chainlink’s Fair Sequencing Service (FSS), and Espresso Systems’ Decentralized Sequencer middleware are among the other options.

SUAVE’s goal of becoming a universal sequencing layer for all blockchains is clearly more ambitious. Of course, convincing Rollups to adopt its solution will be a challenge.

Ecosystem

Quintus writes in the article that Uniswap, Metamask, and Infura, as representatives of dApp, wallet, and RPC service providers, control the majority of total (and often valuable) Ethereum orderflow. Infura’s share of total orderflow is estimated to be more than 70%. These entities serve as transaction chokepoints, capturing the flow of orders and playing an important, but often overlooked, role in the MEV supply chain.

SUAVE’s core is open orderflow, which necessitates the participation of multiple parties; thus, the role of these entities is highlighted in the design of SUAVE and SUAVE can assist in monetizing and generating profits for these orderflow owners.

Every component of the MEV supply chain is economically rational. Searchers and builders are motivated by profit, and if SUAVE provides a high-quality orderflow, they have a strong enough incentive to proactively integrate with SUAVE and this can gradually build up a network effect.

At the interface level, wallets can send transactions to SUAVE by simply changing the RPC endpoint, but additional changes will inevitably need to be made if the wallet needs to adapt for the execution market and preference environment. As a result, in order for SUAVE to realize its vision, it must also build relationships of cooperation with the ecosystem’s primary flows.

Part #3

We also bring up some open discussions in addition to the ones mentioned above.

Originally, users were restricted in expressing their transaction intent, and the state of the transaction when it was uploaded to the chain was largely dependent on the network state, making customization almost impossible. Users can set the conditions for a transaction to be on the chain, such as “I want to put this transaction in a certain position in a certain block in a certain domain,” according to the concept of “preference” proposed by SUAVE. The freedom and richness with which users can express their intentions is increased.

On the other hand, increasing the granularity of expressed preferences can significantly increase network complexity and enable DoS attacks. This, in turn, necessitates a rational fee structure design.

Furthermore, narratives such as Rollup-as-a-Service, DA-as-a-Service, and Restaking-as-a-Service have already emerged. Various zkEVM projects will be coming online on the mainnet in the coming months, and building decentralized sequencing layers was planned in the various Rollup roadmaps.

As a result, Sequencing-as-a-Service is a viable option that we can investigate. Will these Rollups simply use the FCFS solution, outsource sequencing to a professional service provider, or use a combination of both? This will determine sequencing projects’ market share and competitive landscape.

Closing

MEV has been controversial in recent years, but that hasn’t stopped it from growing by leaps and bounds.

The existing MEV solutions cover many aspects, with the main topics centered on minimizing/preventing MEV and democratizing MEV/MEV profit redistribution, the former utilizing some encryption schemes and the latter leveraging profit rebates to upstream players and users.

From PBS to SUAVE, the trend is to keep introducing competitive diversity and ensuring balanced competitive conditions. The community has always made steady progress toward the goal of decentralization, and we continue to respect the community’s efforts to shine a light on the dark forest.

We envision a new decade of MEV: competition rather than monopoly; sharing rather than exclusivity; co-rule rather than dictatorship.