Consolidate accountSpecifier terminology

[gomesalexandre]

Currently, we have some discrepancies in what we call an accountSpecifier.

In accountSpecifiers slice, they're in the form of a {[chainId: ChainId]: PubKey(ish)}, e.g:

• 'cosmos:cosmoshub-4': 'cosmosmypubkey'
• 'eip155:1': '0xgomespubkey'
• 'bip122:000000000019d6689c085ae165831e93': 'ypubMyYPub'

What's an account specifier then? a CAIP10? The value of this object i.e an AssetId/xpub/ypub/zpub?

It seems like the source of the confusion came from the fact that (x|y|z)pubs are not AssetIds as per the CAIP19 spec and from there, we just started referring to accountSpecifiers.

Also, given the shape of our accountSpecifiers slice, we refer to them alternatively as their key:value, or value, e.g:

value e.g "pubKeyish"

Here, we map on accountSpecifiers and destructure an accountSpecifier (?) from the value:

web/src/context/TransactionsProvider/TransactionsProvider.tsx

Lines 45 to 46 in 0e63e45

	return accountSpecifiers.reduce<AccountSpecifierMap[]>((acc, cur) => {
	const [_chainId, accountSpecifier] = Object.entries(cur)[0]

key:value

Here, we reconstruct what we call an accountSpecifier with key:value using selectAccountSpecifierStrings:

web/src/state/slices/accountSpecifiersSlice/selectors.ts

Lines 12 to 16 in 0e63e45

	// returns an array of the full `caip2:pubkeyish` type, as used in URLs for account pages
	export const selectAccountSpecifierStrings = (state: ReduxState) =>
	state.accountSpecifiers.accountSpecifiers.map(accountSpecifier =>
	Object.entries(accountSpecifier)[0].join(':'),
	)

As a temporary terminology, we've gone with pubKeyIsh:

• ad806de
• b185163#diff-bcccd934c3fc099ae907180ecdaa60f38a99865289682fc66896ddba29b6e817R13

But this is just bringing more confusion.
We should really have just one format of what we call an accountSpecifier, whichever it is, and we should make it clear whether or not that's a caip10, or a pubKeyish (what's a pubKeyish?), and stick to this spec whenever we refer to accountSpecifiers.

@elmutt and @DaoDev44 I know that you guys have had a lot of issues with this terminology during the Cosmos work and had some insights on consolidating/unifying what we call account specifiers, so happy to read about the outcome of these discussions here.

[0xdef1cafe]

i'll add some context here. myself and @mrnerdhair came up with this name in december.

CAIP10 defines an account_address https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-10.md

originally @mrnerdhair suggested naming them UnchainedAccountSpecifiers, which i found verbose, but in retrospect, would have been clearer.

the issue is related to unchained, and UTXO chains. we call unchained with x/y/zpubs for UTXO chains, which is closer to an account, rather than an address. bip122:00....:bc1asdfasdf does conform to caip10, but we can't call unchained with it. bip122:00...:xpubasdfasdf does not conform, but it's far more ergonomic to call unchained with this account-like identifier, rather than the client generating a large list of addresses from an extended public key, and making multiple calls/paginating until a zero balance address is found.

for account based chains (ethereum and cosmos so far), the account is the address. an ethereum or cosmos account specifier, as we know it, does conform to caip10.

Pubkeyish is closer, but still not on the mark.

in their current form, an "account specifier" of form eip155:1:0xdef1cafe... contains all necessary and sufficient information to know a) what chainId, and hence which chain adapter to use, which in turn calls an unchained http endpoint getAccount), and an "account Id" (using quotes, as i don't love this naming either), which is the param passed to said endpoint.

this comment above doesn't provide suggestion, but rather history and context as to how we got to this place, and some key requirements (encoding of chain id, and some sort of account... specifier/id) that's required to be able to call unchained, and uniquely identify accounts across chains.

[0xdef1cafe]

to add some further thoughts that might get us closer to a solution

we need to think in the cross chain domain.

• we have chainId's that are globally unique
• we have assetId's containing a chainId that are globally unique
• we should have accountId's that contain a chainId that are globally unique.
  • the chain specific address or x/y/zpub is necessary, but not sufficient, e.g. the same 0xfoobar address can have a different balance on eip155:1 (eth mainnet) and eip155:3 (eth ropsten)
  • we can't call it a CAIP10 either, as bip122:000...:xpubasdf is not a CAIP10
  • the store already has a one-to-many mapping of account -> address. in the case of eth/cosmos, the many is a list of length one. in the case of bitcoin it's a list of addresses with associated balances that roll up into that xpub.

my preference would be to settle on the term and type AccountId, which is globally unique and consistent with ChainId or AssetId

an AccountId would take the form chainId:0xfoobar or chainId:xpubasdf for ethereum and bitcoin as an example, but should generalize across all chains.

the 0xfoobar or xpub bit is the point of contention. i know @mrnerdhair will school me and rip me a new one on the semantics of a public key. Pubkeyish is definitely better than address or account, both of which are strictly wrong.

[mrnerdhair]

• It would be nice if we could use AccountId as a term, but it's already used by BIP44 to refer to the n in m/44'/60'/n'/0/0. We'll probably have naming conflicts with hdwallet if we overload it.
• An "account", at least from the perspective of an accountant, is a fairly abstract idea and not just a public key. Though it's not like the UTXO world is a shining beacon of nomenclature and organization, it's really a deficiency of EVM and Cosmos chains that they use only a single public key to refer to an account and we need to avoid baking in that assumption. For example, on EVM chains we need to consider accounts managed by contract wallets which have addresses with no associated pubkey, and there's already been at least some work in the Cosmos SDK universe about creating account types that can be re-keyed on the fly.
• xpub/ypub/zpub is insufficiently specific for the UTXO future, since taproot uses a different derivation path but still uses the xpub prefix. We get away with this only because unchained gets away with it because blockbook gets away with it because it doesn't support taproot, but it's not a long-term solution.
• Privacy coins will become a problem as well, because a "view key" isn't actually an address.

This is all sort of a dumpster fire. What we really need, though, isn't necessarily to solve for the philosophical definition of an "account", but for the specific information needed to query Unchained for the transactions associated with one. We could, for example, go strict CAIP-10 everywhere -- except that then we'd have to send Unchained a whole set of individual receipt and change addresses instead of one string, and that's not OK. So I still say we go with UnchainedAccountSpecifier, and try really hard not to do anything silly like with it like using it to build indexes over data.

[gomesalexandre]

Thanks for the replies frens!
Read it before bed and let my brain process all those (very detailed) comments.

First of all @0xdef1cafe , this is really great context you've provided, I didn't know that this terminology was created to accommodate for unchained expecting a format that's not compliant to the CAIP10 spec, which makes sense given we effectively need to augment the CAIP10 with more information that's in the spec. So in reality, what we need for unchained is effectively a UnchainedAccountSpecifier as @mrnerdhair suggested, and (correct me if I'm wrong) web does not need more than CAIP10s in most places except for unchained call sites. ### It just seems like that terminology eventually spilled over the whole codebase.

All the insights on "what's an account" are also very helpful, and I agree we shouldn't try to think in terms of crazy account abstractions - our current slice does a good job at that with our current requirements - if all we need is to have unchained-compliant account specifier strings. The rationale to that, as noted in the previous comment, is that there exists multiple different ways to abstract accounts, from the 0 abstraction "address === account", to the most recent EIP-4337 or smart contract wallets a la Gnosis Safe, and within that spectrum lays a whole lot of different ways to define an "account".

I like the approach of an UnchainedAccountSpecifier and going with CAIP10s almost everywhere, withUnchainedAccountSpecifiers used in one specific place for one specific purpose, querying unchained. This terminology would also remove the confusion WRT what a PubKeyish is as well as to why we need it (it is implied in the name).

[0xdef1cafe]

@gomesalexandre just make sure you understand we have this mapping in the portfolio. we can use CAIP10s for UTXO chains, but it means we have to store the balance for each account address, under some top level identifier, and aggregate it to be able to display a useful balance to the user.

https://github.com/shapeshift/web/blob/develop/src/state/slices/portfolioSlice/portfolioSliceCommon.ts#L74

@mrnerdhair i think we need to approach this from a developer and user perspective, not a bean counter one. a user with a UTXO account expects to see the aggregated balances of all the account addresses under that xpub, and a developer expects to be able to make a similar call.

@kaladinlight might be able to weigh in on the option of sending a different type of request to unchained, but ultimately, we still need some top level "account" type identifier to aggregate these account address balances into one.

i also disagree that the same term can't be used in two different contexts. the AccountId in the context of hdwallet makes sense, and it also makes sense in a different context in web.