把一条链上的操作与另一条链上的操作拼成一次完整体验，中间总要有人递话。ERC-7841（Cross-chain Message Format and Mailbox，跨链消息格式与信箱）想给这个”递话”定一套标准信封：消息长什么样、收发的信箱合约放哪里、同步与异步两种玩法怎么区分。提案 2024 年 12 月 12 日提交，官方状态是 Draft，至今没有配套的强制采用要求。下面拆开它的信封。
信封的字段：两个链号、两个地址、一组会话序号
规范定义的 Metadata 结构包含六个字段：源链标识 srcChainId 与目标链标识 destChainId（各 32 位整数），源地址 srcAddress 与目标地址 destAddress（各 32 字节，以太坊地址右对齐、左侧补零装进去），再加上 sessionId（128 位，标识一次跨链交互会话）与 nonce（128 位，会话内的消息计数）。会话号加序号的组合，是为了让”链 A 调链 B、链 B 再调链 C”这类多跳调用保持先后次序。外层 Message 结构再挂一个 payload，里面可以是 ABI 编码的函数调用、跨链资产信息或任意数据。
每条链两座信箱：同步一座、异步一座
规范建议每条链部署两座标准信箱合约，一座服务同步消息、一座服务异步消息。两者的区别在时间对齐：同步协议下各链的出块按同一时间槽对齐，一条链发出的消息在同一个时槽内被目标链接收，甚至可以”发出去随即读回结果”；异步协议则允许两条链的出块节奏完全脱钩，发送与接收之间隔着不确定数量的区块。信箱合约各管两个方向——写出去进发件箱、被读走进出件箱，消息必须通过交易动作进出，而不是靠链下承诺。为什么要拆成两座而不是一个合约两种模式：同步路径对时延与气隙要求苛刻，合约逻辑要贴着自己的时槽规则走；异步路径则要额外处理乱序与重复投递。合并实现会让任一场景的调用者为另一场景的复杂度付 Gas，拆开之后各自还能独立升级。
中间那段路由由”协调协议”负责
链与链之间谁替你把消息搬过去，ERC-7841 称为协调协议：可能是共享排序器，也可能是意图解算者网络，还常带一个保证消息完整性的结算机制。这部分刻意留在规范之外。换句话说，信封是标准的，快递员不是。读跨链产品文档时可以用这个框架问三件事：用的是不是标准信箱、协调协议是排序器还是解算者、异步场景下未结算窗口里出了问题谁兜底。生命周期属性（能否取消、超时、重试）在 ERC-7985 里有另一张属性表，见跨链消息能取消、超时、重试吗：ERC-7985 的生命周期属性表；链标识的取值口径也直接影响这两个 uint32 字段怎么填，跨链签名场景见一枚签名多条链通用：ERC-7964 把链标识从域名里拿掉之后。
与”意图”模型的关系
对普通用户来说，最接近 ERC-7841 体验的产品形态是”签个名说我要什么，别人替你在多条链上办成”。意图从签名、解算到链上结算的完整链路，意图是什么？签名、解算与链上结算的跨链新模型已经讲过。信箱标准补的是解算者落地时的接口统一问题：解算者要同时面对多条链、多种资产，如果每条链的收信动作都不一样，它就得为每条链单独写一套对接，这个成本最后都会体现在报价与延迟上。用户侧的实际含义是把责任问清楚：一次”跨链转账”里，你的钱在哪条链被谁垫付、失败时退回哪、等多少个区块算最终确定——这些答案取决于协调与结算机制，不由信封格式自动保证。
现状与使用建议
ERC-7841 仍是草案：现网桥与跨链方案各用各家格式，这是常态而非异常。看到”支持标准跨链信箱”的宣传，先核对它指的是 ERC-7841、还是别家同思路的私有接口。字段名、位宽与同步/异步定义以官方提案文本为准。本文为机制科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。