New CAIP profile: interoperable address binary specification

[0xteddybear]

No description provided.

[bumblefudge]

Suggested change

	This CAIP namespace aims to be a living & mutable repository of serialization methods for all chains to uniformly conform to Interoperable Addresses.
	This CAIP aims to append a living & mutable repository of chain-specific address serialization methods to the CASA system in the form of its namespace-specific profiles, enabling all current and future chains to uniformly conform to Interoperable Addresses.

[bumblefudge]

Suggested change

- Canonicity: CAIP-10, being a text format which leaves serialization to actual on-chain addresses undefined, makes no guarantees on a blockchain account (_target address_ in ERC-7930 parlance) having only one CAIP-10 representation, which makes them less useful as dictionary keys.

- Canonicity: CAIP-10, being a generic text format, leaves the canonization and serialization of ASCII address to on-chain addresses to each namespace's profile; unless a given namespace's profile specifies such logic, the standard itself makes no universal guarantees on a blockchain account (_target address_ in ERC-7930 parlance) having only one CAIP-10 representation, which makes them less useful as dictionary keys.

For the record, this canonicity issue HAS come up, but CAIP-10 was already final at the time and it was deemed unnecessary for EIP155 because EIP55 is pretty definitive and all known implementations canonicalize to checksum-case for deduplication purposes. See the Syntax section of the EIP155 profile of CAIP-10 for more detail.

[bumblefudge]

Suggested change

	- Succinctness: Text formats have an inherent overhead over binary ones when measured for information efficiency in a machine context.
	- Succinctness: Text formats necessarily have incur encoding "overhead" compared to binary ones, i.e. relative informational inefficiency.

[bumblefudge]

Suggested change

	It is possible that a CAIP-000 profile for a given chain namespace is not able to guarantee requirements of canonicity which are a desired property of Interoperable Addresses due to characteristics of the chain namespace, and systems relying on that canonicity may exhibit unexpected behavior as a result. When this is the case, it should be noted in the `Extra Considerations` section.
	It is possible that a CAIP-350 profile for a given chain namespace is not able to guarantee requirements of canonicity which are a desired property of Interoperable Addresses due to characteristics of the chain namespace, and systems relying on that canonicity may exhibit unexpected behavior as a result. When this is the case, it should be noted in the `Extra Considerations` section.

i wish we had written a section like this for CAIP-10 before it went to final 🙈

[jiexi]

Thoughts on splitting this into separate CAIPs, one for the binary representation of CAIP-2 and one for CAIP-10? If it's one CAIP as it is now, then the only way for me to reference this is "the CAIP-350 binary version of CAIP-2" or "the CAIP-350 binary version of CAIP-10". I think that may look awkward in code at minimum.

[u59149403]

We already have CAIP for binary addresses: CAIP-50.

Also, I don't see any point in binary ids at all. We can just use string id (i. e. CAIP-10) as binary. We just need to agree on case canonicalization. See my thoughts on case canonicalization here: #351

[u59149403]

Also, why we need text representation of CAIP-350? We already have CAIP-10. If you want to add checksum, just add checksum to CAIP-10 address.

Also, why checksum is so long? The only reason why we need checksum is for cases when people type address manually. (This is why bank cards have 1 digit checksum.) For such cases checksum should be as short as possible

[u59149403]

In CAIP context, the word "namespace" has different meaning. It means namespaces such as EIP-155, BIP-122, etc. See https://namespaces.chainagnostic.org/

[0xteddybear]

you're right, I meant 'profile'. Will edit this, thanks!

[0xteddybear]

addressed!

[u59149403]

This means we should fix CAIP-10 instead of introducing new standard

[bumblefudge]

i'm not sure it's fixable in general, given how divergent addressing and account models are across namespaces; each namespace needs to be profiled down and specify its own canonicity behaviors, in my opinion.

[0xteddybear]

update: this standard already defines the 'Extra Considerations' sections to deal with this, but added the possibility of address/chain collisions as a 'Security Consideration' of ERC-7930

[u59149403]

Also, a lot of CAIP-10 implementations for particular namespaces (i. e. CAIP-10 column at https://namespaces.chainagnostic.org/ ) have "Draft" status. (I didn't check, I think they all have "Draft" status.) So, we can still fix them and add canonicalization. Also, CAIP-50 has "Draft" status, too, so we can change it, too.

(Well, I think we are allowed to change all CAIPs, even final ones, because, as well as I understand, they are not adopted widely anyway yet.)

So, again: don't create yet another binary representation. Just contribute to already existing CAIP-50. Of course, we should add column, corresponding to CAIP-50, to https://namespaces.chainagnostic.org/ .

And, of course, don't create new text representation. We just need to use CAIP-10. CAIP-50 should get its own column at https://namespaces.chainagnostic.org/ , and it should describe conversion between CAIP-10 and CAIP-50.

And if you want checksum, just add it to CAIP-10. Yes, it has final status, but I personally think that we still can change it. Or, alternatively, just specify in ERC-7930 that address should have form CAIP-10 # checksum

[u59149403]

Also: 4 byte checksum is too big to be typed manually (I already said this), but in the same time too small to be cryptographically secure. I. e. 4 bytes is not enough to be sure that addresses equal based just on equality of checksums alone. I. e. malicious agent can easily craft address with same checksum.

So, again: consider using 1 byte checksum or even 4 bit checksum. (Bank cards use 1 digit checksum.)

And if your standard is not designed for users to type addresses manually, then don't add checksum at all

[0xteddybear]

Thoughts on splitting this into separate CAIPs, one for the binary representation of CAIP-2 and one for CAIP-10?

I see the point of this CAIP to be the algorithms for converting between the two representations and the namespace-specific ones, and from that point of view it makes sense to have specifications for the input and output of the algorithms live in the same place as the algorithms themselves.

For context, I imagined this CAIP as the one-stop-shop for developers trying to integrate with ERC-7930, and tried to make the life of said hypothetical developer as easy as possible. Although the developer is not hypothetical anymore, wdyt of this @0xJagger?

If it's one CAIP as it is now, then the only way for me to reference this is "the CAIP-350 binary version of CAIP-2" or "the CAIP-350 binary version of CAIP-10". I think that may look awkward in code at minimum.

Fair point. I'll try to come up with better names and define them normatively in the CAIP profile, would that work?

We already have CAIP for binary addresses: CAIP-50.

I gave CAIP-50 a look, and it struck me as:

• stagnant: no updates since 2020.
• incomplete: attempted to define namespaces' implementation inside the CAIP profile itself, instead of leaving it up to the different namespaces, and did not address the length limitations of CAIP-2 references, which can be a problem with standards such as ERC-7785

But otherwise it was a good inspiration. It would be a good idea to reference it as such.
The line on whether to re-write a standard or start a new one had to be drawn somewhere, and in my case I drew it somewhere in between ERC-7828 and CAIP-50 😁

Also, I don't see any point in binary ids at all. We can just use string id (i. e. CAIP-10) as binary. We just need to agree on case canonicalization.

That would be very inefficient for on-chain actors, having to use at least double the memory/storage.

Also, why we need text representation of CAIP-350?

• Avoiding the length limitations imposed on CAIP-2 (and to a lesser extent CAIP-10) outlined above
• Defining a grammar that's friendly to hierarchical names (e.g allowing for dots on the chain reference), which could be a stepping stone towards something line ERC-7828

Also, why checksum is so long?

Mainly I wanted to make the dreams of EIP-55 authors come true: https://eips.ethereum.org/EIPS/eip-55
('This is a ~50x improvement over ICAP, but not as good as a 4-byte check code.', in Rationale section)

The only reason why we need checksum is for cases when people type address manually

That is not entirely true, see my comment on the 7828 PR ethereum/ERCs#735 (comment)

thanks for your feedback @u59149403 @jiexi !, will make sure to tag you both when I implement your suggestions 😁

[u59149403]

@0xteddybear

• Avoiding the length limitations imposed on CAIP-2 (and to a lesser extent CAIP-10) outlined above
• Defining a grammar that's friendly to hierarchical names (e.g allowing for dots on the chain reference), which could be a stepping stone towards something line ERC-7828

Both these things should be fixed in CAIP-2.

• I think it is okay to make maximal length for CAIP-2 bigger, despite CAIP-2 is final. Because it is not implemented widely anyway
• We can surely add hierarchical names to CAIP-2 using namespace-specific versions of CAIP-2. Most of them are not final, and we can add new ones

[bumblefudge]

Also, a lot of CAIP-10 implementations for particular namespaces (i. e. CAIP-10 column at https://namespaces.chainagnostic.org/ ) have "Draft" status. (I didn't check, I think they all have "Draft" status.) So, we can still fix them and add canonicalization. Also, CAIP-50 has "Draft" status, too, so we can change it, too.

Namespace profiles are never final by design! They are also technically non-normative, fwiw, in IETF terms.

CAIP-50 was never officially marked as final because there are no known production deployments. Which brings me to...

(Well, I think we are allowed to change all CAIPs, even final ones, because, as well as I understand, they are not adopted widely anyway yet.)

CAIP-2 IS final, because there are many prod deployments that would break if changed.

I would rather CAIP-2 were extended by a new (ASCII-only) CAIP, personally, because introducing hierarchical strings of CAIP-2s would break some implementations that do not handle this case.

I have been tracking this "L3" issue for a while, as well as the "onchain alternatives to ethereum-lists/chains" issue, and there also exists a more "nuclear option", which would be creating a distinct namespace if the chainId system assumptions and guarantees change drastically enough. eip155 is literally the namespace of EVM chains that you connect to directly once you have an RPC endpoint and a chainId-- evm or eth could be an overlapping namespace (with most of the same chains in it) that assumes different addressing for chains, and allows you to recursively dereference ephemeral or secret chains from onchain data.

Same with the length requirement-- a longer alternative to CAIP-2 would be a breaking upgrade/"major version" for most existing implementations, so I would rather it were a new CAIP#, and implementations that don't make that upgrade can still be in conformance with a final standard.

@pedrouid @vandan may have thoughts on "breaking CAIP-2" 😄

[0xJagger]

For context, I imagined this CAIP as the one-stop-shop for developers trying to integrate with ERC-7930, and tried to make the life of said hypothetical developer as easy as possible. Although the developer is not hypothetical anymore, wdyt of this @0xJagger?

Yes, we're considering developing an interop wallet that supports both CAIP-10 and CAIP-2. I believe having a single CAIP that includes both algorithms will be more developer-friendly.

From the perspective of a new namespace looking to adopt the standard, I think it's simpler to implement one unified specification that includes both algorithms

[0xteddybear]

@jiexi pushed a new commit referencing 'Interoperable Addresses' and 'Interoperable Names', and also updated ERC-7930 to introduce the two concepts. I believe it should be easier to refer to them as:

Interoperable
├── Name
│   ├── Chain
│   └── Address
└── Address
    ├── Chain
    └── Address

let me know if that looks any better to you, would appreciate further input