ChainAgnostic
CAIP-50 - Multi-Chain Account ID Specification
Description
New account id specification with using multicodec format (alternative to CAIP-10)
Comparison
# Bitcoin mainnet
CAIP10 = 128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6@bip122:000000000019d6689c085ae165831e93
CAIP50 = zEbYEtEFFMZvVzJK3AWU5R5egEj1ep1yMVEWiWJ2FARDz
# Ethereum mainnet
CAIP10 = 0xde30da39c46104798bb5aa3fe8b9e0e1f348163f@eip155:1
CAIP50 = zUJWDxUnc8pZCfUtVKcAsRgxijaVqHyuMgeKKF
This still seems somewhat ambiguous from a binary perspective. You're string concatenating ascii, base-16, and base 64, into UTF-8. This is both inefficient from a binary size perspective and ambiguous in a binary encoding perspective. I mean, it does have that "visually easy to read" aspect, so maybe we're prioritizing that.
Are we intending these addresses to ever be read on-chain?
This still seems somewhat ambiguous from a binary perspective. You're string concatenating ascii, base-16, and base 64, into UTF-8. This is both inefficient from a binary size perspective and ambiguous in a binary encoding perspective. I mean, it does have that "visually easy to read" aspect, so maybe we're prioritizing that.
Are we intending these addresses to ever be read on-chain?
Hey @danfinlay, I was discussing with @oed about this proposal and it was clear that the previous proposal didn't bring enough improvements over the CAIP-10 to justify its replacement so we've completely changed it to introduce the multicodec version that was previously discussed on Discord.
Let me know what you think of the new changes 👌
I have published an NPM library for this CAIP-50 which encodes and decodes for BIP122, EIP155, Cosmos and Polkadot namespaces: https://github.com/pedrouid/caip-50
You can also see that in order to implement this I needed to maintain a mapping of encodings for each chainId and reference that currently looks like this:
const namespaces = {
bip122: {
code: 0x00,
namespace: "bip122",
encoding: {
chainId: "base16",
address: "base58btc",
},
},
eip155: {
code: 0x01,
namespace: "eip155",
encoding: {
chainId: "base10",
address: "base16",
},
},
cosmos: {
code: 0x02,
namespace: "cosmos",
encoding: {
chainId: "utf8",
address: "bech32",
},
},
polkadot: {
code: 0x03,
namespace: "polkadot",
encoding: {
chainId: "base16",
address: "base58btc",
},
},
};
Perhaps something to consider for how we should maintain a registry for CAIP-50
Is it possible/practical to maintain the registry within the multicodec registry itself? There's potentially a lot of other uses of chain multicodec identifiers so having a whole section in the multicodec registry for blockchains could have broad utility rather than maintaining a separate one just for addressing here. There was a time when various multiformats registries were maintained separately but they've been rolled into a single registry to avoid conflicts and to have a global namespace without conflicts. Multibase is separate because it's about string representations.
@rvagg I think that's a good idea and could bring a lot of benefits. I guess the main drawback for CAIP-50 specifically would be that we can't use the one byte varints.
Sounds good to me 👍
Cool, are you planning to do a PR to reserve a range inside of the multicodec table for them?
Maybe PR all the ones you have here in starting at 0x0500, there's a large amount of space above there and it's a long way off the 3-byte range so should be pretty safe for expansion. Probably stick caip-50 as the "tag" since we have that reserved as a multiformat now.
I'm not sure if the names will need to be more carefully namespaced though, e.g. polkadot -> polkadot-id. On the one hand these are intended for account IDs but on the other hand they have potential to be generic chain identifiers that are useful for other purposes. :shrug: I might leave that up to you and we'll see if others have objections.
