交易完成后，客服或朋友管你要“交易哈希”，你粘一串 64 位十六进制给对方，对方还得自己猜这是哪条链、该在哪个浏览器打开、怎么解读。ERC-2400 想把这三件事装进同一个链接里。这份 2019 年提出的标准给“已提交交易的回执”定义了一种 URI 格式：哈希之外，还能带上链号和用于解码的函数与事件签名。本文按规范原文拆开它的语法、校验语义和使用纪律。
一个回执链接由哪几段组成
按规范语法，回执链接以 ethereum:tx- 开头，紧跟 0x 打头的 64 位十六进制交易哈希；可以追加 @ 加十进制链号，例如 @1 表示以太坊主网，省略链号时默认主网；再可以带问号参数，允许的参数键只有两个：method 与 events。method 写这笔交易调用的函数签名，形如 method="transfer(address,uint256)"；events 写这笔交易应当触发的事件签名列表，多个事件用分号分隔，形如 events="Transfer(!address,!address,uint256)"，其中类型前的感叹号表示该参数是索引过的主题值。这类“把链标识写进引用”的思路，与浏览器网址路径标准化的 ERC-3091 是互补关系：一个管工具间怎么传回执，一个管浏览器页面怎么拼网址，可对照 区块浏览器的链接能自己拼吗：EIP-3091 统一路径的现状与用法。发送之前的请求链接则由 ERC-681 一类标准负责，见 支付链接里到底写了什么？EIP-681 请求的地址、链标识与金额逐项拆。
打开链接的工具要做哪些校验
规范把工具的责任写得很具体。拿到哈希后先在对应链号的历史里查找；查不到就去待处理队列里等，直到被打包或确认不存在，最终找不到就报错，而不是硬渲染一个空页面。如果链接带了 method，工具要用交易输入数据的前四个字节，与 method 签名哈希的前四个字节做比对，不一致就显示“方法校验错误”而不是交易内容——这正是防止链接与真实调用张冠李戴的关键一步。如果带了 events，交易成功后，列表里每个事件签名都必须在回执日志里至少出现一次，否则同样应当显示校验失败而不是照单展示。回执日志本身的字段读法见 交易回执里的Logs是什么？链上转账“收据”的字段与读法。
实操示范：把一笔代币转账做成可核验的回执
设想你转完一笔 USDT，要给对方留凭证。按规范语法拼出来的链接形如 ethereum:tx-0x5375…2f92@1?method="transfer(address,uint256)"&events="Transfer(!address,!address,uint256)"。对方拿到链接后，合规的工具会做三件事：确认这是以太坊主网的交易并找到它；比对输入数据开头四个字节与 transfer(address,uint256) 签名哈希的前四字节，证明这确实是一笔转账调用而不是别的方法；再核对回执日志里出现过一次 Transfer 事件，主题里是双方地址。三关全过，才轮到展示金额和地址。相比之下，你只发一串裸哈希，对方就必须自己登浏览器、选对链、逐字段肉眼看——每一步都是出错面。反过来说，接收方如果用的工具不认这种格式，也完全没关系：链接的每个组成部分本来就都能在普通浏览器里手工核验，格式只是把核对动作自动化了。
待处理交易的空窗怎么解释
规范特意留了一段容易被误读的空间：新广播的交易哈希查不到是正常现象，工具应当轮询待处理队列直到它被打包。这条对用户端的意义是，刚提交的一分钟内，回执链接显示“未找到”不等于交易没发出去，可能只是还没进块，也可能被更高费用的替换交易顶掉，甚至在重组中回退——三种情形的排查路径完全不同，先核随机数与替换记录再下结论。把这段等待逻辑交给认格式的工具去做，比自己反复刷新浏览器页面更省心，也更不容易在焦虑中重复发交易。
状态与使用纪律
按标准仓库的文本，ERC-2400 的状态行是 Stagnant（停滞），主流浏览器和钱包对它的支持不能想当然，多数场景下你仍然只会传一串裸哈希，这时至少做到：粘贴前核对浏览器域名是自己输入的，链号与转账网络一致，两个浏览器的查询结果互为对照。把这三步做全，比依赖某个链接格式更能挡住张冠李戴。
以上内容是交易凭证的表达与核验方法，不构成任何投资建议；分享交易哈希或回执链接时请勿附带地址以外的敏感信息，涉及资产操作的判断请以链上事实为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。