A New Decade Of Ethereum MEV Growth: From PBS To SUAVE

February 8, 2023 - Around 15 mins mins to read

In order to obtain as much order flow as possible, builders can flexibly adopt a variety of methods: analogous to PFOF (Pay for Orderflow) that appears in traditional brokerages, builders can pay rebates to wallets, RPC service providers, and dApps to obtain their Order flow – it is very easy for the wallet to do this, only need to modify the default RPC port, and most users will not pay attention to whether their transactions are sent to the public Mempool or the private relay.

A New Decade Of Ethereum MEV Growth: From PBS To SUAVE

Builders can also provide users with additional services, such as providing sandwich protection, transaction pre-confirmation, subsidizing users’ Gas fees, etc., to attract users to submit transactions to them.

SUAVE: Standing in the new decade of MEV

Brief:

SUAVE is an EVM-compatible blockchain proposed by Flashbots. As a unified sorting layer for multiple chains, SUAVE aims to solve the centralization problem of builders.
The infrastructure is gradually evolving from a centralized general-purpose layer to a refined professional layer. The improvement of functional modularization and specialization makes it possible that “the whole is greater than the sum of its parts.”
The trend from PBS to SUAVE is to keep bringing in the diversity of the competition and making sure the playing conditions are balanced.
The new decade of MEV we describe competition, not a monopoly; sharing, not exclusive; co-governance, not dictatorship.

What do we already have?

It has been nearly half a year since the merger of Ethereum, and we already have a relatively definite MEV supply chain and corresponding workflow. This workflow is basically doing “integration”: the wallet integrates the user’s transactions, the searcher integrates arbitrage opportunities, and the builder integrates the order flow. Starting from a transaction issued by a single user until a validator proposes a block, the entire process has been highly specialized.

Going back to the DeFi wave at the end of 2020, with the rapid growth of financial activities on the chain, MEV is beginning to emerge. At that time, there was almost no direct communication channel between the miners and the MEV searchers, and the searchers could only simply pay a higher Gas fee in order to get the transaction included. This creates network congestion and gas fee fluctuations, creating negative externalities on the Ethereum network.

Based on the auction mechanism, Flashbots Auction creates a communication channel between miners and searchers. The former sells block space, and the latter capture arbitrage opportunities, which actually realizes the marketization of block space.

Another problem is that there is a huge disparity in the ability of large validator pools to capture MEV compared to individual validators, who already have a higher probability of being selected as proposers, which will gradually lead to the centralization of the Ethereum validator set. Therefore, PBS was proposed, that is, both large-scale verification pools and individual verifiers outsource blocks to professional block builders for construction so as to create a relatively level playing field.

As a PBS implementation prior to the protocol layer, MEV-Boost continues the auction mechanism of Flashbots Auction, which alleviates the centralization problem of verifiers at the MEV level.

And what is still needed?

We still need decentralization of block builders.

What is easy to overlook is that the current builder role is still highly centralized. 79.1% of MEV-Boost blocks were built by only 4 builders in the past 14 days. Centralization will bring some things we don’t want to see (especially in the case of block construction as the core infrastructure), such as censorship and extortion, regulatory pressure and system vulnerability, etc.

The main reasons for the centralization of builders are the following two points.

Exclusive Orderflow (EOF)

We know that there are three main sources of orders for builders: Mempool, private transaction channels, and bundles submitted by searchers; the ultimate goal of builders is to build the most valuable block. In block construction, order flow is the most basic means of production. The more order flows you get, the more opportunities you can express MEV. If the builder cannot grasp enough order flow, no matter how good the strategy is, it is difficult for a clever woman to cook without rice, and it is almost impossible to win in the fierce competition of block construction.

In this regard, the network effect of the dominant side of OF is very obvious. On the one hand, they have more opportunities to express MEV, which means that they are more likely to build a most valuable block; on the other hand, if the OF disadvantaged party fails to win the block, then submit the order to their Orderflow Owner The transaction has also been slow to be confirmed. After a while, these Owners will switch to Builders who can confirm transactions more quickly. The gap between the two parties will widen rapidly and the disadvantaged party will eventually have to withdraw from the competition.

In order to obtain as much order flow as possible, builders can flexibly adopt a variety of methods: analogous to PFOF (Pay for Orderflow) that appears in traditional brokerages, builders can pay rebates to wallets, RPC service providers, and dApps to obtain their Order flow – It is very easy for the wallet to do this, only need to modify the default RPC port, and most users will not pay attention to whether their transactions are sent to the public Mempool or the private relay.

The above figure shows the vicious circle that EOF may bring—the exclusive order flow allows builders to have more freedom and room for maneuvering in how to express MEV so as to build blocks with higher value; over time Over time, these builders will occupy more market share in block construction and verify the rationality of EOF, which in turn becomes an incentive for builders to further optimize and promote EOF.

According to Rated statistics, 529,633 addresses in the blocks built by builder0x69 within 14 days are not in the blocks of other builders; that is, the order flow from 32.7% of the addresses is exclusive to them. It can be seen that EOF has already occupied a large proportion among the top builders.

Cross-domain MEV

Cross-domain MEV is another problem leading to builder centralization.

The background of cross-domain MEV is directly related to the Ethereum Rollup-centric Roadmap proposed by Vitalik. In the next few years, most of the activities of Ethereum L1 will be carried by various Rollups, and the Ethereum main chain itself will only serve as the DA and security base layer. Under this vision, a large number of financial activities will frequently occur between Rollups and cross-Rollups, resulting in more complex arbitrage opportunities and combinations.

It is easy to imagine that builders of multiple domains have more opportunities to capture cross-domain MEV than builders of a single domain, and thus gradually dominate the block production of each domain.

SUAVE

In response to the above problems, Flashbots proposed SUAVE as a solution. At a high level, SUAVE is an EVM-compatible blockchain that serves as a common Mempool and block builder network for all blockchains, as well as a decentralized ordering layer.

What SUAVE wants to do is to solve the centralization problem of builders. More specifically, it needs to solve the above two problems of EOF and cross-domain MEV at the same time.

SUAVE can be disassembled into the following three components:

Preference Environment

A preference environment corresponds to a cross-domain MEV.

The definition of preference is relatively broad: For example, for users, limiting the parameters of a certain Swap is a preference; for MEV searchers, specifying the location of a transaction or the Bundle it builds is also a preference. Preferences can range from simple transactions on a single domain to complex sequences of events across domains. Users pay for their preferences, and if the preferences are met, the fee is unlocked.

Technically speaking, user preferences are finally reflected in the Mempool in the form of transactions, and the preference environment is a public multi-chain Mempool that aggregates as many preferences as possible on the same layer.

Why can the preference environment solve the cross-domain MEV problem? As mentioned above, multi-chain builders will have more advantages than single-chain builders in cross-domain MEVs because multi-chain builders can see and capture more MEV opportunities.

And SUAVE itself is a general sorting layer for multiple chains, and the preference environment is equivalent to placing the user preferences of multiple chains on the same layer, so whether for multi-chain or single-chain builders, user preferences are open and transparent. In this way, the advantage caused by the information gap no longer exists.

Execution Market

The execution market corresponds to EOF.

Now that user preferences have been reflected in SUAVE Mempool, SUAVE has further introduced the role of Executors in the execution market, and they compete with each other to provide the best execution for user preferences. According to different preferences put forward by users, builders, RPC service providers, wallets—anyone can be an executor.

First, the user’s transaction generates MEV; second, the executors compete with each other to satisfy the user’s preference. In the case of providing the best execution, the competition will be reflected in the price, and finally, return as much MEV as possible to the user. This process can be understood as bidding and merit-based admission. This is why in the figure above, the execution market realizes “Minimizes MEV for users.”

The preference environment makes the preferences of all users transparent. The execution market puts these preferences in an open market, allowing all executors to realize user preferences through bidding rather than being satisfied by individual builders, thus solving the problem of EOF.

Decentralized Building (decentralized block construction)

Finally, after integrating the output of the preferred environment and the execution market, a network of builders collaborates to build complete blocks instead of a single builder. This step needs to share this information among builders without revealing the content of Orderflow and Bundle. In the later stage of the SUAVE roadmap, security solutions such as SGX will be introduced to meet this requirement.

Thoughts

Part 1

If we put aside MEV for the time being and think about SUAVE from the perspective of blockchain, then we can sort out the development trend and narrative logic of a blockchain.

First of all, based on the blockchain, Bitcoin realizes value transfer without a trusted third party, and the blockchain provides the most fundamental trust as a financial infrastructure.

After that, the public chain represented by Ethereum is used as the execution environment of dApp, which can be further divided into the general execution environment represented by General Purpose Alt-L1/Rollup and the dedicated execution environment represented by Appchain/Approllup. We abstract the network, consensus and other components into a whole and ignore the technical details, which are essentially the soil for dApp growth.

Although the above-mentioned Rollup can be regarded as the execution layer, which carries a part of the workload of Ethereum L1, the execution environment is still mainly monolithic. Celestia disassembles the various components of the execution environment. The DA layer is also a blockchain, but it is no longer the “execution environment” itself, and the consensus between nodes is only for the Data Blob. At this time, the blockchain is introduced as a trust component to enhance the trust level of DA.

SUAVE further abstracts Mempool and Sequencing from multiple execution layers as a unified coordination layer. The design of SUAVE, such as transaction types and fee structure, can be customized and adapted to “express” MEV, and does not need to be exactly the same as the previous blockchain design. In the scenario of multi-chain and multi-party collaboration, the blockchain exists more in the form of a coordination layer.

We can see that the infrastructure is gradually evolving from a centralized general-purpose layer to a refined professional layer. The improvement of functional modularity and specialization makes it possible that “the whole is greater than the sum of its parts.” For example, we can achieve better composability on the general settlement layer; we can express and capture more MEVs on the general sorting layer.

Part 2

In the middle part of this article, we discussed the general design of SUAVE. At present, SUAVE is still in the early research stage, and there is no public information for its specific implementation. The author proposes two challenges that SUAVE may face here.

Sequencing

The centralization problem of the current Sequencer has not yet been resolved. The Sequencer of Optimism and Arbitrum is run by a team and is completely centralized. Sequencing to achieve decentralization is always an unavoidable topic, and each Rollup has mentioned this plan in its roadmap. For example, Optimism proposes to rotate Sequencer from both economic and governance mechanisms, and Arbitrum proposes its Fair Ordering scheme.

Earlier, Vitalik listed several methods in his article An Incomplete Guide to Rollups, including Sequencer auctions, PoS-based random selection, and DPoS voting. Other proposals include Cosmos’ First Come, First Served (FCFS), Chainlink’s Fair Sequencing Service (FSS), and Espresso Systems’ Decentralized Sequencer middleware.

SUAVE wants to become a unified ordering layer for all blockchains, and this vision is obviously more ambitious. Of course, convincing each Rollup to adopt its solution will be a huge challenge.

Ecosystem

Quintus wrote in the article that Uniswap, Metamask, and Infura, representing dApp, wallet, and RPC service providers, respectively, control the majority (and often value) of Ethereum’s total order flow. Infura is estimated to account for more than 70% of the total order flow. These traffic terminals, as the checkpoints for transaction issuance, control the flow of order flow and play an important but easily overlooked role in the MEV supply chain.

The core of SUAVE is Open Orderflow, which requires the participation of multiple parties. Therefore, the role of the above-mentioned entities has been highlighted in the design of SUAVE, aiming to help these Orderflow Owners monetize and generate profits.

Every entity in the MEV supply chain is Economically Rational. If dApps, wallets, and RPC service providers may have some concerns, but searchers and builders are driven by interests, if SUAVE provides high-quality order flow, Then they have a strong enough motivation to take the initiative to integrate with SUAVE and gradually establish a network effect.

At the interface level, wallets can simply change the RPC port to send transactions to SUAVE. However, if the wallet needs to adapt to the preferred environment and execution market, some additional changes will inevitably be made. Therefore, in order to realize its vision, SUAVE also needs to establish cooperation with the core traffic in the ecology.

Part 3

In addition to the above discussion, we also raise some open questions.

In the past, users had limitations in expressing their transaction intentions. The status of transactions on the chain mostly depended on the real-time network status, and transactions could not be customized. According to the concept of “preference” proposed by SUAVE, users can set the conditions for transactions on the chain, such as “I want to put this transaction in a certain position in a certain block of a certain domain”. The freedom and richness of user expression intentions have been improved.

On the other hand, increasing the granularity of expressing preferences will greatly increase the complexity of the network and make large-scale DoS attacks possible. This further requires a reasonable design of the fee structure.

Additionally, we have seen narratives such as Rollup-as-a-Service, DA-as-a-Service, and Restaking-as-a-Service. In the next period of time, various zkEVM projects will be launched on the main network one after another, and the decentralized sorting layer is also within the planning of each Rollup roadmap.

Therefore, Sequencing-as-a-Service is a potential direction that we can tap. Will these Rollups simply adopt the FCFS solution, or outsource Sequencing to a professional service provider, or even use the rotation of multiple solutions? This will determine the market share and competitive landscape of the Sequencing project.

Conclusion

In the past few years, MEV has been controversial, but it has not hindered its rapid expansion.

Existing MEV solutions cover various aspects, and the basic topics revolve around “minimizing/blocking MEV” and “democratizing MEV/MEV interest redistribution”; the former uses some encryption schemes, and the latter provides upstream players and users Return of profits.

As the inherent nature of the blockchain, MEV occupies a trade-off point in the current “impossible triangle” and may extend the “fourth corner” in the implementation of SUAVE. Based on the certainty of the MEV supply chain structure, SUAVE will create a scale market of over 10 billion in the next ten years.

From PBS to SUAVE, the trend we can see is to continuously introduce the diversity of competition and ensure that the competition conditions are balanced. The community is always moving towards the goal of decentralization, and we respect the continued efforts of the community to illuminate the dark forest.

The new decade of MEV we describe competition, not a monopoly; sharing, not exclusive; co-governance, not dictatorship.

DISCLAIMER: The Information on this website is provided as general market commentary and does not constitute investment advice. We encourage you to do your own research before investing.

Join us to keep track of news: https://linktr.ee/coincu

Harold

Coincu News

Knowledge

A New Decade Of Ethereum MEV Growth: From PBS To SUAVE

In order to obtain as much order flow as possible, builders can flexibly adopt a variety of methods: analogous to PFOF (Pay for Orderflow) that appears in traditional brokerages, builders can pay rebates to wallets, RPC service providers, and dApps to obtain their Order flow – it is very easy for the wallet to do this, only need to modify the default RPC port, and most users will not pay attention to whether their transactions are sent to the public Mempool or the private relay.