B-Harvest propose a Community Fund expenditure of total 3,500 atom on developing New Subkeys Functionality by B-Harvest.
Subkeys Functionality allows users to create a SubKeyAccount with multiple SubKey, each of which has different permission setup on the SubKeyAccount. We expect it will create various good use-cases below.
- Users can create SubKeys of a SubKeyAccount each having different permission on tx types.
- A SubKey for daily casual usage with daily maximum spendable amount, which will greatly reduce the security burden of users.
- A completely/dynamically decentralized shared asset management scheme, which is possible via a SubKeyAccount generation without original public/private keys.
- Minimum deposit and maximum number of SubKey will effectively prevent spam attacks by creating excessive number of SubKeyAccounts or SubKeys.
We see more better use-case to come in the future as below.
- Blockchain service providers can demand users a SubKey of their accounts with very limited access. The service can perform various automatic tx generation features without exposing much risk of abusing client’s account.
- I believe the SubKey features will help to build algorithmic smart transactions such as ESCROW, DEX with less security burdens.
Detail spec can be found at New Subkeys Proposal Spec by B-Harvest · Issue #4480 · cosmos/cosmos-sdk · GitHub
We already did a deep research on how to deploy this functionality on Cosmos-SDK, so we are quite confident that we can show the alpha version in 2 months from starting.
Any discussion on spec, funding amount, paying schedule is welcome!
3 Likes
This functionality is mostly implemented and is already spec’ed out see Sunny’s issue here. In fact, some participants from a Cosmos hackathon in Paris implemented Sunny’s original spec as well, although they haven’t open a PR from their fork to the SDK.
I also honestly don’t think just the implementation of the upgrade is worth >$20k (at current price), unless B-Harvest is going to use those funds to pay for a security audit. I think this proposal will ultimately result in new auctions for who implements a spec for less price (even for free if you have an intrinsic motivation to implement it).
Finally, there’s currently no stablished template for how the community funds will be used in the case of development of new features (eg: security audit, number of devs involved, timeline, etc) and I think we should come out with a template/standard for that.
Sunny’s document is just a spec. It needs much more consideration of adjustment on the SDK side. We think it is 2 month job and we calculated with 2 × 10k dollars. I saw the implementation of hackatom. It is barely an implementation and has several flaws in logic.
The original spec was 3 months ago and I dont see any implementation from sunny, so I am curious why you said it is mostly implemented.
Also keep in mind that our spec is significantly extended from sunny’s original spec, including maximumdailyspendable, completely decentralized subkeyaccount, two protections from spam attacks. The structure of deployment is quite different to manage those new utilities. So it is not just an implementation.
If more dev thinks it does not worth it, we will back off. We cannot do it while losing our human resource.
Security audit is necessary when the functionality is applied in hub. I think it is a completely different subject and it needs another governance proposal. Basically developing functions are for the zones to use it for free(including the hub).
If we back off, I hope Sunny develop it as soon as possible so that community can enjoy the lowering of security burden
Thanks for working on this. I will review it more carefully, but one question that pops up with me often on this topic is:
What are advantages of providing separate subkey-enabled accounts compared to standard accounts? AFAICS a standard account can be represented as a subkey-account using some default values.
At least for Cosmos Hub at seems like we wouldn’t need both but should upgrade everybody to use subkey.
Regarding compensation I think this is valuable and much needed work for the Hub. Unless somebody is willing to do it at lower cost, 3500 ATOMs is not off the mark for the estimated 2 months work by a skilled team working in a developed nation. Since prices are still very volatile, bharvest has significant downside risk for next two months.
1 Like
AFAICS a standard account can be represented as a subkey-account using some default values.
I can’t understand what you mean here. Could you specify what you are trying to point out?
Also for pricing of funding, yes. If there is an entity confident enough to deploy the function with less price, we are happy to back off. I just hope those kinds of good utilities should not be delayed because of minor price difference and lack of community fund execution methodology.
We already have passed proposal about prime execution method, and we are happy to receive the atoms after deployment of the method. Not a blocking reasons.
From almost three months of mainnet so far, we dont see any attempt to use community fund and it has been accumulated almost 70k atom. (B-Harvest is just asking for 3 days of community fund accumulation) Discouraging deployment from community is not a good direction for us to be heading for the enriched library of cosmos-sdk.
@fedekunze Thanks for sharing your opinion. Could you confirm your opinion after comparing our spec and sunny’s(or Paris hackatom implementation) implementation? We are happy to re-adjust our price of building to 2.8k atoms(20% discount 
) if it is the major concern.
Also we will be appreciated a lot by other’s opinion as well. Please express thought! Thank you!
B-Harvest stops this Subkey feature implementation due to a similar feature being developed by gaian team, a winner of Berlin hackatom.
1 Like
Thanks for your efforts so far, BHarvest. You have once more demonstrated great commitment to the community and the betterment of Cosmos.
A follow-up question: Even though a great implementation of subkeys may exist in a repository somewhere, there is still a ways to go before it lands in the Cosmos-SDK and the Gaia application.
Is anyone driving that process now? Anyone from Gaians?
The puzzle of creating PRs, convincing the keepers of the SDK code to merge etc is a significant undertaking, I expect.
I think gaian hackatom repository will be continuosly used as a SDK implementation. You can follow up from there imo.
1 Like