You don’t need that many choices to greatly improve your outcome
If you try to frontrun a Uniswap tx when the order is randomized, you have a 50% chance of winning and a 50% chance of losing. Your win expectation is $0, so there’s no point trying.
If you can give yourself just one more shot at randomization (one more funded account in your proposal), you give yourself a 75% chance of winning and only a 25% chance of losing.
Immediately, you have a positive win expectation. As you can see below you only need 7 accounts to give you a >99% chance of winning!
funded accounts
outcome count
p
1
2
0.5
2
4
0.75
3
8
0.875
4
16
0.9375
5
32
0.96875
6
64
0.984375
7
128
0.9921875
The wealthier the attacker is the more they can manipulate transaction order
The wealthy can best afford to fund the multiple accounts that grant them this preferential tx order.
The most wealthy can even afford the number of accounts required to position two txs and sandwich a trade. In fact, only they can. In this sense, it is less equitable than what we have now.
This is reason that Alex never gives any one participant a choice over outcomes. It is the reason that shufflers cannot withhold, that we only skip sets by consensus, and that we never skip individual roles.
The MEV Auctions defended by this article do not mitigate MEV they maximize the exploitation of it.
They allow order flow attacks that would be unworkable without them and these are not tracked by MEV-Inspect.
I think the reason people are so into MEV Auctions right now is that they reduce the txn bloat caused by price gas auctions. Put another way, MEVA exploits the users to save the network. It should be the users that exploit the resources of the network. It is completely back to front and no kind of a medium to long term solution.
Imagine if when the Heartbleed vulnerability was discovered, the OpenSSL devs decided it was too difficult to fix. Instead they released code that enabled everyone to read everyone else’s encrypted passwords, emails, messages, etc because at least that would democratize access to the vulnerability. I doubt anyone would still be using OpenSSL.
That is where we are right now with MEVA and Ethereum.
im confused based on this comment. It seems like your system just randomizes the ordering… doesn’t this mean with 7 accounts (as you say) in a random order mean 99+% of the time the initial transaction will be frontrun?
I don’t see how two layers of pickers helps mitigate this in any way. Sure it eliminates collusion by the block orderer, but don’t you still get frontrun? I’m still reading through your full documentation, so maybe this is answered somewhere or I am missing something.
You are right that this is an issue, although unlike at the moment it is possible to protect yourself against it. There has been some discussion of this on the other thread…
re this:
So the answer is not really because you can split your transactions as much as any attacker can. We have fairness but at the cost of tx bloat and raised costs. Hence looking at enc mempool and fair ordering variants.
The thing to focus on with Alex is the idea of bringing order to the mempool by chunking it up, and the flexibility this gives you with trying different consensus ordering schemes/MEV mitigations without harming UX.
thanks for the in-depth answer… as an average user I don’t think I would want to split my transaction/ run multiple transactions to fight off attackers. This sort of tx bloat is overall a bad thing for the network as you say.
Maybe the payoff for an attacker goes down if they are competing but I can’t imagine it would drive away attackers if there is still an opportunity for an economic incentive. If their chance is really so low of winning then perhaps it does disincentivize MEV a lot. I could also see it driving collusion (if this is even possible?) or new strategies.
I see an advantage to this Alex method, but I am not convinced it would solve the issue (or benefit the end-user) in any meaningful way personally. I am also curious how this would work with validators instead of miners. However, I concede I am no expert, simply interested in the topic.
I think I am closer to Phil Daian’s opinion on the topic at the present moment.
I appreciate your research on the topic! Keep up the good work.
That’s fine of course, and thank you for engaging. I also do not want tx bloat so I am looking at fair ordering/enc tx versions of Alex.
Phil’s opinion is essentially to leave things as they are. I predict that the more use cases expand for Ethereum the worse the situation will become (ie: the more exploits of transaction order corruption will emerge) until it is becomes clearly intolerable. Over the same time workable solutions to MEV will be getting closer all the time.
So I just ask non-interventionists to continue to keep an open mind about this issue. The situation is changing all the time.
Totally, I am still curious about any solutions to the issue or how the dynamics change over the next several months with EIP-1559 and moving to the PoS chain.
Implementing some solutions that mitigate MEV as much as possible would be great! Maybe that’s your proposal, who knows.
Re: my suggestion that non-intervention will become intolerable, here is a relevant piece I just had published on coindesk.
When you have data corruption in your system you are bound to get wild and unpredictable negative effects. MEV and GPAs cause high transactional data corruption. Here are some possible outcomes.
Do you have a source on HFT in traditional markets being valued at only 1 billion? That seems way too low considering the insane amount of HFT firms around the world and the billions of dollars they invest into frivolous activities like straightening fiber-optic cables undersea (A Transatlantic Cable to Shave 5 Milliseconds off Stock Trades)
pretty interesting solution (not yet decentralized) where the user produces the full block & pays the miner for PoW only (yes not a solution for eliminating MEV but imo a step forward from status quo)
“In 2017, aggregate revenues for HFT companies from trading US stocks was set to fall below $1bn for the first time since at least the financial crisis, down from $7.2bn in 2009, according to estimates from Tabb Group, a consultancy.”
Looking at it again, it seems to be US stocks only, so the amount for all financial instruments will be higher.
However, it is not hard to see why MEV is a much bigger problem for Ethereum than HFT is for trad-fi.
Even when Flash Trading was ubiquitous in 2009, it only gave a 5ms advantage on order visibility. NASDAQ and BATS have since banned even this. Transaction reordering has never been possible in the traditional financial markets in orders sent directly to the exchanges. Brokers like Robinhood might frontrun you- look how it’s ended up for them. I want better than that for Ethereum.
The maximum latency advantage you can get from laying your $1 billion dollar cable is probably around 300ms. As I write this there are 167,540 pending transactions in the mempool. As a miner/MEVA winner I get to pick any combination of those transactions to build a block that is entirely to my advantage as well as adding in any number of my own. Imagine if Nasdaq allowed the highest bidder to pick and reorder what is probably many hours worth of transactions. It is unthinkable, and yet that is the situation with Ethereum today.
Crucially, HFT has declined almost by an order of magnitude over the last decade, whereas MEV is rising exponentially.
Did you read further- what do you make of my ideas for a content layer bound to block attestation? (ignoring the random ordering part which is problematic)
1- In all proposed solutions here, u make ur target to wave away the control of transaction ordering from miners hands, right?
-Doesn’t this imply that users too cannot pay for a certain order in the block anymore?ie users have to understand that higher bids for transaction fees now, or for miner tips after EIP-1559, only increases the probability of inclusion in the current block but has nothing to do with the relative order inside it???
-Did I miss something or am I getting this right? and u think users will be OK with that???
.
2-with the same randomization problem existing in ur protocol as the simple hashing idea of @stri8ed stri8ed
@marioevz marioevz
Can u explain what makes ur protocol better as opposed to the simplicity of just the order of hashes?
»Infact I think the probability of controlling the order of a resulting hash is much less?
I would prefer to take it futher and have no auction at all (whether GPA or MEVA). In this situation, you keep the EIP 1559 base fee to reflect overall demand and mitigate DDOS, but eradicate the tip (thanks @barnabe).
It is way better for users because:
no need to set/guess tx fees (which users dislike and which EIP 1559 is trying to address)
visible guarantees of order execution (tx order is quickly visible in the content layer before entering the block)
exploitative MEV is greatly reduced (simplest content layer=limited MEV auctions possible) or eradicated (enc/fair ordered content layer)
low gas costs
The low gas costs observation is potentially huge and is only just occuring to me. I am actively researching it and would love to stimulate a debate around it.
Essentially, any auction (whether GPA or MEVA) creates MEV by allowing users to bid on transaction order. In doing so we are not only auctioning off tx execution, we are also auctioning off tx priority (which is far more valuable as the MEV crisis has shown).
It is this extra value that makes it worth attackers bidding up gas costs to extract MEV. Users that are not trying to extract MEV then have to raise their bids to compete with the very attackers that are exploiting them.
Put simply, not only do auctions corrupt transaction order, they also raise gas costs (I suspect by a lot- I aim to quantify this).
Yeah what I am proposing is a systemic change. High gas prices and MEV are systemic problems.
Seconding this. Very little of traditional HFT revenue is purely extractive in the same way that the front-running sandwich bots on DeFi are. The sizable bulk of HFT activity is market making, cross-venue arbitrage, or statistical arbitrage based on signals in the microstructure. In all those cases, the HFT entity is increasing liquidity and/or improving market efficiency through price discovery.
Sandwich front-runners contribute neither. There’s no permanent price impact, because the price ends at the same price as it would have without the attack. The closest analog to something traditional HFT actually does is the back runners which arb the price between different liquidity pools. Yes, HFT might contribute element of order flow prediction in the statistical sense. But it’s nothing like the way sandwich front-runners directly. In a traditional exchange order visibility and execution are atomic at the exchange gateway level, so there’s no way to know an order will arrive before it’s already filled. (The Michael Lewis book covered a very small corner case, where very large traders were sweeping liquidity at multiple venues with multiple orders, which were only predictable in the non-determistic statistical sense.)
Sadly not even that. It isn’t healthy price discovery if you can create or exacerbate a price imbalance by reordering/censoring txs.
Miners and MEVA winners literally create arbitrage and backrunning opportunities that would not otherwise exist and then risklessly exploit them.
And the final insult, average users that just want to get their txs executed have to compete on tx costs with the very people that have pushed the gas price up in order to rip them off (see my post above).
This is really, really interesting. If we consider transaction ordering to be a separate layer of consensus, the answer to “can we eliminate MEV” seems to be yes. As a trivial example, if we used a light-weight PoW sidechain that restricts each block to only contain 1 transaction as the content consensus layer for our main chain, the transaction ordering would be decentralized. I feel this framework opens up some new and interesting design space for developing a practical MEV-free blockchain.
Hi @zefram_l. Yes it seems that way to me. I wanted to distinguish between the general concept of a distributed content layer and the Alex protocol as my first attempt at designing one.
Thank you for contributing ideas for another possible implementation. Re: a full secondary blockchain, you’ll have to be sure to keep network usage to acceptable levels and not to introduce another layer of MEV. I’d like to hear your ideas as you progress them.
I’m currently looking at a very stripped down version of Alex that mitigates some MEV (I need to work out how much) and is much simpler to implement as a first version. I’ll then look at how it can be built on to provide encryption and fair ordering.
Great post! I like the distinction b/w content and structure.
Do you think that we could use the randomness in the beacon chain (RANDAO today, VDFs tomorrow) to create shuffle seeds in a way that gives us something like the shuffler approach?