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

Add rpc support for partitioned rewards #34773

Merged

Conversation

CriesofCarrots
Copy link
Contributor

Problem

Since #34624, we can pull the PartitionData PDA to create the hasher to locate specific rewards.

Summary of Changes

  • Add branch for partitioned rewards in get_inflation_rewards
  • Remove feature deactivation in solana-test-validator

@CriesofCarrots CriesofCarrots force-pushed the rpc-partitioned-rewards branch 2 times, most recently from 184dcfc to 8575572 Compare January 12, 2024 21:20
Copy link

codecov bot commented Jan 12, 2024

Codecov Report

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

Comparison is base (b04765f) 81.6% compared to head (89fbcbb) 81.6%.
Report is 7 commits behind head on master.

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     

@CriesofCarrots CriesofCarrots marked this pull request as ready for review January 16, 2024 17:40
@CriesofCarrots
Copy link
Contributor Author

While I want to complete MNB-representative testing before merge, could you reviewers start looking at this code? 🙏

@HaoranYi
Copy link
Contributor

I went through the code. The algorithm logic looks good to me!
Just one comment.

@CriesofCarrots
Copy link
Contributor Author

Just one comment.

I don't see a comment @HaoranYi

rpc/src/rpc.rs Outdated Show resolved Hide resolved
@HaoranYi
Copy link
Contributor

Sorry. Forget to click "submit". Now submitted.

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.

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

  1. a hack for the case of addresses.is_empty()
  2. its own method
  3. 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 Show resolved Hide resolved
rpc/src/rpc.rs Outdated
.unwrap_or_default()
.into_iter()
.filter_map(|reward| match reward.reward_type? {
RewardType::Staking | RewardType::Voting => addresses
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

rpc/src/rpc.rs Outdated Show resolved Hide resolved
rpc/src/rpc.rs Outdated Show resolved Hide resolved
@CriesofCarrots
Copy link
Contributor Author

"get all of epoch E's rewards" use case

We don't have a method that does this currently, except for I suppose getBlock on the first block of the epoch. So I would lean toward a client-side implementation. We could add something to solana_rpc_client or solana_cli as a reference implementation, if you like.

@CriesofCarrots
Copy link
Contributor Author

CI failure is that h2 audit error. Will rebase when fix is available.

@t-nelson
Copy link
Contributor

except for I suppose getBlock on the first block of the epoch

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

rpc/src/rpc.rs Outdated Show resolved Hide resolved
@CriesofCarrots
Copy link
Contributor Author

I tested this on a solana-test-validator and a client spinning up 50k-100k stake accounts. I rekeyed the feature to test pre- and post-activation.
Caught 2 bugs: #34913, and and off-by-one error here
It's now testing well.

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.

t-nelson
t-nelson previously approved these changes Jan 24, 2024
rpc/src/rpc.rs Show resolved Hide resolved
rpc/src/rpc.rs Show resolved Hide resolved
rpc/src/rpc.rs Show resolved Hide resolved
runtime/src/epoch_rewards_hasher.rs Outdated Show resolved Hide resolved
@CriesofCarrots
Copy link
Contributor Author

Rebased to pick up #34934 and removed commit touching EpochRewardsHasher

Copy link
Contributor

@HaoranYi HaoranYi left a comment

Choose a reason for hiding this comment

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

Good job! lgtm!

@CriesofCarrots
Copy link
Contributor Author

No changes; just rebased to pick up the local-cluster fix

@CriesofCarrots CriesofCarrots added the v1.18 PRs that should be backported to v1.18 label Jan 25, 2024
Copy link
Contributor

mergify bot commented Jan 25, 2024

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.

@CriesofCarrots CriesofCarrots merged commit 22500c2 into solana-labs:master Jan 25, 2024
36 checks passed
mergify bot pushed a commit that referenced this pull request Jan 25, 2024
* 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)
CriesofCarrots added a commit that referenced this pull request Jan 26, 2024
…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>
CriesofCarrots added a commit to CriesofCarrots/solana that referenced this pull request Feb 2, 2024
CriesofCarrots added a commit that referenced this pull request Feb 6, 2024
mergify bot pushed a commit that referenced this pull request Feb 6, 2024
This reverts commit 22500c2.

(cherry picked from commit f01f361)
CriesofCarrots added a commit that referenced this pull request Feb 7, 2024
This reverts commit 22500c2.

(cherry picked from commit f01f361)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v1.18 PRs that should be backported to v1.18
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants