Consider using account numbers from x/auth in state

[aaronc]

Summary

New modules might consider using uint64 account numbers in storage rather than 20-32 bytes addresses if the motivation is reducing storage.

Problem Definition

This issue is in reference to the bech32 global removal work (#13140) in which we would pass an address.Codec to modules for converting addresses to/from strings instead of relying on AccAddress.String and AccAddressFromBech32 which rely on the global bech32 config.

The main motivation for modules to do the conversion from bech32 addresses to bytes is to use bytes in storage which saves space. However, if we really want to save space we could use uint64 account numbers which x/auth automatically creates. Bytes addresses are generally 20 to 32 bytes long - not very succinct if we want to reduce storage. uint64 addresses would be much more compact. If we're passing around address.Codec anyone to do the conversion, modules could go one step further and use the auth keeper to get the account number.

Proposal

I do not recommend that existing modules refactor state to reduce storage space using this approach. New modules may want to consider using account numbers in state rather than addresses.

We may also want to add methods to the auth keeper &/or query server to make this easier for modules, ex. GetAccountNumberForAddress(ctx context.Context, addr string) (uint64, error) and a reverse lookup method for getting the account by number.

[alexanderbez]

Definitely worth considering, I'm not opposed to it! Although i see the two points as orthogonal. address.Codec will still be necessary, but in the context of x/auth, an integer can definitely make sense as the primary index 👍

[yihuang]

What's the implication for RemoveAccount and account with same address get created again, in that case, the new account has the same address but different account number.

[aaronc]

As far as I know there is no logic currently to prune accounts. But if there were, yes that could be an issue

[robert-zaremba]

This could be in particular interesting for the storage keys, when we put address as a part of a key.

[robert-zaremba]

One downside is that we would need to always read the account to map address <---> number

BTW, why not combining account.Codec with codec.Codec? We could have a rule there for AccAddress type (as well for other types, VaAddress.

[robert-zaremba]

What's the implication for RemoveAccount and account with same address get created again, in that case, the new account has the same address but different account number.

In that case, I guess you should just reset the previous account, because the association address <---> number should stay.