The Development and Challenges of MEV in the Sui Ecosystem

MEV( Maximum Extractable Value ) has become a hot topic in the blockchain space due to its involvement in transaction ordering and arbitrage opportunities. To enhance transparency, protect transactions, maintain network health, and reward participants, Sui has been purposefully implementing improvement proposals and other mechanisms to regulate MEV activities within its ecosystem.

In addition to the existing mechanisms, Sui also plans to establish more mechanisms to ensure that its core principles guide the development of MEV on the platform.

Design Principles of the Sui MEV Ecosystem

Every transaction on Sui may bring new information and potential profit opportunities. The MEV ecosystem of the platform is mainly formed through the following mechanisms:

• MEV Transaction Submission Mechanism
• MEV Opportunity Release Mechanism
• MEV Revenue Distribution Mechanism
• User Trading Protection Mechanism

The overall priorities of Sui are as follows:

• User trading protection takes precedence over the amount of value extraction. Smaller slippage is prioritized over larger extraction value. Avoid off-chain auctions that increase delays and have no exit options.
• Network transparency takes precedence over off-chain transactions with validators or relayers.
• Promote competition and curb inefficient spam behavior through priority gas auctions (PGA): Ideally, the optimal strategy for seekers is to send a transaction whose priority fee is determined by the value extracted.
• Encourage the distribution of rewards to participants whose interests align with the ecosystem: verification nodes, stakers, applications, and users.

Transaction Submission Mechanism

Due to the sequential execution of transactions modifying the same object, clients will compete to improve their chances of execution order. From a system perspective, PGA is an effective resource allocation method that can prevent abusive behavior while redistributing gas fees among participants.

The key driver of PGA is quantitative execution:

• Transactions sorted by consensus are processed in blocks. Traders compete for priority through gas auctions and can compete between internal or different submissions.
• This is different from market makers in centralized exchanges, where execution priority is entirely dependent on speed, achieved through low-latency networks and algorithms.
• A higher consensus submission rate has reduced the quantitative effect, making decentralized exchanges more efficient, but it has also narrowed the PGA window.
• Currently, the PGA of non-congested objects is most important to the fastest seekers. At a rate of 15 submissions per second on Sui, a 70 millisecond advantage in transaction submission speed could determine whether a transaction can be completed.
• Congestion objects may delay transaction execution, which further amplifies the importance of PGA, as the window for competing transactions may be ten times that of regular consensus submissions.

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

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

   • Transactions submitted through soft bundling have a high probability of being included in the same consensus submission as valid bundles. The validity condition for bundles requires that all transactions have the same gas price.
   • In practice, this mechanism allows for off-chain auctions for the original transaction and its subsequent transactions.

2. Amplifying Priority Transactions through Consensus: SIP-45

• SIP-45 addresses the potential jitter issue in consensus submissions, preventing transactions with lower gas prices submitted at the same time from being queued behind transactions with higher gas prices.
  • SIP-45 amplifies the gas price above k x RGP(, where k is a system parameter currently set to 5. RGP is the reference gas price ) used to enhance consensus submission. Transactions with a gas price of n x RGP will be amplified by n times.
  • The widespread application of SIP-45 will create a more efficient and fair competitive system. It is important to note that SIP-45 will not change the basic properties of the system from the client's perspective: it suppresses spam behavior by providing a more efficient alternative.

Choose the appropriate trading gas price

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

1. Priority gas auction In the consensus submission, transactions modifying the same object are sorted by gas price, providing a fair competition opportunity for searchers.

2. Consensus Submission Amplification The gas price exceeding 5 x RGP transactions is submitted to consensus through n validating nodes to amplify consensus submission. Any gas price that exceeds the amplification threshold will reduce the jitter of inefficient submissions. In practice, an amplification factor of 5 is sufficient to eliminate jitter, while a gas price of 100 x RGP will have a high probability of unlocking the leader submission for the next round.

3. Avoid congestion delays and cancellations Sui controls the transaction rate of modifying the same shared object to limit the wall-clock time for checkpoint execution. Transactions that modify congested objects are sorted by gas price, with lower-priced transactions being delayed and ultimately canceled to limit the longest sequential execution chain for each checkpoint. This is a mechanism known as an object-based local fee market.

The gas price for tracking the execution and cancellation of transactions by full nodes, especially for transactions involving modifications to congestion objects. By analyzing the results of transaction dry runs, one can obtain the gas prices for the lowest price transactions that were executed and the highest price transactions that were canceled. Using this information, clients can determine the required gas price to avoid transaction delays with a high probability.

Trading Information Release

Every transaction on Sui introduces potential profit opportunities. The lifecycle of a shared object transaction, from the moment it is submitted by the client to the time a third party observes its effects, includes the following steps:

1. Client submits transaction
2. RPC Node Broadcast Transaction
3. RPC Node Broadcast Transaction Certificate
4. Verify node submits transaction
5. Trade Execution
6. Transaction effect certificate sent back to RPC node and client
7. Generate Checkpoint
8. Checkpoint signature broadcast
9. Status Synchronization Protocol Propagation Checkpoint
10. Third-party node download checkpoint

Transaction information dissemination before submitting the transaction

Sui has an off-chain auction system for submitting soft bundling, following SIP-19. These auctions intercept transaction submissions through off-chain agreements between the application and the auction system.

This information dissemination assumes that the auction system performs well and can protect users' transactions from potential sandwich attacks. The auction platform is incentivized to protect user transactions to maintain its business, thus adopting some auction techniques such as bait transactions and random delays to undermine the financial gains brought by potential sandwich bots.

( Consensus Block Streaming

In order to achieve low-latency user transaction access, Sui is designing a system for directly streaming consensus blocks. Overall, full nodes will be able to directly subscribe to consensus blocks.

In this way, full nodes can speculatively notify transactions that are likely to be submitted with high probability. The network topology uses a standard open state synchronization peer discovery protocol.

This speculative notification could significantly reduce the latency of transaction propagation to about 160 milliseconds ) after 2 consensus rounds ###, that is, after the verification nodes submit.

The consensus blockchain streaming project is currently in the design phase, and it is expected to release an improvement proposal within the next 1 to 2 months.

User Trading Protection

User transactions need to be protected from the impacts of front-running, back-running, and involuntary submission delays.

( External Member Drive

Sui transaction submission requires external member involvement, usually executed by full nodes.

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

In addition, since the consensus submission of t is decentralized, once t's certificate reaches consensus, it cannot be reliably delayed. Therefore, if t's certificate reaches Sui's consensus before t', t will most likely be settled before t'.

Therefore, external member-driven protection provides a natural preemptive safeguard. Assuming trust in the full node responsible for transaction submission ), front attacks can be easily detected on-chain. These attacks will be logged by the client and damage the reputation of the RPC operator ###.

( Mysticeti Quick Path

Sui is currently working on a project to change transaction submissions to the fast path protocol described in the Mysticeti paper. According to this protocol, user transactions can be submitted to a single validating node, which will leverage Mysticeti to collect and execute transaction certificates. While this significantly enhances system efficiency, it also provides validating nodes with the opportunity to obtain user transactions through pretransactions.

This risk is purely theoretical, as there is currently no evidence to suggest that front-running attacks have occurred on Sui. In the new system, the likelihood of front-running is higher, but on the other hand, due to the deterministic understanding of the submitting validation nodes, it is easier to hold them accountable.

The Future Development of MEV on Sui

The MEV ecosystem of Sui is still in formation, with new mechanisms set to be launched later this year. Currently, priority gas auctions and consensus amplification define the existing system, while upcoming innovations such as time-locked encryption and the Mysticeti fast track will reshape transaction execution and security. As these mechanisms go live, MEV on Sui will continue to evolve, creating a more dynamic and transparent ecosystem.

![Understanding the Current Status and Future of MEV on Sui])https://img-cdn.gateio.im/webp-social/moments-6dae0c442b5d72296728a401858cf5ea.webp###