Repository files navigation

An updated version of the Validator Set module (pallet) that works with latest Substrate is available here -https://github.com/gautamdhameja/substrate-validator-set.

A Substrate runtime which allows addition of new validators in a pure PoA fashion. No tokens or stake needed, just the authorities have to agree. This is mainly for semi-trusted consortium chain scenarios where the validators are generally known entities.

The runtime includes a module calledValidatorSet which is an abstraction on top of the SRMLsession module. It adds logic to propose and add new validators; something similar to how the ValidatorSet contract in Parity Ethereum works.

NOTE: This PoA runtime sample is built on and compatible with the Substrate 1.0 version only. Please do not use it with any later versions or current master of Substrate.

• Clone this repo andcd into it.

• Set theValidatorSet genesis config in thesrc/chain_spec.rs file.The genesis config takes a list of validators. Each validator is represented by a combination of AccountKey (sr25519) and AuthorityKey (ed25519).

validatorset:Some(ValidatorSetConfig{validators:vec![(account_key("Alice"), authority_key("Alice")),(account_key("Bob"), authority_key("Bob"))]}),

IMP: The authority keys here are the session keys for the authorities and they should be exactly the same as what we have set in the genesis config of theconsensus module. Basically, in theValidatorSet module's genesis config, we are associating an AccountKey with the SessionKey of each authority.

For simplicity and easy reuse of same values across genesis config of several modules, we have defined a vec with the initial values and used it thereafter. See thetestnet_genesis function in thechain_spec.rs file for more details.

• Build Wasm runtime using./scripts/build.sh.

• Build the Rust binary usingcargo build --release.

• Run the first validator node by running the following command.

./target/release/substrate-poa --chain local --validator --key //Alice --port 30331 --base-path ~/tmp/a

Note: Theport andbase-path are set to custom values because we intend to run more than one nodes on the same machine for this example. You can choose not to set these params when you are running nodes on different machines.

• Run the second node by running the following command.

./target/release/substrate-poa --chain local --validator --key //Bob --port 30332 --base-path ~/tmp/b

Notice the change in thekey parameter in the above two commands. Also notice that we have passed the exact same keys which we had set in the genesis config.

Note: When running the node using a config other thandev we need at least two validator nodes for production of blocks to start.

With the above commands executed, we would have two nodes running on the same machine and they should produce blocks.

Follow these steps to add a new validator to the chain.

Connect any of the running nodes to the Polkadot Apps portal and create a new set of account and session keys which can be used for the new validator.

• Create Account Key:

• Create Session Key:

Note: You can do this using thesubkey tool as well.

Because theValidatorSet module depends on thesession module, it is important to associate the account and session keys in thesession module before we can add a new validator using theValidatorSet module.

In the extrinsics section of the Polkadot Apps portal, call theset_key function of thesession module by using the account key generated in the previous step as the signing key for this extrinsics call. Use the session key generated in the previous step as the parameter of theset_key function. See the following screenshot for reference.

Go the extrinsics section of the Polkadot Apps portal and select one of the existing validator account keys in theusing the selected account dropdown. This is the key using which the extrinsic would be signed.

Selectvalidatorset as the extrinsic section and selectproposeAddValidator as the function. Then select the newly created account and session key as the parameters. See the following screenshot for reference.

ClickSubmit Transaction.

• Repeat the above step using all existing validator accounts.

Note: For simplicity, we have made all validators required to propose the new validator. As an enhancement, this can be madem of n or any other threshold and can be made configurable too.

• Once all validators have completed theproposeAddValidator step, call theresolveAddValidator function from any of the existing validators.

When theresolveAddValidator extrinsic is finalized, the runtime should emit an eventValidatorAdded.

• Run another validator node with the seed of the newly created session key as thekey parameter.

./target/release/substrate-poa --chain local --validator --key 0xd79a78e28307d346a73439187fd9c5c8df122302f94a2ac5e9e1fbf1feb74ab5 --port 30336 --base-path ~/tmp/g

If all went well, the new validator should sync and should be able to produce blocks.

Following the exact same steps, you can add more validators to the chain.

Note: If you are running these nodes on separate machines then you should also add thebootnodes parameter with the address of one of the previously running nodes.

TheValidatorSet module also includes a functionaddValidator which can be used to add a new validator using the sudo function. This approach does not require all validators to propose the new validator. The new validator is added directly because of the root priviledges of the sudo function. See the following screenshot for reference.

Existing validators can be removed by following the exact same process - either using proposals or sudo.

To remove a validator using proposals, use thepropose_validator_removal andresolve_remove_validator functions similar to the proposal process for addition of validators described above. Allother validators should propose the removal of same validator and only after that theresolve_remove_validator function can be called.

To remove a validator using sudo, simply call theremove_validator function using the sudo key.

• The Substrate framework, related libraries and APIs are rapidly evolving. In case this module does not work with the latest Substrate build, please submit an issue in this repo.You can also try porting the runtime module into a freshly clonedsubstrate-node-template codebase.

• This code not audited and reviewed for production use cases. You can expect bugs and security vulnerabilities. Donot use it as-is in real applications.