MEV Auction: Auctioning transaction ordering rights as a solution to Miner Extractable Value

Economics
4

Optimizing the Auction

Are you assuming here that the sequencing auction for block N happens after the transactions in block N are known? I think what @karl had in mind was the sequencing auction happening well before block N, eg. potentially even a day before. This way the sequencers would be buying rights to the expectation of future MEV, not bidding on permutations (and insertions and delay-to-next-block operations) directly. Does this simplify the above analysis?

Impact on Inflation

The third option has a lot of internal choice! One option that I am particularly excited about is funding public goods through some DAO, on-chain quadratic funding gadget, or similar tool.

he simplest form of MEV that isn’t discussed is transaction elision — e.g. a validator not repeatedly adding a transaction to the transaction set.

I agree this is a form of MEV too! Though I wonder how much of that is captured by the ability to reorder transactions arbitrarily including inserting your own transactions before some of the transactions in the original block.

6 Likes
5

Interesting!

The general idea seems to be to redistribute MEV from miners to some other entity, e.g. a DAO which funds public goods. Wouldn’t this basically be equivalent to leaving the MEV to miners, but instead send an equal fraction of block rewards to the DAO?

The sequencer can only commit on a specific position in a block, not that the transaction will be included at all, no? I guess usually they can predict this fairly accurately, but there’s still a chance that they are wrong (especially if the producer actively refuses to include a specific transaction).

1 Like
6

Wouldn’t this basically be equivalent to leaving the MEV to miners, but instead send an equal fraction of block rewards to the DAO?

No, because it’s not just about long-run average returns, it’s also about incentives. This technique removes the incentive of trying to collect MEV from miners, and gives the incentive to the centralized party that won the auction. This way the auction participants “absorb” the gains from sophistication, making it more plausible that miners/block producers will remain decentralized as they can safely be dumber.

9 Likes
7

This could be a significant problem indeed as it makes block mining a distributed computation between 2 parties. Can this be mitigated by putting the sequencing algorithm into a contract, which the block producers need to follow? Each sequencer will participate in the auction with (sequencing code, bid) pairs. Once the winner is known, the block producers need to obey the current sequencing code.

One downside of this approach is a potential DoS attack against the block producer, by submitting the ordering code, which is artificially complex to execute.

On the plus side, this eliminates the need for communication between 2 parties to mine a block.

3 Likes
8

Hello, I am in the business of MEV. There are some good ideas in this proposal. I have a critique and alternative proposals. Some things you say aren’t true but I won’t go into too much detail because a lot of the game is a well-kept secret.

Transaction ordering is powerful because it determines which transactions succeed and which fail, and also what happens should they succeed. Miners have dictatorial power over this $10m+/year market because there are no rules regarding transaction ordering. Even if there were rules miners still win by excluding transactions.

Block proposers are most analogous to traditional blockchain miners. It is critical that they preserve the censorship resistance that we see in blockchains today

Proposers are still incentivized to exclude transactions. You introduce another source of censorship: independent reordering. Separating these powers is an improvement but the sequencer, the producer, and the transactors could still be the same party, and the sequencer could have conflicts of interest outside of the block.

This auction assigns the right to sequence the last N transactions.

Changing the order of transactions impacts state. This would substantially increase the effective confirmation time leading to instability and a higher rate of reverted transactions.

It also impacts gas usage. If a block proposer only selects the transactions but does not order them, there can be no block gas limit. It is nontrivial to prove that a set of transactions cannot be ordered below a given gas threshold. Using transaction gas limits is sufficient but you end up with barren blocks and substantial gas-usage volatility; the network would be massively under-utilized. A related concern is that the sequencer doesn’t care how much gas is used.

If, within a timeout the sequencer has not submitted an ordering which is included by block proposers, a new sequencer is elected.

This process could last an unbounded amount of time. Block proposers could have incentivizes to exclude the ordering. Moreover the ordering itself could be reverted by a future reordering. Instead you could have a hash of the ordering be part of the bid itself, since the MEV is known at the time of the bid.

In addition to extracting MEV, the MEVA provides the current sequencer the ability to provide instant cryptoeconomic guarantees on transaction inclusion. They do this by signing off on an ordering immediately after receiving a transaction from a user – even before it is sent to a block producer.

I don’t see a reason for the sequencer to do this. An index is not a strong guarantee either. You could even withhold such a proof until you actually provide the sequence.

As long as the sequencer stands to lose more than it can gain from an equivocation, we can expect the sequencer to provide realtime feed of blockchain state which can be monitored, providing, for instance, realtime price updates on Uniswap.

They don’t have to provide this information to the public in realtime.

Bidders colluding to reduce competition and keep the auction price artificially low breaks the ability to accurately discover and tax the MEV.

Collusion requires barriers to entry. You create a barrier to entry by incentivizing the probable-winner to submit more MEV transactions and punishing their competitors for losing. Once you start winning you will probably keep winning indefinitely.

This can help to establish a price floor because with low barriers of entry we can expect enough competition that there will be at least one honest sequencer bid.

Sequence bidding is not free.

Proposals

MEV is potentially significantly higher than transaction fee revenue.

MEV is the true block reward. Gradually diminish the inflationary block reward instead of trying to tax MEV. Let “dumb” block producers maintain viability via open-source software. Preserve confirmation time.

Define a standard transaction ordering algorithm to increase the cost of censorship.

Ban or punish inclusion of transactions that would revert at the top-level. These waste shared computational resources anyway. Preventing block producers from winning revert rewards removes a barrier to entry and reduces the power of the block producer. Let block producers manage revert-DOS off-chain.

2 Likes
9

Making reverting transactions invalid is non-trivial. If you receive an unconfirmed transaction from a peer and validate it locally, whether it reverts or not depends on when it’s executed (i.e. its index in the totally ordered list of transactions provided by the blockchain). Therefore you can’t ban a peer that sends you a reverting transaction (unless you make the peer provide you the complete ordering of transactions it used to execute that transaction, but that’s computationally infeasible). Being unable to ban a peer that sends you an invalid transaction is a DoS vector.

Note that this does not apply in the same way for spending conditions with monotonic validity, such as the predicates used in Bitcoin Script or those that have been proposed for Fuel.

A standard transaction ordering algorithm might help with the above, but I’m not aware of even a single one that has been proposed that isn’t hopelessly broken.

2 Likes
10

This recent paper might be relevant: it separates transaction ordering from transaction execution at the consensus layer.

11

FYI - we came up with these same ideas in 2018 - see here: https://medium.com/@jaybny/on-dex-fac434d7730f

2 Likes
13

@jaybny This is really cool! Did you come up with any fun takeaways/analysis since your first post?

1 Like
14

thanks Karl. I have lots of ideas and directions on where to go with this… but am not a fan on working on top of Eth, although I love the tech and community.

I actually received a patent for some of this, and am looking to build a DEX proof-of-concept.

15

We are working on something somewhat similar in application level. We decided to first tackle the lending platforms liquidation MEV. Where liquidators compete on a well defined premium, which give rise to gas wars and millions of $ that goes to miners.

Our approach is to make the liquidators auction in the beginning of the month for the right to liquidate. And then to divide the liquidations fairly among the liquidators over the month.
We are implementing a practical approach that will go live on September atop makerdao. The idea is that liquidators will share their profits with the users, who in return give them priority in the liquidations.
A defi-lego trick makes it possible to achieve it without any change in makerdao protocol.

More details are available here: https://medium.com/b-protocol/b-protocol-b6dd4e3bf9c0

2 Likes
17

There is a faster alternative. We are implementing it in our project and it could be easily implemented in ETH2 or any other finalizing blockchain.

  • Transactions are submitted encrypted using threshold encryption.

  • A committee (say ETH2 committee) collectively holds the decryption key.

  • Once the block proposer includes the transaction into the block, and once the block is finalized, the committee decrypts the transaction (the committee only needs to decrypt the symmetric key that encrypts the transaction).

  • Once the transaction is decrypted, EVM runs on it.

Thats it - it solves all the problems. You can run Uniswap on it with zero front running.

There are some technicalities (for instance gas price, nonce and some other things need to be submitted unencrypted). But they are all workable. Note that this could be implemented at the application level too.

3 Likes
19

A committee (say ETH2 committee) collectively holds the decryption key.

What happens if the key is lost? Maybe I don’t understand how large the committee is…seems like maybe a pretty central point of failure

20

What is the purpose of this?

Why is maximising MEV extracted a goal? It’s going to happen anyways, why do we want to speed this up? Intellectual curiosity? Market efficiency?

Is any part of this proposal going to be added to the ethereum spec? Or is it all features being built on top of it (via a DAO or something)?

21

I posted about similar issues soon after the ETH ICO (nothing like as rigorous as the Flash Boys 2.0 paper of course).


I’m glad the community is taking these issues so seriously.

It’s a noble idea to accept the MEV losses but redirect them to the commons, but I’m not sure it protects the unsophisticated and under-resourced from the sophisticated and resourced as is.

Consider 3 participants (A,B,C)…

A - calculates that winning the MEV auction for tomorrow is worth 1 ETH in costs because they will likely make 0.1 (after costs) from their trading if they can frontrun, and only 0.05 ETH if they can’t
B - calculates that winning the auction is worth 0.5 ETH in costs because they will likely make 0.1 (after costs) if they can frontrun, and only 0.08 if they can’t
C - just wants to trade and has no idea that MEV auctions even exist

So the outcomes for the A/B sophisticates and the naive C are…

A - wins the auction in this case, and has to pay 1 ETH, but makes 0.1 so is happy
B - loses the auction, but also knows that they have, and therefore avoids trades that they can’t profit from. They make their 0.08 without the overhead of winning the MEV
C - has absolutely no idea that any of this has taken place. They get frontrun continually all day and are none the wiser. Effectively, the 1 ETH paid by A is extracted exclusively from C, the actor we are trying to protect.

“This technique removes the incentive of trying to collect MEV from miners, and gives the incentive to the centralized party that won the auction”
If we’re not careful, this will have achieved nothing. The same bad actors that would have been miners have become MEV auction participants instead, just with a different name.

I think the auction proceeds at least need to be distributed proportionately to all the participants in blocks sequenced by the auction winner (except for themselves), not just some common DAO like fund. In this outcome:

A - pays B and C equally
B - will know they are going to get paid by A and will include that in their expected win calculations
C - will have no idea whats going on, but will be happy to get some compensation (and statistically the set of unsophisticated Cs will not lose out, although individual Cs may lose big)

But really, I’m not sure the focus should be on sequencing. Block production is the weak point as this is where transactions can be censored and frontrun.
Once you have a fair block, sequencing is a non-problem. The fairest method is always to treat all transactions in a block as if they were simultaneous. This could even just be done as a matter of convention in smart contracts. If we are talking about many blocks per second, there is no real downside to this.

So in summary, I think the focus needs to be put back on a fair consensus driven block proposal. Sequencing is a distraction.

22

Just to be clear, this would result in significantly more front-running. Yes, maybe the profits would go to a worthier cause, but the average Dex trader would experience much worse slippage.

Right now existing arbitrage bots don’t exploit every opportunity to the max, because there’s execution risk. There’s all kinds of reasons an attempted front-run order might fail, if another bidder wins the auction, if the target is mined before the sandwich propagates, or even if the target cancels their transaction. If that happens the front-runner still pays gas on the “empty transaction”, and possibly even gets filled at unprofitable prices. Many exploitable target slip past, because the bots don’t think the risk is justified.

In contrast, the sequencer would know with 100% certainty, and therefore would exploit every single opportunity, extracting the maximum amount each and every time. More so, the sequencer would have even worse exploits at his disposal. There’s a lot of exploitation opportunity during periods of turbulent trading, when many trades on the same pool occur in the same block, like ICOs.

These happen to be the time that ordinary traders set the highest slippage. Front-runners can tactically insert their own transactions, but they can’t re-arrange third party transactions. The sequencer’s arbitrary ability to re-sequence introduces very large potential attacks in these instances. For example if the normal sequence is Buy->Buy->Sell->Sell, the sequencer could re-arrange to Buy->Sell->Buy->Sell, which lets them front-run twice as much value. Technically miners could do the same, but in practice 95%+ don’t, because running a mining rig requires different core competencies than being an arbitrage trader.

Finally, the two-phase commit nature of the process gives the sequencer a free option. This is equivalent to “last look” that you see in certain traditional markets like FX. The sequencer has N blocks to declare the sequence. He could include two of his own trades in the block- one to buy ETH/USD and one to sell ETH/USD, with the caveat that the first trade cancels the second. If the price of ETH rises in the next N blocks, he sequences it so that he buys ETH/USD. If it falls, he sells ETH/USD. Front running only extracts value from liquidity takers. But this would impose a persistent cost to Dex liquidity providers.

2 Likes
23

This post is absolutely bang on. Arbitrage risk is a huge deterrent in itself. I say this as an arber myself in other non-crypto markets. Anything which reduced that risk to zero would allow me to put x5 the volume on I otherwise would at the direct expense of other participants.

24

If roles between producer and sequencer are split; why not give block producers a double role? 1) Sequencer: ordering the transactions from the previous block based on hash ordering (with some data from the current block. E.g. pub key); 2) Selector: selecting transactions for the next block.

To the selector the final ordering of transactions appears to be unpredictable and random. The sequencer has only the possibility to drop the last transactions if they exceed block gas and has no possibility to insert/replace orders. The sequencer can only execute a predefined hash order and does therefore not have an arbitrary impact on the order.

Please let me know if such a method has already been proposed (and rejected).

25

There’s another big problem with the auction. It hugely favours whales over small holders.

Let’s say a whale wants to sell 1000 ETH and 1000 small holders want to buy 1 ETH each. The auction is worth 5% of volume in slippage avoided to whoever wins it.

So to the whale it is worth paying up to 50 ETH to win the auction. To each of the small holders it is worth only 0.05 ETH.

So the whale wins hands down each time, and is able to trade perfectly against the order flow of smaller participants, however sophisticated they are.

This is horrible. It doesn’t make any difference how charitably the auction money is spent, the little guy is getting ripped off.

Remember the point of Flashboys was that until it was banned, big players were able to pay to see and react to orders before retail who could never afford the privilege. This is exactly what is being proposed here.

3 Likes
26

very good, very good