Multisignature for the root key

[DylanVerstraete]

Research if we can use multi signature keys for upgrading runtime, inserting policies , ...

[robvanmieghem]

If the root key is a SR25519 Schnorr signature, it supports native signature aggregation.

[DylanVerstraete]

We can use https://crates.io/crates/pallet-multisig in order to create a multisig account and set the multisig account as root key

[DylanVerstraete]

Adding this pallet enabled the following:

[DylanVerstraete]

We can use this: https://wiki.polkadot.network/docs/learn-accounts#generating-addresses-of-multi-signature-accounts

To generate a multisig account address and set that address as root account in genesis state

[robvanmieghem]

It are schnorr signatures, why would you need an extra pallet? Can't you update the sudo key without resetting the chain?

[DylanVerstraete]

First we can create a new sudo key which is multisignature using the multisig-pallet. Then we can set that address as the new sudo key. Sudo -> setKey

[DylanVerstraete]

In order to upgrade the runtime afterwards, both signers of the root key must sign the same transaction:

https://wiki.polkadot.network/docs/learn-accounts#making-transactions-with-a-multi-signature-account

[robvanmieghem]

Basic schorr signatures do not support a threshold to my knowing and pallet_multisig needs a new multisig account when the members change, and you would still need pallet_sudo to dispatch it in the runtime with the root origin.

Isn't using a council through the collective pallet more suitable?

I see you already use package = 'substrate-validator-set' to set the validators. This package supports the collective pallet for changing the validators .

Need to figure out the set_code integration with the council still. system::set_code needs to be called from the root origin but a small layer in between can arrange that I think ( pallet sudo is also just dispatching the call with the root origin).

Don't know if there are other extrinsics where we need the root origin for.

[DylanVerstraete]

Root extrinsics we need to support as well:

pallet tfgrid:

• set_farm_certification
• create_pricing_policy
• update_pricing_policy
• create_farming_policy
• create_certification_code

pallet tft bridge:

• add_bridge_validator
• remove_bridge_validator
• set_fee_account
• set_burn_fee
• set_deposit_fee

We can use the same code as in the validator pallet to also support the pallet collective in order to execute these extrinsics

[robvanmieghem]

We can use the same code as in the validator pallet to also support the pallet collective in order to execute these extrinsics

EnsureOrigin<Self::Origin> from frame support is indeed a handy feature

[robvanmieghem]

we can write a custom pallet to do runtime upgrades that just wraps the set code call with the pallet collective

Indeed, let's just integrate EnsureOrigin too and dispatch the call with the root origin, just like sudo does.

[robvanmieghem]

This is outdated by: DAO Council #159