AHM: Staking Migration Plan #7858

kianenigma · 2025-03-10T08:54:11Z

As the code for staking is almost e2e code-complete, we can draw a more concrete plan as to how the migration is going to work.

Already Done

Release `stable-2503`

Relay Chain

Everything else remains as-is

Asset Hub

Nothing

Release `unstable-AHM` (between `stable2503` and `stable2506` or just `stable2506`)

Relay Chain

Add migration controller
- migration code for pallet-staking
  - slash translation most notably, to deal with slashes that happen x <= SlashDeferDuration before the migration (just migrate UnappliesSlashes)
Add pallet-staking-ah-client
- A new DualSessionManager<Staking, StakingAhController> and switches them with fellowship signal
- A new DualOffenceHandler<Staking, StakingAgController> and switches them with fellowship signal
  - ah-client needs to buffer slashes if they happen and send them over

AssetHub

Add migration controller
Add pallet-staking-next
- Set with initial state of Forcing::ForceNone
- Needs to be completed, and old tests passing
- Bound all storages (Tracking issue for bounding pallet-staking storage items #255)
- Weights for client pallets + use in XCM messages
- Test that it is able to handle delayed+skipped sessions
- (NTH) cleanup: Fully remove controller, remove slashing spans
- (NTH) Code coverage
- Benchmark slashing part of on_initialize
- (NTH) [Staking AHM] Unbounded Era storage deletion at Era start block #7557
Add pallet-election-provider-multi-block::{self, signed, unsigned, verifier}
- (NTH) all storage items as lazy deleted
Add pallet-staking-rc-client
- Id handling
- More tests

Fellowship Signal

Relay Chain

Before migration is done, session manager is still Staking
While migration, set staking-classic to Forcing::ForceNone (likely okay to still the session manager)
- It will always remain in force-none, making pallet-election-provider-multi-phase do nothing.
After migration, session manager becomes StakingAhController

Specifically to test:

Audit that all staking transactions, which are still accessible right before and during the migration, are safe to happen
- Won't everything be simpler if we block all transactions? It will
- Your staking/proxy hold balance is migrated, now you come to unbond/poke-deposit. These are all nuances that might lead to bugs, and we can prevent all by blocking transactions during migration.
Test session indices being skipped + era duration and rewards
- Idea: Fellowship signal tells the staking to start the migration after the next era happens, ensuring migration starts at a clean state, at the start of the next era.
Test for slashing:
- Slashing post migration
- Slashes that happen before migration, but are enacted post migration (translated during migration)
- Slashes that happen during the migration (buffered and enacted on AH)

AssetHub

pallet-staking-next gets populated
- Set ForceEra to Forcing::NotForcing
- Important that we first populate system storage, and then user-based storage
- Most importantly, ActiveEra with its last known (RC) timestamp is set
Staking miner is up and running, funded, with monitoring and owner to monitor
set MinimumScore in election-provider

Note: All other staking pallets migrate as-is: pallet-fast-unstake, pallet-nompools, pallet-delegated-staking and pallet-bags-list

At this point, we need an easy to use AHM-dru-run tool, and test pretty much everything said above.

Kian and Ankan to spend 2 weeks trying to break the system

Misc Leftover Checklist

Systematize ZN tests
AHM-dru-run as noted above
Miner economics
Audit issues must be closed
@Ank4n and @kianenigma's letftover improvements in https://github.com/orgs/paritytech/projects/189/views/1 should be closed
- Most are covered above
Staking System Command Center (discussing with Paulo/Turboflakes to add it to his dashboard)

The text was updated successfully, but these errors were encountered:

kianenigma · 2025-03-10T13:59:33Z

Next steps:

@kianenigma bring back and merge pallet-staking-classic
@seadanda bring back migration pallets in prep for westend migration
@ggwpez prepare staking migration
(Zombie-*) testing

kianenigma · 2025-03-10T17:08:34Z

Dual Staking Pallets

We have decided to fully fork off the staking pallet, and have two versions of it. The outcome should be:

pallet-staking-next
pallet-staking-classic

Upon the migration of AHM, pallet-staking-classic will be on the RC, and it will be the old, single page code, only with some upgrades, as per the backport list below. pallet-staking-next will be on AH, waiting to be populated and start to work.

How we get there:

I will make everything that is in Add pallet-staking-ah-client to Westend and use it instead of pallet-staking #7658 be called pallet-staking-next.

Then, asking @tdimitrov to take over the task of:

Bring back an old version of pallet-staking, which should be as of stable2412 as pallet-staking-classic and merge it back to master
Make sure this has the following backported:
Make sure this is used across:
- All relay runtimes that don't have an asset-hub. For example, Westend, Substrate-node, test-runtime and so on.
- In all the tests for other pallets that rely on pallet-staking: sesssion, beefy, grandpa, babe, etc.
Backport this to stable 2503. This means in stable2503 there should be pallet-staking, there should be only pallet-staking-classic and pallet-staking-next.

Ank4n · 2025-03-10T18:24:21Z

And ideally at the first session of an era. Need a new method to signal limit who can set the code of an authorized upgrade, so fellowship/sudo can control this.

Alternatively, migration is scheduled by era, and the era change signals the start of the migration.

pallet-staking-ah-client should not send session-reports until the migration is over

This is okay but probably easier to not process xcm messages on AH (keep them in the queue) until migration is done? We probably have to do it otherwise as well?

Start migration (Fellowship signal)

If we go by above idea, fellowship schedules the migration era, or once they signal, migration starts on era rotation.

Ank4n · 2025-03-10T18:26:33Z

We have decided to fully fork off the staking pallet, and have two versions of it. The outcome should be:

pallet-staking-next
pallet-staking-classic

Not disagreeing, but what is the motivation for this?

Make sure this has the following backported:
#7685
#7581
#5501

Fungible migration is okay to do in AH as well. But should be done as part of AHM.

kianenigma · 2025-03-12T09:34:01Z

Some slashing storage needs to be translated as part of AHM

tdimitrov · 2025-03-13T13:11:53Z

@kianenigma I think we need to backport the staking pallet changes from #5724 too.
Otherwise validator re-enabling might not work.

Overkillus · 2025-03-21T17:36:06Z

kianenigma I think we need to backport the staking pallet changes from #5724 too. Otherwise validator re-enabling might not work.

This PR was merged before cutoff for 2503 so it should be included in it without a backport. Is there a different reason why we should backport it?

tdimitrov · 2025-03-24T12:31:54Z

kianenigma I think we need to backport the staking pallet changes from #5724 too. Otherwise validator re-enabling might not work.

This PR was merged before cutoff for 2503 so it should be included in it without a backport. Is there a different reason why we should backport it?

Ignore that. Initially we were planning to overwrite staking pallet with the one from stable. We are reverting PRs instead so this comment is no longer relevant.

@tdimitrov

#7939) Revert the following PRs which we are pulling from release stable2503: - #7582 - #7424 - #7282 and leave pallet-staking in its pre-AHM state. ## Context We are forking pallet-staking into `pallet-staking` (also referred as staking-classic, this is the version that will stay on RC) and `pallet-staking-next` which will live on AH post AHM. Additional context: #7858 (comment) These changes in crate `pallet-staking` will become the staking classic. The staking next version is worked in the PR #7601. ## For AHM migration The `UnappliedSlashes` storage will need to be translated from `rc::staking-classic` to `ah::staking-next`. [Bookmarking](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/staking/src/migrations.rs#L91) the code that can be referred for this. ## Follow ups (cc: @tdimitrov and @seadanda ) 1) Revert pallet-staking v17 migration in westend. - Update `in code storage version` of pallet-staking storage from 17 to 16 (separate PR). - Update `on chain storage version` of pallet-staking storage from 17 to 16. The storage key for pallet-staking on chain version is `0x5f3e4907f716ac89b6347d15ececedca4e7b9012096b41c4eb3aaf947f6ea429` which should be set currently to `0x1100`, and needs to be updated to `0x1000`. - After the runtime upgrade with the code from this PR is deployed on Westend, kill the following storage prefixes under the Pallet prefix `Staking`: - OffenceQueue - OffenceQueueEras - ProcessingOffence - UnappliedSlashes: This also exists in staking-classic as a storage map (one key) and in pre-revert code as double storage map (two keys). Killing with prefix `UnappliedSlashes` may kill the ones created post upgrade (but that's okay for westend). - VoterSnapshotStatus - NextElectionPage - ElectableStashes 2) Remove exposure dependency Worked in the PR: #7936. --------- Co-authored-by: Tsvetomir Dimitrov <[email protected]> Co-authored-by: Maciej <[email protected]>

@tdimitrov

#7939) Revert the following PRs which we are pulling from release stable2503: - #7582 - #7424 - #7282 and leave pallet-staking in its pre-AHM state. We are forking pallet-staking into `pallet-staking` (also referred as staking-classic, this is the version that will stay on RC) and `pallet-staking-next` which will live on AH post AHM. Additional context: #7858 (comment) These changes in crate `pallet-staking` will become the staking classic. The staking next version is worked in the PR #7601. The `UnappliedSlashes` storage will need to be translated from `rc::staking-classic` to `ah::staking-next`. [Bookmarking](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/staking/src/migrations.rs#L91) the code that can be referred for this. (cc: @tdimitrov and @seadanda ) 1) Revert pallet-staking v17 migration in westend. - Update `in code storage version` of pallet-staking storage from 17 to 16 (separate PR). - Update `on chain storage version` of pallet-staking storage from 17 to 16. The storage key for pallet-staking on chain version is `0x5f3e4907f716ac89b6347d15ececedca4e7b9012096b41c4eb3aaf947f6ea429` which should be set currently to `0x1100`, and needs to be updated to `0x1000`. - After the runtime upgrade with the code from this PR is deployed on Westend, kill the following storage prefixes under the Pallet prefix `Staking`: - OffenceQueue - OffenceQueueEras - ProcessingOffence - UnappliedSlashes: This also exists in staking-classic as a storage map (one key) and in pre-revert code as double storage map (two keys). Killing with prefix `UnappliedSlashes` may kill the ones created post upgrade (but that's okay for westend). - VoterSnapshotStatus - NextElectionPage - ElectableStashes 2) Remove exposure dependency Worked in the PR: #7936. --------- Co-authored-by: Tsvetomir Dimitrov <[email protected]> Co-authored-by: Maciej <[email protected]>

kianenigma changed the title ~~AHM: Staking Migration Plan~~ AHM: Staking Migration Plan Mar 10, 2025

kianenigma closed this as completed Mar 10, 2025

kianenigma reopened this Mar 10, 2025

tdimitrov mentioned this issue Mar 16, 2025

[AHM] Revert some AH-next staking changes from master #7937

Closed

3 tasks

Ank4n mentioned this issue Mar 20, 2025

[AHM] Revert multi-block election, slashing and staking client pallets #7939

Merged

ggwpez self-assigned this Mar 25, 2025

Ank4n self-assigned this Mar 28, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AHM: Staking Migration Plan #7858

AHM: Staking Migration Plan #7858

kianenigma commented Mar 10, 2025 •

edited by Ank4n

Loading

kianenigma commented Mar 10, 2025

kianenigma commented Mar 10, 2025 •

edited

Loading

Ank4n commented Mar 10, 2025

Ank4n commented Mar 10, 2025

kianenigma commented Mar 12, 2025

tdimitrov commented Mar 13, 2025

Overkillus commented Mar 21, 2025

tdimitrov commented Mar 24, 2025

AHM: Staking Migration Plan #7858

AHM: Staking Migration Plan #7858

Comments

kianenigma commented Mar 10, 2025 • edited by Ank4n Loading

Already Done

Release stable-2503

Relay Chain

Asset Hub

Release unstable-AHM (between stable2503 and stable2506 or just stable2506)

Relay Chain

AssetHub

Fellowship Signal

Relay Chain

AssetHub

Misc Leftover Checklist

kianenigma commented Mar 10, 2025

kianenigma commented Mar 10, 2025 • edited Loading

Dual Staking Pallets

Ank4n commented Mar 10, 2025

Ank4n commented Mar 10, 2025

kianenigma commented Mar 12, 2025

tdimitrov commented Mar 13, 2025

Overkillus commented Mar 21, 2025

tdimitrov commented Mar 24, 2025

kianenigma commented Mar 10, 2025 •

edited by Ank4n

Loading

Release `stable-2503`

Release `unstable-AHM` (between `stable2503` and `stable2506` or just `stable2506`)

kianenigma commented Mar 10, 2025 •

edited

Loading