This issue is quite long, for your convenience, you can preview the catalog:
Review: What is Maximum Extractable Value MEV
Part 1: MEV in Ethereum POS
Centralization of validators
Licensed memory pool
text
Proposer -Builder Separation
text
Builder API
How does the Builder API mitigate the impact of MEV?
Part 3: Is MEV unique to Ethereum?
Part 4: MEV Follows Complexity
text
Part 5: Why MEV is hard to repair
At the beginning of the text, first of all, lets review what is MEV with an example?
For example, there is a $10,000 arbitrage opportunity on Uniswap after a large number of trades caused the price to slide. The arbitrage bot notices the opportunity and submits a transaction to capture it, offering the miner a $10 transaction fee. One of two things may happen:
Miners will copy and censor arbitrageurs transactions in order to seize opportunities themselves
10,Other bots will notice and bid higher txfee, starting a bidding war for arbitrage rights. The auction is called the Priority Gas Auction (PGA)
The potential profit of $000 is MEV. If the miner does not capture it, and a PGA starts, the difference between the auctioned price and the total MEV available is the winning traders profit (e.g., if the miner is paid $7,000 in fees, the remaining 3,000 000 for the trader).In the MEV series offirst article
Here we introduced the form of MEV and its impact in detail, and then we continue to discuss the impact of MEV on Ethereum.
Part.1 MEV in Ethereum PoS
Larger staking pools may have more resources to invest in necessary optimizations to capture MEV opportunities. The more MEV these pools extract, the more resources they have to increase their MEV extraction capacity (and increase overall revenue), essentially creating economies of scale. Independent stakers may not be able to profit from the MEV opportunity due to fewer resources at their disposal. This could put pressure on independent validators to join strong staking pools to increase revenue, reducing Ethereum’s fragmentation.
Licensed memory pool
In response to sandwich attacks and front-running attacks, traders may start conducting off-chain transactions with validators to preserve transaction privacy. Instead of sending potential MEV transactions to a public mempool, traders send them directly to validators, who include them in a block and share the profits with traders.
“Dark pools” are a scaled-up version of this arrangement, functioning as permissioned, access-only memory pools open to users willing to pay a fee. This trend will make Ethereum less permissionless and trustless, and potentially turn the blockchain into a “pay-to-play” mechanism that favors the highest bidder. Permissioned mempools also accelerate the centralization risks described in the previous section. Large pools running multiple validators may benefit from providing transaction privacy to traders and users, thereby increasing their MEV revenue.
Addressing these MEV-related issues in a merged Ethereum is a core area of research. So far, in order to reduce the negative impact of MEV on the decentralization and security of Ethereum after the merger, two solutions have been proposed, namely Proposer-Builder Separation (PBS) and Builder API.
Proposer-Builder Separation
secondary title
Proposer-Builder Separation (PBS) aims to mitigate the impact of MEV, especially at the consensus layer. The main feature of PBS is the separation of block producer and block proposer (Proposer) rules. Validators are still responsible for block proposals and voting; but block builders — block builders — are responsible for ordering transactions and building blocks.
Under PBS, a block builder creates a transaction bundle and bids for it to be included in a beacon chain block (as an execution payload). The validator who proposes the next block is selected and then checks the different bids and chooses the transaction package with the highest fee. PBS essentially creates an auction market where builders negotiate with validators to sell block space.
The current PBS design uses a commit-reveal scheme, where builders only publish a cryptographic commitment to the block content (block header) and their bid. After accepting the winning bid, the Proposer creates a signed block proposal including the block header. A block builder should publish the full block body after seeing a signed block proposal, and must also receive sufficient attestations from validators before it can be finalized.
How does PBS mitigate the impact of MEV?
In-protocol PBS reduces the impact of MEV on consensus by removing MEV extraction from the authority of validators. Instead, block builders running on dedicated hardware will seize future MEV opportunities.
However, this does not completely exclude MEV-related income for validators, since builders have to pay a premium to get validators to accept their blocks. However, as validators no longer focus directly on optimizing MEV revenue, the threat of time-bandit attacks is reduced.
PBS also reduces the risk of MEV centralization. For example, using a commit-reveal scheme removes the need for builders to trust validators not to steal MEV opportunities or expose them to other builders. This lowers the barrier for independent stakers to benefit from MEV, otherwise builders will tend to favor large pools with off-chain reputations and trade with them off-chain.
Builder API
Likewise, validators dont have to trust builders not to withhold block bodies or issue invalid blocks because payments are unconditional. Validator fees are still processed even if the proposed block is unavailable or invalidated by other validators. In the latter case, the block is simply discarded, forcing the block builder to lose all transaction fees and MEV revenue.
While mentioning PBS promises to reduce the impact of MEV withdrawals, implementing it requires changes to the consensus protocol. Specifically, the fork choice rules on the Beacon Chain need to be updated. The Builder API is an interim solution intended to provide an efficient implementation of PBS, albeit with higher trust assumptions.
The Builder API is a modified version of the Engine API that is used by consensus layer clients to request execution loads from execution layer clients. As outlined in the Honest Validators specification, validators selected for block proposal duties request a transaction package from connected execution clients, which they include in the proposed beacon chain block.
The Builder API also acts as a middleware between validators and execution layer clients; but it is different in that it allows validators on the beacon chain to obtain blocks from external entities (instead of using execution clients to build blocks locally) .
The Builder API works as follows:
The Builder API connects validators to a network of block builders running execution layer clients. Just like in PBS, builders are dedicated groups that devote themselves to resource-intensive block building and use different strategies to maximize revenue from MEV + priority tips.
Validators (running consensus layer clients) request execution payloads along with bids from the builder network. The bid from the builder will contain the execution payload block header — a cryptographic commitment to the contents of the payload — and a fee to be paid to the validator.
Validators review incoming bids and choose the most expensive execution load. Using the Builder API, validators create a blinded beacon block proposal containing only their signature and execution payload block header, and send it to the builder.
A builder running the Builder API is expected to respond with a full execution load after seeing a blinded block proposal. This allows validators to create a signed beacon block, which they propagate throughout the network.
Validators using the Builder API will still need to build blocks locally in case the block builder fails to respond in time so they dont miss out on block proposal rewards. However, a validator cannot create another block using the now public transaction or another set of transactions, as this amounts to ambiguity (signing two blocks in the same slot), which is a serious error.
MEV-Boost is an example implementation of BuilderAPI (we will introduce MEV-Boost separately in the next issue), which is an improvement to the Flashbots auction mechanism, which aims to suppress the negative externalities of MEV on Ethereum. Flashbots auctions allow miners to outsource the work of building profitable blocks to specialized groups called Searchers in Proof-of-Work.
Searchers look for profitable MEV opportunities and send miners transaction packages along with sealed price bids included in blocks. Miners running mev-geth, a forked version of the go-ethereum (Geth) client, simply select the most profitable transaction package and mine it as part of a new block. To protect miners from spam and invalid transactions, transaction packets are validated through Relayers before reaching miners.
Relayers are still responsible for validating transaction bundles before passing them on to proposers. However, MEV Boost introduces escrow responsible for providing data availability by storing block bodies sent by builders and block headers sent by validators. Here, a validator connected to a relayer requests available execution payloads and uses MEV Boosts ranking algorithm to select the payload header with the highest bid + MEV fee.
secondary title
How does the Builder API mitigate the impact of MEV?
The core strength of the Builder API is its potential to democratize access to MEV opportunities. Using a commit-reveal scheme removes trust assumptions and lowers the barrier to entry for validators seeking to benefit from MEV. This should reduce the pressure on independent stakers to integrate with large staking pools to improve MEV profits.
Widespread implementation of the Builder API will encourage greater competition among block builders, increasing censorship resistance. When validators review bids from multiple builders, a builder intending to review one or more user transactions must outbid all other non-review builders to succeed. This greatly increases the cost of censoring users and discourages the practice.
Some projects, like MEV Boost, use the Builder API as part of the overall structure, designed to provide transaction privacy to certain parties, such as traders attempting front-running/sandwich attacks. This is achieved by providing a private communication channel between users and block builders. Unlike the licensed memory pools described earlier, this approach is beneficial for the following reasons:
The Builder API software is open source, and anyone can provide block builder services. This means that users are not forced to use any particular block builder, and increases the neutrality and permissionless nature of Ethereum. Additionally, traders seeking MEV will not inadvertently contribute to centralization by using private transaction channels.
text
Part.3 Is MEV unique to Ethereum?
We cannot help but ask: Is MEV unique to Ethereum?
No, assuming MEV is also visible on Bitcoin. The incentive to censor lightning channels or double-spend tokens is technically MEV. However, our hypothesis is that Bitcoin is inherently less susceptible to MEV than blockchains such as Ethereum.
The reason for this is the complexity and statefulness of the respective blockchains:
The rate at which MEV accumulates on a given blockchain is generally proportional to the complexity of its application layer behavior.
Arbitrarily flexible protocols, such as Ethereum, cannot limit this complexity, and are inherently prone to greater complexity over time.
This is why we say Ethereums complexity can be a curse.
text
Part.4 MEV Follows Complexity
In contrast, we can observe an exponential growth in the MEV surface on Ethereum, mainly due to the large flow of value through DeFi applications. These seemingly promising financial foundations can also be seen as Ethereum’s parasites: weaving a boundless network of MEVs that grows bigger and more complex every day.
first level title
Part.5 MEV is difficult to repair
Finally, it is natural to ask whether Ethereum can build a mechanism to offset MEV entry into the protocol. In short, no, at least not changing the developer and/or user experience on Ethereum.
Any attempt to prevent miners/validators from receiving a revenue stream could spur the creation of off-protocol markets. For example, if all transactions were only allowed to pay one uniform rate, we would expect miners/validators to collude with transactors to accept payments to gain transaction priority. Likewise, if all transaction fees are burned or paid to a public pot, miners/validators only need to collect fees individually.
For more blockchain knowledge and dry goods, follow Tokenview.io.
reference article
https://research.paradigm.xyz/MEV
https://ethereum.org/en/developers/docs/mev/#mev-in-ethereum-proof-of-stake
