把一笔交易的哈希贴进工单、群聊或审计底稿，是加密行业最常见的引用姿势。但这串 64 位十六进制字符有个被低估的缺陷：它不告诉你自己是哪条链的。以太坊主网的 tx hash、某条测试网的 tx hash、某条用同样交易格式的二层链上的 tx hash，长得一模一样，全都可能在另一条链上不存在、或者碰巧指向另一笔无关交易。ERC-7950（2025 年 5 月创建的 ERC，标准化轨）针对这个痛点给出一个极简编码：把链 ID 也编进字符串里。
编码规则
规范只有一行：字符串以 0x 开头，后跟链 ID 的十六进制表示（最少位数、小写），再接完整的交易哈希。例如主网链 ID 是 1，一笔主网交易就被写成 0x1 后面跟那 64 个十六进制字符。解析侧同样简单：看到 0x 开头、去掉前导后按”链 ID 段加 64 位哈希”拆分；拿不到合法拆分就当普通交易哈希处理，回退到调用方原来的默认链。规范明确这不是新的链上数据格式——链上什么都没有变，变的只是链下引用与传递交易引用时的字符串形状。钱包、区块浏览器、机器可读回执、聊天机器人可以按这个格式生成和识别，不认识的旧工具也永远不会被它弄坏。
歧义事故的真实形状
为什么值得专门立一个标准？因为多链部署是常态。一条链的合约在另一条链上克隆部署非常普遍，nonce 与签名相同的话，跨链甚至可能出现逐字节相同的交易与相同的 tx hash——同一段字符串在两条链上都是合法回执，指向两笔真金白银的不同资金动作。审计与对账系统里，“先猜链再查哈希”的隐式默认曾经造成过实际差错；对自动化系统而言，引用里缺一个字段，就等于每次解析都要做一次有风险的推断。把链 ID 编进字符串，是把一次推断变成一次读取。
同方向的行业近亲还有 CAIP（链无关资产规范），它用 “eip155:1:0x…” 一类命名空间写法给链、地址、交易统一编制引用身份，覆盖面比本 ERC 大得多，代价是格式更重、改造面更广。ERC-7950 的取舍是不引入新命名体系，只动交易哈希这一个小格——兼容成本近乎零，能覆盖对账自动化与跨链工具最高频的一类歧义。与之相像的还有按链 ID 派生地址别名的方案（如 ERC-6735 用链参数改变地址呈现），方向一致、对象不同：那边解决”地址在多条链指向不同东西”，这边解决”交易号不知道自己在哪条链”。两类问题共享同一个根源：EVM 生态的克隆文化让同一份字节、同一串字符在几十条链上同时合法，歧义不是异常状态而是默认状态。
解析者的防御清单
如果你是工具开发者，实现这个格式时值得同时守住几条线：一是链 ID 段的合法值校验（对已知链表比对，未知 ID 至少原样保留、不得静默丢弃）；二是长度歧义处理——链 ID 段理论上可长可短，拆分逻辑必须以”哈希固定 64 位、自右锚定”为准，避免把哈希的前导字符误当链 ID；三是显示层与传输层区分，界面给人看时可以拆成”链名 + 哈希”两段呈现，序列化传递时保持规范原样。对用户而言，规则只有一条：引用里没有链名的交易号，进任何工具之前先问一句”这是哪条链的”。
快速问答
问：这是新的交易格式或新的链上字段吗？ 答：不是。链上数据结构不变，只规范链下引用字符串的写法。
问：旧浏览器能看懂这种字符串吗？ 答：不能直接看懂，但规范的回退设计保证它可以被当普通哈希处理，不会崩溃。
问：它解决跨链重放吗？ 答：不解决交易层重放，解决的是引用与查证阶段的”指链不明”。
风险提示：跨链查证请以目标链官方 RPC 或浏览器结果为准，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。