Rationale

The community wants a good common-good parachain for handling identity verification. A parachain would be able to off-load the transaction processing and data storage burden for the relay chain. A common-good parachain also ensures that no new token is created, so it acts solely on the interests of the relay chain.

With a parachain, we can deal with identity verification at a much higher transaction frequency, which enables us to do things like per-item verification, on-chain identity data voting, PKI democracy and more. It will also allow us to iterate on the functionalities for identity verifications much faster, independent of the relay chain's runtime upgrades.

Several weeks ago I posted a vision document for an common-good identity parachain design. I also mentioned that it will probably "only happen in the long future". I was wrong -- from what I know, the community wants a common-good identity parachain soon! So, here I make a concrete plan for how the parachain might come into life.

The plan is aimed at being iterative. In each phrase, we do the work to get the next possible milestone done with something people can use. As a common-good parachain, this firstly would require network's council or democracy's (informal) approval. Me as the maintainer will work on this project in my free time and voluntarily, as I currently work for Parity. In the mean time, I think the community would support other teams to collaborate and to get paid by treasuries in Polkadot or Kusama.

Special thanks

Special thanks to those who participated in the original Polkaregistry discussions and to Hanwen from Litentry.

Goals

For visions and current end-term designs of the Polkaregistry Parachain, please see here.

Resources

• Current repository: https://github.com/polkaregistry/parachain

Plan

Phase 1: A parachain on the Rococo

This is the phase we're at now. The plan is to deploy a parachain, with the current identity module unchanged, to Rococo testnet. We do not handle data migration at this stage, meaning the relay chain identity module will exist with the parachain identity module in parallel.

Phase 2: New identity functionalities

We extend the current identity module with the following features:

• Democracy-voted PKI storage: This allows the community to signal that for real-name verification, what real-world identity is considered trusted.
• Per-item registrar verification: Right now, a registrar either verify a whole identity, or none of it. With per-item registrar verification, a registrar will be able to verify only a specific identity item.
• Additional identity items such as bio: Support additional identity items such as bio, which allows users to insert a blob of texts.
• Offchain storage: Allow user to input only a hash and a retrievable URI for a specific identity item, for those who what maximum privacy.

Phase 3: Frontend development

The new parachain identity module will require some frontend changes in polkadot-js to support it. We do not need much UI changes, but will need the frontend able to fetch identity data from the parachain, instead of the relay chain.

Phase 4: Validator-voting-based identity verification

This module change would allow us to move from a registrar-trusted setup to a more trustless setup. The parachain validator will vote on identity data each block, with the publicly-available proof. Substrate already has sufficient support for us to build this, and the main work is to write the proof fetchers in a reliable way.

Phase 5: Data migration

We need data migration scripts to eventually completely remove the identity module on the relay chain. So we need a fast and reliable way to transfer all the data.

Phase 6: Testing and mainnet deployment

With all the above is done, we can start the mainnet deployment!