ERC-5164 跨链执行：一条 dispatchMessage 和两个事件构成的通用跨链调用层

跨链桥市场上每家传输层都有自己的一套函数签名和事件格式，应用方接三条桥就要写三套对接代码。ERC-5164 想解决的是这个适配碎片化：不管底下用哪家 Relayer、哪种验证机制，发送端和接收端各实现一份统一的薄接口，应用只调用这一个入口。按照以太坊 ercs 仓库的记录，这份提案状态为 Last Call，创建于 2022 年 6 月 14 日，定位是面向 EVM 系链的跨链执行标准。

Dispatcher 与 Executor 的分工

标准把一次跨链调用切成两个合约组件。Message Dispatcher 住在发起链上，负责把消息广播进传输层；Message Executor 住在目标链上，负责在验真之后执行消息。实现这个标准的方案必须同时提供两端。发送侧的核心函数只有一个：dispatchMessage(toChainId, to, data)，参数依次是目标链标识、目标合约地址和调用数据，函数是 payable 的，返回值是一个 bytes32 的 messageId——这个 ID 是后续全链路对账的主键，标准要求它跨链、跨 Dispatcher 全局唯一，达成方式是把链 ID、Dispatcher 地址和一个单调递增的调用序号做哈希。标准同时规定：目标链如果不在 Dispatcher 支持的列表里，调用必须直接 revert。

两个事件把链路钉成三段

对账靠事件。发送侧，MessageDispatched 在消息被派发时发出，标记”源链已经放手”；接收侧，MessageIdExecuted 带两个索引字段 fromChainId 与 messageId，在消息或消息批被执行时发出，标记”目标链已经落地”。把一个 messageId 在两条链的日志里各查一次，链路就被钉成三段：源链无 Dispatched 事件，说明卡在发起环节，钱和 Gas 的纠纷在源链解决；有 Dispatched 无 Executed，说明消息在路上或被接收端拒绝，问题出在传输层与 Executor 之间；两边都有，执行已完成，剩下的分歧只可能关于执行结果本身。这种”两事件三段落”的对账方式不依赖任何桥的私有后台，纯靠公开日志，正是标准化的价值所在。

只执行一次，但不保证顺序

标准对执行侧还有一条容易被忽略的保证：每个 messageId 在 Executor 上只会执行一次，但允许乱序执行——消息在传输层里可以不等先后抵达，目标合约不能依赖”先到先执行”的隐含约定，幂等与状态检查必须自己做。对账时的推论也直接：晚几分钟看到 Executed 事件缺失先别判丢，消息可能只是还在路上；确认传输层投递完毕仍无事件，才是真失败的信号。

标准化的边界：只管接口，不管安全

要说清楚 ERC-5164 没有规定什么。消息怎么跨链送达、验证靠轻客户端、多重签名还是预言机，全部留给传输层实现，标准文本刻意不碰。这意味着两件对使用者很实际的事：第一，同一份 ERC-5164 接口底下可以套安全性天差地别的桥，接口统一不代表信任模型统一，选桥时仍要读它的验证机制文档；第二，to 与 data 是被原样搬过链的，目标链上的 Executor 会在自己的上下文里替你调用目标合约，调用方地址、value 与源链不再一致，写合约时必须把”我在谁的环境里执行”这件事显式处理好。此外消息重放也依赖实现：同一个 messageId 在 Executor 端是否记录已执行、拒绝二次执行，标准只给出方向，逐桥核验仍然不可省略。

对普通用户意味着什么

普通用户感知 ERC-5164 的场景通常是桥接界面背后：跨链转账、跨链铸造、把 NFT 从一条链搬到另一条链。可操作的自查动作是拿到交易回执里的 messageId，在两条链的区块浏览器分别按事件主题搜一次，用事件缺失的位置判断问题环节，再决定是找发起方、找桥、还是找目标合约。按 ercs 仓库口径，该标准处于 Last Call 阶段，尚未标记为最终标准，采用它的桥与协议在字段细节上仍可能有出入，对账前先确认目标实现引用的版本号。本文为机制说明，不构成任何投资建议。