MEVpool, The Best Bandaid We Have For MEV

Miner Extractable Value. That phrase is essentially one of the biggest fundamental risk spaces that exist for blockchain based systems. The original conception of a blockchain included incentives for miners (or other consensus participants deciding transaction ordering) to earn revenue based on whatever initial block subsidy is entered into circulation each block in addition to fees paid by users to have their transactions confirmed.

These two things are no longer the only sources of revenues that incentivize the actions of miners. More complicated contracts and protocols now exist to facilitate the creation of, and exchange between, different assets hosted on a blockchain. These contracts, by design, allow open access to anyone. If you have a required asset, and can fulfill the exchange conditions specified, any user can unilaterally interact with the contract or protocol to exchange assets.

Given that miners ultimately decide what transactions are accepted into blocks, this gives miners preferential access to “jump the line” in interacting with such contracts and protocols. This presents a serious problem, depending on the degree of complexity involved in successfully extracting value from different contracts or protocols.

This creates a huge centralization pressure on mining the more complicated these contracts and protocols become. Miners have the ability to collect all of this value, but in order to do so they actually need to analyze the current state of these contracts. The more complex the contract, the more complex and costly the analysis, and the more centralization pressure it creates for miners.

This is horrible for censorship resistance.

Proposer Builder Separation

Ethereum is the poster child of MEV gone wrong. Due to the high complexity of contracts deployed on Ethereum, the amount of MEV created on that chain has been very large. Naturally they have come up with attempted solutions in response to the issue.

Proposer Builder Separation sought to mitigate the centralization risks of MEV by creating separation between the two roles involved in moving the blockchain forward. Builders (block template creators) handle the role of actually assembling transactions into blocks, and Proposers (miners/stakers) choose between the available block templates to select the most profitable one. The idea behind the proposal is that we can let the centralization affect template producers, but safeguard miners/stakers from it. As long as there is a competitive market for template production, things should still be secure.

In practice this isn’t what has happened. The reality is that only a few competitive Builders exist, and when the most profitable template producers decide to censor something, it is effectively censored by every miner/staker that chooses to use those profitable block templates. Given that it is economically irrational to not choose the most profitable template, this doesn’t truly solve the risk of censorship.

MEVpool

The MEVpool proposal by Matt Corallo and 7d5x9 is an attempt to modify the PBS proposal for Bitcoin in a way that actually does provide mitigation for the risk of censorship.

The main difference between PBS and MEVpool is the outsourcing of template construction isn’t total, in MEVpool miners still ultimately construct the end block template themselves. They simply outsource the process of selecting the subset of transactions that optimize MEV extraction, including those in block templates they construct themselves. This aims to allow miners to maximize their cut of MEV while still maintaining the freedom to include whatever transactions they want, as opposed to the binary choice of accepting censorship for maximal profit or forgoing profit to prevent censorship under PBS.

The proposal requires setting up marketplace relays to host orderbooks where MEV extractors can post their proposed transactions and the fees they will pay to miners for including them in a block. They would allow the extractor to define conditions under which they will pay for transaction conclusion, i.e. only if they are the first transaction to interact with a specific contract in the block. Marketplaces would also support sealed or unsealed orders, i.e. sealed requests are orders where the transaction proposed isn’t actually revealed to the miner until they mine the block.

How does that work? All miners need is the hash of a transaction to include in the merkle tree to start mining, they don’t need the full transaction until they find a valid block and go to broadcast it. But they do need to know that the transaction is valid. This is the role the marketplace relays have to fill.

There are two ways they can go about doing this. First, the simplest way is for them to be a purely trusted third party. Extractors of MEV would submit their transactions to relay operators, and miners would connect to these relays. Afterwards they would request the list of Sealed and Unsealed bids from the marketplace operator, including the hashes necessary to include Sealed bids, and have a custom piece of software construct the block template. Once they successfully find a valid blockheader, they would send the block minus the missing data to the relay.

The relay would then include the full Sealed transactions, broadcast the block themselves, and then send the miner the full Sealed transactions so they could broadcast the block as well. During this entire process the MEV extractor’s fee would be held in escrow by the marketplace relay, and released to the miner after they find a valid block.

This requires putting a lot of trust in the relay, both on the part of miners as well as the MEV extractors paying them.

The second option is the use of a Trusted Execution Environment (TEE) to handle the construction of block templates on the part of miners, as well as handling the encrypted Sealed bids. Miners would run the custom template software and a Bitcoin node inside the TEE. After miners have received the Sealed and Unsealed bids and constructed their block, the TEE would sign an attestation of the block and provide the marketplace relay with a session key.

The marketplace would encrypt the Sealed transactions and a transaction paying the miner its fee to the session key. After the miner finds a valid blockhash meeting the difficulty target, the TEE would decrypt the Sealed transactions and allow them to broadcast the full block and collect their fee from MEV extractors. In this scenario everyone involved has to trust the TEE to remain secure.

The End Result

The end result of this is very likely in my opinion to be similar to PBS on Ethereum. There are only a handful of large Builders constructing MEV optimized templates for miners, and they all have transactions directly submitted to them out of band from the mempool. MEVpool marketplace relays, both variations, are trusted to publicly broadcast fee information about orders submitted to them to allow normal users to make proper fee estimation. If large marketplaces were able to attract transaction submissions not sent elsewhere and withheld that fee data, this could affect users at large.

Also, while it does allow miners the freedom to select their own transactions outside of the MEV optimized subgroup, it still leaves room for large marketplaces receiving private transaction submissions to leverage that position. Such marketplaces could coerce miners into censoring other transactions by withholding their orderbook data from them if no competitor existed with access to the same information.

Ultimately I do not see this as a solution to the issue of MEV, more of a bandaid or mitigation of the worst possible effects of it. It does not completely remove the centralization risks and pressures, but it does ameliorate them in certain areas.

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

This post MEVpool, The Best Bandaid We Have For MEV first appeared on Bitcoin Magazine and is written by Shinobi.

Source