SIP-45: Prioritized Transaction Submission

[shio-coder]

This PR creates a new SIP draft, that intends to enable effective prioritized transaction submission.

[Iamknownasfesal]

Looks like this SIP could enable sandwich attacks on Sui?

[shio-coder]

Looks like this SIP could enable sandwich attacks on Sui?

No. This cannot be used to carry out sandwich attacks as there is no public mempool on Sui.

[sblackshear]

I think this is not widely known/understood, and making gas prices work more like folks would intuitively expect is valuable.

[sblackshear]

I was wondering if 1T MIST is big enough to express a very strong preference, and convinced myself that the answer is "yes". Sharing my reasoning in case other readers are wondering the same thing

• 1T MIST = 1000 SUI
• The smallest computation unit gas bucket, is 100,000, so even on the cheapest possible tx a submitter could choose to pay up to 1M SUI (which seems more than good enough to express the strongest possible preference)

[NaitsabesMue]

Unclear why consensus bandwidth is expected to increase by 12%. Removing latency jitters could reduce effective throughput by allowing more duplicates. Also, high-priority transactions may increase object dependencies, reducing execution throughput and, by feedback, consensus throughput. While this issue likely existed before, the proposed changes make users pay more.

[shio-coder]

We assumed most on-chain txs are not competitive in nature (meaning that they are not competing to land before the others do). For those txs, having priority does not change anything.

For competitive txs, once there is priority, the number of txs will be reduced (actors will seek paying higher prices rather than sending more, because simply sending more does not work anymore) - this may slightly increase consensus bandwidth required.

The proposal naturally works with the object congestion, since the congestion control algorithm prefers to select txs with higher gas prices. When there is a congestion (this often but not always means there is a competition), txs with higher gas price win. In this sense, high-priority txs do not lead to congestion, market does. For users, this brings more fairness - whoever pays more gets sequenced first, if there is a competition.

[NaitsabesMue]

Iiuc the increase is in effective throughput, it is expected to come from fewer transaction duplicates for these high-priority transactions. If I am willing to pay a high price, why should I not send my transaction to more than 1 validator, say K? It would increase my chances of getting into the current checkpoint. Then, in the worst case, we have K copies of my transaction, possibly decreasing the effective throughput.

[shio-coder]

Yes. With higher gas prices, N gets bigger, meaning more 'copies' of the transaction will be sent to consensus.

The term 'consensus bandwidth' from the SIP actually refers to network bandwidth (or put it another way, network traffic), not the capacity for consensus to process txs.

The data is to show that despite more copies will be sent over the network, the percentage of competitive txs is small, which do not lead to a significant increase overall.

[NaitsabesMue]

Another way to guarantee fast transaction submission is for validators to bypass latency jitter. Afaik, jitter isn’t verifiable or enforced—validators can take off-chain tips and prioritize transactions. With this SIP, while off-chain prioritization can still occur, transaction reordering (post-consensus) ensures that gas price determines final order. This mitigates the off-chain fee market by prioritizing those who pay the correct gas price.

[shio-coder]

Yes. The choice of validator also matters in this off-chain fee market case.
For example, cooperating with a validator in Asia would unlikely lead to desired result.
Some other factors may also have impact on this, such as leader schedule and the timing of block proposing.

[poelzi]

Looks like this SIP could enable sandwich attacks on Sui?

No. This cannot be used to carry out sandwich attacks as there is no public mempool on Sui.

You don't need a public mempool. All professional (solana) sniper bots run a validator. In Sui, you run a validator and listen to the RPC nodes to request for a transaction signature. You send your attack transaction with higher fees and then slightly delayed the signature. You would need 1/3+x stake to guarantee success with the delay. But higher fees could be enough.
Does this attack vector work ?

[shio-coder]

Looks like this SIP could enable sandwich attacks on Sui?

No. This cannot be used to carry out sandwich attacks as there is no public mempool on Sui.

You don't need a public mempool. All professional (solana) sniper bots run a validator. In Sui, you run a validator and listen to the RPC nodes to request for a transaction signature. You send your attack transaction with higher fees and then slightly delayed the signature. You would need 1/3+x stake to guarantee success with the delay. But higher fees could be enough. Does this attack vector work ?

It will theoretically work. It will even work without priority fees.
Should such attempt exists, the role that priority plays is to provide a somewhat safer way to submit frontruns (comparing to without removing jitters, frontrun could randomly land either before or after the victim tx).

Our argument is that, with or without this proposal, despite it is possible to construct such successful sandwich attacks occasionally, any validator that attempts this will find it hard to make it economically sustainable. That is, a sandwich attempt may result in a success or a failure, but over a longer period of time (looking at a day or a week), losses add up much faster, and the actor overall has a negative gain.

There are several pitfalls to the method:

1. When an authority received a transaction for signing, the transaction certificate has not yet been assembled. It is up to the client to drive the submission (until certain point in time). This introduces undetermined delay. The frontrun tx may land and find out that it a few rounds (or even checkpoints) ahead of the victim. When prices change fast, this leads to inventory risk (from holding the token).

2. It is questionable that if a certain victim transaction will eventually be executed successfully at all. The transaction may fail to submit (for example, object locked), fail to get sequenced (for example, cancellation due to object congestion), fail to execute (for example, slippage), or probably did not exist at all (for example, a bait sent from a frontrunning protection system).

3. Non-atomic execution allows arbitrage against the frontrunning transaction or the victim transaction. Without the perfect information combined with a perfect strategy, it is difficult to determine whether buying from a pair generates an arbitrage opportunity. We argue that such information/strategy is extremely hard (if not impossible) to obtain. This often enough leads to a negative profit.

[mwtian]

What is the downside of using N = gas\_price / RGP here? The advantage is that it would be simpler to reason about, and there will be a constant gas\_price / N which can be considered as per-submission cost.

[shio-coder]

That works as well! Originally the thought was to have a slightly higher amplification than simply submitting multiple transactions, so to remove the incentive of doing that. But the upside is minor and we can choose simplicity over it.

[Iamknownasfesal]

It will theoretically work. It will even work without priority fees.

I have several questions and concerns about the priority fees mechanism:

1. Purpose of Priority Fees

   • What is the actual purpose of priority fees in this context?
   • If they're meant to create a fee market, how does this align with Sui's consensus design?
   • Given that Sui's consensus architecture doesn't inherently require priority transactions, why introduce this mechanism?

2. Security

   • There's a significant concern that priority fees could enable economically viable sandwich attacks
   • When you mention "It will theoretically work, even without priority fees," this suggests the feature isn't essential
   • By allowing transaction prioritization through gas fees, we may be inadvertently creating a new attack vector

3. DeFi

   • In DeFi scenarios where users race to execute transactions (particularly in swap operations), The introduction of priority fees could make certain MEV attacks more profitable and sustainable

I believe we need to carefully evaluate whether the benefits of priority fees outweigh these potential security risks, particularly in DeFi contexts where transaction ordering is critical.

[shio-coder]

It will theoretically work. It will even work without priority fees.

I have several questions and concerns about the priority fees mechanism:

1. Purpose of Priority Fees

   • What is the actual purpose of priority fees in this context?
   • If they're meant to create a fee market, how does this align with Sui's consensus design?
   • Given that Sui's consensus architecture doesn't inherently require priority transactions, why introduce this mechanism?

2. Security

   • There's a significant concern that priority fees could enable economically viable sandwich attacks
   • When you mention "It will theoretically work, even without priority fees," this suggests the feature isn't essential
   • By allowing transaction prioritization through gas fees, we may be inadvertently creating a new attack vector

3. DeFi

   • In DeFi scenarios where users race to execute transactions (particularly in swap operations), The introduction of priority fees could make certain MEV attacks more profitable and sustainable

I believe we need to carefully evaluate whether the benefits of priority fees outweigh these potential security risks, particularly in DeFi contexts where transaction ordering is critical.

It is irrelevant to the sandwich attack. The gas fee mechanism (you call it priority fees) already exists. It just does not behave deterministically. This proposal simply removes the (unwanted) randomness of transaction submission. It does not enable another attack vector that wasn't possible before. It makes the system fairer by allowing transactions that pay more to get higher priority. We believe this is a fair feature for Sui. @sblackshear @mwtian might be able to provide some insights from Sui's perspective as well?

[mwtian]

It will theoretically work. It will even work without priority fees.

I have several questions and concerns about the priority fees mechanism:

1. Purpose of Priority Fees

   • What is the actual purpose of priority fees in this context?
   • If they're meant to create a fee market, how does this align with Sui's consensus design?
   • Given that Sui's consensus architecture doesn't inherently require priority transactions, why introduce this mechanism?

2. Security

   • There's a significant concern that priority fees could enable economically viable sandwich attacks
   • When you mention "It will theoretically work, even without priority fees," this suggests the feature isn't essential
   • By allowing transaction prioritization through gas fees, we may be inadvertently creating a new attack vector

3. DeFi

   • In DeFi scenarios where users race to execute transactions (particularly in swap operations), The introduction of priority fees could make certain MEV attacks more profitable and sustainable

I believe we need to carefully evaluate whether the benefits of priority fees outweigh these potential security risks, particularly in DeFi contexts where transaction ordering is critical.

Thanks for providing feedback @Iamknownasfesal. To clarify, today ordering of transactions in Sui is first determined by which consensus commit the transaction is included in, then transactions are ordered within each consensus commit by gas price before their execution. There are more details: transactions touching different objects can execute in parallel, transactions touching overloaded objects can be deterministically postponed to execute with a later consensus commit etc. But these are the high level ideas.

If we consider the issue of too many transactions trying to use the same shared objects (for example liquidity pools), prioritizing these transactions based on their gas prices ("priority fee") seems to be the most sensible way, which provides the most value to the network. Current protection against sandwich attacks comes from the fact that it should be easy to detect validators carrying out the attack and avoid using these validators for transaction submissions. If you have concrete proposals on alternative ways to order transactions that provide stronger protection against sandwich attacks, feel free to write up an issue at https://github.com/MystenLabs/sui and we can discuss there.

As mentioned by @shio-coder, this proposal is basically to allow transactions to use consensus bandwidth proportional to its gas price, which improves the reliability of having a transaction included in the next consensus commit instead of a later one. Ordering within the consensus commit will be determined by gas prices as discussed above, which is the existing behavior.