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.

[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.

[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.

[Evan-Kim2028]

I think a value of 5 for the amplification factor is very aggressive to start off with.

I propose a higher amplification factor of 120 as a conservative starting amplification factor. This will still have a meaningful effect on better transaction inclusion through higher fees while still protecting validator network bandwidth. The amplification factor can always be lowered in the future.

You can find my full writing and rationale based on a robust quantitative approach here - https://paragraph.xyz/@evandekim/economics-of-sui-shared-liquidity-pool-objects