Kusama Identity Registrar #1 - Why and How?

In a previous article, I submitted a motion to the Kusama Council proposing the registration of a new registrar on Kusama: Registrar #1. Unlike the name suggests, this is not the first registrar on Kusama. It brings a second registrar on the chain as we can see by querying the chain state of the identity module: 1. TLDR If you only want to jump to practical todos ignore the explanations, you may directly go to Certification process.

srtool now showing Substrate proposal hashes

I introduced srtool in a previous article. While the first implementation filled a gap and allowed for the first time users to verify substrate runtime wasm blobs, there was still work to do to improve the user’s experience. 1. Current verification process Up to now, the verification process looked like: a runtime dev works on some changes he builds the new runtime locally, preferably using srtool in order to get the SHA256 of the new wasm blob right away

Kusama Proposal: New Registrar

At the launch of the Kusama network, there was no way to identify who the owner of a given account was beside making your own research and adding a name to an account in the PolkadotJS UI. New solutions have been tested and the system is evolving. Background Address book Building your network of trust with the Address book looks like this: This would look as follow: Figure 1.

Substrate Runtime Toolbox (srtool)

Unlike all other Blockchains, Polkadot (based on Substrate) allows on-chain protocol upgrades without requiring the node operators to do anything but to keep their node up and running. If you know everything about Substrate Runtime, you may jump to the Installation section. In order to achieve this, Polkadot stores its runtime executable as a WASM blob in its own storage. If the WASM blob is replaced, the new runtime kicks in and all the nodes start using it, altogether.