你填的链号从哪来
给钱包添加自定义网络时，那个十进制或十六进制的 chainId 是防串链的核心参数。今天多数链号的来源是社区维护的公开仓库清单：一条链一个文件，文件名用 CAIP-2 表示法，内容里 chainId、networkId、RPC、浏览器地址逐项写清，数字通常由创建者挑一个没被占用的短数。这份仓库支撑着常见的网络目录站点和钱包的自动添加功能。清单模式的问题不在方便，而在信任：名单本身由合并请求维护，号段靠先到先得，一个短数字空间里挤着成百上千条链，名字仿冒与号段误配都有过现实案例——这也是我们反复主张添加网络前三项一致性核验的原因，方法见 钱包 RPC 出错要换节点？先做链标识、高度与编号三项一致性核验。
把标识变成可重算的量
ERC-7785 的思路是把标识从分配的号码变成推导的结果：链标识扩到 32 字节，由链名连同其他参数经哈希函数算出。原文给的示例推导输入包括链名、结算链标识、版本字符串、部署合约地址和盐值。关键性质是可重算：任何人只要知道这些公开输入，就能独立算出同一个值，不需要询问任何名单维护者。哈希把命名域和部署事实压进一个不可伪造的摘要，改名字、换部署方都会得到完全不同的值。
具体到例子，规范展示了一条二层链的推导写法：链名与主网标识、版本、部署合约地址依次进入 Keccak 哈希。输入里带上部署合约地址尤其值得注意——部署合约是链在结算层上的出生证明，把它纳入输入等于把标识锚定到一个链上可查的客观存在，而不是一行可以被提交的文本。
名字到标识：用 ENS 做查询
推导解决了算得出，还需要查得到。规范提出把链名挂到 ENS 上，链名解析到一个含版本号、桥地址和链标识的记录，再用推导公式复核：解析出的标识应当等于重新哈希的结果。这套记录形态沿用 ERC-2304 为链定义过的记录结构，让已有工具无缝对接。复核公式里的每一项都可以从链上和域名系统独立取得，于是查询链条上没有任何单点可以伪造一个看起来合法的链号。这条路径与合约通过域名告诉客户端去哪读数据的 CCIP-Read 思路同族，机制细节可回看 合约说“去别处查”：ERC-3668 的链下读取怎么发生。
对现网的边界
草案明确不碰存量：现有链的数字标识不会被强制迁移，方案面向新链，也为旧链号留了兼容通道。32 字节标识进入日常使用后的直接变化是形态——你会在某些场合看到长十六进制串而不是小整数，钱包与浏览器都要适配显示、输入与缓存。过渡期里同一两条链可能同时挂着旧号与新标识，哪套生效取决于客户端和链自己的接入进度。
对普通用户，眼下能做的核对动作不变且依然足够：添加网络时把 chainId 与链官方文档给出的数字逐位比对，RPC 域名与浏览器地址同样以官方渠道为准，来源是论坛或搜索引擎摘要的一律不填。还有一个低成本习惯值得养成：同一条链至少从两个官方渠道取号——项目官网文档与官方区块浏览器页面上标注的链号应当互相印证，两处不一致时以两者都不采信、去其官方仓库或公告再查第三处为妥。标准成熟之后，这些手工步骤可以被机器复核替代，而在那之前，多一分怀疑比少一步验证安全。
风险提示
本文只解释标识注册机制，不构成投资建议，也不对任何具体链的标识正确性作出保证。链标识配错可能把资产发到错误的链上并造成损失；本文提及标准均为草案状态，尚未形成行业强制。一切涉及资产的网络配置，以链方官方文档为核验依据。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。