Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SIP-45: Prioritized Transaction Submission #45

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 78 additions & 0 deletions sips/sip-45.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@

| SIP-Number | 45 |
| ---: | :--- |
| Title | Prioritized Transaction Submission |
| Description | Enable effective prioritized transaction submission. |
| Author | Shio Coder <[email protected]> |
| Editor | Will Riches <[email protected], @wriches> |
| Type | Standard |
| Category | Core |
| Created | 2024-11-26 |
| Comments-URI | https://sips.sui.io/comments-45 |
| Status | Fast Track |
| Requires | N/A |

## Abstract

Enable effective prioritized transaction submission based on gas price.

## Motivation

Currently, there is no deterministic gas ordering for the transactions, even when these transactions are submitted within an extremely short time window (less than 100ms). This is due to the fact that different transactions are randomly submitted by different validators, and the validator that is supposed to submit the transaction can have latency jitters. We propose a mechanism to mitigate the random factor and enable prioritized transaction submission.

## Specification

We propose the following changes:

- Increase the maximum allowed value of gas price from $99,999$ to $1,000,000,000,000$ (1T).
- Allow immediate transaction broadcast based on gas price.
- Once a validator receives a transaction with a higher gas price, it is submitted immediately to consensus regardless of tx digest, with the least possible delay, if the validator is in the range of $[0, N)$ of submission position.
- $N$ is a function of gas price, defined as:

- if $`gas\_price < K \times RGP`$ then $N = 1$
- else $`N = gas\_price / RGP + 1`$
Copy link

@mwtian mwtian Dec 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


We acknowledge that in order to adapt to the forthcoming Mysticeti Fast Path, further changes are needed.

$K$ is a constant chosen to limit amplification. A smaller value of $K$ will increase amplification to the Sui network. In this case, $5$ is chosen as the initial value of $K$.

## Rationale

Transaction ordering on Sui depends on many factors that may or may not be within the control of the user.

Consider such a scenario where multiple actors are competing against one trading opportunity, where which transaction lands first wins. One actor may send a transaction, specifying the maximum possible gas price (99,999), hoping that the transaction will be included in the earliest possible position in the very next round of consensus commits. However, doing so will not reliably succeed. In fact, she may find out that despite paying the highest possible gas price, transaction inclusion still appears random, the effect of using a higher gas price is negligible.

We have located and analyzed multiple CEX-DEX trading bots and found no exception other than using a constant gas price (for example, 850 MIST), despite the fact that they are competing with each other.

As of today, there is little one can do about the case, other than submitting many different transactions that are further submitted by different validators, or simply resort to luck.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


We believe one way to resolve this is to enable the user to send a tx with a even higher gas price (that comes with a significant real cost) should they choose to do so, while if the price paid is high enough, more validators will submit the transaction immediately, referencing its computed submission position from transaction’s digest. The higher gas price the user pays, the more validators will submit the transaction immediately. We have chosen the function of N so that a user has no incentive to send multiple transactions.

We have studied transactions in the past 30 days (as of 2024-11-07), a distribution of gas price as well as the projected effects from our proposal are shown as follows:

| Gas Price Bucket | Number of Txs | % | $max(N)$ | `Amp%` | `Cum Amp%` |
| ---------------: | :------------ | ------ | ------ | ------ | -------- |
| $[0, 5000)$ | 249058741 | 99.783 | 1 | 99.783 | 99.783 |
| $[5000, 10000)$ | 37872 | 0.015 | 14 | 0.212 | 99.996 |
| $[10000, 20000)$ | 303449 | 0.122 | 27 | 3.283 | 103.278 |
| $[20000, 30000)$ | 58921 | 0.024 | 40 | 0.944 | 104.222 |
| $[30000, 40000)$ | 5370 | 0.002 | 54 | 0.116 | 104.339 |
| $[40000, 50000)$ | 4128 | 0.002 | 67 | 0.111 | 104.449 |
| $[50000, 60000)$ | 9958 | 0.004 | 80 | 0.319 | 104.769 |
| $[60000, 70000)$ | 2818 | 0.001 | 94 | 0.106 | 104.875 |
| $[70000, 80000)$ | 3953 | 0.002 | 107 | 0.169 | 105.044 |
| $[80000, 90000)$ | 1729 | 0.001 | 120 | 0.083 | 105.127 |
| $[90000, 100000)$ | 112992 | 0.045 | 134 | 6.066 | 111.193 |

- `Amp%` represents the percentage of amplification from that bucket.
- `Cum Amp%` represents the cumulative % of amplification from that bucket and all preceding buckets.

From the data above, we predict that consensus bandwidth will be increased by no more than 12% should the proposal get implemented. In return, non-deterministic factors will become minimum, which makes actors able to compete by trying to outbid each other, where the participants will have to pay a much higher gas fee than before, in exchange for the certainty of reliably winning, should one outbid everyone else.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Backwards Compatibility

The SIP introduces no incompatible changes.

## Security Considerations

None.