-
Notifications
You must be signed in to change notification settings - Fork 65
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
base: main
Are you sure you want to change the base?
Changes from 3 commits
878234a
9d4c2b4
f021c57
6b33c97
b31e73e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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`$ | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. With higher gas prices, 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. |
There was a problem hiding this comment.
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 constantgas\_price / N
which can be considered as per-submission cost.There was a problem hiding this comment.
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.