Can we fix it?

The following article is part four of a series of articles covering Miner Extractable Value on Ethereum. This article follows the previous post MEV Induced Crisis and discusses at a high level the solutions to the potential crisis at hand.

Can MEV be removed?

Being aware of the negative implications, it naturally raises the question: Can Ethereum construct a mechanism to counteract MEV?

Let’s examine.

Flat Fees

MEV is possible because of how priority on Ethereum is dictated by gas price. One would imagine setting all transactions to a flat rate would remove MEV. However such an act can create off-protocal markets (darkpools) where miners can collude with traders to accept payment for transaction priority. Likewise if tansaction fees were burned or redistibuted to users, the same would occur.

Decentralised Blocks

One solution proposed by pmcgoohan (the first user to report MEV who is now an advocate for eradicating it) is decentralised blocks. Decentralising a block means that more than one miner will be able to decide what is in a block. This essentially adds another layer of consensus required on a system greatly amplifying the workload required to mine a block. It’s an interesting proposal that would remove MEV however again it may also greatly alter the core consensus of Ethereum itself.

Third Party Transaction Ordering

A third party service that fundamentally order transactions fairly to begin with without miner choice. Automata is an example of such a service that uses a decentralised layer to abstract away the ordering of transactions from miners. This does however required that applications on Ethereum work together with Automata to ensure that only Automata “blessed” chains are accepted in transaction. A similar proposal by Chainlink called FFS uses Oracles to achieve the same notion.

Mitigating MEV

If you can’t kill it try to weaken it. Potential mitigations and compromises exist for reducing the impact of MEV and they require some structural changes to the way Ethereum applications are architected. In order to preserve the paradigms of permisionlessness and security within the Ethereum paradigm:

Better Application Design

Decentralised applications running on Ethereum can be designed to minimize it’s exploitability in reference to MEV. An example of this is in the front end of an AMM like Uniswap. The oracles fetch the correct prices for users saving them from accidentally overpaying for a token and getting frontrun as a result. Automated slippage settings and contract gas price calculators are also helpful to users to minimise the MEV exploitability in their transactions. However, the protocol cannot force applications to do this, and there is a limit to how much MEV can be avoided.

Implementing DAOs everywhere

Improving on better application design, designers can control user bases on apps with DAOs. By forcing users to be a part of a DAO to trade on a Decentralised Exchange service malicious arbitrage bots can be detected and removed by neutral users on the platform. This implementation could be further solidified with legal verification of users of the service via a KYC process.

Benign Mining Pools

Another way to circumvent MEV is to have miners that filter out MEV natured transactions. Users can offer to pay a premium service which allow them to guarantee that their transactions won’t be exploited. Such a service does have it’s limitations as miners are profit driven.

Reducing On Chain Pressure

Accepting that MEV is inevitable, at least we can reduce the strain that frontrunning and backrunning places on the mempool it’s contribution to on-chain congestion by taking the bidding process off-chain. A solution in the works to this is ArcherDao which offers a swap service acting as an extension to a dex that routes orders through a private network before grouping them together for a miner. ArcheDao also doesn’t charge users for failed transactions as miners are only compensated when the transaction is successfully included in a block. The user pays the network with “tips” as a compromise for the protection given.

Front-running-as-a-service

In the FaaS system, miners auction off the right to front-run users. Contracted arbitrageurs can bid off-chain in real time for positions on the block and the winner of the off-chain auction pays the final price to the miner in exchange the preferrential transaction placement. This solution is supported by the Flashbots organisation who have been working on MEV-Geth as a bridging front running service for miners and arbitrage bots.

Such a service also has the benefit of allowing devs or users looking to fix their contracts to contact a private miner in request that their follow up recitfying or cancellations can go through without arbitrage (this will also depend on the benigness of the miner, however atleast now there is a chance compared to before).

Ultimately however such a service is still a tax to all users on the system and doesn’t do much to reduce the value that “MEV” sucks from the system. Additionally having such a widely used and popular service will no doubt impact the reputation of Ethereum.

Preventing Doomsday

Stopping the worst case scenarios is the least that can be done. If the root cause of MEV is hard to fix it is critical that destabilising consensus (time-bandit attacks) is difficult and costly.

Separating Inclusion and Ordering

FaaS will seperate miners from both transaction inclusion and transaction ordering since the ordering of blocks is required to be determined off chain. This theoretically means time bandit attacks from miners is not possible since forking off chain still removes miners from ordering transacitons.

Proof-of-Stake

With ETH transitioning to a PoS-based conensus in ETH 2.0 the Ethereum network can leverage the significantly greater cost of launching a time bandit attack. This is because on PoS validators determine reorganisation and any 51% attack can result in the particiating validators being slashed. However, with enough MEV the incentive to re-org could still be greater than the slashing penalty.

Conclusion

Many of these approaches involve significant changes to the core protocol that require rigorous testing to implement. Even application-layer improvements require developers to re-architect their designs.