一个地址不再等于一个账户：ERC-7831 多链寻址写法

同一个私钥在以太坊主网、各第 2 层网络上的地址字符串完全相同，可资产却各归各链：把 NFT 打到”正确的地址、错误的链”，收款方在目标链上看不到它。ERC-7831（Multi-Chain Addressing）想在书写层面堵住这个歧义：给地址带上链名，写成”账户:链”的形式。该提案状态为 Draft（草案），创建于 2024 年 8 月 30 日，依赖 ERC-55、ERC-137、ERC-155、ERC-165 与 ERC-2304。本文讲机制，不构成任何投资建议。

三段式语法

规范的地址由冒号分段，从具体到一般：local-part（目标链上的账户标识）、chain-part（链名）、可省略的 root-part（负责解析的根链）。歧义场景用圆括号包裹消歧，比如本地部分本身带协议前缀时。链名不是随便写的字符串——解析器通过 ENS 把链名映射到链标识，规范批评了此前靠中心化清单维护链名与链号映射的做法：清单跟不上 L2 数量增长，维护方还是单点。解析失败时按标准应报错，而不是猜一个链。

它解决转错链的哪一半

值得诚实拆解：多链地址让”收哪个链”第一次成为地址的一部分，钱包与转账界面可以据此校验链上下文，给”你正在往这条链发那枚 NFT”的提示提供机器可读依据。但地址本身不能阻止失误发送——发错链的动作仍然由发送方客户端完成。它压缩的是歧义，不是手滑。跨链语义真正生效还要靠规范讨论的桥接与解析代理：声明带链标识后，资金才能被引导到可达的路径上。

对 NFT 用户的现实意义

1. 收跨链礼物或平台提币时，优先要求对方给出带链标识的完整写法，口头报一串 0x 开头的地址在多条 L2 时代已经不够精确。
2. 平台界面若声明支持该写法，解析结果应显示”链名+地址”两段供肉眼复核；只回显一串纯地址的”支持”值得追问。
3. 与灵魂绑定式 NFT（如 ERC-5192 标记的）以及原生链标准（如比特币铭文、TON 的 NFT 合约体系）无关——它们本来就锁死在单链上，多链寻址帮不上忙。

草案阶段的预期管理

提案尚在 Draft，主流钱包与浏览器的支持面需逐项确认；标准本身不改变任何链的转账规则，只是书写约定。在此之前，防转错链最可靠的办法仍是笨办法：先发小额测试、逐字段核对链名、复制地址后肉眼比对首尾若干位。

语法里的几个硬规定

规范对书写细节有明确约束，挑对核验有用的说：本地部分若是十六进制地址，必须保留校验和大小写、不得带 0x 前导；想改写成 ENS 风格的名字则必须含至少一个点，最右侧的点在解析前会被去掉——这条是为了让解析器不把地址误读成名字。链部分必须是一个合法的 ENS 名字，解析责任落在根链上的解析合约与桥接合约上：声明了 root-part 时去那条链解析，省略时按约定的默认根链处理。解析失败的合规行为是报错停止，任何”解析不出来就猜主网”的客户端都属于实现缺陷。

对只想安全收礼的用户，还有一条朴素提醒：无论对方写法多标准，收到 NFT 后先确认它出现在你预期的那条链、那个地址上，再决定要不要动它；带链标识的写法解决的是”发之前别搞错”，收之后的二次确认责任仍在收的人手里。此外，把 ENS 名字直接当收款地址与”带链名的地址写法”是两回事——前者把链选择权交给了名字记录，后者把它写死在字符串里，风险敞口并不相同，给第三方报地址时选哪种要提前说清。

地址书写正在从”一串十六进制”演变为”账户加链加语境”，这条演进对多链持仓者是实际利好；本文仅为机制科普，不构成投资建议。