validator control key migration to a group key during hub-3 -> hub-4 chain upgrade

[Hyung-bharvest]

Summary

• cg key management feature is under implementation (https://github.com/cosmos-cg-key-management/community)
• cg key management feature allows any group account to dynamically manage its authoritiy
• dynamic authority control includes:

1. various level of authority for each member keys (MsgDelegation, Msg Authorization ADR cosmos-sdk#5235)
2. weighted multisig with governance property(Group, Group module spec cosmos-sdk#5236)

• group key as a validator operator key can enjoy great expansion of authority control by validator

Problem Definition

• to enjoy such security policy improvement, validators need to re-create the validator operator as a group account
• already existing validators are practically very difficult to transit its old validator operator to a newly made group account because of existing delegations
• delegators also need to unbond, send, bond again to enjoy the feature

Proposal

• suggest a procedure during hub-3 -> hub-4 upgrade as below
  • step1 : any validator or account owner can submit a newly made group account key with a signature using the old key
  • step2 : each migrated group account key will have a default policy of having the original key as the only member of the group account
  • step3 : the migration script replace all the relevant identity to the submitted group account key
  • step4 : launch hub-4 with migrated genesis
• above procedure should be executed in testnet before launch to minimize the malfunctioning or mistakes from migration submitted validators
• this migration submission should be also allowed from normal account which is not a validator account

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ethanfrey]

This is a good use of the fact we can arbitrarily change state at the upgrade points on the dumps.

To simplify it, I would just collect a list of opt in validator keys at step 1.

On the migration, for every opt in address, a group account is made with 1 of 1 policy and just that one key. The public key address is then switched with the new group address everywhere (validator control, delegation, account balance, etc).

The group account can then be modified after launch using typical transactions.

I prefer to force it to be identical at first, as this prevents any attacks... the conversion does not itself change the control of the account.

I also wonder about allowing this opt in for any account. Eg. If I have a account with 100k atoms delegated and i want to move to a 2 of 3 multisig, i need to unbond, transfer, and rebond. If we allow such a one shot group migration, I think it would make sense to allow anyone to opt in

[Hyung-bharvest]

@ethanfrey

• I agree that migration should use the simplest 1:1 policy so that we eliminate unnecessary complexity. In this case, steps are as follow.

  1. any validator or account owner can submit a newly made group account key with a signature using the old key
  2. the migration script replace all the relevant identity to the submitted group account key
  3. each migrated group account key will have a default policy of having the original key as the only member of the group account

• I suggested at the last sentence in proposal about allowing any account to migrate.

Thanks for sharing opinion! Updated the original request as suggested!

I hope this can be prepared parallel to the actual codebase implementation so that we can be ready to migrate requested addresses when we include the feature in official gaia SRM! Maybe about 2~3 weeks prior to the upgrade(good to have this on the upgrade governance proposal) so that we can spread the chance to enjoy this feature among validators.

[alexanderbez]

Thanks for proposing this @dlguddus. I now understand the issue and proposal. My main concern with the outlined proposal is mostly an operational one. That is, how do you plan on going about announcing, collecting, and verfying the "opt-in" accounts? This seems to me like it'll be an operational headache! In addition, people may miss out and get annoyed or upset.

Here is a braindump of initial thoughts/alternatives (I haven't dug into them in-depth):

1. Can we instead, in the migration, have all accounts simply be "group" accounts with the default 1-of-1 policy? What will this look like from a UX POV? Will anything change?

OR

2. Can we instead introduce a special tx, probably existing only in Gaia, that allows an account to convert itself?

Option (2) seems cleaner. I haven't looked at the implementation yet, only the pre-ADR, so lmk if this would not be feasible.

---

Side note/nitpick,

group key as a validator control key can enjoy great expansion of authority control by validator

We should try and stop using verbiage and nomenclature that isn't really present in the protocol or specs (i.e. control key vs operator key). This can lead to confusion. I, for one, am one of the main reviewers of this work and I get confused easily especially when we have 3-4 modules being worked on in parallel. So let's try and stick with the standard verbiage and nomenclature 👍

[Hyung-bharvest]

I fully agree with option (2), having a special tx to allow users transit their keys to group key.

Sorry for confusion. That was a wrong usage of terminology in the context. It should be validator operator key.

[ethanfrey]

option (1) is not a good idea:

a. how do we distinguish addresses - if the same address could refer to a group account or could refer to a public key account?
b. all txs change when using a group account - you can no longer sendtx, you need to propose a sendtx, vote for it, then execute once votes are tallied. They have a significant overhead, which adds security for those cases when needed, but a pain for those who got magically opted-in

Option (2) sounds much better:

Basically it is adding a tx to do what we would have done in the genesis migration. I also very much like the idea this is only in gaia, as it cannot be generalized. You must know all modules in the app, and for each of them find the references to the owner A and change it to group B. I do think such a Msg can be defined at the app level (not the module level).

My main question is gas cost - is finding delegation, proposal, vote, etc by owner always a O(1) operation - one read and write to get this? Or could it be O(N) - based on number of votes present? In general, the gas cost (db access) will be proportional to how many references the account has, but ideally independent of other data in the system.

[alexanderbez]

Yes, gas costs for this special tx will be expensive. I see no other way. I will look into the implementation details.

[mmulji-ic]

Please add your planning poker estimate with ZenHub @glnro

[okwme]

hey @dlguddus , this is an old issue, but it was b-harvest originally working on the three pillars work that included validator key rotation. is this something else? is that work linked here? otherwise going to clsoe this issue as it's quite old. will check back in a couple weeks.

[Hyung-bharvest]

yes, it is followed by validator key rotation. hence, i will close this. thank you for update.