MEV (Maximum Extractable Value) has become an important topic in the blockchain industry as it involves transaction ordering and arbitrage opportunities. To ensure transparency, protect transactions, maintain network health, and reward participants, we have been purposefully implementing Sui Improvement Proposals (SIPs) and other mechanisms to guide MEV on Sui.

In addition to existing mechanisms, we also plan to establish more mechanisms to ensure that our guiding principles shape the evolution of MEV on Sui.

Design Principles and Considerations

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

• Mechanism for submitting MEV transactions
• Mechanism for publishing MEV opportunities
• Mechanism for distributing MEV revenue
• Mechanism for protecting user transactions

Our overall priorities are as follows:

• Protecting user transactions is more important than the amount of value extracted. Prioritize smaller slippage over larger extracted value. Avoid protocols with external auctions that increase latency and have no exit options.
• Network transparency is preferred over offline transactions with validating nodes or relayers.
• Promote competition through priority gas auctions (PGAs) to suppress spam behavior that leads to system inefficiencies: the perfection we pursue makes the dominant strategy for seekers to send a transaction whose priority fee is determined by the extracted value.
• Encourage the distribution of rewards to participants aligned with the ecosystem: validating nodes, stakers, applications, and users.

Transaction Submission

Since transactions modifying the same object are executed in order, clients compete to increase their chances of execution order. From a system perspective, PGAs are an effective resource allocation method that prevents spam while redistributing gas fees among participants.

The key drivers of priority gas auctions are quantifying execution:

• Transactions sorted by consensus are processed in blocks. Traders compete for priority through gas auctions, competing both internally within submissions and between different submissions.
• This differs from CEX market makers, where execution priority is entirely dependent on speed, achieved through low-latency networks and algorithms.
• A higher consensus submission rate reduces the quantization effect, making DEX execution more efficient, but also narrows the PGA window.
• Currently, PGAs for non-congested objects are most important for the fastest seekers. At a Sui rate of 15 submissions per second, a 70-millisecond advantage in transaction submission speed could determine whether a transaction is completed.
• Congested objects may delay transaction execution, further amplifying the importance of PGAs, as the window for competing transactions may be ten times that of regular consensus submissions.

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

1. Soft bundling to submit a batch of transactions: SIP-19

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

• Transactions submitted through soft bundling have a high probability of being included in the same consensus submission as valid bundles. The validity condition for bundling requires all transactions to have the same gas price.
• In practice, this mechanism allows for off-chain auctions for the original transaction and its subsequent transactions, such as those run by Shio (https://www.getshio.com/explorer).

2. Amplifying priority transactions through consensus: SIP-45

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

• SIP-45 addresses potential jitter issues in consensus submissions, preventing transactions with lower gas prices submitted at the same time from being sorted behind those with higher gas prices.
• Two natural sources of jitter in consensus submissions: (1) the submitting validating node lags behind several consensus rounds: transactions submitted by another validating node may be sorted first. (2) The leader of the consensus round has an advantage over other validating nodes in submissions.
• SIP-45 enhances consensus submissions by amplifying gas prices above k x RGP (k is a system parameter currently set to 5, RGP is the reference gas price). Transactions with gas prices of n x RGP will be amplified 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 does not change the fundamental properties of the system from the client's perspective: it suppresses spam behavior by providing a more efficient alternative.

Choosing the Right Transaction Gas Price

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

1. Priority Gas Auctions

Within consensus submissions, transactions modifying the same object are sorted by gas price, providing seekers with a fair competitive opportunity.

2. Consensus Submission Amplification

As mentioned above, transactions with gas prices exceeding 5 x RGP are amplified in consensus by being submitted through n validating nodes. Any gas price exceeding 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's leader submission.

3. Avoiding Congestion Delays and Cancellations

Sui limits the wall clock time for checkpoint execution by controlling the rate of transactions modifying the same shared object. Transactions modifying congested objects are sorted by gas price, with lower-priced transactions being delayed and ultimately canceled to limit the longest sequential execution chain per checkpoint, a mechanism known as an object-based local fee market. (Note that while gas prices may spike when shared objects provide high arbitrage opportunities, other parts of the system remain unchanged.)

Full nodes track the gas prices of executed and canceled transactions, especially those involving modifications to congested objects. The results of transaction dry runs can provide the gas prices of the lowest-priced executed transactions and the highest-priced canceled transactions. Using this information, clients can determine the required 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 in the next two months.)

Publishing Transaction Information

Every transaction on Sui introduces potential profit opportunities. Consider the lifecycle of a shared object transaction, from the moment the client submits it to when a third party observes its effects.

1. Client submits transaction: The client submits the transaction to an RPC full node (usually chosen by the application).
2. RPC node broadcasts transaction: The RPC node broadcasts the transaction to validating nodes, which validate the transaction's validity and sign it. The RPC node assembles the transaction certificate from the collective signatures of the validating nodes.
3. RPC node broadcasts transaction certificate: The RPC node broadcasts the transaction certificate to validating nodes.
4. Validating node submits transaction: A deterministically selected validating node submits the transaction to consensus. The Mysticeti consensus broadcasts blocks among validating nodes, and within 3 consensus rounds, the block containing the transaction will be submitted. Transaction execution: The transaction is executed on each validating node.
5. Transaction effect certificate sent back to RPC node and client: The effect certificate after transaction execution is returned to the RPC node and client.
6. Checkpoint generation: Within 1 to 3 consensus rounds, each validating node forms and signs a checkpoint (a batch of multiple consensus submissions).
7. Checkpoint signature broadcast: The checkpoint signature is broadcast among validating nodes, and each validating node forms a checkpoint certificate.
8. State synchronization protocol propagates checkpoint: The state synchronization protocol is responsible for propagating the certified checkpoint 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 that receives the checkpoint from that validating node.
9. Third-party nodes download checkpoint: Third-party full nodes connected to the state synchronization full node obtain the checkpoint and download its content. At this point, we assume that third parties directly connected to the full node can post-process and respond to the transaction effects.

Transaction Information Propagation Before Submission

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

This information propagation assumes that the auction system performs well and can protect user transactions from potential sandwich attacks. Shio is incentivized to protect user transactions to maintain its business, thus employing some auction techniques (bait transactions, random delays) to weaken the financial gains brought by potential sandwich bots.

Clearly, this information propagation occurs outside of Sui (between applications and auctions) and is a voluntary choice of applications and users, providing speculative information without guaranteeing the success of the original user transaction.

Streaming Consensus Blocks

To achieve low-latency access to user transactions, we are designing a system to stream consensus blocks directly. Overall, full nodes will be able to subscribe directly to consensus blocks.

In this way, full nodes can speculatively notify 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, taking only about 160 milliseconds (2 consensus rounds) after the validating node submits.

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

Protecting User Transactions

User transactions need protection from front-running, sandwiching, and involuntary submission delays.

Externally Driven Members

Sui transaction submissions require externally driven members, 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 submitting full node has poor connectivity with Sui members, the validating node will lag behind t during the certificate assembly process for t'.

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

Thus, externally driven members provide natural front-running protection, assuming trust in the full nodes responsible for transaction submissions (since front-running attacks can be easily detected on-chain, these attacks will be recorded by clients and damage the reputation of RPC operators).

Mysticeti Fast Path

We are 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 utilize Mysticeti to collect and execute transaction certificates. While this significantly improves system efficiency, it also provides validating nodes with the opportunity for front-running user transactions.

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

This risk is purely theoretical, as there is currently no evidence of front-running attacks occurring 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 validating nodes, it is easier to hold them accountable.

Evolution of MEV on Sui

The MEV ecosystem on Sui is still taking shape, with new mechanisms set to be introduced later this year. Currently, priority gas auctions and consensus amplification define the existing system, while upcoming innovations such as time-lock encryption and the Mysticeti fast path will reshape transaction execution and security. As these mechanisms come online, MEV on Sui will continue to evolve, creating a more dynamic and transparent ecosystem.

Note: This content is for general educational and informational purposes only and should not be interpreted or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment, or financial product, and does not constitute financial, legal, or tax advice.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。