The Development and Future of MEV in the Sui Network

MEV (Maximum Extractable Value) has become a highly discussed topic within the blockchain industry, involving transaction ordering and arbitrage opportunities. To enhance transparency, protect transactions, maintain network health, and reward participants, the Sui network has been purposefully implementing improvement proposals and other mechanisms to guide MEV development on the network.

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

Design Principles and Considerations

Every transaction on the Sui network introduces new information, bringing potential arbitrage opportunities. The MEV ecosystem on Sui is formed through the following mechanisms:

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

The overall priorities of Sui are as follows:

• User trading protection takes precedence over value extraction. Prioritize smaller slippage over larger value extraction. Avoid off-protocol auctions that increase delays and have no exit options.
• Network transparency takes precedence over off-chain transactions with validation nodes or relays.
• Promote competition through priority gas auctions (PGA) to curb garbage behavior that leads to system inefficiencies: Ideally, the optimal strategy for seekers is to send a transaction whose priority fee is determined by the extracted value.
• Encourage the allocation of rewards to participants whose interests align with the ecosystem: verification nodes, stakers, applications, and users.

Transaction Submission

Since transactions modifying the same object are executed in order, clients will compete to increase 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 the quantification of execution:

• Transactions sorted by consensus are processed in the block. Traders compete for priority through gas auctions, which allows for competition both within submissions and between different submissions.
• This is different from market makers on centralized exchanges, where execution priority depends entirely on speed, achieved through low-latency networks and algorithms.
• A higher consensus submission rate reduces the quantification effect, making decentralized trading more efficient, but also narrows the PGA window.
• Currently, the PGA of non-congested objects is most important for 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

• Transactions submitted through soft bundling have a high probability of being included in the same consensus submission as valid bundles. The validity condition for the bundle 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

• This mechanism addresses the potential jitter issue in consensus submission, preventing lower gas price transactions submitted simultaneously from being placed behind higher gas price transactions.
• Two natural sources of jitter in consensus submission: ( The validating nodes submitted are lagging behind several rounds of consensus: transactions submitted by another validating node may be prioritized first. ) The leader of the consensus round has an advantage over other validating nodes in submission.
• This mechanism enhances consensus submission by amplifying transactions that exceed k x RGP(, where k is a system parameter currently set to 5. The gas price is referenced from RGP) to enhance the consensus submission. Transactions with a gas price of n x RGP will be amplified by n times.
• The widespread application of this mechanism will create a more efficient and fair competitive system. It is important to note that this mechanism will not change the basic attributes of the system as viewed from the client 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 searchers with a fair opportunity to compete.

2. Consensus Submission Amplification

As mentioned above, transactions with gas prices exceeding 5 x RGP are submitted to consensus through n verification nodes to amplify consensus submission. Any gas price beyond 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 next round of leader submissions.

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 congestion objects are prioritized by gas price, with lower-priced transactions being delayed and eventually canceled, which limits the longest sequential execution chain for each checkpoint. This is a mechanism known as an object-based local fee market. ( Note that while gas prices may soar when shared objects offer high arbitrage opportunities, other parts of the system remain unchanged. )

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, the gas prices of the lowest price executed transactions and the highest price canceled transactions can be obtained. With this information, clients can determine the necessary gas price to avoid transaction delays with high probability. ( Note that this feature is currently only partially implemented and is expected to be released as part of the SDK within the next two months. )

Publish Trading Information

Every transaction on Sui introduces potential arbitrage opportunities. Consider the lifecycle of a shared object transaction, from the moment it is submitted by the client to when a third party observes its effects:

1. Client submits transaction: The client submits the transaction to an RPC full node ( usually selected by the application ).
2. RPC Node Broadcasting Transactions: The RPC node broadcasts the transaction to the validator nodes, which verify the validity of the transaction and sign it. The RPC node assembles the transaction certificate from the collective signatures of the validator nodes.
3. RPC node broadcasts transaction certificate: The RPC node broadcasts the transaction certificate to the validating nodes.
4. Validator node submits transaction: A deterministically selected validator node submits the transaction to the consensus. The consensus broadcasts the block among the validator nodes, and within 3 consensus rounds, the block containing the transaction will be submitted.
5. Transaction Execution: Transactions are executed on each validating node.
6. Transaction effect certificate is sent back to RPC nodes and clients: The effect certificate after the transaction execution will be returned to the RPC nodes and clients.
7. Generate Checkpoint: Within 1 to 3 consensus rounds, each validator node will form and sign a checkpoint (. The checkpoint is a batch of multiple consensus submissions ).
8. Checkpoint signature broadcast: The checkpoint signature will be broadcast among the validating nodes, and each validating node will form a checkpoint certificate.
9. State Synchronization Protocol Propagation Checkpoints: The state synchronization protocol is responsible for propagating certified checkpoints through a peer-to-peer manner. Typically, each validating node has a direct peer node that does not provide RPC requests—a state synchronization full node, which receives the checkpoints from that validating node.
10. Third-party node downloads checkpoints: The third-party full node connected to the state-synchronized full node obtains checkpoints and downloads their content. At this point, we assume that the third party directly connected to the full node can perform post-processing on transaction effects and respond accordingly.

( Transaction information dissemination before submitting the transaction

As mentioned earlier, Sui has an off-chain auction system for submitting soft bundles. These auctions intercept transaction submissions through an off-chain protocol 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 system is incentivized to protect users' transactions to maintain its business, and therefore employs some auction techniques such as ) bait trading and random delays ### to undermine the financial gains brought by potential sandwich bots.

Clearly, this information dissemination occurs outside of Sui ( between applications and auctions ), it is a voluntary choice of applications and users, providing only speculative information, and cannot guarantee that the original user transactions will be successful.

( consensus block streaming

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

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

This speculative notification has the potential to significantly shorten the latency of transaction propagation, requiring only about 160 milliseconds ) after 2 consensus rounds ###, that is, after the validation nodes submit.

The consensus blockchain streaming project is currently in the design phase, with an improved proposal expected to be released in the next 1 to 2 months.

Protecting User Transactions

User trading needs to be protected from the effects of front-running, whipsawing, and involuntary submission delays.

( External Member Drive

Sui transaction submissions require external member involvement, typically 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 lag 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 during the certificate assembly process of t'.

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

Therefore, external member-driven mechanisms provide a natural front protection, assuming trust in the full node responsible for transaction submission ), as front attacks can be easily detected on the chain. These attacks will be recorded by the client and damage the reputation of the RPC operator ###.

( Fast Track

Sui is currently working on a project to change transaction submissions to a fast path protocol. According to this protocol, user transactions can be submitted to a single validating node, which will use a consensus mechanism to collect and execute transaction certificates. While this greatly improves system efficiency, it also provides validating nodes with the opportunity to obtain user transactions before they are processed.

This risk is purely theoretical, as there is currently no evidence indicating that a front-running attack has occurred on Sui. In the new system, the possibility of front-running is higher, but on the other hand, due to the deterministic understanding of the submitting validator nodes, it is easier to hold them accountable.

The Evolution of MEV in Sui

The MEV ecosystem of Sui is still forming, with new mechanisms set to be launched later this year. Currently, priority gas auctions and consensus amplification define the existing system, while upcoming innovations like time-lock encryption and fast paths 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.

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