MEV SERIES #3. Original blog for @DeFi_LATAM at mirror here
Background:
Broadly speaking, there are two main schools of thought about how the problems of extracting value in distributed networks should be addressed:
- MEVA (MEV Auctions): Accept that the MEV will always be found on the blockchain and implement a democratic auction system so that extraction is not centralized in a few actors.
- MEV Mitigation: Implement mechanisms to minimize MEV extraction as it causes an existential threat to network users. On this sidewalk, they usually argue that MEVA makes the job easier for thieves.
In this blog we explore the mechanism developed by Chainlink and implemented in the future by Arbitrum to deal with the problem of ‘fair-ordering’ in distributed networks, and the possible trade-offs that it faces.
Sequencer in Arbitrum:
Basically, the sequencer is the actor that takes the txs sent by the users in L2, sorts them and then sends the set of those grouped txs to the contract in L1.
Unlike L1, the order of transactions in Arbitrum is determined by a contract in L1 called Inbox. The sequencer is an actor that is given the power to reorder the latest transactions in the Inbox.
In the initial stage of Arbitrum, the sequencer is controlled by Offchain Labs, this means that the company has the power to manipulate the order of transactions in the L2 blocks. The sequencer unilaterally decides how the txs are ordered, and since this power is centralized in a single entity, it could be greatly benefited at the expense of the users. At the beginning, and since the sequencer run by Offchain Labs, the slashing for bad-behavior mechanism is not yet activated.
At first, users will be trusting the centralized sequencer not to act maliciously, e.g. by front-running or censoring the txs it processes.
In the L2, the transactions are not sent to the public mempool, but are concentrated in the rollup contract. In short, what happens is that the power of MEV extraction is transferred from the miners / validators in L1 to the sequencer in L2.
‘Fair Ordering’ in blockchain
Two opposite definitions demarcate the transactions ordering in a P2P system:
1. Send-order-fairness. In a utopian world, the order of transactions in a block would be given by the specific order in which users send their txs. For example, if a user submitted tx1 before another user submitted tx2, tx1 should always be processed before tx2.
Ideally, transactions should sit on the network in the same order that they were created and sent to nodes by the users. But since in a blockchain the system is geographically distributed, such order cannot be captured.
In practice, this scenario is hardly achievable. The nodes from the network can receive user transactions at different times, due to the geographical location of both (users + nodes) and their respective latency. Therefore, they have different views of the state of the blockchain at a specific time. Each node may receive transactions at slightly different times, resulting in a different order.
2. Receive-order-fairness. What ultimately ends up happening is that the order of the transactions is defined by looking at when the majority of the nodes received the transactions individually, locally. This view corresponds to the FIFO (First-In-First-Out) concept.
When enough nodes receive transactions and reach a consensus on their order, this ordering will be the final state. For example, if enough nodes receive a transaction tx1 before another transaction tx2, so tx1 must be ordered before tx2 in the final state.
Fair Sequencing Services, by Chainlink:
The concept that FSS seeks to implement is to ‘decentralize’ the block ordering: instead of having a single centralized entity holding the power to create blocks, the sequencer is replaced by a committee of nodes from Chainlink (DON*), which collectively decide how the txs are ordered in the blocks. The network of oracles in CL collect the transactions and then come to a consensus on their order, instead of a single leader dictating it. There are two ways nodes collect txs:
- Users can submit their txs normally to sit in the public mempool, Chainlink committee nodes watch the mempool and collect txs from there.
- Users can send their txs directly to the committee members, and then they decide how the txs are ordered.
*Decentralize Oracle Network
Users send transactions simultaneously to multiple nodes, and the content of the transactions they send to the CL nodes is encrypted, so that the content of the transaction is revealed only after consensus has been reached about the order of transactions.
Secure causal ordering in FSS:
No node can see the content of the transaction before a consensus is reached on the order of the transaction. The txs are sorted and sequenced before anyone can look at their content. It is valid to clarify that the SCO does not actually specify how the txs themselves should be ordered, it only specifies that once the txs are ordered, they can be decrypted.
How is it implemented?
- The txs are transmitted to the committee in encrypted form under a private key belonging to the node committee, with its corresponding public key
- The committee orders the encrypted txs based on their arrival at the majority of the DON
- After a consensus has been reached on the order, they are decrypted. By the time the contents of the tx are revealed, it’s too late to front-run them.
There will always be primary actors with the power to reorder transactions. What is achieved with this mechanism is to transfer this power. From miners in L1 → centralized sequencer in L2 → Chainlink nodes
The Condorcet paradox
The ‘voting paradox’ is a result of social choice theory which indicates that collective voting preferences do not satisfy the transitivity assumption even though individual preferences do.
The transitivity assumption assumes that: given three alternatives (A, B and C) the transitivity assumption will be met if the following results are achieved:
- A is better than B
- B is better than C
Then, by the transitivity assumption, we can assume that A is better than C.
Applying the paradox to the ordering of the txs, in the following scenario we find 3 nodes: A, B and C. There are 3 users, who send 3 transactions — tx1, tx2 and tx3 — to all nodes.
- Node A receives transactions in the order tx1, tx2, tx3
- Node B receives transactions in the order tx2, tx3, tx1
- Node C receives transactions in the order tx3, tx1, tx2
Now, 2 nodes (A and C) received the tx1 before tx2, 2 nodes (A and B) received tx2 before tx3 and 2 nodes (B and C) received tx3 before tx1. The 3 views of the 3 nodes are different, and paradoxically, they are all correct. There is no single path that satisfies all users since the final order will depend on the time the nodes saw the 3 users’ txs.
A protocol that wants to implement a ‘fair ordering’ mechanism must include tx1 before tx2; tx2 before tx3; and tx3 before tx1 in the final state, a contradictory scenario.
The Impossibility of Fair Ordering
The main argument for the impossibility of fair ordering in blockchain is that different nodes can receive the same transaction from a user at different times of arrival, which leads to different perspectives on the order of transactions.
In a scenario where the consensus threshold must reach ⅔ of the nodes, and the necessary majority of the nodes to reach an agreement are in Europe, an actor or entity with sufficient economic motivation can establish itself geographically (or rent spaces) as close as possible to the miners / validators, or in other words: choose a midpoint between the majority of nodes. What in TradFi is known as ‘Collocation’, is also feasible in blockchain.
If a user sends his tx first, but then this actor/entity located much closer to most nodes sends his tx after the user, his transaction most likely be processed before ours due to latency, and always will run with an advantage that is difficult to refute, and the transactions that they send will always be propagated first over the retail user, making it impossible for the latter to compete.
Users farthest geographically from most nodes will be always at a substantial disadvantage compared to others. Even if your transaction was sent first, it won’t matter.
Since the transactions that a block contains are limited (blocksize), users must have a way to communicate to the miner/sequencer that they want/need their tx to be processed first; consequently, miners must have a way to prioritize some transactions over others. Generally, the miners order the txs in descending order according to the fee bidded by the users.
Currently in Ethereum, to ensure a space in the next block users participate in a kind of ‘auction’ in which they offer the highest gasfee they are willing to pay to the miner so that their transaction is processed and included before the others in the network.
What could potentially happen in practice if a ‘fair ordering’ mechanism is implemented where this ‘auction’ system is discarded, is that the searchers, not being able to bribe the miners / validators to have a priority space in the next block, they end up spamming their txs to the nodes to increase the chances of capturing the MEV in a probabilistic way, resulting in an increase in the cost of gas in the network and affecting the retail user.
Let’s take the example of networks like Polygon or Solana, where although FSS is not implemented, transactions are very cheap and the marginal cost of spamming the network is negligible. The dominant strategy for trying to capture MEV on networks with low gasfee is to spam the chain by sending the same tx over and over again until your tx is finally processed. Although these duplicate txs are reversed, they still consume useless block space, congesting the network and creating a bottleneck between normal users and bots that’s trying to mine MEV. Not so good UX.
So, how can the concept of ‘order fairness’ even exist in web3 without systematically harming some users and greatly benefiting others?
The concept of ‘order-fairness’ in geographically distributed networks is subjective, not a matter of semantics. There is no single truth in the nodes’ view of the state of the blockchain at any given time, as all nodes have different views of the same state, all of which are potentially correct.
FSS as a temporary solution in L2:
Certainly, in a rollup designed like Arbitrum’s, it may be a better implementation to have a distributed network of nodes as proposed by FSS to order transactions in L2, instead of concentrating this power in a single actor run the Offchain Labs.
It is clear that the FSS mechanism is far from being a long-term solution, but rather it can act immediately by patching the centralization problem in a single sequencer, while an idea is developed to decentralize the sequencer in a truly effective way.
It is also true that, when implementing FSS, the only token needed to ‘decentralize’ the sequencer ends up being LINK, without the need for Arbitrum to launch its own token to encourage running a sequencer.
Further reading:
