header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Scan to Download the APP

MEV order flow: The king of block builders

Read this article in 46 Minutes
Block Builder, a new entity in the post-merger world, is about to enter a brutal royal battle game.
Original title: MEV Order Flow: The King of Block Builders
Original author: Noxx
The Block unicorn


After the merger, Block Builder's Royal Battle. With just over 2 weeks to go until the merger, it will change the Ethereum MEV landscape forever.


Block Builder, a new entity in the post-merger world, is about to enter a brutal royal battle game.


And their weapon of choice: order flow.


In this article, we'll discuss how builders use their order flow as a weapon, the risks it poses to the Ethereum chain, and peek into the potential future that lies ahead of us.


Game state: Pre-merge


Before we see how things play out post-merger, we'd better get a sense of where things stand.


The image below shows a Uniswap transaction for a user, it highlights the roles involved in the transaction from the user to the miner and shows some of the paths the transaction takes to enter the chain.



1.  A user has some "intent", in this case, to trade some tokens on Uniswap.


2.  The user navigates to the application he wants to use and uses his wallet provider to connect, in this case, we'll assume he uses Metamask.


3.  The user specifies the transaction he wants to make 10 ETH to buy 20,000 DAI. The application builds some call data for him to sign (0x5AE4... 000) to create a transaction representing his transaction, and this signed data will be sent to the RPC endpoint in the next section.


4.  We assume that the user has not changed any of the default Settings on Metamask, specifically the RPC endpoints of the Ethereum network.


If this is the case, the RPC endpoint will be set to https://mainnet.infura.io/v3/. This means that the transaction will be sent to Infura.


The Block Unicorn comment:

Infura: In plain English, Infura is a platform that allows your DApp to quickly access Ethereum without having to run Ethereum nodes locally.

RPC: Remote procedure call, which is a protocol to request services from a remote computer program over a network without any knowledge of the underlying network technology. (Colloquial interpretation, for example, you go out to work today and forget to do the laundry, you then call your family to do the laundry for you, this is a remote procedure call)


5.  Infura then propagates the transaction to other nodes in the Ethereum network. When transactions are logged in at each node, they are placed in the common mempool, which is a staging area for transactions before they are committed to the chain. The transaction will be placed here until it is sorted into a block.


6.  Miners create blocks by selecting and sorting transactions in their memory pool. Typically, they give preference to high Gas (transaction fee) deals.


7.  This user may not know that another group of actors called searchers is monitoring the memory pool. They are looking for valuable deals. When they see a user's ETHDAI trade, their bot will put it in the middle, giving him the worst strike price while they make the biggest profit themselves.


8.  They do this by submitting transaction packets to Flashbots Repeaters, where they are guaranteed to be on top of the block and all or none of the transactions in the packet are executed.


9.  These block packages are merged into a big pile by Flashbots and sent to whitelisted miners to be included at the top of the block (thus allowing miners to quickly package their transactions).


10.  If we recall the beginning of our journey, a user can change his RPC endpoint in the Metamask setting. He can switch to a private RPC endpoint, one that bypasses the Mempool. An example of a private RPC endpoint is Flashbots protection, which guarantees no false start bots or sandwich attacks, enabling you to avoid monsters in the dark forest.


11.  The private RPC is set up to route to the specified miner, where the transaction can be agreed upon. These miners will usually have a custom client (i.e. MEV-GETH), which enables them to have a private memory pool and will not broadcast transactions sent there. Miners extract as much "moral" value as they can (that is, by running it in reverse) and rank them in blocks.


The idea is to show you the order flow that already exists. I highlighted "user common order flow," which comes from common memory. User private order flow ", which comes from a private RPC endpoint, and "Searcher order flow", which comes from Searcher auction/repeater.


The common user order flow is available to everyone.


On the other hand, the order flows of searchers and private users are "exclusive" to the entities that set up these private Repeaters /RPC terminals.


It is this exclusive order flow that has the power to change games.


The merged world


Okay, so that's what happened in the pre-merger world, but what happens in the post-merger world? In order for us to understand that two important changes occur when merging, we need to go back.


PBS, proposer builder separation and the concept of the dead zone, let's start with PBS.


Proposed Generator separation (PBS)


PBS is the ability to separate block builders from block proposals, let's take a look at one by one.


Block Builder


Block building involves sorting/sorting transactions within a block. It's a game where hardware, algorithms, and information determine your success.


It's a competitive game, which means you need to upgrade your hardware, improve your algorithms, and get the best order flow (information) in order to stay in the game.


These requirements mean that block construction has a high barrier to entry.


Block proposed


The block proposal requires that you have some pledge 32 ETH and run some client software. Currently the software has very low hardware requirements and each participant can maintain their own validators.


The only way you can compete is to put in more ETH, and when you add validator nodes, the computing requirements don't increase much.


While the initial pledge of 32 ETH may be prohibitive for many, the computational requirements have been kept low enough for individual stakeholders to compete in the block proposal.


MEV block


Let's first consider what happens if the validator builds and proposes blocks of code at the same time.


A single verifier does not have access to the hardware, algorithms, and information needed to build an MEV block, so it builds an ordinary block. This common block uses the default sorting logic of the execution client to sort transactions by Gas price.


MEV verifiers will be larger existing entities with access to hardware, algorithms, and information that will be able to produce these more valuable MEV-based blocks.


MEV yields


It is estimated that MEV can earn as much as 60% of a prover's revenue in a year. This means that if our individual verifiers earn 4% per year with their vanilla block, MEV verifiers will earn 10% with their MEV block.


The graph below shows what this yield differential does to individual verifiers over time.



Let's get a sense of what's happening here:


1. This equation represents the compound interest of individual verification nodes.


A.1.04 represents an annual return of 4%.

B. x indicates the number of years that the node has been running.

c. 注意在现实中,质押不会自动复合你的奖励,你需要拿出你赚到的钱,并创建一个新的验证节点/购买更多的流动质押 Token 。


2. This equation represents the compound interest of the MEV validator.


1.10 represents a 10% annual return.


3. The figure shows the revenue of the two verification nodes in 30 years.We can clearly see that as the yield differential intensifies, MEV validators begin to significantly outperform individual validators. Over time, the situation will get worse at an even faster rate.


4. At the 30-year stage,Individual verifiers have earned 2.25 times their original investment, while MEV verifiers have earned 16.5 times.


a.  MEV verifiers have been able to capture these profits and launch new verifiers faster than individual verifier nodes, reducing their market share.


b.  It is clear that if the entire verifier group is split 50/50, with one half being individual verifier nodes and the other half being MEV verifier nodes, then MEV verifier nodes will quickly gain dominance in the verifier node group.


This graph shows us how much centralizing power MEVs can have if block building and block building proposals are put together.


Now you might be thinking that if you separate the roles, you're just shifting this centralizing power to the builder rather than the verifier, and you'd be right.


Implicit in the design of PBS is that MEV is a concentrated force, but we would rather concentrate at the builder level than the verifier level.


With PBS, a new entity has officially entered the Ethereum ecosystem, one focused on building blocks.


Block Builder


Block builders already exist, and mine pools have private Repeaters dedicated to search teams. Flashbots with Flashbots Auction receive search bundled block packages. Both entities have a set of transaction/block packages and sort them in a way that gets the most value.


The mining pools are built for blocks, and Flashbots are built for their giant mining pool bundling blocks.


Pre-merge: Trust-based systems


Prior to the merger, these "builders" would only delegate their "construction" to themselves or to miners with whom they had agreements, a system based on trust.


If we look at "builders" like Flashbots, they have to send their huge sums of money to the miners and trust that they won't steal the MEVs.


Miners have the ultimate power because the combined verifier will have the ultimate power.


If a searcher sends a $10 million clearing deal, the miner could, in theory, steal the opportunity by calling the clearing from his address at the top of the block.


To prevent this, they formed partnerships with large mining pools, where the incentive meant stealing individual transactions was not worth damaging the relationship with Flashbots and losing access to the MEV bundle.


For individual miners, these incentives do not exist, as stealing MEVs and damaging relationships may generate the highest expectations given how infrequently they win blocks.


The result is a licensing system where only some miners can get Flashbots MEV order flow and profits.



After the merge: No trusted system


In Ethereum, the post-merger builder/verifier relationship (similar to the pre-merger builder/miner relationship) is closer to an untrusted model.


This is done through a new Ethereum feature called "Blind Block".


A blind block is a block that only includes the block header that exists in the Ethereum block and does not send any transactions along with the data block.


After the validator signs the blind block and sends it to the builder, the transaction is sent. Since the builder sends this signed block to the network, this means that the verifier cannot steal the MEV contained in the block before it starts propagating to other nodes.


At this point, if the verifier proposes a new block and it "steals" an MEV opportunity, it will "propose two different blocks at the same height" and he will be penalized for the 32 Ethereum pledged.


Furthermore, there is no guarantee that a block claiming a MEV opportunity will ultimately become a classic block. There is a 50/50 chance that it is original, and the verifier gets a slash (after being punished) and is unable to get another MEV.


This is a deterrent to the proband, as the high penalty costs may be higher than the potential gains from stealing MEVs. (People are investigating situations where the highest expected value is an attempt to steal a MEV, but this is not common)


Ethereum specification - Blind blocks can only access transaction roots


Note that when we say that this relationship is closer to a no-trust pattern, this is applied in the builder to verifier direction.


Since the block is masked, the verifier cannot determine whether it is a valid block, and it must trust a block that the builder has already sent.


The builder is clearly incentivized to send valid blocks, and if it doesn't, it loses the value it might have gained and may be blacklisted in the future.


Fortunately, the verifier's loss is limited to missing their block proposal, because invalid blocks are not a punishable action.


In the merged world, any verifier will be able to connect with any builder and access these MEV transactions through blind blocks.


This puts individual verifiers on an equal playing field with larger entities, as both can now earn more rewards through MEVs.


MEV supply chain


Next, let's look at the combined MEV supply chain, specifically the builder. We'll use "Flashbots builders "as an example to show some of the different areas where they can compete.


Exclusive trade order flow


Searcher Order Process - Flashbots relay

User Private order process - Protected by Flashbots (MEV Robot Auction)


Internal MEV


  Identify MEVs that are not in your Searcher order flow

  Capture ethical MEV from "user private order flow"


delay


The MEV auction will introduce some additional network jump delays.

Vertical integration/co-positioning can limit the timing of these jumps.

This can give builders more time to see trades/figure out the best blocks before the submission deadline.


Block construction algorithm


  More efficient packaging of a block to include the most value.

Of all these, "exclusive order flow" is almost certainly the most important factor.

Let's revisit the Uniswap transaction described earlier, but now in builder/verifier mode.



The white boxes show where most of the changes have taken place. I omit the repeater, which acts as an aggregator for the block builder, delivering the most profitable blocks to the validator.


1.  In this case, the private RPC endpoint represents the Flashbots protection that previously sent the order flow to whitelisted miners. Now, they will become exclusive order flow for the Flashbots builder, and exclusive means that other competitors cannot access them.


2.  The searcher order flow here is the bundled block packets received by Flashbots Relay. Again, this will be an exclusive order flow that only Flashbots builders can access.


3.  For the public order flow found in MemPool, the Flashbots generator can also access these transactions, but so can other generators, meaning it does not provide a competitive advantage.


4.  A verifier running MEV-Boost (MEV auction) will be able to connect to this builder network. They will receive the blind block from the builder and will propose the block that offers them the most value.


This example is specific to Flashbots, but we can expect every builder to have the same theme. They will have their own searchers and private trading terminals, and they will try to encourage people to use these services, which are their unique order flow and key competitive advantage.


Here's an excellent chart from Flashbots that shows the white dashed box above in more detail.



Now let's zoom in on "private RPC endpoints" and the benefits they provide to users.


Benefits of private RPC endpoints


Private RPC endpoints can provide users with a number of benefits, some of which we have already mentioned, so let's take a look at them:


Pre-transaction privacy


Pre-emptive trade/Sandwich attack protection


Trading simulation


Restore protection - Never include if failed/recovered


Comprehensive Protection (in the future)


如果你发送 Token 到一个已知的蜜罐地址,会发出警告。

If the payment for gas is very high, please check with the user carefully as this is their intention.


So, with all these great features, why aren't all users using them? It's all about knowledge and friction in the setup.


If we look at the knowledge, a lot of users don't know this thing exists and don't know that there are solutions to some of their problems. They don't know that they are being sandwiched by the person in front of them. They don't know that they can prevent that expensive recovery during the NFT coinage process.


To see the friction, let's take Metamask as an example, and see how we can set this on Metamask.


Users must enter the Metamask wallet to set a new RPC URL for the network Ethereum Main Network (Networks) and change the URL.


This may sound easy to you, but for a new user, it may feel uncomfortable or want to play around with the defaults.


Arguably, this is not something the user should be dealing with and requires too much knowledge to make an informed decision.


So how do we solve this problem? One way is for wallet providers such as Metamask to change their global default Settings to private relays.


Metamask  The sleeping kingmaker


Let's think about how powerful is this ability to change the global default endpoint for a wallet provider like Metamask?


Think about how much public memory comes from Metamask's wallet. Some studies suggest that up to 70% of transactions on Ethereum are conducted through Metamask.


How much builders are willing to pay to monopolize that order flow, or how easily they could dominate if Metamask decided to create their own construction entity.


In other words, Metamask appears to be a "sleeping kingmaker" that could crown itself if it wanted to, and it's a tough road for Metamask.



They get this tremendous value through their order flow, but they want to make sure that they don't compromise the user experience and that the community is on board with any changes being made.


If Metamsk uses the default private RPC and the builder at the other end does not consistently win builds, then users may wait for many blocks to confirm their transaction.


Since their transactions are not in Mempool, they cannot be chained until the Metamask builder wins a build.


To limit this waiting time, Metamask can easily embed some default logic. As an example, transactions that are not contained within three blocks are sent to a public memory library.


Monetization of order flow


钱包提供商正在考虑将他们的订单流货币化,货币化他们的订单流使他们能够捕获 MEV 价值并将其回馈给他们的用户。他们可以通过 Gas 折扣、代表所获价值份额的 Token 释放等方式做到这一点。


If mainstream wallets decide not to monetize order flow, we could see a big shift from those that ignore order flow to those that acknowledge and exploit it.


To me, payment solutions for order flow exist at the app and wallet level, and the best apps and wallets will be those that return the most value to their users. -- Stephane Gosselin - Flashbots - Unchained Podcast


Does it force the hand of the dominant wallet provider into the order flow game? Is there too much value to ignore?


Let's look at how this order flow can be sold.


Sole Agency Agreement


The easiest way for wallet providers (Metamask) to sell order flow is through some agreement that provides exclusive order flow to one or more builders.


The agreement will have terms of service:


- No malicious MEV, including false start trade, sandwich attack.

- After 3 blocks, transactions will be vented into Mempool.

- 6 month contract.


I think this approach will be very concentrated in the builder's market. If only one builder has access to the MetamAsk order flow, it may be game over for everyone else.


Order flow auction


Another possibility is the concept of individual trading auctions.


Wallets can provide an auction service for all builders, where they expose an unsigned transaction stream to bid on.


The auction will be time-limited to ensure inclusion, and only builders registered at the verifier of the next proposed block can bid.


If no transaction bids are received, these transactions are sent to the common memory pool, and transactions that are known to have no "MEV value, such as simple ETH transfers, can also be set to the default memory pool.


When a builder wins the bid, they pay the fee and receive the signed deal. Similar to an "exclusivity agreement", there will be auction terms of service that Tx will be sent to the memory pool after 3 blocks etc. Builders will need to write algorithms/models to automatically price different trades and determine bids.


Wallet providers can take a small portion of these auctions and return the rest to the user for a specific transaction. The higher the user's transaction value, the higher the builder's bid, and the higher their return. This auction method fixes the issue of assigning MEVs to different addresses when a batch of transactions is sold.


Psychological tactics


Another thing we can see from order flow auctions is that builders make predictions based on available unsigned trades, much like bots looking at a trading platform order book.


Can entities fake transactions in an auction to gain some advantage? It will be up to the wallet provider/auctioneer to prevent this from happening.


The power of centralization


Let's take a look at what happens when one builder monopolizes most transactions on Ethereum.


For example, 20 builders can access 300 transactions in a mempool. A single builder, in addition to the 300 Mempool Txs (memory pool transactions), has exclusive access to Metamask's 700 transactions, giving them 1000 transactions to build from.


The builders of these 1000 blocks can build most blocks, they have more search space to build blocks, and they can monopolize some of the value.


Slowly, block builders who only have mempool permissions will go out of business. They did not win enough blocks and any exclusive order-flow agreements they may have entered into were not renewed or terminated.


How often builders win blocks has a direct impact on their user experience, and ultimately, they can't compete and operate profitably.


"Exclusive order flow is a very big risk and a very big danger in the MEV space over the next few years." -- hasu-flashbots -- Wintermute MEV Hackathon


A world in which block builders compete on exclusive order flows is one in which there is a strong gravitational pull on the winner-take-all effect that emerges among block builders.


MEV dystopia


Below, from Stephane's MEV Utopian and dystopian talk, highlights the decentralized MEV supply chain. The red square I added indicates that vertical integration can be done through exclusive order flow.



Let's run a simulation and let Metamask create their own builder and see what happens. Metamask owns 70% of the public order flow, and they have made this exclusive order flow their own, allowing them to quickly dominate the block building space.


Since they dominate the block build, searchers have no choice but to send their packages to the Metamask builder. If they don't, they can only access the MEV on the block won by the current builder, due to the low percentage of Metamask domains.


Metamask began building a team of internal searchers who learned from the searcher order flow they were exposed to.


Internal searcher teams can extract value from 70% of Ethereum transactions without competition, while external searchers can only compete for value from the remaining 30% in Mempool (memory pool).


By dominating the builder's domain, Metamask can also keep more MEV for itself, rather than passing it on to verifiers.


In a competitive market, profits are slashed and most of the value ends up in the hands of the verifier.


In a monopoly, Metamask only needs to ensure that their block builds pay slightly more than the next best builder. Metamask soon came to dominate the wallet, search and construction markets.


It will be interesting to see how the community reacts, and it is likely that Metamask will have to self-regulate like the mine pool and the verifier pool. Jon Charbonneau's figure below shows the feedback loop discussed above, which can quickly lead to centralization.


Application layer optimization, cross-chain and CEX


There are many factors that I haven't touched on that will affect this future development. Let's talk briefly about each of these factors and provide a high-level overview.


Application of optimization


Decentralized applications such as Uniswap and Sushiswap have a strong incentive to reduce the MEV exposure of their protocols. Ideally, they can capture value for themselves and their customers at the source of Tx.


A good example of this is the partnership between Sushiswap and Manifold Finance, which wants to be one of the main block builders after the merger. Sushiswap will replace Manifold's "transaction router" at the protocol level with Manifold's "MEV router ".


MEV routers "want to capture arbitrage opportunities as users trade and return value to the protocol. These application/builder relationships will be another area of builder competition.


Across the chain MEV


Cross-chain MEV is already here, but we can expect it to become more competitive in the future. Cross-chain MEVs are non-atomic, have higher execution risks, involve inventory management, and require deep knowledge of multiple chains.


So it has a much higher barrier to entry. Everything we've talked about is broadly mirrored on the other chains. Imagine the opportunity to get Solana (SOL) order flow, Avalanche (AVAX) order flow, etc.


Order flow on other chains will affect what can be done on Ethereum, increasing the search space for valuable transactions and always making it more conducive to finding the highest value combinations. It remains to be seen how much of an impact this "other chain" order flow will have on the builder's network, but in a hyper-competitive environment it will provide an advantage.


Centralized Trading Platform (CEX)


Like cross-chain MEVs, we have seen opportunities for on-chain/off-chain MEVs exploited. With a centralized trading platform, builders will have to minimize delays by hosting and negotiating transactions to get the lowest transaction fees.


If one builder negotiates a transaction fee of 0.02% and another builder deals with a transaction fee of 0.08%, how does this affect the on-chain/off-chain opportunities available to them? This will be another area where builders can compete and try to find their strengths.


The unknown future


Who knows what will happen in the future, this is an active area of research with a lot of changes. Stephane's following quote reflects the reality of the builder's market, as well as the community's mission to remain as decentralized/flat as possible.


"At the end of the day, the builder's market is likely to have some power-law distribution where the top builders gather most of the proposal power, but we want to keep that distribution as flat as possible." -- Stephane Gosselin -- Flashbots -- Bankless


Who knows, maybe there's light at the end of the tunnel.


The original link


Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit