-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Add rpc support for partitioned rewards #34773
Add rpc support for partitioned rewards #34773
Conversation
184dcfc
to
8575572
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #34773 +/- ##
=========================================
- Coverage 81.6% 81.6% -0.1%
=========================================
Files 828 830 +2
Lines 224339 224721 +382
=========================================
+ Hits 183274 183482 +208
- Misses 41065 41239 +174 |
While I want to complete MNB-representative testing before merge, could you reviewers start looking at this code? 🙏 |
I went through the code. The algorithm logic looks good to me! |
I don't see a comment @HaoranYi |
Sorry. Forget to click "submit". Now submitted. |
8575572
to
569e79a
Compare
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.
looking like a good start!
i imagine we'll need some way to ease the "get all of epoch E
's rewards" use case. not sure if it makes more sense as
- a hack for the case of
addresses.is_empty()
- its own method
- a client-side version of similar logic (would be cool if we could maximally share code)
i'm kinda leaning toward (3) atm
rpc/src/rpc.rs
Outdated
.unwrap_or_default() | ||
.into_iter() | ||
.filter_map(|reward| match reward.reward_type? { | ||
RewardType::Staking | RewardType::Voting => addresses |
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.
and only staking rewards here
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 one can be changed, yes.
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.
Given the dereplicode refactoring, I'm not sure this is worth doing. It's a little prickly to match only one or the other type after feature activation, but both before.
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 a little prickly to match only one or the other type after feature activation, but both before.
mmm... is it tho? split the filter_map()
to a discrete filter()
and map()
, pass in different filter closures, works no?
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.
Fine, I've pushed that. I don't think it gains us much, though, since after feature activation there won't be any RewardType::Staking rewards in the first block to check.
We don't have a method that does this currently, except for I suppose |
c2b1d6a
to
771df04
Compare
CI failure is that |
771df04
to
766a416
Compare
yeah i should've mentioned that this implicit implementation is what i was talking about. client-side is fine (preferred even), just kinda annoying that the runtime and client code is so divergent that we'll basically be fully replicoding this logic |
8976385
to
a56e364
Compare
bf01475
to
9fdb774
Compare
I tested this on a I'd like to run one test with mnb-levels of stake accounts (we're working on getting that set up on pop-sim), but in the meantime, I think this is ready for final review. |
9fdb774
to
f367f12
Compare
Rebased to pick up #34934 and removed commit touching EpochRewardsHasher |
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.
Good job! lgtm!
…h must exist for partiion PDA to exist
… catch Voting rewards
f367f12
to
89fbcbb
Compare
No changes; just rebased to pick up the local-cluster fix |
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
* Check feature_set for enable_partitioned_epoch_reward * Keep common variable outside if case * Keep common early return out of if case, since the first_slot_in_epoch must exist for partiion PDA to exist * Get and parse epoch partition data PDA * Find partition index for all addresses * Pull relevant blocks and get rewards * Reuse ordering and reformatting * Remove feature deactivation from TestValidator * Restore rewards iteration in first block in epoch for feature case to catch Voting rewards * Add fn get_reward_map helper to dedupe code * No need to start 2nd get_block_with_limit call with first block again * Replace filter_map to parameterize RewardType filter expression * Weird thing to make clippy and compiler agree (rust-lang/rust-clippy#8098) * Use activated_slot to ensure the right approach for past rewards epochs (cherry picked from commit 22500c2)
…34960) Add rpc support for partitioned rewards (#34773) * Check feature_set for enable_partitioned_epoch_reward * Keep common variable outside if case * Keep common early return out of if case, since the first_slot_in_epoch must exist for partiion PDA to exist * Get and parse epoch partition data PDA * Find partition index for all addresses * Pull relevant blocks and get rewards * Reuse ordering and reformatting * Remove feature deactivation from TestValidator * Restore rewards iteration in first block in epoch for feature case to catch Voting rewards * Add fn get_reward_map helper to dedupe code * No need to start 2nd get_block_with_limit call with first block again * Replace filter_map to parameterize RewardType filter expression * Weird thing to make clippy and compiler agree (rust-lang/rust-clippy#8098) * Use activated_slot to ensure the right approach for past rewards epochs (cherry picked from commit 22500c2) Co-authored-by: Tyera <tyera@solana.com>
This reverts commit 22500c2.
This reverts commit 22500c2.
Problem
Since #34624, we can pull the PartitionData PDA to create the hasher to locate specific rewards.
Summary of Changes
get_inflation_rewards