CAIP-10 Proposed Changes

[pedrouid]

CAIP-10 has received a lot of feedback within the last year including some criticisms over its structure. Many Twitter and Discord threads have been written about what would constitute an ideal multi-chain account identifier from which it has also generated new CAIP proposals (#50).

A lot of feedback has also been generated recently in an Ethereum Magicians thread: https://ethereum-magicians.org/t/chain-specific-addresses/6449

Additionally some polls were also created on Twitter: Poll 1 - https://twitter.com/SchorLukas/status/1404831686714613769 Poll 2 - https://twitter.com/pedrouid/status/1404869512512606218

From my perspective there is essentially a division between 3 main identifiers:

A - "0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1" (current CAIP-10)
B - "evm:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb" (updated CAIP-10)
C - "zUJWDxUnc5gJJSWFzxyKkmLp1dgyxiPYT3BrT4" (proposed CAIP-50)

From both polls and also from the Ethereum Magicians thread, the majority supports the identifier with format B.

This would mean that it would require the following changes:

1. change of endianness of CAIP-10 and using the same separator as CAIP-2

   specific@generic:middle → generic:middle:specific

2. update CAIP-2 namespaces to shorter and more recognizable names

   bip122 → btc
   eip155 → evm
   cosmos → cosm
   polkadot → dot

I propose that we make these changes to respective CAIP standards which are in DRAFT status with two separate PRs for each change and follow up with discussions for each.

[lukasschor]

I support these changes and we would be happy to adopt the updated CAIP-10 address format with Gnosis Safe.

[ligi]

I am also in favor of B (although I think we should keep eip155 and not evm as evm is to broad and eip155 is where the chainIDs are coming from) - but not really sure we should change CAIP-10 - this might be a bad precedence. I think it is better to create a new one and just let CAIP-10 die.

[pedrouid]

My motivation for changing CAIP-10 is mainly because we didn't finalize its status yet besides I wouldn't want to create another CAIP standard that doesn't offer much changes

While CAIP-50 is a more compact and efficient format than CAIP-10 by encoding all accounts in the same base and even introduces a checksum

CAIP-10 (both versions) attempt to preserve the same readability as the original account addresses by simply prefixing or suffixing the CAIP-2 chainId

[romeo4934]

I am in favor of B as well. It follows the same logic of CAIP-19 where we always start by the chain-id.

[bohendo]

I am also in favor of B (although I think we should keep eip155 and not evm as evm is to broad and eip155 is where the chainIDs are coming from)

In what way is evm more broad than eip155? I kinda like evm bc it specifies the execution environment. Maybe someday we'd use oevm or zkevm prefixes to specify evm-like optimistic/zk rollup execution environments, this gives a little extra info about the address's capabilities.

Can you point out any edge cases where eip155 is more clear or where an evm prefix would cause problems @ligi?

[ligi]

It is mainly about being future compatible - the EVM might live longer than chainID's. Also it is a separation of concerns. We take the number from the chainID introduced with EIP155 - not from the EVM

[oed]

@ligi to me the shorthands suggested by @pedrouid are just that, e.g. if you see evm in a CAIP-10 then it means eip155 is used. This shorthand name would be defined by each blockchain namespace anyway.

[ligi]

yea - it's a short-hand now - but can bite in the future. Be future compatible ..

[wyc]

This direction makes our work with did-pkh a lot easier. +1 to simpler and more recognizable representations.

[bohendo]

One suggestion: instead of using btc as the shorthand for UTXO-style chains, we can be a little bit less maxi here by specifying them as utxo. Then the namespace would specify the abstract chain type rather than an archetype. And it would be less likely to cause confusion than prefixing a litecoin address with btc:.

I'm going to tentatively move forward w this <namespace>:<chainId>:<address> format in valuemachine btw. I've been using vanilla addresses so far but need a better way to track assets as they move across chains.

Eth address: evm:1:0x1057Bea69c9ADD11c6e3dE296866AFf98366CFE3 Polygon address: evm:137:0x1057Bea69c9ADD11c6e3dE296866AFf98366CFE3 Bitcoin address: utxo:000000000019d6689c085ae165831e93:16EW6Rv9P9AxFDBrZV816dD4sj1EAYUX3f Litecoin address: utxo:12a765e31ffd4059bada1e25190f6e98:16EW6Rv9P9AxFDBrZV816dD4sj1EAYUX3f

I'm following @pedrouid's lead here btw & only using the first half the bip122 chain id (aka genesis/forked block hash). Not sure if that's a widely adopted standard but the full bip122 id is too annoyingly long.

[pedrouid]

this was one of the reasons that we first started with namespaces labelled after existing standards like eip155 and bip112 because we didn't want to introduce biases or "maximalism"

the issue with utxo is that it really isn't descriptive of the execution machine... there are other utxo chains that do not interface like btc while in this case all bip112 scoped chains interface like Bitcoin as the examples decribe for "Bitcoin", "Litecoin" and "Feathercoin"

[ukstv]

How do you feel about caip10: including also prefix for option B, so that one can understand it is account, not say an asset or something else that can exist on chain?

[wyc]

here are some design goals for consideration by the group:

• human readability: for many data formats that may have a developer one day look through them, it would be preferred to have human readable identifiers. while it reasonable to expect developers to know that evm:1 is mainnet ethereum, it's less so to expect understanding that utxo:000000000019d6689c085ae165831e93 is bitcoin mainnet.
• identifier length: if these are used at scale, across trillions of data packets, an extra 32 bytes (vs 4-5) could make a big impact.

re: https://en.wikipedia.org/wiki/Zooko%27s_triangle

[bohendo]

there are other utxo chains that do not interface like btc while in this case all bip112 scoped chains interface like Bitcoin as the examples decribe for "Bitcoin", "Litecoin" and "Feathercoin"

Which UTXO chains couldn't be identified by the hash of the genesis/fork block? If I understand correctly, Z-cash and Monero both have genesis blocks that could be hashed & used as IDs a la bip122. I'm not sure which other UTXO chains are out there tho tbh..

Either way, I agree w @wyc that utxo:000000000019d6689c085ae165831e93 is non-obvious & verbose & I'm not super gung ho about it.. Maybe we could use a slip44-style index so that bitcoin, litecoin, and dogecoin become utxo:0, utxo:2, and utxo:3 respectively (or prefix with slip44 or btc or something else entirely).. Slip44 was designed to for asset types tho so it's not a great fit here..

How do you feel about caip10: including also prefix for option B, so that one can understand it is account, not say an asset or something else that can exist on chain?

@ukstv CAIP-19 defines globally unique asset specifications & we can use some of these patterns to make this distinction. eg DAI could be evm:1/erc20:0x6b175474e89094c44da98b954eedeac495271d0f where the /erc20 after the chain id specifies the asset type & distinguishes it from account addresses.

[pedrouid]

@wyc when it comes to compactness and reducing bandwidth I think that CAIP-50 (#50) should be used instead which could be interpreted as a special encoding of CAIP-10

Another reason to not use utxo is that Polkadot namespace (dot) also uses the genesis hash but it doesn't share the same namespace as Bitcoin (btc) because they have completely different execution machines.

When you use any Ethereum (evm) chain you get to interface with it equally because the execution machine is the same.

That is why I would oppose to using utxo as a namespace

[oed]

@wyc when it comes to compactness and reducing bandwidth I think that CAIP-50 (#50) should be used instead which could be interpreted as a special encoding of CAIP-10

CAIP-50 wouldn't really help much in that regard though. You would still need to include all the bytes of the genesis hash.

[clehner]

How do you feel about caip10: including also prefix for option B, so that one can understand it is account, not say an asset or something else that can exist on chain?

Using a common prefix such as this, and conforming to URI syntax as options B and C appear to do, opens the possibility of using CAIP-10 identifier as URIs.

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

[pedrouid]

CASA Meeting #1 notes:

• change endianness of CAIP-10 has reached consensus by the majority
• renaming namespaces of CAIP-2 chains did not have majority consensus
• arguments were made during the call whether CAIPs are supposed to be targeted at end-users or developers
• the majority agreed that CAIPs aims to target developers and not end-users
• renaming namespaces provides such as eip155 to evm favors labelling chainId's by ecosystem rather than grouping them by different chain identifiers
• there was a split between a group that favored using namespaces to cover ecosystems such as EVM chains while another group favored using namespaces to cover different chain identifiers
• examples were made where an ecosystem would either more than one chain identifier standard or it would eventually migrate to a new one
• ecosystem-based namespaces would need to be dynamic and follow different chain identifiers and CAIPs would need to favor one or the other
• chain identifier standards instead favor that the namespace only concerns with one type of chain identifier and does not force one ecosystem to only use one
• in the end we asked again if anything was strongly opposed to keeping the same namespaces but there was not enough support

CASA Meeting #1 results:

• CAIP-2 namespaces will not be renamed as proposed in issue #51
• CAIP-10 endianness will change as proposed in issue #51

[ukstv]

Using a common prefix such as this, and conforming to URI syntax as options B and C appear to do, opens the possibility of using CAIP-10 identifier as URIs.

Exactly.

[bumblefudge]

Should've been closed by #59