New Paper: Fairness and front-running — an invitation for feedback
At Vega, we have always had a clear mission to design and create decentralised trading infrastructure that can operate professional-grade markets. A key aspect is ensuring that traders who compete for order book access are treated transparently and fairly, i.e. handling attempts of front-running, rushing, denial of service, or other endeavours to manipulate the sequencing of trading instructions.
The value of gaining a preferential position on the order book is so well known that exchanges legally earn billions of dollars each year by selling physical space next to their servers (colocation) to HFT traders who compete on translating that proximity into value. This creates a grey area where well funded clients compete for preferred access to an exchange, as well as plaguing the centralised models with questions about the trust model. The key thing to note is that nobody currently provides any cryptographic proof of fair access.
As part of our response to this challenge, Klaus Kursawe, Vega’s blockchain researcher, is publishing his paper on Fairness today, entitled ‘Wendy, the good little fairness widget’. In it he explores adding a module to blockchains that supports the concept of relative fairness so that competing transactions may be sequenced under a known and understood protocol, and not subject to a validator’s discretion. We are welcoming comments and discussion around it on our community forum.
Traditionally, fairness in a blockchain has been defined in absolute terms, i.e. once a transaction is seen by a sufficient number of validators, it will be executed in some block, soon. In most commonly used, blockchains, even this level of fairness is only a best-effort (if at all). But while this generally works in practice, there is little guarantee for users on how long a transaction will take to finalise.
Since many decentralised applications don’t have a high reliance on sequencing fairness, generalised smart contract blockchains such as Ethereum were not designed with this in mind. Currently anyone sending an order to an Ethereum based exchange may simply pay a higher gas fee to increase their likelihood of being included in a block. Ethereum miners have full discretion over the sequencing of those orders within the block. It is for this reason that many have commented that fair, decentralised order books are not possible.
As a blockchain that is running an on-chain order book, Vega’s requirements are that if a transaction is sent to the network first, it is also executed first in the blockchain (and therefore Vega order books), without major impacts to latency. This is a non-trivial task even if everything goes right. If traders collaborate with some of the validators to get an advantage, it turns into quite a challenging problem.
Current blockchains largely ignore this challenge of ordering transactions and either provide explicit ways to front-run. Ethereum, for example, is explicitly designed against fairness in the Vega sense. A user who wants their block to be treated with a higher priority can simply offer more gas, and thus get a preferred treatment by the validators, or leave the transaction ordering to the full discretion of the miners, thus rendering the system susceptible to miners extracting value either explicitly (via bribes from traders) or implicitly (by including their own transactions and ordering the block contents to optimise their personal profitability).
This is not a blockchain specific problem, centralised exchanges also provide no trustless guarantees against this kind of extraction of value from traders. This is where we think Vega can add new functionality to advance blockchain technologies for trading. As the exact definition of fairness required for different applications can differ, our end goal is to provide a library of fairness pre-protocols, allowing different contracts or markets on the same blockchain to apply whatever is best for them.
A few approaches have been made to reduce this risk. Commit & reveal schemes ensure the transaction (and potentially even the sender) is encrypted (or similarly protected) while it is being processed by the validators, and only gets decrypted after the block has been scheduled. While no guarantee of relative fairness is given, anyone who wants to cheat has to do so blindly — they can still execute their transactions first, but they can’t react to the content of someone else’s transaction. We think this is a good step (which will be supported in Vega), but it is still insufficient. In a crash scenario, it still allows rogue traders to unfairly rush past others and get privileged execution.
Another approach for leader based protocols is to change leaders fast and, ideally, randomly. While this approach also does not guarantee fairness, it makes it somewhat harder for an attacker to control the unfairness of the blockchain to their advantage.
Definitions of fairness
The precise definition of relative fairness has a number of subtleties. Ideally, one would want a property such as “If all honest parties saw transaction a before transaction b, then a is executed before b”. Unfortunately, we can show that this is impossible to achieve even if only one validator is acting unfairly. The next best approach is to assure that in the above case, a and b are at least scheduled in the same block, which is possible, but comes with the potential that the overall performance might drop dramatically — essentially, in this scenario relative fairness is only possible by allowing the protocol to treat everybody rather poorly.
Vega is proposing a working definition of relative fairness around the use of local time. “If there is a time t such that all honest validators saw a before t and b after t, then a must be scheduled before b”. This is a property we can assure at any time with a minimal impact on performance.
To get the best combination, our current approach is a hybrid of the two. In normal operation, the protocol will assure block fairness. If the network detects that this causes a bottleneck, it temporarily switches to the timed approach (thus sacrificing a little fairness for performance), before switching back once the bottleneck is resolved. However, Vega will ultimately make the level of fairness customisable by marketAs relative fairness only matters within one market, the protocols are designed in a way that relative fairness can be implemented independently and with different approaches for each individual market.
This is where we are asking for feedback: As there is a balance to be found between performance, fairness level and achievability, we would be very interested in additional concepts of relative fairness market makers would like to see, so we can investigate if those concepts can be offered in the Vega blockchain. Please join the discussion or our AMA on Tuesday 7th July 4pm BST / 11am EST / 9am PDT all on our community forum.