Eigen Seminar｜A Technic Analysis： To Protect Traders from MEV using Layer2 Rollup Solution
The fairness, transparency and verifiability in blockchain lay the foundation for users’ trust, but meanwhile bring many troublesome issues to the whole system. Today let’s dive into one of the tricky issues, MEV or Miner Extractable Value. MEV is a kind of typical Dark Forest which engages in probably every transaction.
In DeFi area, MEV is generally divided into three categories:
1.Good MEV: Mainly happens in arbitrage and liquidation. In arbitrage trading, let’s take an example. A user initiates a large amount of transactions and creates some arbitrage opportunities. An arbitrage bot makes an arbitrage transaction and pulls the price to a normal level. The result is that the bot makes a profit without any harm to the user’s interests. On the other hand, let’s consider the situation in the liquidation business. When the value of the mortgage isWhen lowered, liquidation is triggered if the difference is not filled or the asset is sold. The liquidator can acquire the mortgaged asset at a price between 3% and 5% below the market price.
2.Unfortunate MEV: Mainly happens in sandwiching, front-running, etc. For example, there is token A and token B, a trader can identify a token a victim is about to buy 1000 B with 1000 A and make a trade to push the price up. So the victim can only get 980 B. Then the trader sells the token straight after the victim’s buy order has further increased the price to 1020 A. Front-running involves getting a transaction first in line in the execution queue ahead of a known pending transaction. Front-running bots that scan the network for large orders on decentralized exchanges and submit competing transactions with higher gas fees to get them mined before the victim’s transaction.
3.Disastrous MEV: Brings consensus threat through re-orgs, time-bandit attacks to profit when the block reward is far less than the MEV reward.
There are many solutions to alleviate MEV. In our last post, we briefly introduced the solutions to embracing or eliminating MEV. But in the Layer2 solution, how does the mainstream project tackle MEV? Let’s have a look at MEV protection for Optimsm and Arbitrum.
Optimism Rollup — — MEV Auction
MEV Auction was first proposed by Karl Floersch in early 2020. Coincidentally, Karl Floersch is the CTO of Optimism.
The basic idea of MEVA is to split the two core powers of validators, namely mining and sequencing. Validators still have dictatorial power because there are no rules regarding transaction ordering. But once the transaction is fully finalized, the ordering power belongs to the Sequencer. It turns out that in an MEV Auction (MEVA), the winner of the auction has the right to reorder submitted transactions and insert their own, as long as they do not delay any specific transaction by more than N block. Instead of eliminating MEV, MEVA gives the right to the winner of the auction to make a profit. This market mechanism can greatly reduce network congestion but cannot protect participants or networks from suffering losses by unfortunate MEV.
Why does MEVA bring losses to users and even threaten network security?
Here is the explanation. Validators take part in mining to make profits. Then when the income decreases, the ROI also decreases, and so does the number of miners. As the number of participants decreases, the security of the blockchain network becomes weaker, and the value of the whole blockchain network will decline. So, anyway, we need to assume that the validator’s income remains unchanged.
Suppose a validator gains N coins from mining reward, transaction fees and MEV. For every block, the MEV value is M coins. To keep the validator’s income unchanged, here are two solutions:
- Transfering the MEV value (M coins) to the third-party, the user pays the validator N coins.
- The validator keeps the MEV value (M coins), the user pays the validator N-M coins.
The first solution is an auction scheme. The second one is a general scheme. In terms of the first scheme, ordinary users have to bear the loss that they do not deserve to make up for the losing coins of validators. Then the earnings from M coins fall into the pocket of a very “rich” auctioneer. MEVA proposes to allocate the ordering rights of transactions for a full day at an auction. That gives the winner absolute monopoly. The winner has enormous power to postpone, reorganize and review transactions arbitrarily within such a time span. This centralized control can cause unpredictable losses to the network.
Arbitrum Rollup — — FSS Solution
FSS (Fair Sequencing Service) is raised by Chainlink to prevent MEV. Simply speaking, FSS requires users to send transactions to specialized smart contract SCON.
Oracle nodes monitor the mempool of a target blockchain and pluck transactions from it on behalf of a relying contract SCON, as shown in the figure below.
Specifically, let’s consider how to realize the transaction “Order-Fairness” . The Byzantine fault has lasted for several decades. But it seems like we are all neglecting the “Order-Fairness” issue. Kelkar et.al recently added the “Order-Fairness” dimension to consensus for the first time in a study, which indicated: If most nodes receive transaction (T1) before another transaction(T2), then T1 cannot be placed after T2, which is called Aequitas. The protocol is currently expensive to run. In the future, however, Aequitas will have critical practical importance. FSS determines transaction ordering in the same way as Aequitas. Certainly, it supports more simple protocols like encrypting the transaction directly, Nodes can only be decrypted using threshold signature after ordering.
What is the life cycle of transactions in the FSS framework?
First the user needs to send the transaction to the mempool of the SCON contract, then the augur gets the data in the transaction pool, order according to the time when the transaction reaches the mempool, and finally send the transaction to the SCON contract.
Such use of the mempool is a powerful idea with two significant benefits:
- Legacy compatibility: Users can transmit transactions directly to the blockchain. There’s no need to provide them with special-purpose software for interacting with the oracle network.
- Lower gas costs: When these transactions are eventually mined, they provide an auditable record showing that transactions weren’t censored. By using batching, rollups, or any of a number of other techniques, the network can keep per-transaction gas costs low.
However, Arbitrum still needs to rely on external Oracle Networks to provide services, and Oracle Networks incentives are uncertain.
EigenNetwork — — TEE Solution
EigenNetwork has made double guarantees in alleviating MEV from two aspects: fair sequencer and privacy mempool.
EigenNetwork relies on Layer2 sequencer as others. But being different from other solutions, EigenNetwork runs the Sequencer in Eigen Node in the Eigen TEE. This special design requires all the Sequencers to determine the execution order according to the given code. The whole process cannot be changed. Once the Sequencer publishes batch transactions to Layer1, the transaction order is finalized. This is the fundamentals of fair sequencer of EigenNetwork.
At the same time, since EigenNetwork broadcasts the message only after it has been encrypted to ensure the privacy of mempool. The sequencer cannot directly obtain MEV information. Users can use appropriate solutions as needed.
EigenNetwork adopts the Layer2 Rollup solution to protect traders from MEV. To some extent, EigenNetwork alleviates MEV at the lowest cost. Instead of introducing risty MEVA or complex Oracle Network, Eigen Network aggregates Sequencer to Eigen Node, which is one of the simplest and most reliable ways.
About Eigen Network
If you liked this article and care about Privacy, smash that clap button, then tweet everyone