[Proposal] 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

  1. Users can create SubKey of her account with restricted permission so that she can use it in everyday life without extreme security risk exposure
  • Thease SubKeys will greatly reduce the security risk of individual non-professional users.
  • Reduced security risk will result in great expansion of usage of mobile/web application because with SubKeys, users can feel much safer to store and use private keys in her mobile or laptop/desktop.
  1. SubKeys also can benefit the quality of dapp services by letting service providers hold their clients’ SubKeys with restricted accesses
  • Dapp services providers can safely hold their clients’ SubKeys and use it to generate transaction on the behalf of clients. It can allow users using dapp services even without using any key or signature.
  • If user does not trust dapp service provider, she can simply remove the submitted SubKey.
  1. Validators also can reduce security burden of frequent private key usage
  • Validators can attach multiple SubKeys on their validator account.(https://github.com/cosmos/cosmos-sdk/issues/3863)
  • Each SubKey can have restricted access, and validators also can rotate SubKeys by add/remove, so that validators can benefit from such reduced security risk.
  1. Decentralized asset management
  • Any group with variable member composition can control their asset effectively via SubKey feature.
  • For example, ICF can create various SubKeys and distribute it to their team members with respect to each member’s role. They can also add/remove SubKeys when there is a change in members or roles.
  • This decentralized control of asset management can be extended with more sophisticated way by deploying governance feature on top of the SubKeyAccount, original idea from Regen Network.(https://github.com/cosmos-cg-key-management)
  1. Completely decentralized delegation exchange using atomic swap

ETC

  • The content of this proposal is subject to change, and it is not final.
8 Likes

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.


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 this.

For ethereum case, there exists quite many multisig smart contracts widely used. But none of them is targeted as our subkey function want to achieve.

But, solidity is turing complete, so anyone can make any smart contract with subkey feature. We don’t have smart contract feature in Cosmos Hub, so it is difficult to compare with ethereum situation.

1 Like

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.

2 Likes

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.

1 Like

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.

1 Like

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

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