[PROPOSAL][ABANDONED] Adding SubKey Feature to Cosmos-SDK and apply it to the Hub

Who is proposing? • B-Harvest and Sikka proposes this governance proposal together. What is this proposal for? • Ask community whether we need the SubKey feature on Cosmos-SDK and also on the Hub • Pass of this proposal will trigger further implement plans and ultimately inclusion of feature on SDK What is SubKey feature? • Definition : Allow users to create SubKeys of an account with different permissions • Original concept of SubKey is from @sunnya97 Must-Have Features • An account can have multiple SubKeys • A SubKey can have multiple permissions • Management(add/remove) of SubKeys • Management(add/remove) of permissions • Feature to create a SubKeyAccount whose public/private key is unknown (There is no masterkey for the account) • Daily spendable amount feature (a SubKey cannot spend more than daily limit spendable amount) (amount can be configured for each SubKey) • SubKey feature must have spam prevention method (limit on maximum number of SubKey, minimum deposit for each SubKeyAccount) Benefits of SubKey feature • Users can create SubKey of her account with restricted permission so that she can use it in everyday life…

Excerpt (1192 of 3440 characters). Read the whole post on the forum ↗

It seems extretemely interesting. Is there any similar feature already implemented or specified elsewhere (e.g. Ethereum) so we can compare and check the pros and cons based on previous experiments / implementations ?

@jleni shared below bitcoin bip relating key management. github.com bitcoin/bips/blob/master/bip-0032.mediawiki#use-cases ``` RECENT CHANGES: * (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage) * (30 Apr 2013) Switched from multiplication by I<sub>L</sub> to addition of I<sub>L</sub> (faster, easier implementation) * (25 May 2013) Added test vectors * (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions. * (24 Feb 2017) Added test vectors for hardened derivation with leading zeros <pre> BIP: 32 Layer: Applications Title: Hierarchical Deterministic Wallets Author: Pieter Wuille <[email protected]> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032 Status: Final Type: Informational Created: 2012-02-11 License: BSD-2-Clause </pre> ``` This file has been truncated. show original I think this bip is rather about very restricted subkey feature which is the only way for bitcoin network, but not in the case of our network. @jleni please point out if I am wrong about…

Excerpt (1194 of 1554 characters). Read the whole post on the forum ↗

ddrdrck:

It seems extretemely interesting. Is there any similar feature already implemented or specified elsewhere

The general concept of delegating a subset of authority to a set of constrained subkeys is found in several systems:

• Object capabilities (a.k.a. OCap): through revocable forwarders / membranes
• X.509 PKI (also SPKI/SDSI): through certification hierarchies and constraints
• Authorization programs / “smart contracts”: via programmatic policy
• Macaroons / Vanadium: via caveats (see Vanadium Authorization)
• YubiHSM2 “capabilities”: via bitflag ACLs

Any number of ideas from these systems might be applicable here.

Does this proposal allow for rotating the consensus keys for a validator?

@roman Unfortunately it does not. afaik, current cosmos-sdk only allows 1:1 pairing of valoper and valconspub, so rotating consvalpub will cause validator to also change the valoper.

I think we need independently different approach to provide the rotation of valconspub. One easy approach is allowing to change valconspub from edit-validator msg, but not sure about any security vulnerability about it.

@iqlusion thank you for your knowledgable reply!

From a technical perspective (and validator operator perspective) I see this proposal introducing a lot of complexity (technical and UX) with little gain to the common use case.

In order to allow rotating valconspub, we need to make sure the slashing module is aware that the delegations to that validator can be slashed for faults under both keys for 21 days.

I just want to add that Polkadot (see https://wiki.polkadot.network/en/latest/polkadot/learn/staking/#accounts) also leverages a multikey system with different access rights and that I find this something highly useful. Especially for institutional users, it’s kind of a must have.

I checked the document. I think the SubKey feature is superior for long term because it is more flexible and detailed. Polkadot case only covers very general access categorization and does not allow more detail approach.

SubKey is mostly for delegators and users, dapps, and service providers, but not for validators. definitely it needs client side UI upgrade, but the use-case advantage of users will exceed the inconvinience when frequency of private-key usage hike for normal users(imagine several times a day, or even some dapps might need it online 24 hours.)

Can someone point me to the current work/design for subkeys? Is the pr spec the latest work or has there been updates since then?

Bharvest version is in spec phase, Regen network version in PR stage

cosmos-cg-key-management/cosmos-sdk

:chains: Blockchain Application Framework :sparkles: - cosmos-cg-key-management/cosmos-sdk

Awesome thanks! I noticed the Bharvest subkey issue has been closed, is continued work planned? Also, do you know if there is any documentation for the Regen network version?

We think regen version is a superior version of ours. That is why we closed the issue as now. Therefore , no we dont have plan to continue our implementation. Instead, we are tracking, reviewing and possibly suggesting features and implementation detail on regen version.

Regen spec : https://gist.github.com/aaronc/b60628017352df5983791cad30babe56