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

separate priority fee and transaction fee from fee calculation #34757

Merged

Conversation

tao-stones
Copy link
Contributor

Problem

To reward priority fee differently from transaction fee (SIMD-0096), priority fee should be separated from return of calculate_fee(...).

Summary of Changes

  • change calculate_fee() return type from u64 to FeeDetails
  • no other functional changes.

Fixes #

@tao-stones tao-stones force-pushed the calculate-fee-returns-details branch 2 times, most recently from 2ae2a72 to 6725461 Compare January 11, 2024 22:01
Copy link

codecov bot commented Jan 11, 2024

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (51c0649) 81.6% compared to head (f84b315) 81.6%.
Report is 1 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #34757   +/-   ##
=======================================
  Coverage    81.6%    81.6%           
=======================================
  Files         830      830           
  Lines      224746   224757   +11     
=======================================
+ Hits       183515   183547   +32     
+ Misses      41231    41210   -21     

sdk/src/fee.rs Outdated Show resolved Hide resolved
@t-nelson
Copy link
Contributor

t-nelson commented Jan 12, 2024

can this wait for 1.19? should be able to cut 1.18 in ~1wk if all goes well with mb 1.17 adoption, making this mergeable into master

@tao-stones
Copy link
Contributor Author

can this wait for 1.19? should be able to cut 1.18 in ~1wk if all goes well with mb 1.17 adoption, making this mergeable into master

1.19 sounds good, need time to test anyway.

@mergify mergify bot added community Community contribution need:merge-assist labels Jan 23, 2024
@tao-stones tao-stones removed community Community contribution need:merge-assist labels Jan 23, 2024
@tao-stones tao-stones force-pushed the calculate-fee-returns-details branch 2 times, most recently from 9cd885f to 1f186d1 Compare January 23, 2024 20:24
sdk/src/fee.rs Outdated Show resolved Hide resolved
sdk/src/fee.rs Outdated Show resolved Hide resolved
@@ -83,7 +96,7 @@ impl FeeStructure {
_lamports_per_signature: u64,
budget_limits: &FeeBudgetLimits,
include_loaded_account_data_size_in_fee: bool,
) -> u64 {
) -> FeeDetails {
Copy link
Contributor

Choose a reason for hiding this comment

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

this is changing the signature of a public interface, which is technically against semver. who's consuming this?

Copy link
Contributor Author

@tao-stones tao-stones Jan 24, 2024

Choose a reason for hiding this comment

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

Direct callers (besides tests) are bank (calculate tx fee for distribution) and accounts (to validate payer account), both are updated in this PR. Don't think it is exposed to external 🤞🏼

Copy link
Contributor

Choose a reason for hiding this comment

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

well it's exposed for sure 'cause sdk is a publicly consumable crate and this method is publicly exported. question is whether it's actually consumed by anyone, which we really ought not find out the hard way.

i suppose the most pedantic thing to do here would be to move this logic to a new method calculate_fee_details(...) -> FeeDetails, then deprecate calculate_fee(...) -> u64 replacing its body with a call to calculate_fee_details(...).total_fees()

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with Trent here, it's quite possible 3rd party code usees this function.
Though I'm not sure we need to actually deprecate calculate_fee, so long as the impl is just calculate_fee_details(...).total_fees().

Seems reasonable there are many call-sites that don't care about the details, just the total fee. Might simplify this PR as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree too. But does calculate_fee() need to be exposed to external? Users use simulator to get tx fee, are they? github says this function was moved from runtime::bank to sdk::fee_structure not too long ago. Maybe entire fee_structure belong to solana_runtime instead of sdk?

Copy link
Contributor

Choose a reason for hiding this comment

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

the ship has sailed on whether it needs to be or not. we've already shipped releases with it exposed in the public api of a publicly consumable crate that we've promised to follow semver on. removing that symbol for public availability anytime but a major release will be a violation of semver

Copy link
Contributor Author

Choose a reason for hiding this comment

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

033c98b for the sailed ship

@@ -75,15 +88,32 @@ impl FeeStructure {
.saturating_mul(heap_cost)
}

/// Calculate fee for `SanitizedMessage`
#[cfg(not(target_os = "solana"))]
pub fn calculate_fee(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Keep this function live & active. @apfitzge has a good point that most use case just want total_fee. Doesn't need to deprecate it.

Comment on lines +149 to +152
transaction_fee: (signature_fee
.saturating_add(write_lock_fee)
.saturating_add(compute_fee) as f64)
.round() as u64,
Copy link
Contributor

Choose a reason for hiding this comment

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

unrelated, but why do we round here even after removing congestion? these are all integers, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! I'll patch it separately

Copy link
Contributor

@t-nelson t-nelson left a comment

Choose a reason for hiding this comment

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

thanks! :shipit:

@tao-stones tao-stones merged commit 5ecc47e into solana-labs:master Jan 26, 2024
45 checks passed
@tao-stones tao-stones deleted the calculate-fee-returns-details branch January 26, 2024 14:24
tao-stones added a commit to tao-stones/solana that referenced this pull request Jan 30, 2024
tao-stones added a commit to tao-stones/solana that referenced this pull request Jan 30, 2024
tao-stones added a commit that referenced this pull request Jan 30, 2024
mergify bot pushed a commit that referenced this pull request Jan 30, 2024
#34757)"

This reverts commit 5ecc47e.

(cherry picked from commit df2ee12)

# Conflicts:
#	sdk/src/fee.rs
tao-stones added a commit that referenced this pull request Jan 31, 2024
* Revert "refactor unused parameter (#34970)"

This reverts commit 0838909.

(cherry picked from commit 1542392)

# Conflicts:
#	sdk/src/fee.rs

* Revert "separate priority fee and transaction fee from fee calculation (#34757)"

This reverts commit 5ecc47e.

(cherry picked from commit df2ee12)

# Conflicts:
#	sdk/src/fee.rs

* Revert "Remove congestion multiplier from calculate fee (#34865)"

This reverts commit 73d3973.

(cherry picked from commit 0dcac3f)

# Conflicts:
#	sdk/src/fee.rs

* fix merge conflicts

---------

Co-authored-by: Tao Zhu <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants