Why lions shouldn’t invest in DeFi Smart Contracts

By Kurt Seifried, Chief Blockchain Officer at Cloud Security Alliance

This article is not legal or investment advice, it covers some aspects of front running in DeFi, and potential security solutions. This article also assumes you have a relatively deep understanding of the following Blockchain/DLT related terms: 100% matches: Block, Blockchain, Consensus, Exchange, Ledger, Mempool, Miner, Mining, Oracle,Token, Transaction

Why did the lion lose at poker? Because he was playing against a cheetah.

Front running in Blockchain/DLT

Front running is defined as someone (usually a stock broker) selling or buying stock before executing a client's transaction. The idea being that the client’s transaction will move the market, or is offering a price that provides an arbitrage opportunity. Front running typically involves elements of insider trading; the front runner often takes advantage of non public information to gain an advantage. The other common aspect is that the person doing the front running has a fiduciary duty to the person being taken advantage of.

Front running in Blockchain/DLT (Distributed Ledger Technology) and crypto currencies / DeFi (Decentralized Finance) is even more complicated than traditional financial markets because of the added complexity of smart contracts, smart assets, and the manner in which transactions are executed and finalized can vary significantly and take an extended time period. Also the two most popular blockchains (Bitcoin and Ethereum) do not have a central controlling authority, they are truly decentralized.

Please note that I’m not even going to talk about flaws in smart contracts (technical or architectural), the exchanges, the platforms running smart contracts and so on (that’s a later article). We’re going to assume a system that is “secure”, and the attacker is simply taking advantage of speed and public knowledge. Also for the rest of this article I’m going to focus on Ethereum for one simple reason: it’s the biggest, most widely used smart contract platform.

Example of how front running works in DeFi

First let’s define how front running typically works in DeFi (I’m going to use DeFi as the catch all term), basically Alice (the victim) wants to take an action (sell something, buy it, whatever) and Eve (the attacker) learns about the action Alice is taking, Eve then does something to gain an advantage. Some of the more common scenarios currently are:

1. Eve learns about a transaction Alice is going to take, and does something before Alice’s transaction can run or possibly before it completes. Eve still needs Alice’s transaction to execute (sometimes referred to as “insertion” front running), for example Eve spots Alice offering a bid on something at above market price, Eve buys the item at current market price and then offers it at Alice’s bid price to make some money

2. Eve learns about a transaction Alice is going to take, and does something before Alice’s transaction can run or possibly before it completes. Eve doesn’t care if Alice’s transaction then executes or not (sometimes referred to as “displacement” front running), for example Eve spots Alice trying to buy a domain name and Eve buys it first.

3. Eve learns about a transaction Alice is going to take, and does something before Alice’s transaction can run or possibly before it completes. Eve then needs Alice’s transaction to be delayed or not execute at all (sometimes referred to as “suppression” front running), a good generic example of this is not available

This list is not complete, but you get the general idea of how it works. Please also note that in the above scenarios the “and does something before Alice’s transaction can run or possibly before it completes” can range from simple to complicated.

Many transactions are relatively simple and can execute within a single block, for example buying an item. But some transactions are more complicated and can take longer to execute, for example a transaction that involves taking a loan, using the borrowed value to purchase something else and then sell it and pay back the original loan back (see ”Flash Loan Attacks” for more information). This can introduce latency and provide more time for an attackers transaction to take place.

The first thing to look into is, how do attackers gain information about transactions before they run?

In most DeFi systems this is trivial: they look at the public MemPool of transactions that have not yet been completed or mined. So the most obvious thing that comes to mind is that transactions need to run fairly.

Unfortunately in most DeFi systems transactions do not run fairly. Many DeFi chains require transactions to have an attached fee such as Ethereum transaction fees, and many also require additional fees attached to the smart contract to ensure that smart contracts don’t take up too much compute resources, such as Ethereum gas.

An attacker that can spot a transaction in advance can simply create a malicious transaction with a much higher transaction fee attached to it, which miners will prefer (because the miner will earn more money). There is very little a victim can do to avoid this, other than by paying higher transaction fees to make attacks more expensive (in other words this is not a sustainable solution).

So if transactions can’t run fairly we could secure them by obfuscating the code and intent of the transaction. But this is far from perfect for one simple reason: the transaction still needs to be executed, an attacker can simply run the transaction (in a sandbox) and see what the effects of it are, even with multiple and difficult to reach code paths most smart contracts are relatively simple and their real purpose can often be determined quickly. A great example of this is the posting “Ethereum is a Dark Forest” which I strongly recommend everyone reads.

So we can’t make transactions run fairly, and we can’t obfuscate them safely if they are mined by public miners, what if we use our own mining pool?

The reality is in most Blockchains and DLTs outside of Bitcoin and Ethereum the network doesn’t have a huge amount of capacity, if your transaction is not time sensitive you can also mine a block with a high degree of success, with 1% of the network work rate you’d have a 39.5% chance of mining at least one block successfully, and that jumps to just over 50% after 69 blocks. It should be noted that you can rent compute power for most blockchains, and this has been done in order to execute 51% attacks against some of the smaller blockchain networks. We’ll cover this specific topic more in our “Rent to Pwn the Blockchain” article (it has graphs/charts and all sorts of exciting numbers).

So if you need to do transactions that are not time sensitive you can do that with 1-2% of the network capacity, and if you need to execute quickly you could in theory rent capacity for short amounts of time to improve your chances. Another solution to this would be “dark Mempools” where the Mempool is not public but is limited to “trusted” miners. It should be noted that research in this area could be done, monitoring the public Mempools and then flagging any transactions in blocks that were not in the public Mempool. This topic will also be covered more in the “Kansas city shuffle” article covering how dark pools and other forms of information secrecy could work in the DeFi world.

Key takeaways:

• Complexity in systems that have value to be captured or extracted will be abused. In other words bank robbers go where the money is.
• Systems that do not have clear regulatory or jurisdictional coverage mean victims will have little if any recourse. Who are you going to call? The Internet police?
• Private addresses / wallets are nearly impossible to track down until they move the assets to known wallets, or move them to a Fiat currency on/off ramp, and even this can be complicated if they move between different assets and blockchains.

Follow this weekly blog series to keep learning about front running.

So this article covered the more “traditional” forms of front running in the DeFi space, in the next article I’m going to cover the information asymmetry and latency scenarios especially as they apply to scenarios with multiple exchanges and distributed exchanges. For example Eve (the attacker) learns some other information that shows an imbalance in the system, which represents an arbitrage opportunity. Perhaps one exchange has an order selling a token at a significantly lower price than another exchange with a buy order at a much higher price, or perhaps a pricing Oracle has spit out a bad quote, or someone has made a typo in an order. Eve then constructs a transaction that takes advantage of this, technically speaking there may not be a victim per se in this situation and it may not actually be front running, but instead simply be a sharp trading strategy. We’ll cover what wallet software and exchanges can do to protect users in our “Fear and loathing in Las Vegas” article.

Related reading:

SoK: Transparent Dishonesty: Front-Running Attacks on Blockchain

https://users.encs.concordia.ca/~clark/papers/2019_wtsc_front.pdf

Ethereum is a Dark Forest

https://medium.com/@danrobinson/ethereum-is-a-dark-forest-ecc5f0505dff

Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges

https://arxiv.org/pdf/1904.05234.pdf