-
Notifications
You must be signed in to change notification settings - Fork 81
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
feat: impl block rewards #1198
feat: impl block rewards #1198
Conversation
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.
I really like how it looks! Good job William! 🙌🏻
Some comments/suggestions/questions below
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.
Sorry for coming a bit late to the convo. Looks good overall!
pallets/block-rewards/src/lib.rs
Outdated
/// Admin method to set the inflation amount for the Beneficiary used for the next epochs. | ||
/// Current epoch is not affected by this call. | ||
#[pallet::weight(T::WeightInfo::set_distributed_reward())] | ||
pub fn set_beneficiary_reward( |
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.
I am wondering if instead of giving the exact amount here we do give the inflation_per_epoch
and then internally we substract the collator reward and the rest goes to the beneficiary (if set). If I am seeing this correctly, this will avoid us from:
- Having to calculate the split between those two values outside of the chain
- Everytime we include a new collator, we will need to update this value, which possibly for a period of time we would be giving more than what we should.
WDYT?
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.
We could definitely do it your way as well! I kind of went this path before 1ee21af, when it became aware that rewarding a group with amount x
consumes the entire x
.
Everytime we include a new collator, we will need to update this value, which possibly for a period of time we would be giving more than what we should.
The current design does not need to be reconfigured when new collators join as the configured reward is per collator, at least under the assumption that n * collator_reward + beneficiary_amount
does not need to stay static.
However, I definitely see the upside in your approach. Just on a note: We would still need to store two reward amounts, otherwise we would have to hardcode the share for a collator.
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.
yes, the collator_reward
is per collator and that doesn't have to change when changing the collator size, but that new value now affects the beneficiary_amount
that goes into the treasury right? That value will need to be adapted accordingly when a new size of collators is defined.
Am I understanding correctly that the beneficiary_reward
is the 3% inflation rate - the collator reward
? If so those two values are interconnected.
Yes, in my proposal we still have to store 2 values.
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.
Yes that is correct. Let's summarize: I will change beneficiary_reward
to denote the total reward per epoch instead. From that, we subtract the rewards for all collators and the rest
- is minted in the Treasury for Centrifuge chain
- stays in the Treasury for Altair, e.g. is not moved anywhere
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.
I think so, that means that the beneficiary_reward
, if set, has to be at least the same as the collator_reward * number of collators at that point in time.
And for Altair, we basically do not set it, and the logic should be able to only mint/move the collator_reward without interacting with the Zero value of the beneficiary_reward
.
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.
Fixed in 8b8c40f. Not sure if I should rename Beneficiary
to Treasury
.
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 ready for me! 🚀
Good job @wischli !!
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.
Niiiiiiice!!
Migrations looks good, code looks good, tests look good, integrations test are sick!
The only thing before merging this one from my side would be to check miguels comment and wait for #1233
.ok(); | ||
weight.saturating_accrue(T::DbWeight::get().reads_writes(6, 6)); | ||
} | ||
Pallet::<T>::current_storage_version().put::<Pallet<T>>(); |
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.
Is this substrate magic? Where is the version defined?
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.
The function itself is part of the GetStorageVersion
trait. The pallet's storage version current_storage_version
is in scope of the frame_support::pallet
magic.
So anytime we bump a pallet's storage version we still need to do a migration to have the on_chain_storage_version
and current_storage_version
aligned.
pallet_rewards::Pallet::<Runtime, pallet_rewards::Instance1>::list_currencies(&account_id) | ||
.into_iter().chain( | ||
pallet_rewards::Pallet::<Runtime, pallet_rewards::Instance2>::list_currencies(&account_id).into_iter() | ||
).collect() |
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.
Is list_currencies
a trait method?
Then we can impl that for tuples.
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.
Yes it is! Should this be handled in this PR or in a follow-up one?
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.
Follow up. Just a clean up
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.
Follow up. Just a clean up
collator_reward_per_session: T::Balance, | ||
) -> DispatchResult { | ||
T::AdminOrigin::ensure_origin(origin)?; | ||
|
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.
I think this is not needed, but a good sanity check maybe as we also do this check in set_total_reward
. Wdyt @wischli or is the check in set_total_reward
otherwise a safety mesaure?
do_advance
: Already does checklet total_reward = min(num_collators*reward_collator, total_reward)
pallets/block-rewards/src/lib.rs
Outdated
|
||
/// The identifier of the artificial block rewards currency which is minted and burned for collators. | ||
#[pallet::constant] | ||
type StakeCurrencyId: Get<CfgCurrencyId>; |
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.
Can CfgCurrencyId
be identified by Currency::AssetId
?
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.
I mean, the pallet can works without knowing that the CurrencyId
is exactly a CfgCurrencyId
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.
Yes, we have to add an AssetId
associated type to the Config then. Will do this tomorrow! Good catch.
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.
No hurry! Maybe a CurrencyIdOf<T>
using the CurrencyId
from Rewards
traits or from Currency
trait saves you from another Config parameter
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.
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.
Since we need to specify the CurrencyId
for the Rewards
trait, I don't see how we get around adding a CurrencyId
parameter to the pallet_block_rewards::Config
.
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.
LGTM! Let's get this merged soon!
A couple of minor questions.
>; | ||
|
||
type UpgradeDev1020 = | ||
pallet_block_rewards::migrations::InitBlockRewards<Runtime, CollatorRewards, TotalRewards>; |
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.
Why is this migration needed for development?
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.
For the demo
chain and to enable testing the migration locally before we add it to Altair
and Centrifuge
later.
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.
Ok, so as a norm, we should always create migrations for any breaking change in development,
right?
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.
I would say so, 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.
Re approval! 🚀
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.
Re-approve
Description
Implements
pallet-block-rewards
.Fixes #1000
Changes and Descriptions
pallet_block_rewards
based on the rewards spec<<pallet_rewards::Pallet::<T, I>> as GroupRewards>::reward_group
which defaults toT::Currency::mint_into
: Add interface Inflation exposing fn inflate(amount) -> DispatchResultpallet_block_rewards
pallet_collator_selection
pallet_session
Handled in a follow-up PR
Type of change
How Has This Been Tested?
cargo test -p pallet-block-rewards --features runtime-benchmarks PARA_CHAIN_SPEC=development ./scripts/init.sh benchmark pallet-block-rewards
Checklist:
main
branch