feat: add block number for CTypes #440
Conversation
This reverts commit 8875d86.
runtimes/spiritnet/src/lib.rs
Outdated
| @@ -553,6 +553,8 @@ impl delegation::Config for Runtime { | |||
| type Deposit = constants::delegation::DelegationDeposit; | |||
| } | |||
|
|
|||
| type CTypeBlockNumberSetOrigin = pallet_collective::EnsureProportionAtLeast<AccountId, TechnicalCollective, 3, 5>; | |||
There was a problem hiding this comment.
i would argue that we should do that using a general vote and not the TC.
There was a problem hiding this comment.
By general vote you are referring to a referendum or the Council collective? I agree we shouldnt give special power to special entities.
There was a problem hiding this comment.
I don't see why the general public would be concerned about setting the preimage for a CType hash. Yes, it will probably be a one-off operation, but I don't see why we want to wait 2+ weeks to do something that only has technical motivations?
There was a problem hiding this comment.
Since the block number is set automatically, you would only need to trust the blockchain, that the number is correct. So trust the chain == trust that polkadot checks everything and the KILT governance(all token holders) is honest and fair.
If you allow the TC to set the block number you would need to trust them, that they set the correct number. It feels weaker.
Also since this should only be necessary once after the upgrade, i would say it's fine to wait 2 weeks.
William was suggesting we want to have a migration strategy for CTypes that mirrors what the Ethereum migration does. Do we still want to do that? I think in this case is probably unnecessary, but it is also true that this feature is not super high priority and could wait. |
I think it's not necessary. The current strategy is fine. |
Fixes https://github.com/KILTprotocol/ticket/issues/2327 and fixes https://github.com/KILTprotocol/ticket/issues/2325.
Adds a creation block number to future CTypes, and it introduces a
set_block_numberextrinsic that can be called by sudo on standalone and Peregrine, and by 3/5ths of the technical committee on Spiritnet (this can be changed if we agree to). I personally think that involving (part of) the technical committee is the right compromise between agility of action and decentralization. An alternative, more complex solution would be to implement an RPC function that verifies, given the block number and the ctype hash, whether there was a tx in that block for the given CType. This would be cool, and technically could also be feeless, but I am not sure it's worth the hassle.