MEV (Maximum extractable value) has become an important topic in the blockchain industry as it relates to transaction ordering and arbitrage opportunities. To ensure transparency, protect transactions, maintain network health, and reward participants, we have been implementing Sui Improvement Proposals (SIPs) and other mechanisms to guide MEV on Sui.
In addition to existing mechanisms, we plan to build more mechanisms to ensure that our high-level principles guide the evolution of MEV on Sui.
Design principles and considerations
Every transaction on Sui introduces new information and potential profit opportunities. The MEV ecosystem on Sui is formed through several mechanisms:
- Mechanism for submitting MEV transactions
- Mechanism for issuing MEV opportunities
- Mechanism for distributing MEV revenue
- Mechanisms to protect user transactions
Our overall priorities are as follows:
- User transaction protection is more important than the amount of extracted value. Prioritize smaller slippage over larger extracted value. Avoid off-protocol auctions that increase latency and have no exit options.
- Network transparency is superior to offline transactions with validating nodes or relayers.
- Promote competition through priority gas auctions (PGA), disincentivizing spamming that causes system inefficiencies: We strive for perfection such that the dominant strategy for searchers is to send a transaction with a priority fee determined by the value extracted.
- Encourages the distribution of rewards to participants that are aligned with the ecosystem: validators, stakers, applications, and users.
Transaction submission
Since transactions that modify the same object are executed sequentially, clients compete to increase their chances of being executed in the order they are executed. From a system perspective, PGA is an efficient way to allocate resources that prevents spam while redistributing gas fees among participants.
The key driver for the priority gas auction is quantitative execution:
- Transactions ordered by consensus are processed in blocks. Transactors compete for priority via gas auctions, both within a submission and between submissions.
- This is different from CEX market makers, where execution priority is entirely based on speed, achieved through low-latency networks and algorithms.
- Higher consensus submission rates reduce the quantization effect, making DEX execution more efficient, but also shrinking the PGA window.
- Currently, the PGA of non-congested objects is most important to the fastest searchers. At a Sui rate of 15 commits per second, a 70 millisecond advantage in transaction commit speed can mean the difference between a deal being completed or not.
- Congested objects can delay transaction execution, further amplifying the importance of PGA since the window for competing transactions can be 10 times larger than regular consensus submission.
There are two mechanisms for directing transactions to a specific upcoming Sui commit:
1. Submitting a batch of transactions via soft bundling: SIP-19
🌟 SIP-19: https://github.com/sui-foundation/sips/blob/main/sips/sip-19.md
- Transactions submitted via soft bundling have a high probability of being included in the same consensus submission as a valid bundle. The bundle validity condition requires that all transactions have the same gas price.
- In practice, this mechanism allows for off-chain auctions to be run for both 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 solves potential jitter issues in consensus submissions, preventing transactions with lower gas prices submitted at the same time from being queued behind transactions with higher gas prices.
- There are two natural sources of jitter in consensus commits: (1) The validator that commits lags behind by a few consensus rounds: a transaction submitted by another validator may be ordered first. (2) The leader of a consensus round has an advantage over other validators in committing.
- SIP-45 enhances consensus commits by amplifying gas prices above kx RGP (k is a system parameter, currently set to 5 in the configuration, and RGP is the reference gas price). Transactions with a gas price of nx RGP will be amplified n times.
- Widespread adoption of SIP-45 will create a more efficient, fair-playing system. It is important to note that SIP-45 does not change the fundamental properties of the system from the client's perspective: it discourages spam by providing a more efficient alternative.
Choose the right transaction gas price
The client should consider the following main factors to determine the gas price for submitting a transaction:
1. Priority gas auction
Within a consensus commit, transactions that modify the same object are sorted by gas price, which provides a fair chance for searchers to compete.
2. Consensus submission amplification
As mentioned above, transactions with gas prices exceeding 5 x RGP are submitted to consensus by n validators to amplify consensus submissions. Any gas price above 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 of the next round.
3. Avoid congestion delays and cancellations
Sui limits the wall clock time of checkpoint execution by controlling the rate of transactions that modify the same shared object. Transactions that modify congested objects are sorted by gas price, and lower-priced transactions are delayed and eventually canceled to limit the longest sequential execution chain of each checkpoint, a mechanism called an object-based local fee market. (Note that although gas prices may spike when shared objects offer high arbitrage opportunities, the rest of the system remains unchanged.)
Full nodes track the gas prices of executed and canceled transactions, especially those involving modifications to congested objects. The results of a transaction dry-run provide access to the gas prices of the lowest-priced transaction executed and the highest-priced transaction canceled. Using this information, clients can determine the required gas price to avoid transaction delays with a 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 transaction information
Every transaction on Sui introduces a potential profit opportunity. Consider the lifecycle of a shared object transaction, from the time it is submitted by the client to the time its effects are observed by a third party.
- Client submits transaction: The client submits the transaction to an RPC full node (usually selected by the application).
- RPC node broadcasts the transaction: The RPC node broadcasts the transaction to the verification node, the verification node verifies the validity of the transaction and signs it, and the RPC node assembles the transaction certificate from the collective signature of the verification node.
- RPC node broadcasts transaction certificate: The RPC node broadcasts the transaction certificate to the verification node.
- Verification node submits transaction: A deterministically selected verification node submits the transaction to consensus. Mysticeti consensus broadcasts blocks between verification nodes, and within 3 consensus rounds, the block containing the transaction will be submitted. Transaction execution: The transaction is executed on each verification node.
- Transaction effect certificate is sent back to RPC node and client: The effect certificate after the transaction is executed will be returned to the RPC node and client.
- Generating checkpoints: Within 1 to 3 consensus rounds, each validator node forms and signs a checkpoint (a checkpoint is a batch of multiple consensus commits).
- Checkpoint signature broadcast: The checkpoint signature will be broadcast among the verification nodes, and each verification node forms a checkpoint certificate.
- State Sync Protocol Propagation Checkpoints: The state sync protocol is responsible for propagating authenticated checkpoints in a peer-to-peer manner. Typically, each validator has a direct peer node that does not provide RPC requests - a state sync full node, which receives the checkpoints of the validator.
- Third-party nodes download checkpoints: A third-party full node connected to a state-sync full node obtains the checkpoint and downloads its contents. At this point, we assume that a third party directly connected to the full node can post-process and react to the transaction effects.
Transaction information propagation before submitting the transaction
As mentioned earlier, Sui has an off-chain auction system for submitting soft bundles, following SIP-19. These auctions intercept transaction submissions through an off-chain protocol between the application and the auction system (such as Shio).
This information propagation assumes that the auction system is well behaved and protects user transactions from potential pinch attacks. Shio is incentivized to protect user transactions to maintain its business, and therefore employs some auction techniques (decoy transactions, random delays) to weaken the financial benefits of potential pinch bots.
Obviously, this information dissemination occurs outside of Sui (between the application and the auction), is a voluntary choice of the application and the user, and only provides speculative information, and there is no guarantee that the original user transaction will be successful.
Consensus block streaming
In order to achieve low-latency access to user transactions, we are designing a system for directly streaming consensus blocks. In general, full nodes will be able to subscribe to consensus blocks directly.
In this way, full nodes can speculatively notify transactions that will be committed with high probability. The network topology uses a standard open state synchronization peer discovery protocol.
This speculative notification has the potential to significantly reduce the latency of transaction propagation to only about 160 milliseconds (2 consensus rounds) after a validating node commits.
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, pinch-hitting, and involuntary submission delays.
External member driven
Sui transaction submission requires external member drive and is usually executed by a full node.
If a validator receives a submission request for transaction t and wishes to initiate a new transaction t', it will fall behind the original member driver in the certificate assembly process. Unless the submitting full node has a poor connection to the Sui member, the validator will fall behind t in the certificate assembly process for t'.
Furthermore, since consensus submission of t is decentralized, once t’s certificate reaches consensus, it cannot be reliably postponed. Therefore, if t’s certificate reaches the consensus of Sui before t’, t will be settled before t’ with high probability.
Therefore, external member drivers provide natural pre-emption protection, assuming trust in the full nodes responsible for transaction submission (since pre-emption attacks can be easily detected on-chain, these attacks will be logged by clients and damage the reputation of the RPC operator).
Mysticeti Fast Path
We are currently working on a project to change transaction submission to the fast-path protocol described in the Mysticeti paper. Under this protocol, user transactions can be submitted to a single validator, which will use Mysticeti to collect and execute transaction certificates. While this greatly improves the efficiency of the system, it also provides an opportunity for the validator to obtain user transactions in advance.
🌟 Mysticeti paper: https://arxiv.org/abs/2310.14821
This risk is purely theoretical, as there is currently no evidence that a front-end attack has occurred on Sui. In the new system, the possibility of front-end transactions is higher, but on the other hand, it is easier to hold the submitting validating nodes accountable due to the deterministic knowledge of their transactions.
Sui's MEV Evolution
Sui's MEV ecosystem is still in the process of forming, with new mechanisms coming later this year. Currently, priority gas auctions and consensus amplification define the current system, while upcoming innovations such as time-lock encryption and Mysticeti fast paths will reshape transaction execution and security. As these mechanisms come online, MEV on Sui will continue to develop, creating a more dynamic and transparent ecosystem.
NOTE: This content is for general educational and informational purposes only and should not be construed 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.
