-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
default compute units per instruction #24899
default compute units per instruction #24899
Conversation
5b52cae
to
624f465
Compare
Codecov Report
@@ Coverage Diff @@
## master #24899 +/- ##
=========================================
+ Coverage 81.8% 82.0% +0.1%
=========================================
Files 632 597 -35
Lines 167499 165739 -1760
Branches 322 0 -322
=========================================
- Hits 137169 136047 -1122
+ Misses 30217 29692 -525
+ Partials 113 0 -113 |
compute units used by each instruction in the transaction must not exceed that | ||
value. The default number of maximum units allows is intentionally kept large to | ||
avoid breaking existing client behavior. | ||
default number of maximum units will calculated per instruction which means the |
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.
I don't really understand what this is trying to say
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.
better? #24955
(cherry picked from commit e070c5c) # Conflicts: # docs/src/developing/programming-model/runtime.md # sdk/src/feature_set.rs
(cherry picked from commit e070c5c)
would be good to update the docs https://docs.solana.com/developing/programming-model/runtime#transaction-wide-compute-budget |
* default compute units per instruction (#24899) (cherry picked from commit e070c5c) # Conflicts: # docs/src/developing/programming-model/runtime.md # sdk/src/feature_set.rs * fix merge Co-authored-by: Jack May <[email protected]>
* default compute units per instruction (#24899) (cherry picked from commit e070c5c) * update doc Co-authored-by: Jack May <[email protected]>
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.
gate lgtm. I thought we were going to swing a heavier hammer here, but I guess this is fine too.
// Compute budget instruction must be in the 1st 3 instructions (avoid | ||
// nonce marker), otherwise ignored | ||
if i < 3 { | ||
match try_from_slice_unchecked(&instruction.data) { |
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.
OT, but should it be an error to specify any of these multiple times?
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.
eh, just take the last
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.
To be fair, it's pretty confusing when looking at the explorer and some transactions have like 10 compute budget instructions and you have to know it's the 3rd one that was applied
requested_units | ||
} | ||
.unwrap_or(MAX_UNITS as u64) | ||
.min(MAX_UNITS as u64); |
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.
should we really clamp here? failure is always an option
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.
figure clamp and hope for best, max might change but in a way that would still allow the tx to succeed
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.
yeah, just thought it might be confusing DX
|
||
self.max_units = if default_units_per_instruction { | ||
requested_units | ||
.or_else(|| Some(num_instructions.saturating_mul(DEFAULT_UNITS as usize) as u64)) |
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.
I thought we were just requesting DEFAULT_UNITS
for the entire TX if unspecified, not retaining today's behavior. I guess this is OK, but I'd rather put some pressure on the offenders to change their ways
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.
This is the smoothest transition to tx-wide caps without breaking folks and the additional fee will schedule folks appropriately. I'm still a fan of charging a requested CU based fee to encourage low CU requests. @aeyakovenko using for additional fee based motivation, open market.
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.
I think we should still cap the number of instructions for this calculation.. Like maybe 10 instructions? If you're doing more than that, you're a bot and can add the compute budget ix yourself.
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.
It's capped at a total maximum unit which should be sufficient, what does capping the ix's doing for us? Seems artificial to say that if there are 10 instructions it must be a bot
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.
It's capped at a total maximum unit which should be sufficient
Ah ok, this works too! I clearly didn't read the PR 😅
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.
This is the smoothest transition to tx-wide caps without breaking folks
Yep. I was just fully prepared to break the right folks 😉
Problem
Defaulting the tx-wide cap to the max overestimates what a transaction will need and later will skew transaction scheduling for transactions that don't explicitly request
Summary of Changes
Default the units to 200k per non-compute budget instruction in the transaction
Fixes #
Feature Gate Issue: #24898