ERC-7930：互操作地址 - ERC

摘要

Interoperable Addresses (可互操作地址) 是一种二进制格式，用于描述特定于一条链的地址，并带有可选的人类可读名称表示。

它的设计方式允许社区在未来对其进行扩展，以支持命名方案（或其他尚未想到的功能），并支持任意长度的地址和 chainid。

ERC pull request: https://github.com/ethereum/ERCs/pull/1002

背景

在对各种互操作组进行了广泛的讨论，并试图将其作为 ERC-7828 的重写版本进行推广之后，我们正在推进一种二进制优先的 Interoperable Addresses 格式，并希望你能就此主题提供反馈。

虽然我们已努力在 ERC 本身中列出相关的跨链命名和寻址工作，但我认为这里有必要提供一些额外的内容：

最初，我们试图推动一个单一的标准，既要处理跨链寻址，又要处理跨链命名，规范地定义地址的二进制和人类可读的（字符串形式）表示，并在 ENS 和类似解析器的帮助下，以不同的程度解析为更精简的名称。

然后，我们意识到这种标准将有两组不相交的用户：

• 钱包开发者，他们主要关心命名，只是间接地关心规范性或二进制编码。
• 链上基础设施（如跨链消息传递和流动性桥接）开发者，他们对二进制 payload 的紧凑性和规范性有严格的要求，但不关心命名注册表或人类可读的表示。

本标准旨在满足后者的需求，同时也有望成为实现前者目标的基石。

需要反馈的内容：

• 我们应该如何与 CASA 协调，使其成为未来链/地址类型追加的注册表？理想情况下，我希望最终得到类似于 BIP-0044/SLIP-0044 的东西，即此标准在最终确定时支持一小部分高度期望的链，并且将来维护在相应链的命名空间中支持其他链所需的规范。

• 我们应该如何处理 CAIP-2 对链引用的长度的限制？Frangio 提到此标准实际上与 CAIP-2 不同，因为将实际的 CAIP-2 标识符转换为此格式非常困难，因为它需要名称本身不提供的额外数据。此外，也不可能定义清晰的截断方案，因为 CAIP-2 标识符是文本，根据所使用的编码，它可以存储的内容会有不同的界限（例如 base16 为 16 字节，base58 为稍多）。

• 我们是否应该对字符串表示更具规范性？少一点？完全删除它？

• ERC-7828: Chain-specific addresses using ENS

• ERC-7786: Cross-Chain Messaging Gateway

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～