Prefix Account store key by type

[fedekunze]

Summary

Add the account type to the Account key bytes to ease iteration over custom account types.

Problem Definition

Some apps implement a custom auth.Account (eg: ethermint's EthAccount or Kava's ValidatorVestingAccount). These apps usually have iteration logic over these accounts, but since Accounts are stored by their address on auth's AccountKeeper, they have to iterate over all of the accounts and cast the type to the concrete type in order to perform the logic.

Proposal

• Add a Type() string function to the AccountI interface
• Change the account key to the following:

// AddressStoreKey turn an address to key used to get it from the account store
func AddressStoreKey(accountType string, addr sdk.AccAddress) []byte {
	return append(AddressStoreKeyPrefix,  append(byte(accountType), addr.Bytes()...)...)
}

• Add Iterator for a given account type

cc: @karzak @alexanderbez

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[fedekunze]

I can work on this if there's consensus about the feature

[alexanderbez]

I think this is reasonable, but note, you may be able to just use the bech32 HRP instead of introducing Type().

[karzak]

+1 to this idea - we created a keeper in validator vesting that just stores the addresses of these accounts to avoid iterating over everything - would be nice to be able to do it directly.

[alexanderbez]

@fedekunze go for it, although I would check if there are more pressing items in the 0.39 board of higher priority before taking this on.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[amaury1093]

@fedekunze This is marked for v0.42, do you still want this for the next release? Do you have bandwidth to work on it?

[fedekunze]

Ideally we should include it for the next release. If someone could pick this that would be awesome 🙂

[aaronc]

Hmm... I don't really want to add this sort of complexity to address keys. What you're asking for is basically a secondary index. So why not create a secondary index instead of trying to overload address keys with a secondary index function?

Also, I would just note that with ADR 028 there might be different ways we think about module accounts...

[fedekunze]

So why not create a secondary index instead of trying to overload address keys with a secondary index function?

Is there an example on how to implement a secondary index for a given key on the SDK?

[tac0turtle]

closing this as it can already be done via indexes