Users only send their txHash to the L2 chain with some advance charge (to prevent DOS attack)
The chain accepts these txHashes, sort them based on the amount of tips, and then make a Tx-Order-commitment and broadcast it to the other chain nodes. Also, user can subscribe this commitment.
When users see the order-commitments, they will send their tx-content to the L2 chain and the DA-layers.
Chain accepts the tx-content from users, and also fetch txs from DA-layers , pack them according to the previously promised order. If the tx-content does not match the previously tx-hash, chain will put them behind the txs which made order-commitment. All promised txs will be sorted before the unpromised txs.
NOTICE: In this way, the chain may deduct tx-content and pretend not to receive it. To prevent this situation. We have to:
i. Decentralise chain node.
ii. Use DA to complete the txs if one node does not accept the txs.
In this case, we call it MEVless protocol, it means you don’t have to trust any group and institution. You do not have to depend on a privacy node, not through MEVA, to protect your transactions from MEV attack. Because all the attackers(besides miners themselves) cannot see your tx-content when it orders. Once the tx-content is packed and executed, it must be packed by the previously commitment, attackers cannot front-run and sandwich attack you.
We have developed some of it and you can see the running effect:
You can see the txHash order-commitment in the above red box and you can try MEV-attacking these txs when they are completed by tx-contents later, then you will find you cannot insert your tx into their order at all.
Does the user need to post the transaction content to the DA layer every time, or is it just a backup solution? If it’s a backup solution, how does the user know that the sequencer won’t include the transaction before the block is mined?
Yes.
The DA is an enhance solution that users can choose to protect their txs further because the decentralization of L2/3 may not higher than L1, the DA can protect users from L2 deduct the tx-content.
It is possible that sequencer miss the tx-content:
The L2 does not accept the user’s tx timely due to some objective reasons such as public network delay
The L2 subjectively accepts the tx but maliciously withheld txs to facilitate MEV attacks.
So, in this case, if L2 can obtain the tx-content from multiple channels as much as possible, it will be more healthy and strong.
Traditionally the main criticism against this type of commit-reveal scheme has been that users get a 2nd choice to cancel their tx by not revealing the hashed data. This likely solves sandwitch attacks but front-running, back running, cex/dex arb are still possible.
You can spam arbitrage tx for high volatility pools and only reveal them if you can make a profitable trade (pool price vs CEX price). You’ll still have to pay a fee all tx even those that are not revealed it’s not hard to still be profitable
If you cancel the tx by not revealing the txHash, your tx will be put behind all the commitment ordered txs. That means you cannot front-running, the back-running will be possible.
MEVless protect all the order-commitment txs from sandwich and front-running.
As for arb and clearing, I believe they are MEVs in a broad sense, and their harm to blockchain is not as bad as the previous ones. So our design is not aimed at arb and clearing.
Addressing DoS attack: A better way may reveal the tip fields of an existing Ethereum transaction and use ZK to verify the validity (sufficient fund) of the existing Ethereum transactions. This avoids introducing a new Tx type and creating the compatibility issue.
DA issue: small Tx content itself may not be efficient using existing DA. E.g., EIP-4844 BLOB is 128KB, while a transfer Tx is about ~100B. A VDF may address the DA problem at the cost of delay.
