-
Notifications
You must be signed in to change notification settings - Fork 992
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
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
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. |
Testing that this behaves as expected for a validator that claimed rewards in epoch 51:
|
Of particular note, this code accounts for the
|
Mind adding some unit tests here to demonstrate the behavior too @joel-u410? |
For sure, I can look into that. |
…st rewards_counter
…re as of beginning of epoch
89df61f
to
8cb563f
Compare
@brentstone @tzemanovic -- I've added a unit test that demonstrates querying for Please take a look: 8cb563f Note that my test initially would not pass because the MockDB didn't provide a proper implementation for |
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" } |
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 shouldn't be needed - the symbols used are re-exported from namada_token
_, | ||
namada_parameters::Store<_>, | ||
governance::Store<_>, | ||
namada_trans_token::Store<_>, |
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.
namada_trans_token::Store<_>, | |
namada_token::Store<_>, |
StorageWrite::write( | ||
&mut client.state, | ||
&storage::Key::from( | ||
namada_trans_token::storage_key::balance_key( |
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.
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<_>, |
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.
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; |
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 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) |
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, that's right :/
let native_token = client.state.get_native_token().unwrap(); | ||
StorageWrite::write( | ||
&mut client.state, | ||
&storage::Key::from( |
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 already a storage key
Describe your changes
This adds an
epoch
argument to therewards()
function invp::pos
. It does require a RPC node update in order to work, but it's backwards compatible. Tested with previous build ofnamadan
and results are same as before:With node on
main
and client on this branch:With both client and node on this branch:
Checklist before merging
breaking::
labelsnamada-docs
reponamada-indexer
ornamada-masp-indexer
, a corresponding PR is opened in that repo