Module Account generation options after sdk v0.43.x

[dongsam]

Background

Based on the latest SDK v0.43.0-RC2 version, option address.Module()(code) to create a module account with a longer length of 32 was added, which is coexisting with the existing option authtypes.NewModuleAddress length of 20.

However, only the existing legacy module name(string) with existing 20-length addresses in SendTo or FromModule(), GetModuleAccount(), and ModuleAccountAddrs() in app.go, but 32 lengths of newly added rule module name + key patterns of address.Module() are not supported.

Questions and Discussion

1. Can I use it as option address.Module()(code) to develop a new module based on version sdk v0.43.x?
   To do that, the GetModuleAccount(), and ModuleAccountAddrs() in app.go functions need to be expanded to use both new and legacy module account options, not just string names of the module, is that right?

2. Can I set the module account dynamically with permission on on-chain logic that does not predefine the permission of the module account maccPerms in app.go?

3. Is The SDK recommended migrating existing 20 length accounts from apps, chains that will be upgraded to version sdk v0.43.x to a new module account with a longer length of 32?

[fdymylja]

Can I set the module account dynamically with permission on on-chain logic that does not predefine the permission of the module account maccPerms in app.go?

I don't think it's possible currently, although I'd been advocating to make that information part of state in order to make it dynamic, and not keep it in volatile keeper "state". Also, depending on the permissions needed, it would require keeper method modification (for example if you wanna forbid a module from calling a certain keeper method).

If we had ADR-033 we could easily introduce the RBAC module (developed here), to easily impose a granular, extendable and dynamic access control layer for modules and external clients.

Regarding the rest, I suppose @robert-zaremba is best suited to answer the questions.

[aaronc]

Unfortunately, we did not get around to aligning the new module account generation in ADR-028 with x/auth and x/bank in 0.43. I believe all those APIs need to be substantially upgraded and it is in our roadmap.

For the time-being, it should be possible to create an ADR-028 derived module account that can't directly mint/burn coins. This is what we will be using for group accounts.

We have not had an explicit stance yet on whether existing module accounts should transition from 20 to 32 bytes in the future when we support that. Probably it will be opt-in and legacy 20 byte module accounts will still work when needed. I don't generally like the idea of rewriting account addresses already in the store. If someone were to do that they would need to be very thorough with the migration.

Hope that helps.

[dongsam]

Thank you for your reply. Is there any possibility that the address.Module()(code) creation rule will be changed? Since the ADR-028 is still in the proposed stage, if there is a possibility that it will be changed in the future, the addresses consistency of the version may be broken, If so, it is likely that the existing 20-lengths account generation should be used first before the new 32-lengths rule is fully released.

Which version of the group module using this new length account do you expect to release?

[aaronc]

We had ADR 028 reviewed by a cryptographer and I don't expect it will change. @robert-zaremba what do you think? Maybe we can mark it as accepted.

The group module will use these addresses as soon as the code is merged into the SDK proper.