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

[Staking] Noop refactor to prep pallet for currency fungible migration #5399

Open
wants to merge 38 commits into
base: master
Choose a base branch
from

Conversation

Ank4n
Copy link
Contributor

@Ank4n Ank4n commented Aug 18, 2024

This is a no-op refactor of staking pallet to move all T::Currency api calls under one module.

A followup PR (#5501) will implement the Currency <> Fungible migration for the pallet.

Introduces the new asset module that centralizes all interaction with T::Currency. This is an attempt to try minimising staking logic changes to minimal parts of the codebase.

Things of note

  • T::Currency::free_balance in current implementation includes both staked (locked) and liquid tokens (kinda sounds wrong to call it free then). This PR renames it to stakeable_balance (any better name suggestions?). With [Staking] Currency <> Fungible migration #5501, this will become free balance that can be held/staked + already held/staked balance.

@Ank4n Ank4n added the T2-pallets This PR/Issue is related to a particular pallet. label Aug 27, 2024
@Ank4n Ank4n changed the title [WIP] Prep staking pallet for currency fungible migration [Staking] Noop refactor to prep pallet for currency fungible migration Aug 27, 2024
@Ank4n Ank4n marked this pull request as ready for review August 27, 2024 12:17
@Ank4n Ank4n added the R0-silent Changes should not be mentioned in any release notes label Aug 27, 2024
@Ank4n Ank4n requested a review from a team as a code owner August 28, 2024 12:40
@paritytech-cicd-pr
Copy link

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7166366

/// Stakeable balance of `who`.
///
/// This includes balance free to stake along with any balance that is already staked.
pub fn stakeable_balance<T: Config>(who: &T::AccountId) -> BalanceOf<T> {
Copy link
Contributor

Choose a reason for hiding this comment

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

How about we do it from another perspective and expose both:

  1. fn asset::staked and
  2. fn asset::free_to_stake

And the remove fn stakeable_balance, which can be calculated by summing "staked + free_to_stake".

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 makes sense in this PR but probably not 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.

Clarification: The only way to calculate free_to_stake in currency::locks world is by checking free_balance (aka stakeable_balance) - locked_balance.

/// Kill the stake of `who`.
///
/// All locked amount is unlocked.
pub fn kill_stake<T: Config>(who: &T::AccountId) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe unlock_all_stake instead? Kill stake is very similar to kill ledger etc, although in a completely different context.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I actually named it keeping in convention with kill ledger. This is only to be used while killing ledger.
Can rename if you still think it is confusing.

@@ -269,7 +261,7 @@ impl<T: Config> StakingLedger<T> {
// kill virtual staker if it exists.
if <VirtualStakers<T>>::take(&stash).is_none() {
// if not virtual staker, clear locks.
T::Currency::remove_lock(STAKING_ID, &ledger.stash);
asset::kill_stake::<T>(&ledger.stash);
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
asset::kill_stake::<T>(&ledger.stash);
asset::unlock_all_stake::<T>(&ledger.stash);

nit

/// Mint `value` into an existing account `who`.
///
/// This does not increase the total issuance.
pub fn mint_existing<T: Config>(
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems to me that one goal of this module is to abstract the asset interface so that we can make the currency->fungible refactor and ensure the changes are concentrated in this module. I think this is a good idea. How about going a step forward and ensure the naming does not need to change in future designs of the inflation/rewards? E.g. in Plaza, we are not expected to "mint_into" but rather transfer or reward into an account. wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah makes sense. I can call it mint_reward? OTOH, this would be a simple rename in future so we probably don't need to worry about it much.

@@ -779,7 +779,7 @@ pub mod pallet {
status
);
assert!(
T::Currency::free_balance(stash) >= balance,
asset::stakeable_balance::<T>(stash) >= balance,
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
asset::stakeable_balance::<T>(stash) >= balance,
asset::free_to_stake::<T>(stash) >= balance,

Just an idea, as per my comment in the asset module.

@@ -619,7 +619,7 @@ pub trait DelegationMigrator {
///
/// Also removed from [`StakingUnchecked`] as a Virtual Staker. Useful for testing.
#[cfg(feature = "runtime-benchmarks")]
fn migrate_to_direct_staker(agent: Agent<Self::AccountId>);
fn force_kill_agent(agent: Agent<Self::AccountId>);
Copy link
Contributor

Choose a reason for hiding this comment

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

unrelated change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I backported some changes from #5501 to minimise diff in the other one. Earlier DelegationMigrator::migrate_to_direct_staker would kill agent + migrate to direct staker in staking. But due to the fungible changes this is not possible anymore (freezes can apply even without enough balance but for holds, we need to kill agent, transfer all funds from delegators to agent and then make it a direct staker).

It is also cleaner like this.

@paritytech-review-bot paritytech-review-bot bot requested a review from a team September 11, 2024 15:32
@@ -124,7 +124,7 @@ impl<T: Config> DelegationMigrator for Pallet<T> {

/// Only used for testing.
#[cfg(feature = "runtime-benchmarks")]
fn migrate_to_direct_staker(agent: Agent<Self::AccountId>) {
Copy link
Contributor Author

@Ank4n Ank4n Sep 17, 2024

Choose a reason for hiding this comment

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

renamed this since it does not actually migrate to direct staker anymore but only kills agent.

@Ank4n Ank4n requested a review from gpestana September 17, 2024 11:51
#[cfg(feature = "runtime-benchmarks")]
pub fn burn<T: Config>(amount: BalanceOf<T>) -> PositiveImbalanceOf<T> {
T::Currency::burn(amount)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This file is like a shim that makes the usage of LockableCurrency and Hold overlap, I can kind of see where you are going with this and it is good :)

Copy link
Contributor

@kianenigma kianenigma left a comment

Choose a reason for hiding this comment

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

LGTM as long as it is double checked to be a noop, I only checked asset.rs and not individual usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R0-silent Changes should not be mentioned in any release notes T2-pallets This PR/Issue is related to a particular pallet.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants