Detailed Explanation of How MEV Operates on Sui - Mechanisms for Transaction Ordering, Protection, and Fair Competition.
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 direct 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:
User transaction protection is more important than the amount of extractable value. Prioritize smaller slippage over larger extractable value. Avoid increasing delays and protocols with no exit options for external auctions.
Network transparency is preferred over offline transactions with validating nodes or relayers.
Promote competition through priority gas auctions (PGA), suppressing 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 reward distribution 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 the system's perspective, PGA is an effective resource allocation method that prevents spam while redistributing gas fees among participants.
The key driver of priority gas auctions is quantified 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, PGA for non-congested objects is most important for the fastest seekers. At Sui's 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 PGA, 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 validating node submitting is lagging 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 in the current configuration, 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 more efficient alternatives.
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 submissions 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 for each checkpoint, a mechanism referred to as 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.
Client submits transaction: The client submits the transaction to an RPC full node (usually chosen by the application).
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.
RPC node broadcasts transaction certificate: The RPC node broadcasts the transaction certificate to validating nodes.
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.
Transaction effect certificate sent back to RPC node and client: The effect certificate after transaction execution is returned to the RPC node and client.
Checkpoint generation: Within 1 to 3 consensus rounds, each validating node forms and signs a checkpoint (a batch of multiple consensus submissions).
Checkpoint signature broadcast: The checkpoint signature is broadcast among validating nodes, and each validating node forms a checkpoint certificate.
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.
Third-party node downloads checkpoint: A third-party full node connected to the state synchronization full node retrieves the checkpoint and downloads its content. At this point, we assume that the third party directly connected to the full node can post-process the transaction effects and respond.
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 directly stream 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 has the potential to significantly reduce transaction propagation delays to 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 a SIP in the next 1 to 2 months.
Protecting User Transactions
User transactions need protection from front-running, sandwich attacks, and involuntary submission delays.
External Member Driven
Sui transaction submissions require external member-driven processes, 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'.
Moreover, since the consensus submission of t is decentralized, once the certificate for t reaches consensus, it cannot be reliably delayed. Therefore, if the certificate for t arrives at Sui's consensus before t', t will most likely be settled before t'.
Thus, external member-driven processes provide natural front-running protection, assuming trust in the full nodes responsible for transaction submissions (as 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 opportunities 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 forming, 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.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
