Add ERC: Interoperable Addresses #1002
Conversation
ERCS/erc-X.md
Outdated
|
|
||
| ## Guarantees provided by the standard | ||
| - Any future Interoperable Address will be trivially convertible to Interoperable Address v1 (specified below), which, together with the point below, makes them a canonical representation for users who need to treat them opaquely. | ||
| - Two Interoperable Addresses, converted to this canonical version, will be bitwise-equal iff they represent the same _target address_. |
There was a problem hiding this comment.
| - Two Interoperable Addresses, converted to this canonical version, will be bitwise-equal iff they represent the same _target address_. | |
| - Two Interoperable Addresses, converted to this canonical version, will be bitwise-equal if and only if they represent the same _target address_. |
Just for clarity. Some people are not familiar with the abbreviation.
ERCS/erc-X.md
Outdated
| : 1-byte integer encoding the length of Address in bytes. | ||
|
|
||
| Address | ||
| : Variable length field containing the binary format of the address component. For EVM addresses this is always 20 bytes, for serialization details of other types of addresses see [Appendix B](#appendix-b-binary-encoding-of-addresses) |
There was a problem hiding this comment.
For EVM addresses this is always 20 bytes
This statement would be an issue in the event of an address expansion upgrade. There are no concrete plans to do it and it's not clear it can be done, but there's definitely interest in it. Consider that EOF has been designed in a way that ensures compatibility with address expansion such that contracts shouldn't assume that addresses are 20 bytes. So I do think we need to be careful here.
We have two options:
- Represent addresses in 32 bytes like in the EOF EVM.
- Represent pre-expansion addresses with 20 bytes, but clarify that other lengths may be possible in the future.
There was a problem hiding this comment.
good catch! given this standard will easily be able to represent 32 byte addresses if they are ever implemented, I'll lean on the second option
There was a problem hiding this comment.
I'd remove the mention of EVM here and explain this in more detail in the appendix:
| : Variable length field containing the binary format of the address component. For EVM addresses this is always 20 bytes, for serialization details of other types of addresses see [Appendix B](#appendix-b-binary-encoding-of-addresses) | |
| : Variable length field containing the binary format of the address component. For serialization details of different types of addresses see [Appendix B](#appendix-b-binary-encoding-of-addresses) |
ERCS/erc-X.md
Outdated
| <human readable name> ::= <account>@<chain>#<checksum> | ||
| <account> ::= [-:_%a-zA-Z0-9]* |
There was a problem hiding this comment.
This section uses "account" but the paragraph below uses "address". Which one should it be? Let's make it consistent.
There was a problem hiding this comment.
Reasonable. I wanted to use 'account' so the 'address' concept remains coupled to Interoperable Address, but 'account' is never really defined in this document so I'll stick to 'address' for consisntency I think
ERCS/erc-X.md
Outdated
|
|
||
| In the human-readable name, it should be displayed in full and base58btc-encoded, as returned by the node. | ||
|
|
||
| Note: CAIP-2 limits chain references to 32 characters and instructs to only use the first 32 characters of the base58btc-encoded genesis block 10000 hash, therefore converting to it will require truncating the reference, so converting _from_ actual CAIP-2 to this standard is potentially ambiguous |
There was a problem hiding this comment.
I've already commented on this in ethereum/L2-interop#30 (comment) but I'm raising it again because we still haven't resolved what to do about it.
I think "ambiguity" is an understatement. If I have a CAIP-2 id I can't convert it to a chain id of this kind without additional information.
There was a problem hiding this comment.
thanks for bringing this up again. I'll define anoter CAIP profile which will take care of:
- defining how to serialize addresses
- choosing the two-byte identifier for the namespace
- defining how to serialize the chain reference
I imagine the mapping from short/text to long/binary ids can be defined as part of the last item? that'd mean moving choosing between potential hash collisions to the social layer.
Alternatively we could just not solve it, I don't think it'd be too problematic since users are very unlikely to type out caip-2 identifiers directly, and I find it hard to imagine a context where you start from the CAIP-2 string, have to produce an Interoperable Address, and can't afford a dictionary to map between the two.
What other solutions do you have in mind?
There was a problem hiding this comment.
update: given that this has to be defined for every chain namespace, there's the obvious solution of specifying how to truncate the blockhashes in this document 😀
Since solana does not actively mine collisions on the first bytes as bitcoin does, and AFAIK does not have competing forks, the first few bytes are likely to remain meaningful. wdyt? Am I missing something?
ERCS/erc-X.md
Outdated
| @@ -0,0 +1,321 @@ | |||
| --- | |||
| eip: X | |||
There was a problem hiding this comment.
| eip: X | |
| eip: 7930 |
Please update the file name too!
ERCS/erc-X.md
Outdated
| <checksum> ::= [0-9A-F]{8} | ||
| ``` | ||
|
|
||
| Where: | ||
|
|
||
| Chain | ||
| : String representation of CAIP-2 blockchain identifier, recovered from the binary representation described in [Appendix A](#appendix-a-binary-encoding-of-caip-2-blockchain-id) | ||
| : String representation of CAIP namespace, recovered from the binary representation described in [Appendix A](#appendix-a-binary-encoding-of-caip-2-blockchain-id). In the case where `ChainReferenceLength` is zero, it should be the empty string. |
There was a problem hiding this comment.
-CAIP-2 blockchain identifier
+CAIP namespaceIs this right? Namespace sounds wrong to me. A namespace would be for example eip155. I do think we want the CAIP-2 blockchain identifier here, e.g. eip155:1.
There was a problem hiding this comment.
you're right, good catch! I've rewritten this part to display the chain type (which actually is the chain namespace 🙃 ) in the case where the chain reference is not actually defined, which came up as an inconsistency when prototyping the wallet
ERCS/erc-X.md
Outdated
|
|
||
| #### solana | ||
| Solana networks are distinguished by its genesis blockhash, which is to be decoded from base58btc and stored raw in the binary representation and without removing any leading zeroes: | ||
| Solana networks are distinguished by its genesis blockhash, which is normally represented as 44 base58btc characters, corresponding to 32 bytes. We chose to perform the same truncation as CAIP-2[^2] to keep representations trivially convertible between the two, making them also visually identical. |
There was a problem hiding this comment.
I think we should be consistent in the decision to truncate ids following CAIP-2 or not... Currently eip155 and solana are treated differently.
I'm not fond of truncation, so unless we know of scenarios where it will be necessary to convert CAIP-2 ids to interoperable addresses I think I would avoid truncation altogether.
ERCS/erc-X.md
Outdated
|
|
||
| ## Appendix B: Binary encoding of addresses | ||
|
|
||
| ### eip155 | ||
| Bytes of evm addresses are trivially stored as the payload. For text representation, the EIP-55 format MUST be used. | ||
| Bytes of EVM addresses are trivially stored as the payload. | ||
| It's worth noting that addresses are currently 20 bytes, but that might change in the future, most likely to 32 bytes, if the EVM Object Format is ever adopted. |
There was a problem hiding this comment.
| It's worth noting that addresses are currently 20 bytes, but that might change in the future, most likely to 32 bytes, if the EVM Object Format is ever adopted. | |
| It's worth noting that addresses are currently 20 bytes, but that might change in the future, most likely to 32 bytes, if Address Space Expansion is ever implemented. If that happens, expanded addresses may be represented in 32 bytes, but pre-expansion addresses must remain 20 bytes in order to preserve a consistent address. |
There was a problem hiding this comment.
For context: EVM Object Format doesn't increase addresses to 32 bytes, it only lays the groundwork to make that possible in the future.
There was a problem hiding this comment.
Thanks for coming back to this!
Clarified this as a footnote in f1c7714 , lmk what you think
|
update: since it's not required to link to CAIPs, I removed links to CAIP-350, in order to minimize the amount of warnings. I'll link to CAIP-350 once we have a definitive commit hash of it |
|
On my phone at the moment, so forgive my brevity. Putting both in the same PR, but generally speaking we prefer an acyclic graph of dependencies. If you feel strongly about it, I'll make an exception. All technical discussion should take place in Ethereum Magicians. There will be a number of pull requests regardless of whether both proposals are in the same initial PR. |
|
There seems to be a bug in |
I do feel strongly about this since, in order to have all technical discussion happen on ethereum magicians it'd be best to have a page on eips.ethereum.org as the main means to share the standard instead of having an open PR where people can comment. I believe we can get this standard to an official 'Draft' state very quicky but ERC-7828 is a few days away from that.
Solved, thanks! |
Co-authored-by: moebius <132487952+0xmoebius@users.noreply.github.com>
ERCS/erc-7930.md
Outdated
| [EIP-55]: ./erc-55.md | ||
| [ERC-7828]: ./erc-7828.md | ||
| [ERC-7785]: ./erc-7785.md |
There was a problem hiding this comment.
Links need to be to eip- files even though they're named erc-.
| [EIP-55]: ./erc-55.md | |
| [ERC-7828]: ./erc-7828.md | |
| [ERC-7785]: ./erc-7785.md | |
| [EIP-55]: ./eip-55.md | |
| [ERC-7828]: ./eip-7828.md | |
| [ERC-7785]: ./eip-7785.md |
ERCS/erc-7930.md
Outdated
| - Addresses do not include any indication of the chain to which the address applies. This means chain information must be expressed out of band, and introduces the risk of an address being mistakenly used on a chain it is not valid for. This risk is particularly pronounced for addresses that represent smart contracts. | ||
| - The existing address format provides no mechanism for extension, meaning that there is no natural method to add these features to the existing address format. | ||
|
|
||
| Interoperable Addresses build on insights from [ERC-7828], CAIP-10 and CAIP-50, offering a unified format which combines: |
There was a problem hiding this comment.
| Interoperable Addresses build on insights from [ERC-7828], CAIP-10 and CAIP-50, offering a unified format which combines: | |
| Interoperable Addresses build on insights from [ERC-7828], [CAIP-10] and [CAIP-50], offering a unified format which combines: |
| [EIP-55]: ./erc-55.md | ||
| [ERC-7828]: ./erc-7828.md | ||
| [ERC-7785]: ./erc-7785.md | ||
| <!-- TODO: link to CAIP-350--> |
There was a problem hiding this comment.
| <!-- TODO: link to CAIP-350--> | |
| [CAIP-10]: https://github.com/ChainAgnostic/CAIPs/blob/b23e772369f2bc885c2ab70af4f0a0ec6bff6631/CAIPs/caip-10.md | |
| [CAIP-50]: https://github.com/ChainAgnostic/CAIPs/blob/e1842d3a311aefbcc8fb0cebf7a80615b40c7aef/CAIPs/caip-50.md | |
| <!-- TODO: link to CAIP-350--> |
ERCS/erc-7930.md
Outdated
|
|
||
| Interoperable Address: | ||
| ``` | ||
| 0x0001000001A4B114D8DA6BF26964AF9D7EED9E03E53415D37AA96045 |
There was a problem hiding this comment.
ChainReferenceLength is 2 bytes here (A4B1)
| 0x0001000001A4B114D8DA6BF26964AF9D7EED9E03E53415D37AA96045 | |
| 0x0001000002A4B114D8DA6BF26964AF9D7EED9E03E53415D37AA96045 |
ERCS/erc-7930.md
Outdated
| ^^---------------------------------------- AddressLength: decimal 20 | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Address: 20 bytes of ethereum address | ||
| ``` | ||
| keccak256 input for checksum: `0x000001A4B114D8DA6BF26964AF9D7EED9E03E53415D37AA96045` |
There was a problem hiding this comment.
see https://github.com/ethereum/ERCs/pull/1002/files#r2109831208
| keccak256 input for checksum: `0x000001A4B114D8DA6BF26964AF9D7EED9E03E53415D37AA96045` | |
| keccak256 input for checksum: `0x000002A4B114D8DA6BF26964AF9D7EED9E03E53415D37AA96045` |
| ## Motivation | ||
| The Ethereum ecosystem is rapidly expanding into a multi-chain environment encompassing L1s, L2s, sidechains, and rollups—some EVM‐compatible, others not. A simple address alone is not sufficient to describe a blockchain account, since it does not identify which chain the address belongs to, creating ambiguity for wallets, dApps, and users. At the same time, it is important for the format to be extensible to support both current standards for address naming and future standards for chain naming. | ||
|
|
||
| The current standard ethereum address representation defined in [ERC-55], with _optional_ retrofitted checksums implemented via selective capitalization of `a-f` characters, poses the following challenges: |
There was a problem hiding this comment.
I believe it's correct since it's a reference-style link whose reference is defined in the bottom of the document. It points to eip-55.md instead of erc-55.md due to changes performed in later stages of the eip website's generation. Or are you referring to something else?
Errors in link definitions would be caught by the htmlproofer ci step
ERCS/erc-7930.md
Outdated
| ### Example 3: EVM address without chainid | ||
| Chain: `eip155` namespace, chainid not specified. | ||
| Address: `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045` | ||
| Interoperable Name: `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155:#144A4B21` |
There was a problem hiding this comment.
could we do without the colon ? What would be the issue if we did not use it ?
My understanding is by parsing the @ and the # we would get the 3 blocks (address, chain, checksum). The chain would be eip155. From here, the absence of column makes it clear that there is only a namespace without reference.
Absence of colon is only an issue if the system wants to support both "namespace without reference" and "reference without namespace" ... but I don't this the second case makes any sens, does it?
There was a problem hiding this comment.
you're correct, there's no need to include the colon in cases where there's no chain reference. Updated the spec & this example at 59ace6b
ERCS/erc-7930.md
Outdated
| Chain: Arbitrum One | ||
| Address: `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045` | ||
|
|
||
| Interoperable Name: `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155:42161#38DDF570` |
There was a problem hiding this comment.
incorrect hash
| Interoperable Name: `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155:42161#38DDF570` | |
| Interoperable Name: `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155:42161#D2E02854` |
ERCS/erc-7930.md
Outdated
|
|
||
| Address: Not specified. | ||
|
|
||
| Interoperable Name: `@solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d#2eb18670` |
There was a problem hiding this comment.
specs says checksum should use upercase
| Interoperable Name: `@solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d#2eb18670` | |
| Interoperable Name: `@solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d#2EB18670` |
ERCS/erc-7930.md
Outdated
|
|
||
| Address: `MJKqp326RZCHnAAbew9MDdui3iCKWco7fsK9sVuZTX2` | ||
|
|
||
| Interoperable Name: `MJKqp326RZCHnAAbew9MDdui3iCKWco7fsK9sVuZTX2@solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d#88835c11` |
There was a problem hiding this comment.
checksum should be upercase
| Interoperable Name: `MJKqp326RZCHnAAbew9MDdui3iCKWco7fsK9sVuZTX2@solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d#88835c11` | |
| Interoperable Name: `MJKqp326RZCHnAAbew9MDdui3iCKWco7fsK9sVuZTX2@solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d#88835C11` |
|
The commit 59ace6b (as a parent of 12ad91f) contains errors. |
| ## Motivation | ||
| The Ethereum ecosystem is rapidly expanding into a multi-chain environment encompassing L1s, L2s, sidechains, and rollups—some EVM‐compatible, others not. A simple address alone is not sufficient to describe a blockchain account, since it does not identify which chain the address belongs to, creating ambiguity for wallets, dApps, and users. At the same time, it is important for the format to be extensible to support both current standards for address naming and future standards for chain naming. | ||
|
|
||
| The current standard ethereum address representation defined in [ERC-55], with _optional_ retrofitted checksums implemented via selective capitalization of `a-f` characters, poses the following challenges: |
There was a problem hiding this comment.
imo this section is a bit convoluted, I would just keep it to:
| The current standard ethereum address representation defined in [ERC-55], with _optional_ retrofitted checksums implemented via selective capitalization of `a-f` characters, poses the following challenges: | |
| Current Ethereum addresses ([ERC-55]) lack chain specificity and have optional checksums, creating several challenges: |
|
|
||
| The current standard ethereum address representation defined in [ERC-55], with _optional_ retrofitted checksums implemented via selective capitalization of `a-f` characters, poses the following challenges: | ||
|
|
||
| - Verification of the checksum by a client is optional, meaning that mistyped or erroneous addresses may be accepted by these clients. There is no way for a user to distinguish a correct address from an incorrect one processed by a client that does not do validation. |
There was a problem hiding this comment.
This bullet point could be simplified for better readability:
| - Verification of the checksum by a client is optional, meaning that mistyped or erroneous addresses may be accepted by these clients. There is no way for a user to distinguish a correct address from an incorrect one processed by a client that does not do validation. | |
| - Optional checksum validation allows mistyped addresses to be accepted without user awareness. |
The current version covers the same concept but is a bit lengthy. This shorter version captures both the acceptance issue and the user awareness problem in one clear statement.
| ### Concepts | ||
| Interoperable Address | ||
| : A binary payload which unambiguously identifies a target address and allows conversion to a human-readable name. | ||
|
|
||
| Interoperable Name | ||
| : A string representation of an interoperable address, meant to be used by humans. | ||
|
|
||
| Target address | ||
| : The (address, chain ID) pair a particular Interoperable Address points to. |
There was a problem hiding this comment.
The definitions have a circular reference issue where "Interoperable Address" references "target address" before it's defined. Consider this revision to maintain the same order while fixing the circularity:
| ### Concepts | |
| Interoperable Address | |
| : A binary payload which unambiguously identifies a target address and allows conversion to a human-readable name. | |
| Interoperable Name | |
| : A string representation of an interoperable address, meant to be used by humans. | |
| Target address | |
| : The (address, chain ID) pair a particular Interoperable Address points to. | |
| Interoperable Address | |
| : Binary encoding of a (chain, address) pair with version and checksum. | |
| Interoperable Name | |
| : Human-readable text representation of an interoperable address. | |
| Target Address | |
| : A (chain, address) pair identifying a specific account on a specific blockchain. |
This way each definition builds on concepts already established rather than forward-referencing.
| ### Interoperable Address binary format definition | ||
| In binary format addresses have the following encoding: |
There was a problem hiding this comment.
The standard references V1 throughout but never formally introduces it. This section should clearly establish the V1 specification and use formal language:
| ### Interoperable Address binary format definition | |
| In binary format addresses have the following encoding: | |
| ### Interoperable Address V1 binary format definition | |
| In binary format, addresses MUST have the following encoding: |
Adding "V1" to the title provides the formal introduction, and "MUST" establishes the normative requirement.
| Version | ||
| : A 2-byte version identifier. In the current standard this must always be the big-endian unsigned int 1. Other versions should be defined in future ERCs. |
There was a problem hiding this comment.
The phrasing could be more direct and concise:
| Version | |
| : A 2-byte version identifier. In the current standard this must always be the big-endian unsigned int 1. Other versions should be defined in future ERCs. | |
| : A 2-byte version identifier. For version 1, this MUST be `0x0001` (big-endian). Future versions SHOULD be standardized in separate ERCs. |
This removes "In the current standard" redundancy and makes the future versioning guidance clearer.
| #### Restrictions for all Interoperable Address versions | ||
| - Future Interoperable Address versions whose `ChainType`, `ChainReference` and `Address` can't be extracted in the same way as a `v1` address MUST set its most-significant version bit to 1, to allow for parser forward-compatibility. | ||
| - The Interoperable Address MUST define the mechanism to both include an address and specify the chain it belongs to directly in the payload, fully defining a target address. Any version adding an indirection layer between payload data and these two fields would violate this restriction. | ||
| - While it is possible that a given instance of an Interoperable Address to not include an address or a chain reference, every version must allow for both to be specified at the same time. | ||
| - Furthermore, future versions MUST be serialized to v1 and use the same input data to the checksum algorithm as described below, so an Interoperable Address' checksum only represents its target address. |
There was a problem hiding this comment.
This section would benefit from a brief introduction explaining its purpose, plus clearer formatting of the rules:
| #### Restrictions for all Interoperable Address versions | |
| - Future Interoperable Address versions whose `ChainType`, `ChainReference` and `Address` can't be extracted in the same way as a `v1` address MUST set its most-significant version bit to 1, to allow for parser forward-compatibility. | |
| - The Interoperable Address MUST define the mechanism to both include an address and specify the chain it belongs to directly in the payload, fully defining a target address. Any version adding an indirection layer between payload data and these two fields would violate this restriction. | |
| - While it is possible that a given instance of an Interoperable Address to not include an address or a chain reference, every version must allow for both to be specified at the same time. | |
| - Furthermore, future versions MUST be serialized to v1 and use the same input data to the checksum algorithm as described below, so an Interoperable Address' checksum only represents its target address. | |
| #### Version Compatibility Rules | |
| These rules ensure that future versions of Interoperable Addresses maintain backwards compatibility and consistent behavior across implementations: | |
| - Future versions incompatible with v1 parsing MUST set the most significant bit of the version field to 1 | |
| - All versions MUST support both address and chain specification simultaneously | |
| - All versions MUST serialize to v1 format for checksum calculation, excluding the version field from the hash input |
The intro paragraph clarifies why these rules exist, and the bullet points are more consistently formatted with clearer language.
| ### Comparisons with other standards | ||
|
|
||
| #### [CAIP-10] | ||
| [CAIP-10] proposes a standard text format to represent what in this document is defined as target addresses. | ||
| Since it's a text-only standard, it does not concern itself with the serialization/deserialization of the various chains' address formats, simply using the text representation of addresses already defined by the respective chains. This means it is trivial to add support for chains to [CAIP-10], while doing so with this standard involves defining a serialization scheme. | ||
|
|
||
| The above has the drawback of not being able to guarantee canonicity. That is, there could be multiple valid [CAIP-10] addresses pointing to the same target address. | ||
|
|
||
| Also, the text format is of little use for smart contracts involved with cross-chain liquidity transfers and message passing due to its reduced data efficiency and lack of canonicity. | ||
|
|
||
| Interoperable Names are convertible to [CAIP-10] without even going through the binary representation, so backwards-compatibility with actors expecting [CAIP-10] identifiers should not be an issue. | ||
|
|
||
| #### [ERC-7828] | ||
| [ERC-7828] is a text-only representation of addresses with optional resolution into more human-readable strings by use of existing ENS infrastructure for address names, and both the centralized ethereum-lists/chains list and [ERC-7785] for resolution of chain names, while this aims to be a simple but extendable binary-first format. | ||
|
|
||
| The interop roadmap is better served by having a standardized binary format for addresses first, which allows the message passing and intents verticals to move forward on a common interface, with a good-enough text representation which is familiar to users and useful for developers, and as a next step develop a chain & address name resolving standard on top of it, leveraging its uniformity and extensibility. |
There was a problem hiding this comment.
This condensed section is much better than the previous lengthy comparisons, but could use slight expansion for clarity:
| ### Comparisons with other standards | |
| #### [CAIP-10] | |
| [CAIP-10] proposes a standard text format to represent what in this document is defined as target addresses. | |
| Since it's a text-only standard, it does not concern itself with the serialization/deserialization of the various chains' address formats, simply using the text representation of addresses already defined by the respective chains. This means it is trivial to add support for chains to [CAIP-10], while doing so with this standard involves defining a serialization scheme. | |
| The above has the drawback of not being able to guarantee canonicity. That is, there could be multiple valid [CAIP-10] addresses pointing to the same target address. | |
| Also, the text format is of little use for smart contracts involved with cross-chain liquidity transfers and message passing due to its reduced data efficiency and lack of canonicity. | |
| Interoperable Names are convertible to [CAIP-10] without even going through the binary representation, so backwards-compatibility with actors expecting [CAIP-10] identifiers should not be an issue. | |
| #### [ERC-7828] | |
| [ERC-7828] is a text-only representation of addresses with optional resolution into more human-readable strings by use of existing ENS infrastructure for address names, and both the centralized ethereum-lists/chains list and [ERC-7785] for resolution of chain names, while this aims to be a simple but extendable binary-first format. | |
| The interop roadmap is better served by having a standardized binary format for addresses first, which allows the message passing and intents verticals to move forward on a common interface, with a good-enough text representation which is familiar to users and useful for developers, and as a next step develop a chain & address name resolving standard on top of it, leveraging its uniformity and extensibility. | |
| ### Relationship to Existing Standards | |
| ERC-7930 provides binary encoding for the CAIP-10 semantic model with guaranteed canonicity, addressing CAIP-10's limitation of potential multiple representations for the same target address. The Interoperable Names format maintains backwards compatibility with CAIP-10 text format for seamless integration with existing tooling. |
This adds just enough context about why binary encoding matters (canonicity) and what backwards compatibility means (existing tooling) without returning to the verbose comparisons. Also, I think this section should be moved to the "Backwards Compatibility" section regardless
|
|
||
| The interop roadmap is better served by having a standardized binary format for addresses first, which allows the message passing and intents verticals to move forward on a common interface, with a good-enough text representation which is familiar to users and useful for developers, and as a next step develop a chain & address name resolving standard on top of it, leveraging its uniformity and extensibility. | ||
|
|
||
| ## Test Cases |
There was a problem hiding this comment.
I think the examples 3 and 5 don't demonstrate new serialization concepts beyond what 1 and 2 already cover.
-
Example 3 (chain-only): While the spec allows zero-length addresses, this edge case adds complexity without showing practical usage. The parsing mechanics are identical to Example 2, just with
AddressLength = 0. -
Example 5 (Arbitrum): This is essentially a variation of Example 1 (EVM chain) with different chain ID encoding length. It doesn't demonstrate new serialization patterns.
I would consider either removing them or repurposing them
| While this standard aims to be a foundation to be able to canonically refer to addresses on different chains, that guarantee is going to be a leaky abstraction in the real world, given that e.g. a particular chain namespace might define a serialization scheme that can't guarantee canonicity of addresses, or a given network might have two valid [CAIP-2] ids referring to it. | ||
|
|
||
| It is therefore advised for implementers requiring canonicity of addresses (e.g by using them as keys in smart contract mappings or other key-value stores), to thoroughly review the the CAIP-350 profile of a chain namespace for the possibility of a lack of canonicity of addresses (which should be noted in the profile's 'Extra Considerations' section) as well as collisions with other already-supported namespaces. | ||
|
|
There was a problem hiding this comment.
I think the security considerations should be divided in sections so that we can accomodate the following.
| ### 4-byte checksum collisions | |
| Feasible to mine with current hardware. Implementers should display full addresses alongside checksums. | |
| ### Version collision risk | |
| Future versions may create name collisions. See versioning restrictions for mitigation strategies. |
Purposely recommending small sections but feel free to expand.
No description provided.