Understand the current situation and future of MEV on a single article

MEV (Maximum extractable value) has become an important topic in the blockchain industry because it involves transaction sorting and arbitrage opportunities. To ensure transparency, protect transactions, maintain network health and reward participants, we have been implementing Sui Improvement Proposals (SIPs) and other mechanisms in a targeted manner to guide MEVs on Sui.

In addition to existing mechanisms, we plan to establish more mechanisms to ensure that our high-level principles guide the evolution of MEV on Sui.

Design principles and considerations

Every transaction on Sui introduces new information, bringing potential profit opportunities. The MEV ecology on Sui is formed through several mechanisms:

• Mechanism for submitting MEV transactions
• Mechanisms for the opportunity to release MEV
• Mechanism for distributing MEV income
• Mechanisms to protect user transactions

Our overall priorities are as follows:

• User transaction protection is more important than extracting the amount of value. Prioritize smaller slippages over larger extraction value. Avoid extra delays and no exit options for off-protocol auctions.
• Network transparency is better than offline transactions with validation nodes or relayers.
• Promote competition through priority gas auctions (PGAs) and suppress spam behavior that leads to inefficient systems: the perfection we pursue makes the searcher's dominant strategy to send a transaction whose priority fees are determined by the value of the withdrawal.
• Rewards are encouraged to be allocated to the participants aligned with the ecosystem: validator nodes, stakers, applications, and users.

Transaction Submission

Since transactions that modify the same object are executed in sequence, the client competes to increase the chances of their execution order. From a system perspective, PGA is an effective way to allocate resources that prevent spam while redistributing gas fees among participants.

The key driver of priority gas auctions is quantitative execution:

• Transactions sorted by consensus are processed in blocks. Traders compete for priority through gas auctions, either by competing within submissions or among different submissions.
• This is different from CEX market makers, where execution priority is entirely dependent on speed, implemented through low-latency networks and algorithms.
• Higher consensus submission rates reduce quantification effects, making DEX execution more efficient, but also narrows the PGA window.
• Currently, non-congested objects are most important for the fastest searchers. At a 15 submission rate per second, the 70 millisecond transaction submission speed advantage may determine whether a transaction can be achieved.
• Congested objects may delay transaction execution, which further amplifies the importance of PGAs, as the window for competing transactions may be 10 times the usual consensus submission.

There are two mechanisms to direct transactions to specific upcoming Sui submissions:

1. Submit a batch of transactions through soft bundling: SIP-19

🌟 SIP-19: https://github.com/sui-foundation/sips/blob/main/sips/sip-19.md

• Transactions submitted through soft bundles have a high probability of being included in the same consensus commit along with the valid bundles. Bundle validity conditions require that the gas price of all transactions is the same.
• In practice, this mechanism allows off-chain auctions for the original transaction and its subsequent transactions, such as transactions run by Shio (https://www.getshio.com/explorer).

2. Amplify priority transactions through consensus: SIP-45

🌟 SIP-45: https://github.com/sui-foundation/sips/blob/main/sips/sip-45.md

• SIP-45 addresses the potential jitter problem in consensus submissions, avoiding transactions with lower gas prices submitted at the same time being ranked behind transactions with higher gas prices.
• Two natural jitter sources in consensus submissions: (1) The submitted verification node lags behind several consensus rounds: transactions submitted by another verification node may be sorted first. (2) The leader of the consensus round has an advantage over other verification node submissions.
• SIP-45 enhances consensus submissions by amplifying gas prices above kx RGP (k is a system parameter, set to 5 in the current configuration, and RGP is the reference gas price). Trading with gas price nx RGP will be magnified n times.
• The widespread use of SIP-45 will create a more efficient and fair competition system. It should be noted that SIP-45 does not change the basic properties of the system viewed from a client's perspective: it suppresses spam behavior by providing more efficient alternatives.

Choose the right gas price

Clients should consider the following main factors to determine the gas price for submitting transactions:

1. Priority gas auction

Within the consensus submission, modifying transactions for the same object sorted by gas price provides searchers with a chance to compete fairly.

2. Consensus submission and amplification

As mentioned above, transactions with gas prices exceeding 5 x RGP are submitted to the consensus through n verification nodes to amplify consensus submissions. Any gas price that exceeds the amplification threshold will reduce jitter in inefficient submissions. In practice, a magnification factor of 5 is sufficient to eliminate jitter, while a gas price of 100 x RGP will have a high probability of unlocking the next turn of the leader submission.

3. Avoid congestion delays and cancellations

Sui limits the wall clock time for checkpoint execution by controlling the transaction rate of modifying the same shared object. Transactions that modify congested objects are sorted by gas prices, and transactions with lower prices will be postponed and eventually cancelled to limit the longest order of execution chains for each checkpoint, a mechanism called the local fee market for objects. (Note that although gas prices may soar when shared objects provide high arbitrage opportunities, other parts of the system remain the same.)

The full node tracks the gas price for executing and canceling transactions, especially transactions involving modifications to congested objects. The gas price of the executed minimum price transaction and the cancelled maximum price transaction can be obtained through the results of the transaction dry-run. Using this information, the client can determine the required gas price to avoid delays in transactions with high probability. (Note that this feature is only partially implemented at this time and is expected to be released as part of the SDK within the next two months.)

Publish transaction information

Every transaction on Sui introduces potential profit opportunities. Consider the life cycle of a shared object transaction, from the time the client submits to the third party's observation of its effect.

1. Client submits transaction: The client submits the transaction to an RPC full node (usually selected by the application).
2. RPC node broadcasts transactions: The RPC node broadcasts the transaction to the verification node, verifys the validity of the transaction and signs it, and the RPC node assembles the transaction certificate from the collective signature of the verification node.
3. RPC node broadcasts the transaction certificate: The RPC node broadcasts the transaction certificate to the verification node.
4. Verification node submits a transaction: A deterministically selected verification node submits the transaction to consensus. Mysticeti consensus broadcasts blocks between verification nodes, and within 3 consensus rounds, the blocks containing the transaction will be submitted. Transaction Execution: Transactions are executed on each verification node.
5. Transaction effect certificates are sent back to RPC nodes and clients: The effect certificates after transaction execution will be returned to RPC nodes and clients.
6. Generate checkpoints: Each verification node forms and signs a checkpoint (a checkpoint is a batch process of multiple consensus submissions) within 1 to 3 consensus rounds.
7. Checkpoint signature broadcast: The checkpoint signature will be broadcast between verification nodes, and each verification node forms a checkpoint certificate.
8. State Synchronization Propagation Checkpoint: The State Synchronization Propagation Propagation Propagation Propagation of certified checkpoints through point-to-point mode. Typically, each verification node has a direct peer node that does not provide RPC requests—a state synchronization full node that receives checkpoints for that verification node.
9. Third-party node download checkpoint: A third-party full node connected to a state synchronization full node acquires the checkpoint and downloads its content. At this point, we assume that a third party directly connected to the full node can post-process and react to the transaction effect.

**Dissemination of transaction information before submitting a

transaction**

As mentioned earlier, Sui has an off-chain auction system for submitting soft bundles, following SIP-19. These auctions intercept transaction submissions through an off-chain protocol between the application and the auction system (such as Shio).

This information dissemination assumes that the auction system performs well and can protect user transactions from potential pinch attacks. Shio is incentivized to protect user transactions to maintain its business, so it uses some auction tips (bait trading, random delay) to weaken the financial benefits of potential pinched robots.

Obviously, this information dissemination occurs outside Sui (between the application and the auction), and is a voluntary choice of the application and the user, providing only speculative information and cannot guarantee that the original user transaction will be successful.

Consensus block streaming

To achieve low latency user transaction access, we are designing a system that directly streams consensus blocks. Overall, the full node will be able to directly subscribe to the consensus block.

In this way, the full node can speculatively notify transactions that will be submitted with a high probability. Network topology uses a standard open-state synchronous peer discovery protocol.

This speculative notification has the potential to significantly shorten the delay in transaction propagation, which takes only about 160 milliseconds (2 consensus rounds), i.e. after the verification node is submitted.

The consensus block streaming project is currently in the design phase and is expected to release SIPs within the next 1 to 2 months.

Protect user transactions

User transactions need to be protected from pre-trading, pinched and involuntary submission delays.

External member driver

Sui transaction submission requires external member drivers and is usually executed by full nodes.

If a verification node receives a submission request for transaction t and wishes to initiate a new transaction t', it will lag behind the original member driver during the certificate assembly process. Unless the submitted full node has poor connection with Sui members, the verification node will lag behind t during the certificate assembly process of t'.

Furthermore, since the consensus submission of t is decentralized, it cannot be reliably delayed once the certificate of t reaches the consensus. Therefore, if the certificate of t reaches Sui's consensus before t', t will be settled with high probability before t'.

Therefore, external member drivers provide natural preprotection, assuming trust in the full node responsible for transaction submissions (as preprotection attacks can be easily detected on the chain, these attacks will be recorded by the client and damage the reputation of the RPC operator).

Mysticeti Fast Path

We are currently working on a project that changes the transaction submission to the fast path protocol described in the Mysticeti paper. Under this protocol, user transactions can be submitted to a single verification node, which will utilize Mysticeti to collect and execute transaction certificates. Although this greatly improves the system efficiency, it also provides a pre-transaction opportunity for verification nodes to acquire user transactions.

🌟Mysticeti paper: https://arxiv.org/abs/2310.14821

This risk is purely theoretical, as there is currently no evidence that a pre-trade attack occurred on Sui. In the new system, the possibility of pre-transactions is higher, but on the other hand, it is easier to hold them accountable due to the deterministic understanding of the submitted verification nodes.

Sui's MEV evolution

Sui's MEV ecosystem is still in the process of forming, and new mechanisms will be launched later this year. Currently, priority gas auctions and consensus amplification define the current system, while upcoming innovations such as time lock encryption and Mysticeti fast path will reshape transaction execution and security. With the launch of these mechanisms, MEVs on Sui will continue to develop and create a more dynamic and transparent ecosystem.

Note: This content is for general educational and information purposes only and should not be interpreted or relied upon as endorsement or recommendation of the purchase, sale or holding of any assets, investment or financial products, and does not constitute financial, legal or tax advice.