Read the current situation and future of MEV on Sui

Explain in detail how MEV operates on Sui-the mechanisms for transaction sequencing, protection and fair competition.

MEV (Maximum extractable value) has become an important topic in the blockchain industry because it involves transaction sequencing and arbitrage opportunities.To ensure transparency, protect transactions, maintain online health and reward participants, we have been implementing Sui Improvement Proposals (SIPs) and other mechanisms in a targeted manner to guide MEVs on Sui.

In addition to existing mechanisms, we plan to establish 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 brings 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 allocating MEV revenue
• Mechanisms to protect user transactions

Our overall priorities are as follows:

• User transaction protection is more important than the amount of value extracted. Prioritize smaller slip points over larger extraction values. Avoid out-of-agreement auctions that add delays and have no opt-out options.
• Network transparency is better than offline transactions with verification nodes or relays.
• Promote competition through priority gas auctions (PGA) and curb spam that leads to system inefficiencies: Our pursuit of perfection makes searchers ‘dominant strategy to send a transaction, with priority fees determined by the value extracted.
• Encourage the allocation of rewards to ecologically aligned participants: verification nodes, pledgers, applications, and users.

transaction submission

Because transactions that modify the same object are executed sequentially, clients compete to increase their chances of execution order. From a systems perspective, PGA is an effective resource allocation method that prevents spam while redistributing gas fees among participants.

The key driver for priority gas auctions is quantitative execution:

• Transactions ordered by consensus are processed in blocks. Traders compete for priority through gas auctions, both within submissions and between different submissions.
• This is different from CEX market makers, where execution priority depends entirely on speed and is achieved through low-latency networks and algorithms.
• Higher consensus submission rates reduce the quantitative effect and make DEX execution more efficient, but also reduce the PGA window.
• Currently, the PGA of non-congested objects is the most important to the fastest searchers. At a Sui rate of 15 submissions per second, a 70-millisecond transaction submission speed advantage may determine whether a transaction can be completed.
• Congestion objects can delay transaction execution, further amplifying the importance of the PGA, as the window for competing transactions can be 10 times larger than regular consensus submissions.

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

1. Submit a batch of transactions through soft bundling: 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 valid bundling. Bundling validity conditions require the same gas price for all transactions.
• In practice, this mechanism allows off-chain auctions for the original transaction and its subsequent transactions, such as those run by Shio (https://www.getshio.com/explorer).

2. Amplify 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 ranked behind transactions with higher gas prices.
• There are two natural sources of jitter in consensus submissions: (1) The submitted verification node lags several consensus rounds: transactions submitted by another verification node may be sorted first. (2) The leader of the consensus round has an advantage over other verification node submissions.
• SIP-45 enhances consensus submission by amplifying gas prices higher than k x RGP (k is a system parameter, set to 5 in the current configuration, and RGP is the reference gas price). Transactions with a gas price of n x RGP will be amplified by n times.
• The widespread adoption of SIP-45 will create a more efficient and fair competition system. It should be noted that SIP-45 does not change the basic attributes of the system from a client perspective: It suppresses spam behavior by providing more efficient alternatives.

Choose the right trading gas price

Clients should consider the following main factors to determine the gas price at which to submit transactions:

1. Priority gas auction

Within consensus submissions, transactions that modify the same object are sorted by gas price, which provides searchers with a level playing field.

2. Consensus submission is enlarged

As mentioned above, transactions with gas prices above 5 x RGP amplify consensus submission by submitting it to the consensus by n verification nodes. Any gas price that exceeds the amplification threshold reduces jitter from inefficient submissions. In practice, a amplification factor of 5 is enough to eliminate jitter, and a gas price of 100x RGP will have a high probability of unlocking the next round of leader submissions.

3. Avoid congestion, postponement and cancellations

Sui limits the wall clock time for checkpoint execution by controlling the transaction rate at which the same shared object is modified. Transactions that modify congested objects are sorted by gas price, and lower-priced transactions will be deferred and eventually cancelled to limit the longest sequential execution chain per checkpoint, a mechanism known as object-based local fee markets. (Note that although gas prices may soar when shared objects provide high arbitrage opportunities, other parts of the system remain the same.)

The full node tracks the gas price for executing and canceling transactions, especially those involving modifying congested objects. Through the results of the transaction dry-run, you can obtain the gas prices of the lowest price transactions executed and the highest price transactions cancelled. Using this information, the client can determine the required gas price and avoid delay in transactions with a 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.)

Publish transaction information

Every transaction on Sui introduces potential profit opportunities. Consider the life cycle of a shared object transaction, from the time the client submits to the time the effects are observed by a third party.

1. Client submits transactions: The client submits transactions to an RPC full node (usually selected by the application).
2. RPC node broadcasts transactions: The RPC node broadcasts the transaction to the verification node, which verifies the validity of the transaction and signs it. The RPC node assembles the transaction certificate from the verification node’s collective signature.
3. RPC node broadcasts transaction certificate: RPC node broadcasts transaction certificate to verification node.
4. Verification node submits transactions: A deterministically selected verification node submits transactions to consensus. Mysticeti consensus broadcasts blocks between verification nodes, and within 3 consensus rounds, blocks containing the transaction are submitted. Transaction execution: Transactions are executed on each verification node.
5. The transaction effectiveness certificate is sent back to the RPC node and client: the effectiveness certificate after the transaction is executed is returned to the RPC node and client.
6. Generating checkpoints: In 1 to 3 consensus rounds, each verification node forms and signs a checkpoint (a checkpoint is a batch of multiple consensus submissions).
7. Checkpoint signature broadcast: Checkpoint signatures will be broadcast between verification nodes, each of which forms a checkpoint certificate.
8. State synchronization protocol propagates checkpoints: The state synchronization protocol is responsible for propagating authenticated checkpoints in a point-to-point manner. Typically, each verification node has a direct peer node that does not provide RPC requests-a state-synchronized full node that receives checkpoints from that verification node.
9. Third-party node download checkpoints: Third-party full nodes connected to the status synchronization full node obtain checkpoints and download their content. At this point, we assume that a third party directly connected to all nodes can post-process and react to the transaction effect.

Dissemination of transaction information before submitting transaction

As mentioned earlier, Sui has an offline auction system for submitting soft bundles, which follows SIP-19. These auctions intercept transaction submissions through off-chain protocols between the application and the auction system such as Shio.

This kind of information dissemination assumes that the auction system performs well and protects user transactions from potential pinch-in attacks. Shio is incentivized to protect user transactions to keep its business, so it uses some auction techniques (bait transactions, random delays) to undercut the financial benefits of potential pinch-in robots.

Obviously, this kind of information spread occurs outside Sui (between the application and the auction) and is a voluntary choice by the application and the user. It only provides speculative information and does not guarantee that the original user transaction will be successful.

Consensus block streaming

In order to achieve low-latency user transaction access, we are designing a system that directly streams consensus blocks. Overall, full nodes will be able to directly subscribe to consensus blocks.

In this way, full nodes can speculatively notify transactions that will be submitted with a high probability. The network topology uses the standard open-state synchronous peer discovery protocol.

This speculative notification has the potential to significantly reduce the delay in transaction propagation, which takes only about 160 milliseconds (2 consensus rounds), that is, after the verification node commits.

The consensus block streaming project is currently in the design stage and is expected to be released in the next 1 to 2 months.

Protect user transactions

User transactions need to be protected from pre-trading, cross-cutting, and involuntary submission delays.

External member driven

Sui transaction submission requires external member driving and is usually performed by all nodes.

If a verification node receives a commit request for transaction t and wants to start a new transaction t, it will lag behind the original member driver during the certificate assembly process. Unless the submitted full node has poor connections to Sui members, the verification node will lag behind t in the certificate assembly process for t.

In addition, since consensus submission for t is decentralized, once t’s certificate reaches consensus, it cannot be reliably postponed. Therefore, if t’s certificate reaches Sui’s consensus before t, t will be settled before t with a high probability.

Therefore, external member drivers provide natural pre-protection, assuming trust in the entire node responsible for transaction submission (since pre-emptive attacks can be easily detected on the chain, these attacks will be logged by the client and damage the reputation of the RPC operator).

Mysticeti Fast Path

We are currently working on a project to change transaction submissions to the fast-path protocol described in Mysticeti’s paper. Under the protocol, user transactions can be submitted to a single verification node, which will utilize Mysticeti to collect and execute transaction certificates. Although this greatly improves system efficiency, it also provides verification nodes with the opportunity to obtain user transactions in advance.

🌟Mysticeti paper: arxiv.org/abs/2310.14821

This risk is purely theoretical, as there is currently no evidence that a pre-transaction attack has occurred on Sui. In the new system, front-end transactions are more likely, but on the other hand, it is easier to hold them accountable due to the deterministic knowledge of the submitting verification node.

Sui’s MEV evolution

Sui’s MEV ecosystem is still taking shape, and a new mechanism will be launched 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 Path will reshape transaction execution and security. As these mechanisms come online, MEVs on Sui will continue to evolve, creating a more dynamic and transparent ecosystem.

Note: This content is for general educational and information purposes only and should not be interpreted or relied on as an endorsement or recommendation for the purchase, sale or holding of any assets, investments or financial products, and does not constitute financial, legal or tax advice.