Front running is detrimental to users, who end up paying more to the profit of front runners. A few previous solutions have been proposed to solve this issue, though none of them are as effective at preventing front running as Ferveo, as deployed in Anoma. Ferveo is an implementation of a distributed key generation (DKG) coded in Rust and is built upon ground-breaking academic research in cryptography. It allows users to submit encrypted transactions that can only be decrypted if at least ⅔ of the validators (by staked weight) act honestly. As a result, anyone observing the mempool only sees encrypted transactions, thereby fully preventing front running. Ferveo will be deployed as one of the key components of the Anoma protocol.
Front running on Layer1 protocols
Although front running frequently occurs on decentralized exchanges (DEX), it is a general class of problem faced by all current base layer chains. It is detrimental to the vast majority of users, who end up paying more to the profit of front runners. Front running is made possible by the mempool, which stores broadcasted transactions until they are ready to be included in a block. As everyone can inspect the contents of the mempool, everyone can try to front run pending transactions. Considering that block proposers are incentivized to include transactions with the highest transaction fee first, front runners can obtain a higher chance of having their own transaction included in the next block by simply paying a higher fee than the transaction they would like to front-run1.
As there is money to be made, this type of arbitrage has become highly competitive, with bots becoming increasingly complex. As described in this blogpost  by Dan Robinson: “We knew intellectually that these generalized frontrunning bots existed. But until you’ve actually seen them in action, you’re likely to underestimate them.”
While bots competing to front run users (as well as other bots) is bad enough, the situation has been made worse now that block proposers themselves have started to engage in front running. Since block proposers can decide on an arbitrary order of the transactions, they do not have to engage in a bidding competition with front runners or users. They can arrange transactions to favor them or even simply censor transactions that are detrimental to their front running efforts. In blockchains that utilize Nakamoto consensus, they can also perform what is referred to as a time bandit attack , in which the block proposer is incentivized to fork the blockchain to scoop the miner extractable value (MEV) from previously mined blocks .
Preventing front running
As mentioned above, front running is detrimental to users who end up paying more to the profit of front runners. In addition, MEV also threatens the consensus-layer security because of potential time bandit attacks. Therefore, it is necessary to find a solution to these issues, which will likely worsen as time passes.
In the past, a few solutions have been proposed. One potential solution is to simply auction the MEV and use it to subsidize public goods; as Ed Felten  argues, though, this causes several problems and is still prejudicial to users. To use an analogy, it is as if cities, in order to fight crimes, would “auction off the right to mug people and burglarize homes” . A second potential solution would be to use libsubmarine; unfortunately, this method adds block latency as well as an increased amount of fees.
In the next section we introduce Ferveo, which implements a Byzantine-fault-tolerant distributed key generation protocol to solve this problem. It fully prevents front running by first committing encrypted transactions into blocks, which are decrypted after an ordering of the transactions has been committed to.
Ferveo is an implementation of a distributed key generation (DKG) protocol written in Rust. It builds and extends on previous theoretical research  and provides an effective way to protect users against front running.
Ferveo is built upon a broad range of ground-breaking academic research in cryptography. The DKG involves validators handling Verifiable Secret Sharing (VSS) instances in order to recover a distributed key. The VSS used is based on a modified version of ETHDKG , with improved performance (e.g. fast Fourier transform (FFT) based polynomial operations and a modified Kate, Zaverucha, and Goldberg (KZG) polynomial commitment scheme with additional performance improvements, see here and here) and weighted shares. Thus, validators receive private key shares in proportion to their stake. At the time of writing, the curve used is BLS12-381 with fast subgroup checks (as described here). To learn more about the details of Ferveo, please visit this repo.
At a high level, Ferveo is implemented as follows: firstly, validators generate a shared public key in a fashion such that shards of the private key will be generated and distributed among them. Notice that the full private key will not be generated in a single location, as each validator generates their own shard locally, which is a huge advantage, as it does not require any trust assumptions (as no one is in possession of the full private key). Secondly, after the public key is available, users encrypt their transaction to it before broadcasting it to the network, so that only encrypted transactions are present in the mempool. Certain required data, such as transaction fees, is left unencrypted in order to prevent DoS attacks (illustrated with a $ on fig. 1). In contrast, without Ferveo, transactions sent to the mempool are not encrypted, allowing anyone to see and front run them as desired (as illustrated on fig. 2).
Fig 1. Illustration of a user’s transaction being encrypted using the public key before being sent to the mempool. Everything is encrypted except the transaction fee (represented by $). Each validator has a shard of the private key.
Fig. 2 Illustration of a transaction sent to the mempool without using Ferveo. As everyone sees the content of the transactions (as they are not encrypted), anyone can front run them if so desired.
Among the validators, a validator will be randomly selected to propose a block, before picking encrypted transactions from the mempool and including them in a block. Notice that the only information that is not encrypted is information needed for basic transaction validation (fees, fee payer, etc.). The block proposer then creates and commits the block, thereby committing the ordering of the included encrypted transactions. Next, every validator participates in decrypting the transactions present in the committed block, by using their private shard (and the encrypted transactions) to calculate a decryption share (see fig. 3).
Fig. 3 A block proposer selects transactions from the mempool to create a block and commit them. Each validator then uses his private shard and the committed block to calculate a decryption share.
Once the quorum is reached (i.e. at least 2/3 of the validators participated honestly and communicated a valid decryption share), every validator can use the combination of decryption share to decrypt the transactions from the committed block (illustrated on fig. 4). After the transactions in the committed block are revealed, the decrypted transactions are included in the blockchain and subsequently executed.
Fig. 4 Once the quorum is reached, a combination of decryption shares can be created to decrypt the transactions included in the commited block. The decrypted transactions are then executed.
At first, validators –as well as anyone observing the mempool– can only see encrypted transactions, and so cannot front run them. Since each validator has only his private shard of the private key, they cannot decrypt the encrypted transactions. Notice that validators do not communicate their shard of the private key but use it with the committed block to calculate a decryption share.
In order to allow changes to the validator set, such as changes in stake, the distributed key generation protocol is run periodically. At every execution of the protocol, each validator generates a new private shard, with each newly-generated shard independent from the previous one. Thus, this process can be run indefinitely without compromising the security of the system, thereby efficiently preventing front running. Threshold encryption and decryption adds an extra block worth of latency to the transaction execution (as transactions need to be encrypted and then decrypted).
Ferveo on Anoma
Ferveo is implemented as a component of Anoma, a sovereign, proof-of-stake blockchain that enables private, asset-agnostic bartering among any number of parties. Anoma aims to help foster “Self-Sovereign Communities” by providing better access to financial privacy, sovereignty, and coordination technology (read more here and/or visit the website).
How to contribute
Ferveo is currently being developed by Heliax in collaboration with Sikka. If you have any feedback, questions, want to learn more about Ferveo or get involved, visit this repo to find out how you can contribute.
- https://medium.com/@danrobinson/ethereum-is-a-dark-forest-ecc5f0505dff, accessed: 2021-04-23
- Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges, Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov ,Lorenz Breidenbach, Ari Juels, 10 April 2019, accessed: 2021-04-23
- https://medium.com/offchainlabs/mev-auctions-considered-harmful-fa72f61a40ea, accessed: 2021-04-23
- https://www.coindesk.com/miners-front-running-service-theft, accessed: 2021-04-23
- Distributed Key Generation in the Wild, Aniket Kate Yizhou Huang Ian Goldberg, accessed: 2021-04-23
- ETHDKG: Distributed Key Generation with Ethereum Smart Contracts, Philipp Schindler, Aljosha Judmayer, Nicholas Stifter, Edgar Weippl, accessed: 2021-04-23
- The front runner’s and the user’s transaction might even be included in the same block. However, as the front runner pays a higher fee, their transaction should be executed first, thus effectively front running the other transaction. As block proposers are incentivized to include transactions with the highest transaction fee, they usually order them in descending order. Transactions with the highest paying transaction fees are being placed at the top of the block and executed before the lowest ones.↩