Lighting up the Ethereum Dark Forest

This post is by Joshua Gans and Richard Holden

https://commons.wikimedia.org/wiki/File:Gloomy_Forest.jpg

Smart contracts that involve token payments need to be safe. As outlined by Dan Robinson and Georgios Konstantopoulos in a 2020 post, many blockchains, including importantly Ethereum, are profoundly unsafe. They liken the situation to a dark forest, popularised by sci-fi author Cixin Liu, whereby making yourself known invites attack. In the case, of smart contracts, when a party to a contract broadcasts a request for payment, that request can be seen and hijacked by others to steal the payment for themselves. It is as if every time you left payment for a restaurant meal, someone swooped in and took it. Suffice it to say, the restaurant business would not last long. So to blockchain smart contract which, despite years of promise, has yet to take off. With recent moves towards DeFi, this issue becomes a potentially catastrophic problem for blockchain ecosystems.

In this post, we describe a new, and straightforward to implement, solution to smart contract front-running. It requires the addition of some code to smart contracts (an example of which is here) which we call a Solomonic clause. The name is inspired by the mechanism created by King Solomon to resolve ownership disputes 3,000 years ago but is more readily applicable as we outline in this paper. In contrast to other solutions, it neither requires baseline protocol changes to blockchains nor the use of cryptography. We are economists specialising in implementation theory — a branch of game theory — that focuses on the design of procedures to make transactions and contracts safe without outside enforcement.

A little background (which you can skip if you know this stuff)

The issue was noticed by Reddit poster, pmcgoohan, in 2014:

Miners can see all the contract code they run (obviously), and the order in which transactions run is up to individual miners.

What is to stop front running by a miner in any market place implementation by ethereum?

For example, in an ethereum decentralized stock exchange, I could run a miner (or rather many miners) processing exchange transactions. When a large buy order comes in, I could delay it on all my miners, put a buy order in myself on all my miners simultaneously, and then process the original transaction. I would get the best price, and could possibly even sell to the originator for an immediate profit.

You wouldn’t need anything close to 50% of mining power, because you aren’t breaking any network rules. It would probably be profitable even if it only worked a fraction of the time, as in a low transaction fee environment, you could afford many misses for a few hits.

This is true for many of the proposed killer apps on ethereum, including peer-to-peer betting, stock markets, derivatives, auction markets etc

It seems like a big problem to me, and one fundamental to the way ethereum operates.

This sparked discussion but little action. However, by 2019, there were bots engaged in front-running payments on Ethereum. This video from Scott Bigelow, showed the issue in action:

To explain how front-running arises, here is what is supposed to happen with regards to a smart contract:

1. A contract is written to the blockchain that it will send tokens to a wallet if evidence of contractual performance is provided.
2. Someone performs the contractual requirements and then broadcasts a transaction, along with associated transaction fees, to the mempool.
3. The mempool is public and is the source of transactions that miners (or validators in proof of stake) use to assemble blocks to append to the blockchain. Miners use the transaction fees, their reward, to give priority to transactions to be recorded in a block.
4. The smart contract executes when it receives the performance evidence on the blockchain.

Front-running arises because, between steps 2 and 3, the transaction broadcast by the legitimate claimant to the contractual payment, can be seen and slightly altered by others — specifically, bots — to direct token payment to an alternative wallet. In all other ways, including the evidence of performance, the transaction is the same. This provides a time period by which it is possible for the front-runner to have their claims recorded to the blockchain and, because there is a lag involved in this process, they can potentially be recorded with an earlier time-stamp, on the same or an earlier block, than the legitimate claimant. Indeed, by offering higher transaction fees, they can make this very likely.

This front-running is very similar to that described in Michael Lewis’s Flashboys. There, front-running involved racing to take advantage of arbitrage opportunities that are created in the nanoseconds after someone engages in an asset purchase on financial markets but before the transaction has reached the market. This same kind of front-running occurs on blockchains to take advantage of similar arbitrage opportunities between cryptocurrency exchanges. This has created half a billion dollars of value extracted over the last couple of years. The value can accrue to miners who have the ultimate control over transaction ordering. For this reason, it is often referred to as miner extraction value (or MEV).

The front-running we are concerned with here is so problematic, it actually makes smart contracting unsafe and is perhaps a reason why that hasn’t emerged.

Many have been engaged in trying to resolve this problem. One solution was actually posited by Vitalik Buterin in the comments to the initial 2014 Reddit post:

One idea is process orders in batches rather than sequentially. Specifically, let orders accumulate for a few blocks, and then come up with a list of all orders that have appeared during that time sorted by price, and them match them one by one. If “a few” is something like 5, then there are going to be enough different miners that every order will almost always get in.

The batch idea is a way to discretise time and as also proposed by economists to deal with Flashboys type front-running. Once this is done, a more transparent auction for priority can be run that potentially reduces congestion that might otherwise be induced on the network. It does not prevent front-running but some have suggested that the fees collected from such auctions can be used to fund public goods of some kind. Others, such as Ed Felten, disagree. A group called Flashbots has worked to implements such solutions.

Another solution that would eliminate front-running involves using cryptography to disguise transactions in the mempool and decrypt them once they are written to a block. The Cosmos ecosystem is looking to implement this type of solution in the near future. (There is a discussion of their plan here). That would resolve the problem but it requires changes at the protocol level to implement. It also moves away from the spirit of a public blockchain which may worry some people.

A Solomonic Solution

When there are multiple claimants to a contract payment, what we have is an ownership dispute over tokens. When King Solomon faced an ownership dispute regarding who was the true mother of a baby, he, according to the biblical account, exposed the truth by proposing to cut the baby in two. That worked because the true mother objected while the false one did not. Solomon then gave the baby to the true mother. Game theorists have noted that, had the false mother understood this mechanism, they also would have objected and Solomon would have been none the wiser and would still have to work out what to do with the baby. When designing mechanisms, we need to presume that all people involved understand the mechanism.

What we propose is that transactions be accumulated in batches (as Buterin suggested) and that they form the pool of potential claimants. There are several important features of this:

1. All claimants whose claims are recorded to the blockchain must pay some transaction fee.
2. The legitimate claimant is necessarily part of that pool because, without their initial transaction, others could not have front-run them.
3. The legitimate claimant and illegitimate claimant(s) know who they are.

In other words, this set-up is just like that facing Solomon — everyone else but him knows the truth. The trick of the mechanism is to use that fact to surface the truth.

There is a long history of such mechanisms being proposed by economists going back to John Moore and Rafael Repullo in 1988. They showed that there exists a solution but practically the solution itself depends on characteristics of those involved.

What do we know about those characteristics here? Illegitimate claimants can be presumed to care about profits. What is their expectation of obtaining tokens and is this enough to justify transaction fees they have to pay? So that part is easy — they care about the money.

What about the legitimate claimant? They obviously care about the money too. But they have also done the ‘work’ to expect a payment from the contract. Our conjecture is that they arguably care also about who gets the payment if not them. So we presume that, if they had to choose, they would rather the tokens be burnt (or given to charity) than go to an illegitimate claimant. (Of course, they would rather get the tokens themselves but here we are ranking options 2 and 3 for them). In other words, they are like the true mother who would rather the baby live than die.

Given this, we propose the following mechanism:

1. If there is one claimant in the pool, that claimant gets the tokens and we are done.
2. If there is more than one claimant, we move to a challenge stage.

Now a few things can happen in a challenge stage. In our mechanism we select one claimant at random and ask them (although their response could be pre-programmed) to assert their claim or withdraw. If they assert, then the tokens are burned. If they withdraw, they are removed from the pool and another claimant is chosen at random and is asked the same question.

It is easy to see what happens if there are only two claimants:

1. If the true claimant is chosen, they will assert their claim. Why? By doing so the tokens are burnt rather than going to the other party that they know to be illegitimate. So the true claimant can always be relied upon to assert.
2. If the illegitimate claimant is chosen, they are indifferent as to asserting or not. So they might do either.

Now it looks like that doesn’t resolve anything but that is not where the action matters. The issue is: what does this challenge stage do to the incentives to claim the tokens in the first place?

1. For an illegitimate claimant, they know the true claimant is in the pool and will assert their claim. Thus, there is no possibility that they will ever obtain the tokens. Front-running will not work. Hence they will be spending transaction fees to get into a claimant pool that can never give them tokens.
2. For the legitimate claimant, they know that illegitimate claimants won’t have an incentive to be in the pool, so it will be safe for them to proceed.

In other words, the mechanism here, which can be implemented with just a few lines of code, works.

Now we should stress that it works in equilibrium. If you try this right now, front-running bots will still front-run and so it may take a while for them to be disincentivised of that. We will leave it to others to think about ways of implementing this that might deter bots more quickly. That said, we did try it out and our contract with the Solomonic clause was not front-run on the very same block that an otherwise identical naive contract was (video here).

Conclusion

We believe that the Solomonic mechanism holds great promise to make smart contracts safe. It is simple and easy to implement. It is grounded in solid economic theory. There are some implementation choices but these do not seem to be hard to resolve.