ERC-7533 公共跨链端口：桥不用再逐条推消息，改成拉取默克尔根

传统桥的架构是一问一答式的：每条桥各自监听源链事件、各自组织验证、各自往目标链投递，桥与桥之间互不相干，同一份跨链安全性要重复建设 N 遍。ERC-7533（Public Cross Port，简称 PCP）把方向倒过来：源链不再往外推消息，而是把所有桥要用到的跨链消息集中进一个公共发送端口打包成默克尔树，各条桥只需把树根”搬”到目标链，谁收到请求谁拉全量消息来验证。按标准摘要的说法，这将显著减少桥接所需的桥体数量与 Gas 开销，参与桥项目越多，整体安全性反而越高。按照以太坊 ercs 仓库的记录，这份提案状态为 Draft（草稿），创建于 2023 年 10 月 11 日。

SendPort：只负责收和打包

每条链部署一个 SendPort 合约（标准建议一链一个，无须重复部署），职责单一到近乎偏执：收事件、攒叶子、打包、重来。桥合约收到用户存款之类的跨链请求后，把事件哈希和目标链 ID 交给 SendPort 的 addMsgHash，连同发送方桥合约的地址哈希一起作为叶子记入数组；攒够一定数量或经过一段固定时间（标准举例为一分钟），SendPort 自动把这一批叶子打包成一棵哈希默克尔树，随即开始下一轮收集。打包完成的信号由 Packed 事件发出，登记叶子的动作则由 MsgHashAdded 事件留痕。addMsgHash 是无许可调用——任何合约都能往里塞消息，标准对此的防欺诈设计是把提交者的地址一并编进叶子内容：解码目标链消息时能看到”是谁声称要把这条信息送到哪条链”，责任可追。整个合约无人管理、无须升级，工具侧可用 getPackage 按包序号回看任意一批已打包或待打包的叶子。

ReceivePort：根是信封，不是信

搬运工（桥项目方）把源链打好的包——含默克尔根及其元数据——提交到目标链的 ReceivePort。ReceivePort 不唯一：每个桥项目按 IReceivePort 接口实现自己的接收合约，多个搬运方就有多个 ReceivePort。根的妙处在于信息与传输分离：根自身不能还原出任何消息内容，只能用于验证消息真伪；完整消息要去源链的 SendPort 查。接收侧的验证函数是 verify(msgHash, merkleProof, targetChainId)——拿到完整消息、算出哈希、按默克尔证明复算根，对上即为真。

多接收端互验：把冗余变成安全

标准里最反直觉的一段安全逻辑：由于所有根出自同一个 SendPort，诚实搬运方在不同链的 ReceivePort 里登记的根应当完全一致。于是一条消息如果在多家的 ReceivePort 都能验真，其真实性就获得了类似多签的背书；若某家的接收端对得上、其他家对不上，要么那家桥被黑、要么故障，异常被公开化而不是被单条桥的黑箱吞掉。换言之，PCP 把”多条桥各干各”的冗余投入改写成”多家互相校验”的安全增量——桥越多，验证越可信，这与传统认知中”桥数增加攻击面”正好相反。

谁不能直接用这套接口

标准自己划清了一个适用边界：需要直接发送单条消息的桥或应用，不应部署自己的 SendPort，而应做包搬运方或复用现有端口；SendPort 是为”许多桥共享同一源链消息流”这个特定场景设计的。这条边界解释了为什么该标准更像基础设施协议而非应用层积木——一链一口的设定意味着先发部署的 SendPort 可能天然成为公共地段，围绕它的中立性治理（打包节奏、参数由谁定）反而会成为比技术更难的问题，标准对此的答案是让它完全自动运行、无人掌舵。

对用户的实际意义

普通用户短期感知有限：跨链体验仍由具体桥产品提供，PCP 只是它们背后可能共享的一层端口。可操作的变化有两点：一是消息可自证——拿到交易哈希与消息 ID，理论上可以在源链 SendPort 与目标链 ReceivePort 两头独立验真，不必全信桥的进度条；二是选桥时多了一个问题可问：“你们搬的是 PCP 公共根还是自建通道？“公共根意味着验真逻辑对所有参与者一致。局限同样清楚：标准停留在 Draft，端口自身不担保某条桥的密钥管理与经济安全，任何桥仍可能有 PCP 之外的失效路径。本文为机制说明，不构成任何投资建议。