The MEV Review Dilemma: Will SUAVE Be a Good Solution?
Original compilation: aididiaojp.eth, Foresight News
Original compilation: aididiaojp.eth, Foresight News
Current status of MEV review
Not all validators explicitly and purposefully propose blocks built by MEV relays. Many validators propose normal blocks, or choose blocks from the mempool, without regard to ordering, purely based on priority fees and block limits.
For example, Coinbase, the largest centralized staking provider outside of Lido, only recently started incorporating MEV into their proposed minority blocks. On the other hand, more than half of Kraken's proposed blocks are explicitly ordered. Kraken apparently gets more staking rewards than Coinbase. The question then is why would Coinbase forego this extra benefit? Did Kraken take on additional risk?
Validators consider several variables when selecting MEV relays, of which there are two main considerations:
Are there transactions from OFAC-sanctioned addresses in the block?
Are MEV Relays Helping Front Runners?
Validators weigh these variables by a combination of compliance and profitability, respectively.
Take, for example, the BloXroute Max Profit, the only MEV repeater that strictly prioritizes profitability. As the chart below shows, this relay accounts for only 12.2% of all relayed transactions, suggesting that the sole goal of most validators is not to make a profit.
Below we show the distribution of relay blocks on Ethereum since the merge:
Since Ethereum transitioned to proof-of-stake, Flashbots have relayed over 75% of explicitly ordered Ethereum blocks. This is obviously not ideal from a decentralization standpoint, but fortunately this market share has gradually normalized. We have identified three similar measures of post-merger concentration.
We are considering a subjective tradeoff. For example, centralized exchanges are required by law to select relays that enforce OFAC's blacklist. Additionally, any entity, whether centralized or decentralized, that stakes ETH on behalf of others is financially obligated to propose blocks from relays containing front-running transactions. That is, the fiduciary duty requires proposing the most profitable blocks.
Only individual validators, users who can determine their own Ethereum staking rewards, will be able to choose relayers who neither adhere to the OFAC blacklist nor propose blocks containing mempool front-running transactions. This is not to say that front-running is unethical, we simply state that independent node operators are the only players who are strategically able to drop the above two considerations and pursue the BloXroute Ethical relay.
Both variables, compliance and profitability, have a considerable impact on Ethereum MEV. For example, if an OFAC-sanctioned address submits a transaction with a high-priority fee, validators who choose to include such a transaction are bound to benefit economically. Since validator proposals are randomized, we know that validators subscribing to the OFAC-agnostic relay will eventually be able to propose blocks containing non-compliant transactions, as long as it remains in the mempool.
Likewise, front-running, sandwich trading, arbitrage, and other forms of transaction sequencing provide a more efficient price discovery mechanism on the blockchain, allowing MEV-enabled operators to achieve higher yields.
However, when looking at the relay block averages, something interesting happens, for example the BloXroute Max Profit relay earns the same as its regulated relay. In theory, this shouldn't come up, as excluding blacklisted addresses would only negatively affect priority fee ranking.
Ordering strategy and block value
To understand why "average block value" does not necessarily represent the most profitable relay strategy, we must first clarify two things.
First, we must recognize the economies of scale inherent in MEV repeaters. If relayers propose a certain percentage of blocks, at some point they are able to calculate the probability of building subsequent blocks. If two blocks can be successfully constructed in a row, more relay opportunities can be provided for MEV.
Let's put it another way: if the Flashbots relay builds the most profitable block for a proposed validator and knows how likely they are to build the next block in the blockchain, this will affect the original block and subsequent The composition of the block. As Flashbots' builder dominance declines, so does their likelihood of winning consecutive blocks.
Second, we have to understand how repeaters are technically chosen. Depending on the smart node stack used to deploy the node, validators may be able to order their preferred relays, which cannot be banned. In this case, validators can always utilize the most profitable relay, and an Ethereum validator who happens to get a block proposal is able to force that block to be committed by the most profitable relay.
With this in mind, then from a statistical perspective, the observed "average block value" does not necessarily represent the most profitable relaying strategy, regardless of sample size. For example, why is the block value proposed by the "BloXroute Max Profit" relay usually smaller than the block value proposed by "BloXroute Regulated"? From Table 1 we know this is not possible.
A practical example can illustrate this clearly:
The entire staking pool has only whitelisted Flashbots and BloXroute supervised relays. By definition, a validator in the relevant pool will only choose a block from a BloXroute Regulated relay if the BloXroute Regulated relay is more profitable than the proposed Flashbots relay, i.e. the validator will not consider other relays We know that MEV ordered blocks are bound to be more profitable than normal fee blocks.
Due to the different ordering strategies, regardless of blacklists and front-running tasks, a BloXroute Regulated relay will usually easily get higher blocks than an unrestricted BloXroute relay if it is elected as a backup proposer for the main pool award.
Censorship
It was mentioned above that the Flashbots review relay alone accounted for over 80% of all relay transactions. But keep in mind that not all validators outsource their block building to the MEV relay, many will still propose normal blocks, or locally ordered blocks. As of December 14th, approximately 70% of proposed blocks were routed through the MEV relay, which performs OFAC review.
After withdrawals are enabled in the upcoming Shanghai upgrade, the reshuffled staked ETH could reduce this number significantly.
How many transactions are actually censored on Ethereum right now? Given that we know the number of proposed blocks routed through the OFAC compliant relay, the only additional information we need is the average block time, and we know that there is a new Ethereum block every 12 seconds.
We can do some basic math to calculate the probability of a non-compliant transaction being included in a block, and then project that into any number of blocks that are added to the chain.
C = Percentage of proposed blocks that meet OFAC requirements.
B = number of blocks in the future
Y = probability of including a censored block after a given number of blocks
Y = 1 – (C^B)
With a 30% chance, a censored transaction is completed in a block.
With a 51% probability, the transaction under censorship is completed in the next two blocks.
With a 97% probability, the censored transaction will be completed in the next 10 blocks.
As mentioned earlier, we know that the time for 10 blocks is 120 seconds.
Therefore, even if more than 90% of validators pass MEV to review relayer transactions, non-compliant transactions will be completed within an hour. This also assumes that users do not propose to include fees with higher than average priority; in most cases, a sufficiently high priority fee will ensure inclusion in the next block.
Would SUAVE be a good solution?
At Devcon, Flashbots gave the answer to these review questions with a new version of their repeater: SUAVE.
SUAVE is decentralized and open source, with an encrypted mempool built in, which means that transactions retain a degree of opacity. The MEV relay will be able to dynamically calculate the extractable value sorted from the mempool without knowing the exact content of the transaction, thus allowing a block to be successfully constructed given a fuzzy boundary when including any censored transaction.
The current token scheme is still unknown, but it is very likely that tokens will be issued, otherwise it will be difficult to operate in a decentralized protocol. It is also possible that they simply present the solution as a public good and forego any form of tokenization. Flashbots are not currently monetizing MEV-Boost, and have open-sourced all of their relay code, and most recently their block builder code.
Flashbots is trying to build and deploy this solution as quickly as possible, but no other details have been available since Devcon. Ethereum’s protocol level also presents some technical solutions that could significantly reduce the role of Flashbots in the Ethereum ecosystem.
Certain versions of SUAVE may be integrated into all or most repeaters. As it stands, most of the most popular repeaters referenced in Table 1 share the same codebase. Flashbots' first reaction to the censorship issue was to open source their code, allowing BloXroute and Eden to develop quickly.
While SUAVE is currently being developed, Flashbots is trying to improve this problem in other ways. Recently Flashbots released a new parameter called "min-bid". This feature allows validators to set a minimum threshold at which they will ignore blocks proposed by MEV and can directly build locally. As a validator, one can still catch the occasional ultra-highly profitable MEV proposal without enabling censorship just to be slightly more profitable.
The value of proposed blocks is known to vary widely. Some blocks are more profitable than normal blocks, and some can even reward you with dozens of Ethereum! By using this "minimum bid" threshold, validators can now choose a specific price at which they are willing to comply with OFAC.
crLists and PBS Limits
Censorship-resistant lists crLists can force block builders to include transactions in a given block, otherwise validators must reject it. Proposal Builder Separation (PBS) will force proposers or validators to use blocks built by builders instead of building their own blocks locally.
Combining and including both of these upgrades at the protocol level would severely inhibit the relayer's ability to obfuscate a particular transaction. Any future upgrade will likely merge both upgrades into the same branch, not just one. For example, PBS without crLists actually makes censorship worse.
Original link
