MEVless, the solution for MEV

A MEV attack (Maximum Extractable Value attack) is a blockchain behavior that exploits control over the ordering of transactions to gain additional profits by reordering, inserting, or excluding specific transactions.

Author: Wei Wenhou

What is MEV?

A MEV attack (Maximum Extractable Value attack) is a blockchain behavior that exploits control over the ordering of transactions to gain additional profits by reordering, inserting, or excluding specific transactions.

The most common form is the sandwich attack, where attackers insert their own trades before and after the user's buy order, manipulating prices to profit from the arbitrage and causing the user to pay a higher price. Other forms include front-running and liquidation arbitrage.

It's important to note that sandwich attacks and front-running attacks are essentially detrimental to the blockchain ecosystem. They profit at the expense of users' trading profits, unlike triangular arbitrage, which contributes to blockchain liquidity. Sandwich attacks and front-running attacks damage liquidity; when no transactions occur, these attacks disappear. Therefore, sandwich attacks and front-running attacks have a significant negative impact on blockchain (especially DeFi), making them a veritable cancer in the industry.

MEVless Protocol

premise

MEVless is suitable for the following attack scenarios:

• Sandwich attack
• front-running attack

Chains that MEVless is applicable to:
Here, I do not recommend using the MEVless protocol on the L1 public chain layer (especially general-purpose blockchains like ETH and Solana), because MEVless requires specific modifications to the blocks themselves, which are designed specifically for MEV resistance and may not be suitable for other business types (especially those that do not require MEV resistance). I suggest placing MEVless on dedicated DeFi application chains or L2, and then finally settling back on ETH L1.

principle

The principle behind MEVless lies in constraining miners' behavior regarding transaction ordering. Our approach is to prevent miners from seeing the specific transaction content during the ordering process. Furthermore, transactions are ordered without the miners knowing the details, thus preventing even miners from launching MEV attacks. After ordering, this order is published to the public network so that other nodes and users are aware of it. At this point, the transaction order is fixed and incorporated into the block. Subsequent submissions of specific transaction content will then be forced to follow this consensus order, eliminating any room for MEV manipulation.
We divide the blocks on the chain into two types:

• Sequential blocks perform only three tasks: receive transaction hashes, deduct the user's prepayment, and commit to the order of transactions. The interval between sequential blocks can be shorter than that between execution blocks.
• Executing a block is no different from executing a regular block; it simply involves executing transactions according to the order promised in the previous ordered block.

These two types of blocks are produced alternately. For example, after the Genesis Block, the block with the highest odd-numbered block is the ordering block, and the block with the highest even-numbered block is the execution block.

process

1. Block N (sequential block) starts generating blocks.
2. Users send their transaction hash on-chain and pay a prepayment. The prepayment consists of two parts:
   1) Transaction Hash Gas Fee: This is the computational cost used for storing and sorting the transaction hash. This cost is generally fixed and mandatory.
   2) Bonus tip: An extra fee paid by the user to ensure the transaction ranks as high as possible in the order list. This amount is not fixed and may be optional.
3. After receiving the transaction hash, the chain node will complete the following steps:
   • Check if the trading account has enough money to cover the prepayment.
   • Transaction hashes are sorted from highest to lowest based on the amount of the prepayment.
   • Deducting the prepayment amount from the trading account
   • The ordered transactions are stored as commitments in blocks and published on the P2P network.
4. After a user subscribes and queries the hash of their recently issued transaction, which is then committed to a specific sequence number on the blockchain, the user sends the detailed transaction content to the blockchain and the DA (DA is optional).
5. Block production begins at block N+1 (execution block).
6. After receiving the transaction details, the chain node will complete the following steps:
   • Retrieve transaction content from DA (if all txHashes in the previous block have corresponding transaction content, skip this step).
   • Check if the transaction content matches the previously promised ordered txHash; if they do not match, discard the transaction.
   • Execute transactions in the previously agreed order.
   This continues in a cyclical manner.

The role of DA (optional)

In this scenario, once a transaction is sent to the blockchain, a miner might see that the transaction is profitable and maliciously withhold it to prevent it from being recorded on the blockchain, then wait for the user to resend the same transaction to launch another attack.
At this point, not only will the user's transaction profits still be eroded, but they will also have to pay an extra prepayment due to the transaction hash sent earlier.
Therefore, we need DA (such as ETH Blob) to ensure that transactions sent by users are recorded on the blockchain. This way, even if a block-producing node maliciously withholds the transaction, other validator nodes and full nodes will still receive the transaction content.
The transaction is then executed during the subsequent block production process. In this way, to prevent inconsistencies between its state and that of other nodes, the block-producing node is forced to include the transaction in its block.
In this process, DA provides an extra layer of protection for users, but it is not a mandatory option. If users feel that the transaction has been sufficiently propagated to enough full nodes in the P2P network, they can choose not to use DA.
Introducing DA can also prevent the chain's miner group from withholding user transactions through a joint monopoly.

Advantages

1. Compared to encrypted memory pools, the MEVless solution has lower overhead, eliminating the need for CPU and memory-intensive decryption operations.
   Only the transaction hashes are ordered first. A hash is only 32 bytes long, or even shorter. After the ordering is completed, the transmission will have a very light burden on network bandwidth.
2. Compared to PBS, MEVless imposes constraints starting from the transaction ordering right, the source of a MEV attack. Because it blocks attackers' intelligence on transaction information before ordering, it eliminates the prerequisites for an attacker to launch a MEV attack.
3. This facilitates decentralized execution and verifiable results. All steps involved in resisting MEV attacks are hardcoded into the code layer. As long as the full node executes the code according to this code, the result is deterministic, making it very difficult to launch MEV attacks through black-box operations.
4. Unlike privacy mempool nodes, which do not publish the promised transaction order to all nodes for consensus before knowing the specific transaction content, MEVless publishes the promised transaction order to the entire network, allowing all full nodes to reach a consensus before writing it into the block to ensure that transactions are executed in the promised order.

Speculative MEV

We previously discussed standard MEV attacks. However, if attackers cannot see the specific transaction details and cannot target specific transactions, they may resort to another method of attack: speculative MEV attacks.
This attack method is specifically manifested in the following way: In MEVless, an attacker can lay a trap in advance and submit the hash of the transaction to the chain. When the block execution begins and everyone submits their transaction content, the attacker can judge and calculate whether they have any attack benefits based on the transaction content submitted by other users. If they do, they submit their own transaction content; if not, they choose to refuse to submit their own transaction content, thus realizing a sandwich attack.
This approach is difficult to sustain in the MEVless protocol because speculation incurs costs. When an attacker finds it unprofitable and chooses to abandon submitting their transaction, the prepayment they made when submitting the txHash is wasted. Furthermore, the more an attacker tries to rank their transaction higher in the order, the more...
Then the higher the upfront cost he needs to pay.
Then, some readers may wonder, if the block-producing node itself launches the MEV attack, then this prepayment is essentially giving itself to the attacker, completely offsetting the attack cost. In this case, how should we resolve it?

Consensus layer optimization

Indeed, when a block-producing node launches a MEV attack, the prepaid amount is covered by its block reward, so there is no waste of attack costs. Our approach to weaken this speculative method is to make it impossible for miners to predict whether they will be the next block producer, thus drastically increasing their speculative costs. To achieve this, we need to add the following design to the consensus layer:

• Access consensus: proof of burning L1-token. People must burn some L1 tokens (ETH/USDT/USDC) on L1 to gain the right to join the mining group.
• Block consensus: VDF based on L1 hash. We use the hash of the latest block on ETH L1 as input, generate random output values ​​with VDF, and compare the output values ​​of all miners. The node that obtains the maximum value (output value * number of L1 tokens destroyed) will become the block producing node for this round.
• Final consensus: The blocks generated in the above steps are uploaded to ETH L1 in cycles of 3 ETH slots, and the fork with the largest value of (output value * number of L1 tokens destroyed) is selected as the finalized branch. Once finalized on ETH, it cannot be rolled back.

Furthermore, this consensus design is more effective at resisting MEVs as decentralization increases, because the more miners there are, the harder it is for each miner node to predict whether it will be the next block-producing node, and the higher their risk of speculative MEVs.

Disclaimer: As a blockchain information platform, the articles published on this site represent only the personal views of the authors and guests and do not reflect the position of Web3Caff. The information contained in the articles is for reference only and does not constitute any investment advice or offer. Please comply with the relevant laws and regulations of your country or region.