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 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.
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.
Validators also can reduce security burden of frequent private key usage
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 ?
@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.
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.)
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.