Hacker News Reader

Can't crypto kill front running entirely?

Alice, wanting to transact, writes down two opposing orders, say buy 1 share of A for $10 and sell 1 share of A $10, plus a signed secret stating which order it actually is.

Other players subscribe to one of the two opposite orders.

Next thing (whatever that means in these blockchains, but after other players have subscribed to one of the two opposite orders), Alice reveals the secret using her private key. This reveals which order it was (buy or sell). Alice then makes a deal automatically with whoever subscribed to that order. The other opposite order is cancelled.

Bots can probably still front run arbitrage opportunities where it's clear which transaction is the correct one, but the same can probably be done by encrypting the whole transaction and only specifying the wallets involved.

This has been proposed quite a few times, but the problem comes down to that it requires letting a single participant "lock down" the entire liquidity pair.

For the above scheme to work, Alice's reveal would have to occur at a later block than her initial commit. Otherwise an arbitrage bot could simply peek at the reveal before the commit is mined. Also Alice's commit has to lock the chain until its reveal. Otherwise when her reveal is propagated on the P2P network, the arbitrage bot could jump the queue in front of her commit and still exploit her.

You're now talking about the market freezing for 12-seconds (the block time) on every single trade. That's completely infeasible for any sort of liquid pair like ETH/USDT. Not to mention a single malicious player could DDoS the entire market. Or use it as a free option during periods of high volatility: lock the market then "reveal" in whatever direction the centralized exchanges moved in the lock-up period.

Maybe you could only lock "big trades", but that in itself reveals a lot of information. You don't necessarily know the direction, but you can likely infer it with high certainty. For example if Alice doesn't own much of a token, then it's nearly certain she's buying not selling.

Front running cannot happen if the mempool is encrypted. These types of blockchains are current being explored but have tradeoffs are are not widely adopted. Here are two example blockchains:

SCRT (Hardware TEE, functional on Cosmos)

Partisia (MPC, no working product)

Other theoretical methods include homomorphic encryption and indistinguishable obfuscation.

Moving to Optimism L2 will remove miner advantage.

Edit: of course, Optimism "Chain Organizers" can front-run, but if they will be run by Uniswap themselves, then they have no incentive to ruin their own product.

This is a misunderstanding. You don't need to be a miner to front-run transactions. You simply need to run a full node, with visibility into the P2P network.

It's true that miners always have "right of first refusal", in that whoever mines the block can choose to prioritize his own transactions over anyone else. But if miners don't exercise that option, then any third party can front-run the target by outbidding them. Getting rid of miners, does not in anyway remove the issue of front-running. Currently, less than 5% of front-running activity is performed by miners.

As long as transactions are propagated over a P2P network, then front running is still possible. So Optimism only fixes this problem, if Uniswap LLC is hosting the entire side chain and participants are directly submitting their transactions to Uniswap's servers instead of the block chain. However if that's the case, then they almost certainly will be legally obligated to perform KYC/AML on all clients, at which point they are essentially a centralized exchange.

For reference, even Binance Smart Chain, which is heavily criticized for being a centralized exchange in disguise, does not take this approach. Centralize validators are used, but the network itself is still P2P instead of centrally hosted.

There's a lot of semi-incorrect information here.

With Optimism, there can be multiple L2 chains, by different "Chain Organizers". When you submit a transaction, you get a receipt from Organizer, a cryptographic promise that it will be included in future rollup.

It means only Organizers can attempt to front-run, by adding a transaction before giving out your receipt. And users can always choose to use different Organizers, those that don't front-run. Since Organizers gain a small amount of fees, it doesn't make sense to be a bad, front-running Organizer.

I spent quite a lot of time developing Uniswap/Sushiswap/other dex arbitrage (back/front/sandwich) tools and bots over the last 6 months.

When you say you simply need to run a full node, thats incorrect. It is a prerequisite yes, but much less than half the battle. You also need now to ensure correct order placement (on any opportunity there are upwards of 5-15 competing bots), a friendly relay network/mining pools, efficiently node peering (e.g. 2-400 peers per node, managed on a custom routing table), a network of nodes to broadcast/listen for mem pool messages across the entire network instantaneously without waiting for P2P propagation (1-2 hops may introduce enough latency to lose out on the arb) (& some nodes are malicious - who fail to propagate arb'ble tx's), patched/custom GETH instances running on nodes (I am not at liberty to reveal what optimizations make one competitive). And then above all of that you need to be able to absorb, identify profitable transactions and then compute/simulate optimal transaction parameters in a very constrained amount of time.

So its not at all simple, in fact I have wound down most of my operations as the costs vs. rewards are extremely marginal now vs. what they were mid last year.

> Currently, less than 5% of front-running activity is performed by miners.

How do we know this number? It seems like it would be possible for miners to front run without any identifying characteristics.

It seems to me that the opportunities you are describing will be rare. If we classify liquidity providers into static and dynamic, under an efficient market it should be expected that the static liquidity providers will over time distribute their funds efficiently along the curve. The event you describe will only occur if volatility is greater than expected and the dynamic liquidity provider has a large share.

Can't these narrow ranges be misused by miners who can decide which transactions they want to put in the next block? I think it would make sense for them to start looking at the contracts themselves, not just the gas fees, and take part of providing liquidity. Even ordering the transactions matter a lot, as they could find arbitrage opportunities.

Yes, but this is solved by PoS.

Also, there's https://libsubmarine.org/

>Yes, but this is solved by PoS.

How so? Now rather than colluding with miners and/or mining pools they'll collude with stakers and/or staking pools.

What do you mean by "take liquidity ahead of a large order" and "adding liquidity in a narrow range"?

When a user creates a swap transaction on Uniswap, it goes into the ETH transaction queue (prioritized by gas amount). If a bot notices that a user has a large swap (say swapping $1.5M USDC for 1K ETH), a bot could theoretically 'front-run' the order (by paying a higher gas fee than the original swap) and inject say, $10M of liquidity into the expected price-band of movement caused by the trade. They could then pocket a portion of the transaction fees (whatever their fraction of the 0.3% trade fee that Uniswap charges is), and then immediately pull the liquidity out of the LP to then wait for another front-running opportunity.

This doesn't harm the person doing the swap, per se. It harms the Liquidity Providers that hold their capital in the pool for longer term.

Is it really draining the liquidity or switching it to flash liquidity instead?

That would make the estimates worse though.

Would it help if Uniswap implemented a cooldown on adding/removing liquidity?