ERC-6170 跨链消息接口：给所有桥写同一份两个函数的说明书

跨链开发者面对的现实是：每条桥都自称通用，每份集成文档都要重读一遍。有的桥接口叫 send，有的叫 bridge；有的链标识用数字，有的用字符串。2022 年 12 月 19 日创建、状态为 Draft 的 ERC-6170 想做跨链世界的最小公分母：不管底层是哪条消息协议，合约侧一律实现两个函数、两个事件。本文按原文拆这份极简设计。

两个函数与两个事件

接口定义叫 IEIP6170。发送侧是 sendMessage，四个参数依次为目的链标识、接收者、任意消息内容和一段桥端自定义的编码数据，函数可支付、返回布尔值；接收侧是 receiveMessage，参数换成来源链、来源发送者、消息本体加一段用于安全校验的附加数据，注释举例这段可以放 LayerZero 风格的随机数。事件侧 MessageSent 与 MessageReceived 各自记录收发双方和链标识，标准明确要求即使消息为空也必须触发发送事件，防止零字节传输悄悄溜过审计。整份接口没有管理函数、没有权限函数，刻意保持最小。

全是字节类型，是为了迁就谁

这份接口最显眼的设计是链标识和地址参数全部用字节类型而不是定长数字或地址类型。原文注释写得很直接：全用字节是为了支持非以太坊虚拟机链。在以太坊上地址是二十字节，在别的链上可能是任意编码，用定长类型等于自动淘汰一批链。动机部分还留了一个有趣提案：链标识建议用各链原生代币名的字节编码来表示，比如把 ETH 与 SOL 两个字符串编码后当作链的身份，理由是链的原生币名很难被两个链同时冒认。这只是一个提案层面的想法，落地约束有限，但它解释了为什么这份标准宁可用宽松的字节类型换最大的覆盖面。

这份接口没写到哪一步

6170 的接口刻意很浅，浅的部分恰恰是要自己检查的部分。它不定义中继费怎么付，不定义消息证明的格式——一条消息是靠轻客户端证明、委员会多签还是中心化服务送达，接口层面完全看不出来；它也不定义投递失败后的重试语义，超时后发送方要不要主动查询 MessageReceived 事件，同样没有标准答案。收消息先验来源的那句注释终究只是注释，具体约束力取决于各家实现是否照做。这正是这份标准实用的打开方式：不必指望它把任何桥无缝拼起来，而是把“这座桥的链上入口长什么样”变成固定提问模板——两个函数在不在、事件齐不齐、receiveMessage 处理消息之前做了哪些验证、MessageSent 是不是真的连空消息都记录。四问都有实证，这座桥才算接口友好；有一问答不上，再顺滑的跨链叙事都值得多花核验时间。

收消息前的那道检查

receiveMessage 的注释里有一句容易被略过、实际最重要的话：发送者验证或消息验证必须发生在处理消息之前。跨链消息桥的安全史几乎就是一部假消息注入史——问题很少出在消息传不到，而多出在目的链没验清楚这条消息真的来自来源链的那份授权合约。这份标准把先后顺序写进注释，等于把最贵的教训折进接口文档。同很多 Draft 提案一样，它没有强制执行力，合规与否取决于具体实现。对读者的实用价值在于核对清单：评估任何跨链藏品桥接、跨链消息应用时，先问三个问题——有没有类似两个函数的分离结构、发送事件是否连空消息都记、目的端在执行业务逻辑之前验没验来源。标准本身停留在 Draft，把这份清单当作检查表，比把它当作已建成的基础设施更接近现实。

本文为机制说明，不构成任何投资建议。