Friday, June 12, 2015

Front running Decentralized Exchanges: The problem with Augur, Bitshares, Nxt, and Counterparty

Decentralized exchanges have been raved about for a while now in the Bitcoin space and has been crowned as the future saviour of our financial exchange infrastructure (even Mark Karpeles of Mt. Gox fame is talking about it ) . But unfortunately, this is a very hard problem and the current batch of decentralized exchanges have one system breaking issue that makes them entirely unusable. I’m specifically talking about decentralized exchanges where the actual process of matching orders happens on the blockchain. This includes the likes of Nxt, BitShares, Counterparty, and Augur which has a built in limit order book, or some approximation of the limit order book, on the protocol consensus level (Augur is not branded as a decentralized exchange, but you can think of them as an exchange for a specific asset class which is prediction of future events).  All of these platforms allow you to issue assets and trade them on the blockchain. The basic premise  is that you can submit an order to trade like you would submit a transaction to the blockchain, and then the underlying protocol would act as an order book and match up the orders automatically and execute them for you.

This sounds awesome, and if it works it would be a cure for the cancer of incompetent centralized exchanges in the cryptocurrency ecosystem. Unfortunately, the currently available solutions cures the cancer, but also kills the patient.  The basic problem is that the miners can ruthlessly front run you without any repercussion. This is made possible simply by the fact that in a bitcoin derived distributed system, a miner can see all the transaction before they are put into a block, and they are free to put in their own transaction into the block before your transaction happens. For example, let’s say I submit a large order to buy some asset on the Counterparty exchange. This order finds its way to a Bitcoin miner (Counterparty is built on top of the Bitcoin blockchain) who says, “hey, that’s a fat and juicy order that will drive up the price, let’s create our own order to buy the asset and put it in the blockchain before he does”. Then, if the miner is able to mine this particular block, he would have gained an easy risk free profit by utilizing the information in my order.

Bitshare’s Daniel Larimer has a very informative article called “How Bitshares prevents frontrunning ” , which describes the problem better than I can, but unfortunately makes a terrible conclusion. The conclusion of the article is that they can’t prevent frontrunning, so you should just assume that you are being front run. This conclusions seems to be missing the whole entire point of having a limit order book. If you cannot provide a fair and orderly execution, you should just provide an auction system where orders are not automatically executed and users can choose the orders they execute against. Using a limit order book gives a dangerous illusion that the system is fair, when it is inherently rigged in favor of the miners.

Another great feature of the limit order book that is lost upon these decentralized exchanges is that it rewards traders that reveal price information by giving them priority of trade execution. This feature has a lot of social benefits because it encourages people with new price information to disclose it to the rest of the world and improve the price accuracy of the underlying asset. However,  in these decentralized exchanges, the miners are always favoured to have the priority of execution, thus traders have no incentive to reveal price information. This is going to be particularly system breaking for Augur whose main premise is to provide a decentralized prediction system. If traders with information are not given priority of execution, they cannot extract value out of their information because the miners will take all or most of the value by front running them. If traders cannot extract value out of their information, they will simply not use Augur.  Unless they can provide some solution for this problem, my opinion is that this project will be a complete failure.

One argument I’ve heard against this problem is that the situation is not any worse than a centralized exchange. They are kind of right because a centralized exchange can also front run you. But they are wrong because a centralized exchange faces serious damage in its reputation and business if it is revealed that they are front running. Bitcoin hard liners will scoff at this idea but believe it or not, some systems work fine based on reputation and trust. Miners face no such disincentives for front running. These decentralized exchanges have basically anointed the miners to collectively act as a fair exchange, but the miners never agreed to it. The miners are in the business of following consensus rules and getting block rewards, not running an exchange. If they can skim some tasty frontrunning profits on the side in addition to collecting their block rewards, why not?

No practical technical solutions exists to solve this problem currently. The only thing that mitigates front running is enforcing random ordering of transactions within a block, cutting down the possibility of front running to 50% within the same block. But this only mitigates, and does not remove it entirely. A two phase commit and reveal system is another potential solution. This is when orders enter the block encrypted so that the miner cannot see your orders, and then once they are confirmed in the block, the order is decrypted so everyone can resolve the state of the order book. Unfortunately, this suffers from the problem that people can selectively choose not to decrypt their order, thus destroying the integrity of the order book. You could use a trusted arbiter whose job is to encrypt and decrypt orders, instead of having each participant encrypt their own orders. The problem of course is that the arbiter now has the ability to front run instead of the miner, but this is a better proposition because the arbiter’s sole job depends on him being trustworthy.

It may also be possible to use time locked encryption , to turn the two phase commit and reveal system into a one phase commit and reveal system. This would prevent people from selectively decrypting their order, since decryption does not rely on revealing a secret and relies on computation time. But in practice, time locked encryption is very hard to implement since you need access to large computational power, and have to estimate accurately the computational power of your adversaries.

There may be a simple solution, which is economic in nature as opposed to technical. The solution is to pay miners to be fair. If miners are getting a large share of profit from validating exchange related activities, they may be incentivized to play fair and encourage trading to continue at a healthy volume. This can be done by attaching high transaction fees on exchange related transactions or paying miners out of band. Some miners could also choose to establish themselves as a trustworthy entity that specializes in processing exchange related orders (and charge people for it). Now this solution raises many important and difficult questions. How much should the miners be paid for this service? If miners are essentially acting as an exchange, does it subject them to securities and exchange regulations? Should they be subject to third party audits to make sure their system is fair? Is there really any benefit to a decentralized exchange if the system is ultimately reliant on trust? Developers on Augur, Bitshares, Counterparty, and Nxt needs to seriously consider these questions if they want their exchanges to be taken seriously.  

In summary, the current batch of decentralized exchanges have serious problems with no good solutions in sight. The inherent architecture of the blockchain makes the task of frontrunning a decentralized order book trivial as a miner. Anyone using these exchanges for trading purposes should consider the consequences of miners having perfect information against you.

No comments:

Post a Comment