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

Merged
merged 41 commits into from
Oct 7, 2024

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
/// 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.

Copy link
Contributor

@gui1117 gui1117 left a comment

Choose a reason for hiding this comment

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

PR is indeed no-op except for one benchmark which seems fixed.

@@ -131,6 +131,8 @@ fn migrate_to_transfer_stake<T: Config>(pool_id: PoolId) {
)
.expect("member should have enough balance to transfer");
});

pallet_staking::Pallet::<T>::migrate_to_direct_staker(&pool_acc);
Copy link
Contributor

Choose a reason for hiding this comment

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

this is not no-op, but it seems to be a fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is actually no-op as well. Previously, T::StakeAdapter::remove_as_agent would do the migrate_to_direct_staker implicitly.

@Ank4n Ank4n enabled auto-merge October 7, 2024 15:31
@Ank4n
Copy link
Contributor Author

Ank4n commented Oct 7, 2024

bot fmt

@command-bot
Copy link

command-bot bot commented Oct 7, 2024

@Ank4n https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7526196 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh". Check out https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 25-8b26308c-7ab6-4b68-91a4-eb8f509c9c3b to cancel this command or bot cancel to cancel all commands in this pull request.

@command-bot
Copy link

command-bot bot commented Oct 7, 2024

@Ank4n Command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh" has finished. Result: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7526196 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7526196/artifacts/download.

Copy link
Contributor

@seadanda seadanda left a comment

Choose a reason for hiding this comment

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

Largely nits, no blockers

@@ -322,24 +322,24 @@ fn automatic_unbonding_pools() {
assert_eq!(<Runtime as pallet_nomination_pools::Config>::MaxUnbonding::get(), 1);

// init state of pool members.
let init_free_balance_2 = Balances::free_balance(2);
let init_free_balance_3 = Balances::free_balance(3);
let init_stakeable_balance_2 = pallet_staking::asset::stakeable_balance::<Runtime>(&2);
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe worth a use here to shorten these since they're used a few times. Likewise in other files with the new functions


// Controller then changes mind and deregisters.
assert_ok!(FastUnstake::deregister(RuntimeOrigin::signed(1)));
assert_eq!(<T as Config>::Currency::reserved_balance(&1), 0);
assert_eq!(<T as Config>::Currency::reserved_balance(&1) - pre_reserved, 0);
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
assert_eq!(<T as Config>::Currency::reserved_balance(&1) - pre_reserved, 0);
assert_eq!(<T as Config>::Currency::reserved_balance(&1), pre_reserved);

@@ -289,7 +297,7 @@ mod on_idle {
);
assert_eq!(Queue::<T>::count(), 3);

assert_eq!(<T as Config>::Currency::reserved_balance(&1), 0);
assert_eq!(<T as Config>::Currency::reserved_balance(&1) - pre_reserved, 0);
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
assert_eq!(<T as Config>::Currency::reserved_balance(&1) - pre_reserved, 0);
assert_eq!(<T as Config>::Currency::reserved_balance(&1), pre_reserved);

T::Currency::total_issuance()
}

/// Total balance of `who`. Includes both, free and reserved.
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
/// Total balance of `who`. Includes both, free and reserved.
/// Total balance of `who`. Includes both free and reserved.

/// 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.

I would keep the "into" part of this here, as it's quite different from mint_creating.
mint_creating = mint into an account that you create
mint_into_existing = mint into an existing account that you don't create

So to me mint_into and mint_creating would make more sense if you want to keep things short, or just keeping the mint_into_existing pattern from before

@Ank4n Ank4n added this pull request to the merge queue Oct 7, 2024
Merged via the queue into master with commit 9128dca Oct 7, 2024
206 of 208 checks passed
@Ank4n Ank4n deleted the ankan/staking-migrate-currency-to-fungible branch October 7, 2024 17:20
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.

6 participants