Refactor Nomination Pool to support multiple staking strategies

[Ank4n]

Third and final PR in the set, closes #454.

Original PR: #2680

Precursors:

• Allow privileged virtual bond in Staking pallet #3889.
• Introduces: Delegated Staking Pallet #3904.

Follow up issues/improvements

• [Pools] Follow up issues/improvements for Pools open gov integration #4404

Overall changes are documented here (lot more visual 😍): https://hackmd.io/@ak0n/454-np-governance

Summary of various roles 🤯

Pallet Staking

Nominator: An account that directly stakes on pallet-staking and nominates a set of validators.
Stakers: Common term for nominators and validators.
Virtual Stakers: Same as stakers, but they are keyless accounts and their locks are managed by a pallet external to pallet-staking.

Pallet Delegated Staking

Agent: An account that receives delegation from other accounts (delegators) and stakes on their behalf. They are also Virtual Stakers in pallet-staking where pallet-delegated-staking manages its locks.
Delegator: An account that delegates some funds to an agent.

Pallet Nomination Pools

Pool account: Keyless account of a pool where funds are pooled. Members pledge their funds towards the pools. These are going to become Agent accounts in pallet-delegated-staking.
Pool Members: They are individual members of the pool who contributed funds to it. They are also Delegator in pallet-delegated-staking.

Changes

Multiple Stake strategies

TransferStake: The current nomination pool logic can be considered a staking strategy where delegators transfer funds to pool and stake. In this scenario, funds are locked in pool account, and users lose the control of their funds.

DelegateStake: With this PR, we introduce a new staking strategy where individual delegators delegate fund to pool. Delegate implies funds are locked in delegator account itself. Important thing to note is, pool does not have funds of its own, but it has authorization from its members to use these funds for staking.

We extract out all the interaction of pool with staking interface into a new trait StakeStrategy. This is the logic that varies between the above two staking strategies. We use the trait StakeStrategy to implement above two strategies: TransferStake and DelegateStake.

NominationPool

Consumes an implementation of StakeStrategy instead of StakingInterface. I have renamed it from Staking to StakeAdapter to clarify the difference from the earlier used trait.

To enable delegation based staking in pool, Nomination pool can be configured as:

type StakeAdapter = pallet_nomination_pools::adapter::DelegateStake<Self, DelegatedStaking>;

Note that with the following configuration, the changes in the PR are no-op.

type StakeAdapter = pallet_nomination_pools::adapter::TransferStake<Self, Staking>;

Deployment roadmap

Plan to enable this only in Westend. In production runtimes, we can keep pool to use TransferStake which will be no functional change.

Once we have a full audit, we can enable this in Kusama followed by Polkadot.

TODO

• Runtime level (Westend) migration for existing nomination pools.
• Permissionless call/ pallet::tasks for claiming delegator funds.
• Add/update benches.
• Migration tests.
• Storage flag to mark DelegateStake migration and integrity checks to not allow TransferStake for migrated runtimes.

[georgepisaltu]

Changes look good. The delegate staking tests need to switch to the new interface to become relevant, but it should be fairly easy as the testing logic should be the same, maybe a couple of extra corner cases here and there. Will re-review once that's done.

[georgepisaltu]

With the suggestion above it could just be:

Suggested change

	let maybe_pool = BondedPool::<T>::get(self.pool_id);
	if maybe_pool.is_none() {
	defensive!("pool should exist; qed");
	return Zero::zero();
	}
	let pool = maybe_pool.expect("checked pool is not none; qed");
	let pool = BondedPool::<T>::get(self.pool_id);

[georgepisaltu]

Option 1 is to have this weight function not take into account any slashing and only consume the weight later if necessary. We'd need a bench function for Self::do_apply_slash.

Option 2 is to have a new weight function that assumes worst case and then at the end refund any weight if necessary

#[pallet::weight(
   cmp::max(
      T::WeightInfo::withdraw_unbonded_regular(*num_slashing_spans),
      T::WeightInfo::withdraw_unbonded_with_slash(*num_slashing_spans)
   )
)]

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable 2/3
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6263801

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-digest-13-jun-2024/8598/1

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/any-update-on-voting-while-staking-in-a-pool/8589/3