Internal Module Accounts

[robert-zaremba]

Introduction

In ADR-28 we introduced a general mechanism for address generation which is safe to use with different key schemas. Mainly:

• The Module function creates an address which can be used by users (eg to send coins there).
• The Derive - a general function which can be used for more advanced constructions.

For module owned, internal addresses we have NewModuleAccount which operates on string. It is designed to take a module name as an argument to assure uniqueness. But it works with custom strings as well.

Problems:

• it kind of promotes to have only one module omnibus account, rather than multiple accounts
• doesn't have the conflict protection as the ADR-28 has. This is only unsafe if user input would be part of the name parameter for NewModuleAccount

Proposal

1. Add address.InternalModule which will return a special type: address.Module
2. Add to bank keeper.SendToInteranlModule which will require address.Module and will reject sdk.AccAddress
3. Deprecate auth.NewModuleAccount (without any precise date what we will do with it -- probably in the future we will fully migrate and delete it).

References

• Use ADR-28 addresses for module accounts #10225
• Implement ADR 028 and Address Follow-ups #7618 (nice to have section)
• ADR 028
• ADR-028 implementation: https://github.com/cosmos/cosmos-sdk/blob/master/types/address/hash.go