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

[pos] Add epoch argument to vp::pos::rewards #4196

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

joel-u410
Copy link
Contributor

@joel-u410 joel-u410 commented Dec 18, 2024

Describe your changes

This adds an epoch argument to the rewards() function in vp::pos. It does require a RPC node update in order to work, but it's backwards compatible. Tested with previous build of namadan and results are same as before:

With node on main and client on this branch:

$ ./target/debug/namadac rewards --source tnam1qrtypl0yazfamk8ptmgp608msl8wzrkpmqwppc7w --validator tnam1qxsx2ezu89gx252kwwluqp7hadyp285tkczhaqg0
Current rewards available for claim: 4625.955882 NAM

With both client and node on this branch:

$ ./target/debug/namadac rewards --source tnam1qrtypl0yazfamk8ptmgp608msl8wzrkpmqwppc7w --validator tnam1qxsx2ezu89gx252kwwluqp7hadyp285tkczhaqg0
Current rewards available for claim: 4625.955882 NAM

$ ./target/debug/namadac rewards --source tnam1qrtypl0yazfamk8ptmgp608msl8wzrkpmqwppc7w --validator tnam1qxsx2ezu89gx252kwwluqp7hadyp285tkczhaqg0 --epoch 60
Rewards for epoch 60: 4625.955882 NAM

$ ./target/debug/namadac rewards --source tnam1qrtypl0yazfamk8ptmgp608msl8wzrkpmqwppc7w --validator tnam1qxsx2ezu89gx252kwwluqp7hadyp285tkczhaqg0 --epoch 59
Rewards for epoch 59: 3887.536527 NAM

$ ./target/debug/namadac rewards --source tnam1qrtypl0yazfamk8ptmgp608msl8wzrkpmqwppc7w --validator tnam1qxsx2ezu89gx252kwwluqp7hadyp285tkczhaqg0 --epoch 58
Rewards for epoch 58: 3148.755426 NAM

Checklist before merging

  • If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
    • This will require 2 reviewers to approve the changes
  • If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
    • Relevant PR if applies: (coming soon)
  • If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo

Copy link

codecov bot commented Dec 18, 2024

Codecov Report

Attention: Patch coverage is 13.79310% with 50 lines in your changes missing coverage. Please review.

Project coverage is 74.42%. Comparing base (2ae305c) to head (89df61f).
Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
crates/sdk/src/queries/vp/pos.rs 12.28% 50 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4196      +/-   ##
==========================================
- Coverage   74.46%   74.42%   -0.05%     
==========================================
  Files         342      342              
  Lines      107773   107826      +53     
==========================================
- Hits        80257    80252       -5     
- Misses      27516    27574      +58     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@joel-u410
Copy link
Contributor Author

Testing that this behaves as expected for a validator that claimed rewards in epoch 51:

$ ./target/debug/namadac rewards --validator tnam1qyf80vw4e8aa2efuk4jsg9lpwxrntsj2dql4tssa --epoch 50
Rewards for epoch 50: 2.179855 NAM

$ ./target/debug/namadac rewards --validator tnam1qyf80vw4e8aa2efuk4jsg9lpwxrntsj2dql4tssa --epoch 51
Rewards for epoch 51: 4.363707 NAM

$ ./target/debug/namadac rewards --validator tnam1qyf80vw4e8aa2efuk4jsg9lpwxrntsj2dql4tssa --epoch 52
Rewards for epoch 52: 2.897536 NAM

@joel-u410
Copy link
Contributor Author

joel-u410 commented Dec 19, 2024

Of particular note, this code accounts for the rewards_counter when specifying an epoch by:

  • Subtracting the current counter that was included by query_reward_tokens
  • Adding the historical counter queried from storage at the height of epoch start

@Fraccaman Fraccaman requested a review from tzemanovic December 19, 2024 12:27
@brentstone
Copy link
Collaborator

Mind adding some unit tests here to demonstrate the behavior too @joel-u410?

@joel-u410
Copy link
Contributor Author

Mind adding some unit tests here to demonstrate the behavior too @joel-u410?

For sure, I can look into that.

@joel-u410 joel-u410 force-pushed the joel/rewards-at-past-epochs branch from 89df61f to 8cb563f Compare January 24, 2025 00:23
@joel-u410
Copy link
Contributor Author

joel-u410 commented Jan 24, 2025

@brentstone @tzemanovic -- I've added a unit test that demonstrates querying for rewards with the epoch argument.

Please take a look: 8cb563f

Note that my test initially would not pass because the MockDB didn't provide a proper implementation for read_subspace_val_with_height . I added a very basic implementation (which does seem to work!) in this commit: 3c47541

@tzemanovic
Copy link
Member

hi @joel-u410, thanks for the PR!

Do I understand correctly that you'd like to know the rewards distributed at the given epoch? The rewards query current returns unclaimed rewards, which accumulate and may be claimed at any point so I think there are some limitations with getting this information out of it. Specifically, when the rewards are claimed, the delegation bond amounts and validator commission rewards counter will go back to 0, but from this query endpoint it won't be very apparent what's happened. Because of this, I'm tempted to say that this functionality may be better built into an indexer, but if this is useful despite the limitations we could still add it, but I think we might need to better document how this work (I think one might expect that this returns the rewards obtained in the given epoch, but really it is accumulated unclaimed rewards)

@@ -162,6 +162,7 @@ namada_proof_of_stake = { path = "../proof_of_stake", default-features = false,
namada_state = { path = "../state", features = ["testing"] }
namada_storage = { path = "../storage", features = ["testing"] }
namada_token = { path = "../token", features = ["testing", "masp"] }
namada_trans_token = { path = "../trans_token" }
Copy link
Member

Choose a reason for hiding this comment

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

this shouldn't be needed - the symbols used are re-exported from namada_token

_,
namada_parameters::Store<_>,
governance::Store<_>,
namada_trans_token::Store<_>,
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
namada_trans_token::Store<_>,
namada_token::Store<_>,

StorageWrite::write(
&mut client.state,
&storage::Key::from(
namada_trans_token::storage_key::balance_key(
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
namada_trans_token::storage_key::balance_key(
namada_token::storage_key::balance_key(

namada_proof_of_stake::bond_tokens::<
_,
governance::Store<_>,
namada_trans_token::Store<_>,
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
namada_trans_token::Store<_>,
namada_token::Store<_>,

@@ -101,6 +101,8 @@ pub trait NamadaTypes: Clone + std::fmt::Debug {
type MaspIndexerAddress: Clone + std::fmt::Debug;
/// Represents a block height
type BlockHeight: Clone + std::fmt::Debug;
/// Represents an epoch
type Epoch: Clone + std::fmt::Debug;
Copy link
Member

Choose a reason for hiding this comment

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

this addition is not needed - you can refer to the concrete Epoch type from both impls (I see you probably followed what's been done and there are already bunch of types here that don't need to be generic)

// querying by height.
// TODO: this might not be valid if rewards have been claimed in the current
// epoch? (because the rewards_counter would be removed from
// storage until the next epoch)
Copy link
Member

Choose a reason for hiding this comment

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

yeah, that's right :/

let native_token = client.state.get_native_token().unwrap();
StorageWrite::write(
&mut client.state,
&storage::Key::from(
Copy link
Member

Choose a reason for hiding this comment

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

this is already a storage key

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants