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 proactively implementing Sui Improvement Proposals (SIPs) and other mechanisms to guide MEV on Sui.
In addition to the existing mechanisms, we also plan to establish more mechanisms to ensure that our high-level principles guide the evolution of MEV on Sui.
Design Principles and Considerations
Each transaction on Sui introduces new information and brings potential profit opportunities. The MEV ecosystem on Sui is formed through several mechanisms:
- Mechanisms for submitting MEV transactions
- Mechanisms for publishing MEV opportunities
- Mechanisms for distributing MEV revenue
- Mechanisms for protecting user transactions
Our overall priorities are as follows:
- User transaction protection is more important than the amount of value extracted. We prioritize smaller slippage over larger extraction value. Avoid protocols with offline auctions that increase latency and have no exit options.
- Network transparency is more important than off-chain transactions with validators or relayers.
- Promote competition through priority gas auctions (PGA) and suppress spam behavior that leads to system inefficiency: the perfect we seek makes the dominant strategy for searchers to send a transaction whose priority fee is determined by the value extracted.
- Encourage the distribution of rewards to participants aligned with the ecosystem: validators, stakers, applications, and users.
Transaction Submission
Since transactions modifying the same object are executed in order, clients compete to increase their execution order. From the system's perspective, PGA is an effective resource allocation mechanism that can prevent spam while redistributing gas fees among participants.
The key drivers of the priority gas auction are quantified execution:
- Transactions ordered by consensus are processed in blocks. Traders compete for priority through gas auctions, both within a submission and across different submissions.
- This is different from CEX market makers, where execution priority is entirely dependent on speed, achieved through low-latency networks and algorithms.
- Higher consensus submission rates reduce the quantification effect, making DEX execution more efficient, but also shrink the PGA window.
- Currently, PGA for non-congested objects is most important for the fastest searchers. At Sui's 15 TPS rate, a 70ms transaction submission speed advantage may determine whether a transaction is executed.
- Congested objects may delay transaction execution, further amplifying the importance of PGA, as the competition window for transactions may be 10 times that of regular consensus submission.
There are two mechanisms to guide transactions to specific upcoming Sui submissions:
1. Soft-bundling submissions of 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 the effective bundle. The bundle validity condition 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. Consensus amplification of priority transactions: SIP-45
? SIP-45: https://github.com/sui-foundation/sips/blob/main/sips/sip-45.md
- SIP-45 addresses potential jitter in consensus submissions, preventing lower gas price transactions submitted at the same time from being ordered after higher gas price transactions.
- The two natural sources of jitter in consensus submissions are: (1) the submitting validators lag behind by a few consensus rounds: transactions submitted by another validator may be ordered first. (2) the consensus round leader has an advantage over other validators in submitting.
- SIP-45 amplifies gas prices above k x RGP (k is a system parameter, currently set to 5, and RGP is the reference gas price) to enhance consensus submission. Transactions with gas price of n x RGP will be amplified n times.
- Widespread adoption of SIP-45 will create a more efficient and fair competitive system. 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 Appropriate Transaction Gas Price
Clients should consider the following key factors to determine the gas price for submitting transactions:
1. Priority Gas Auction
Within consensus submission, transactions modifying the same object are ordered by gas price, providing fair competition opportunities for searchers.
2. Consensus Submission Amplification
As mentioned above, transactions with gas price above 5 x RGP are amplified in consensus submission through n validator submissions. 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 has a high probability of unlocking the next round's leader submission.
3. Avoiding Congestion Delays and Cancellations
Sui limits the wall clock time of checkpoint execution by controlling the rate of transactions modifying the same shared object. Transactions modifying congested objects are ordered by gas price, with lower-priced transactions being delayed and eventually canceled to limit the maximum sequential execution chain per checkpoint, a mechanism known as the 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 unaffected.)
Full nodes track the gas prices of executed and canceled transactions, especially those involving modifications to congested objects. By performing transaction dry-runs, they can obtain 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 a high probability of transaction delay.
Publishing Transaction Information
Every transaction on Sui introduces potential profit opportunities. Consider the lifecycle of a shared object transaction, from the time 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 (typically chosen by the application).
- RPC node broadcasts transaction: The RPC node broadcasts the transaction to the validators, who verify the transaction's validity and sign it, and the RPC node assembles the transaction certificate from the collective validator signatures.
- RPC node broadcasts transaction certificate: The RPC node broadcasts the transaction certificate to the validators.
- Validators submit transaction: A deterministically selected validator submits the transaction to consensus. The Mysticeti consensus broadcasts the block among the validators, and within 3 consensus rounds, the block containing the transaction will be committed. Transaction execution: The transaction is executed on each validator.
- Execution effect certificate sent back to RPC node and client: The certificate of the transaction's execution effects is returned to the RPC node and the client.
- Checkpoint generation: Within 1 to 3 consensus rounds, each validator forms and signs a checkpoint (a batch of consensus submissions).
- Checkpoint signature broadcast: The checkpoint signatures are broadcast among the validators, and each validator forms a checkpoint certificate.
- State sync protocol propagates checkpoints: The state sync protocol is responsible for propagating the certified checkpoints peer-to-peer. Typically, each validator has a direct peer node - a state sync full node - that receives the checkpoints from that validator.
- Third-party nodes download checkpoints: Third-party full nodes connected to the state sync full nodes acquire the checkpoints and download their contents. At this point, we assume that third-party nodes directly connected to the full nodes can post-process and react to the transaction effects.
Pre-submission Transaction Information Propagation
As mentioned earlier, Sui has an off-chain auction system for submitting soft-bundled transactions, following SIP-19. These auctions are intercepted by a protocol between the application and the auction system (e.g., Shio).
This information propagation assumes that the auction system performs well and is able to protect user transactions from potential front-running attacks. Shio is incentivized to protect user transactions to maintain its business, and thus employs some auction tactics (decoy transactions, random delays) to diminish the financial gains of potential front-running bots.
Clearly, this information dissemination occurs outside of Sui (between applications and auctions), and is a voluntary choice of applications and users, providing only speculative information without guaranteeing the success of the original user transactions.
Consensus Block Streaming
To achieve low-latency user transaction access, we are designing a system to directly stream consensus blocks. In general, 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 committed 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, taking only about 160 milliseconds (2 consensus rounds) after the validator node submits.
The Consensus Block Streaming project is currently in the design phase and is expected to release a SIP within the next 1-2 months.
Protecting User Transactions
User transactions need to be protected from front-running, sandwich attacks, and involuntary submission delays.
Externally Member-Driven
Sui transaction submission requires external member-driven, typically executed by full nodes.
If a validator node receives a submission request for transaction t and wishes to initiate a new transaction t', it will lag behind the original member-driven program in the certificate assembly process. Unless the submitting full node is poorly connected to the Sui members, the validator node will lag behind in the certificate assembly process for t'.
Furthermore, since the consensus commitment of t is decentralized, once the certificate of t reaches consensus, it cannot be reliably delayed. Therefore, if the certificate of t reaches Sui's consensus before t', t will likely be settled before t' with high probability.
Thus, external member-driven provides natural front-running protection, assuming trust in the full node responsible for transaction submission (as front-running attacks can be easily detected on-chain and will damage the reputation of the RPC operator).
Mysticeti Fast Path
We are currently working on a project to change the transaction submission to the fast path protocol described in the Mysticeti paper. According to this protocol, user transactions can be submitted to a single validator node, which will use Mysticeti to collect and execute the transaction certificates. While this significantly improves the efficiency of the system, it also provides an opportunity for validator nodes to front-run 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, it is easier to hold the submitting validators accountable due to the deterministic understanding of them.
The Evolution of MEV on Sui
The MEV ecosystem on Sui is still in formation, and new mechanisms will be introduced later this year. Currently, priority gas auctions and consensus amplification define the current system, while upcoming innovations such as time-lock encryption and the Mysticeti fast path will reshape transaction execution and security. As these mechanisms are deployed, 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 purchase, sell, or hold any asset, investment, or financial product, and does not constitute financial, legal, or tax advice.
