Hi Bryan,
Just wanted to follow up on Joyce’s answer to answer a few of your specific points, especially your questions about staking and recommendations for how this should be done.
We have a full list of pallets, their status and what needs to happen for them to run on AH here
We also have got the tracking issues on the project’s public GitHub board separated into verticals which you can check out for more details or for specific implementation details.
Someone more familiar with staking pallets to make up some plan.
This was our idea too - getting people who are best placed to determine the plan for each subsystem and then work through the intersections to get an overall plan for the whole system.
Staking
Staking on a parachain has been a project at Parity for over a year involving Kian, Gonçalo, Ankan and George (among others). Kian wrote the original staking system and Ankan and Gonçalo have been working on the staking system for around 2 years. They have designed and implemented the majority of the pieces required to transition to running on a parachain (more on those specific changes later).
Originally the project aim was left open as to which parachain it would be running on - recently the decision was made that it would be running on Asset Hub as part of the Plaza vision.
The way that staking on a parachain will be achieved has been planned out extensively by the staking team, with input from others and then combined with expertise in the other areas affected to create the overall migration.
All of the major changes in staking are related to:
-
how validators are elected
-
how election results are communicated to the Relay Chain
-
how slashes are communicated and enacted from the Relay Chain to AH
Much of this is a direct result of moving to a parachain, where there are different implications of overweight blocks on AH vs the RC - currently on the relay chain staking works by just accepting that sometimes it will produce overweight blocks, but if this were to happen on Asset Hub it would stall. We are putting bounds on storage, paginating where needed, and allowing the elections and snapshots to run across multiple blocks.
As far as the staking API goes: for any staking user (end user, liquid staking etc) the interface is the same, albeit on AH instead of RC. From this perspective the same staking pallet will be migrated and be running on AH. This means that during the migration, you just need to switch the liquid staking solution over from RC to AH. There will be an entry in the supervisor pallet’s state to note the stage of the migration.
The only major exception to this is that we are also tackling the long standing issue of nomination pool funds not being held in user accounts. We are changing this during the migration, and therefore allowing these funds to be usable in governance. This will impact wallets, as the funds staked in nomination pools will suddenly re-appear in the user account as an amount on hold.
The only detailed change for normal stakers would be that validators would have to set their session keys in relay, and the rest of the operations will happen as-is, just on AH instead of RC (validate, set_commission, etc.)
Overall migration
For the migration, we determined what needed to happen for the migration to be successful for staking and other parts of the system, discussed several options of how that would work and went through many steps of iteration to work out the kinks and where things overlapped to ensure that we have a smooth transition of the system as a whole. We considered going in multiple stages in the early discussions but after exploring it a bit we realised that it is much cleaner to do it in one go for a range of factors.
I’ll not go too deep into those now, but on a high level:
-
It’s not always possible to disentangle each pallet with a balances dependency from the others e.g. locks can overlap, so migrating one pallet’s lock and the associated funds without the others means there are cases where the account no longer has the balance remaining to have the other locks.
-
Migrating staking moves 51% (currently) of the total issuance away from the chain where governance is ongoing - by moving staking or governance first and leaving the other behind would mean that the amount of funds usable for voting is diminished. This can be solved by either changing the curves or writing some method of remote locking, but the extra work and complexity can be avoided by just moving them together in one step. Since governance is relatively easy to move, we decided to go for this option.
Taken from a slide from my presentation at the parachains AHM AMA that we ran in November:
-
Add functionality to AH
-
Special supervisor pallet in runtimes to handle migration of state via XCM during one special era
-
Balances: Account by account, unlock, transfer, re-lock
-
Pallet states: chunked basically 1to1 replication
-
Referenda calls: converted where possible, sent back to RC where not possible
-
Extrinsics to recalculate deposits/locks (decreasing) called by bots
Staking migration
Election pallet - no need to migrate, recreated every era
Bags list - does not need to be transferred, can be recalculated, but needs to be done before the next snapshot
Staking migration steps:
(block new election signal if we overrun)
What calls will be disabled at which steps?
The Staking and Governance calls in particular will be disabled on the relay chain from the start of the special era in which this will all happen. These filters will remain on staking on the relay chain until the pallets are removed.
The supervisor pallet will control the flow of the overall migration and each of its subtasks. A rough order of operations is the following:
-
Temporarily filter all calls affecting balances, staking, governance or other pallets which are moving to avoid the state changing mid-migration
-
Migrate as mentioned above
-
Remove the call filter on calls temporarily filtered that are still allowed (broadly this is just the following pallets: Balances, Multisig, Proxies, HRMP ops and parachain registration)
Remove the state which has been migrated
Remove the pallets that have been moved
Require all offchain applications to support AH.
I would love to be able to do this, but alas I don’t know how this could be achieved. Since this requires an investment in time and/or infrastructure by all those applications it is unlikely that everybody could be induced to switch before they need to, as other business cases would take priority. A lot of weight is in the word “require” - the three step plan that Joyce shared above aims to maximise the number of projects that we have in place to incentivise parts that could still be done on both before removing the functionality completely. For things like staking and governance it doesn’t make sense to have them in two places at once. Requiring people to support AH to me is the same as announcing that this is happening (Sept 2024), communicating it well (subjective but continuing) and providing time, testing and support for the transition.
If there’s any part of that where we could step up let us know! Otherwise we’re trying to get support and guides/tutorials up with time for people to migrate, while also making it a priority to move everything such that we have all the benefits that this brings ASAP.
