People Chain Launch and Identity Migration Plan

As explained in RFC-32, we are working on migrating the Identity pallet and its functionality from the Relay Chain into a system parachain. This will be the first time that functionality is migrated from the Relay Chain rather than simply introduced.

After successful tests on both Rococo and Westend (the Rococo one revealing a small bug, and the Westend one working as expected), we are ready to start deploying this People Chain on production networks.

Everything will happen on Kusama first, and after a successful migration, will happen on Polkadot. This migration will be especially important to UI developers, who will need to source identity information from a new location. The change also comes with a 100x reduction in deposits, making the Identity system much more accessible to users. [1]

Phase 1: Genesis

At the moment of writing, the Kusama and Polkadot runtimes maintained by the Fellowship are based on Polkadot SDK v1.3.0. They will need to be on v1.7.0 for the migration to take place, so that will be the signal that everything is ready.

Once that is in place, we can do two things:

  1. Block Identity pallet calls in the Relay Chain;
  2. Create a People Chain runtime.

Once the Relay Chain upgrades (let’s call it v1.X.0), we will take a snapshot of all existing Identity state like account identities, sub-accounts, and registrars. This will form the genesis state of the parachain. [2]

Phase 2: Free Deposits

With the Relay Chain upgraded and a genesis state to work with, we can propose to actually register the People Chain. This will not quite be ready to use from the point of being onboarded, as we need to free up all the deposits held on the Relay Chain and update it on the parachain (at genesis there will be no balances on the parachain).

This will require a patch update of the Relay Chain (let’s call it Relay v1.X.1 [3]) that will allow any account to call a special extrinsic just for migrating identities. You can see an example of this on Westend.

This extrinsic will free the Identity deposit on the Relay Chain, calculate the deposit required on the People Chain (again, about 100x lower), teleport the parachain deposit, and add an instruction for the People Chain to reserve the deposit there. That is, users with 20 DOT reserved on the Relay Chain will end up with roughly 19.8 DOT free on the Relay Chain and 0.2 DOT reserved on the People Chain with their Identity Info and sub accounts preserved.

This process will look like this on the Relay Chain and People Chain, with identityMigrator.identityReaped and identityMigrator.depositUpdated events, respectively:

At the end, the Identity state will be off the Relay Chain:

image

To minimize downtime, I’d recommend setting the enactment time for the patch upgrade a few days after the parachain onboarding, such that users don’t need to wait for an entirely new referendum to pass.

Phase 3: Free Identity

Once all Identities have been migrated (and as this is permissionless, I expect it to take less than one day), then the People Chain can also upgrade (again, People v1.X.1 [3]). This upgrade will allow everyone to start using the Identity pallet functionality again.

Like the Relay Chain upgrade, this patch upgrade can also be scheduled to happen a few days after the Relay Chain’s patch upgrade.

Notes

[1] You can already start using it on Rococo and Westend.
[2] A script for doing that is in this PR. Note that it also migrates the additional data for those who have set github and discord fields.
[3] You can see these “v1.X.1” changes in this PR for Westend.

15 Likes

Is there a possibility of integrating a ENS like service with Identity here?

5 Likes

look at this Unique Usernames in Identity Pallet by joepetrowski · Pull Request #2651 · paritytech/polkadot-sdk · GitHub

2 Likes

@joepetrowski will the above changes shared by xlc, be live on Polkadot or its system parachain? I don’t see it currently.

Yes. You don’t see it because it’s not in the runtime yet.

1 Like

We really need to have functional user interfaces (UIs) before updating the Kusama and Polkadot chains. This is a screenshot of the experience when trying to set an identity on the Westend People chain.

Looks like something to report here.

It also looks like you are on the Accounts tab, could have nothing to do with Identity. That’s why they are on testnets and then Kusama before Polkadot.

Yes, it has been reported: Set Identity fails on account page · Issue #10540 · polkadot-js/apps · GitHub

We can set identity via the account page.

All I want to emphasize is the importance of having at least one functional UI before releasing new features on Kusama.

1 Like

Step 2 is now complete, meaning there is no more Identity info left on the Kusama Relay Chain. All deposits are updated (and much lower) on the People Chain (current Apps UI link).

Note that all front ends that use Identities need to switch @polkassembly @wliyongfeng @wirednkod @Tarik

Once 388 enacts then all functionality (including registrars) will be available on the parachain.

1 Like

Working on getting this stable in the Apps UI :+1:

PR is up to fix that bug you mentioned: Fix set identity on accounts by TarikGul · Pull Request #10581 · polkadot-js/apps · GitHub

With the enactment of 388, the Kusama People Chain is now ready for use. Users can now set/modify their identity there, request judgement, provide judgement, etc.

6 Likes

Everything is up to date and working for identities in Polkadot-js UI. The relay, and subsequent system parachains will all query the people chain for any identity needed.

3 Likes

anyone opening openGov ref for .ksm username suffix :eyes: at Kusama?

Is there any Identity Registrar that is operating on People chain now? I am trying to get verified but it seems all backends are still pointing to Kusama. Thanks