Reducing front-running on a DEX
How THORChain implements technology to prevent front-running on a public order book.
THORChain is a decentralized exchange protocol that allows a single public order-book that anyone can view and make trades on.
THORChain validators receive orders, validate them, assemble them into blocks, and then commit them to the blockchain with a minimum of 67% consensus from other validators.
As part of the design of the protocol, THORChain validators are permissionless — that is anyone can become a validator by staking enough Rune and running the required infrastructure. Additionally, to prevent transaction spam, gas is required to pay for transactions and prioritize them into a block. A fee market is created so that people who pay more for gas will have their transactions prioritized first.
Front-running
Front-running refers to the action of a trader observing an incoming trade and then placing their trade ahead of it to benefit from it. Front-running on centralized exchanges is normally not an issue, as only the exchange entity can influence trade order. Whether they do or not, is unknown.
On decentralized exchanges where the orders are public and there are agents or mechanisms that can influence the order of trades, front-running is more of a public issue (as it validators can gain unfair advantage in being able to front-run).
THORChain’s fast block times (less than a second) will largely prevent anyone being able to have the time to observe an order and place a trade in front of it, but it is not completely eliminated.
The are two main situations that cause front-running on THORChain, and this is discussed below.
Fee Market
The first situation that may allow traders to front run is caused by the fee market. A trader wishing to place their order in front of another will pay a higher gas fee. Validators then will choose this trade over others and unknowingly cause a front run.
The partial solution to this is to add a max_gas_fee limit to trades only, so that traders who want to be protected can set the maximum gas allowed. This will remove any ability for another trader to place a trade ahead of theirs.
If all the trades are placed at max_gas_fee limit then the only entity that can then change the order of trades is then the validator preparing the block.
Validators
Validators can choose to re-order transactions in a block before they prepare them for consensus, and they can make the order of transactions in their favor, or in the favor of anyone who bribes them.
There are a number of reasons why the likelihood of a validator front-running is low in THORChain:
- Block Times. Block times on THORChain are pushed to the limits of latency to improve the experience of the exchanges that are built on it, as well as preventing the ability for any validator to have time to observe a trade and front run it. If block times are pushed to (latency * 2), where latency is the average speed that a block can be prepared and committed (500ms), and the block limit is (blocktimes * 2), where a validator is skipped if they can’t produce a block in this time (2 secs), then the front running validator has less than 1 second to observe and position a trade in their favor.
- Block Proposer. The block proposer for a particular block is chosen in a round-robin fashion (currently). In the case that a validator has the intention to front-run, they would have a 1/n (where n is the number of validators in the set) chance of being the validator proposing the block after the trader has placed their order. If there are a large number of validators, then there is an increasingly lower chance that the trader would be front run by the offending validator.
- Trader Control. If any trader is suspicious they are being front-run by a particular validator, they can elect to broadcast their trade to a different validator.
Commit-reveal scheme
Overview
A commit-reveal scheme may help solve the problem of front-running. A trader commits to a trade, encrypted with their key. Since the validator processing it is unable to decipher the trade, they cannot front-run it at that point. Once committed to the blockchain, the trader can then choose to reveal it. The trade then has to be processed in the order that it was committed. Whilst this sounds like it could solve the problem, there is no ability to know if a validator has received a revealed message, and they still retain the option to ignore it and make the trade order in their favour.
The solution to this issue is to encrypt all trades with a key that a Validator must know — their own key. In this case the Validator will be able to decrypt all trades and all participants will be able to verify this. This solution is referred to as “blinded trades”.
Blind Trades with Trade Slots
Each block contains a limited number of trade slots, separated into Blinded Trades and Revealed Trades, with a third section reserved for non-trade transactions. At block N, with Validator X committing the block, traders blind their trades with the public key of a validator who will commit the block at block N + n, being Validator X + n. The current validator, not able to decrypt the trade contents, will instead commit them into the fixed trade slots, assigning each a random trade slot. At block N + n, Validator X + n will be able to decrypt all trades but will be forced to process and commit them in the order that was randomly assigned by Validator X. At the same time, they also receive and commit a fixed number of blinded trades into the Blinded Trade slots for the next block — that they themselves are unable to reveal.
Since Validator X + n is not able to re-arrange the trades, instead only able to decrypt and process them in order, then they are significantly limited in being able to front run.
If they had have committed their own order into block N, then all they can do is pretend to not be able to decrypt their own trades and not process them. However, if a trade is not decrypted and committed at block N + n, then that trade is forever invalidated.
Validator X can attempt to collude with Validator X + n ahead, but there will be very little time to communicate received trades and attempt to arrange ahead of time, and can only work if the colluding Validators are X and X + n. Additionally the public key that is used to encrypt is the same key used to stake, so the relationship between the colluding Validators must be absolute and high-trust. A semi-trusted collusion between two nefarious actors will result in both of them being able to steal each other’s stake — a far higher economic gain than just front-running.
Even if private keys are not shared, this issue can be minimised by shuffling the Validators and their round-robin sequence regularly.
This approach does cause delays in processing trades by n blocks, and also reduces how many trades can be processed in a block, however the advantage is that front running by validators is all but completely removed.
Conclusion
Front-running on decentralized exchanges is perceived to be an issue as there are mechanisms for agents in the ecosystem to influence the order of trades. THORChain implements a max_gas_fee limit for trades, as well as having a deterministic order of block proposers and fast block times to prevent front-running occurring. If a trader is suspicious they are being front-run, they can choose to broadcast their trades to different validators.
A commit-reveal scheme involving blinded trades and trade slots may also solve the front-running problem, but will require further research.
Lastly, and not to be understated, if a trader has verifiably evidence of large-scale front-running, they are likely to broadcast this on out-of-band channels and social media. If the offending validator has any votes delegated to it, then it may lose delegation and drop out of the validator set. This is another reason to create an anti-fragile and permissionless validator set with high churn.
Join the Distribution
For more information or to participate in the distribution, head on over to https://thorchain.org/token.
Be sure to check out our official community channels for updates:
- Github: https://github.com/thorchain
- Medium: https://medium.com/thorchain
- Twitter: https://twitter.com/thorchain_org
- Reddit: https://reddit.com/r/thorchain
- Telegram Community: https://t.me/thorchain_org
- Telegram Announcements: https://t.me/thorchain
