让合约订阅合约的事件：ERC-5902 事件钩子的注册与中继

区块链的合约之间天生”看不见”彼此：A 合约发出的事件，B 合约不会自动感知。现在做联动要么靠链下机器人监听后触发，要么把两个合约焊死在一起。ERC-5902（Smart Contract Event Hooks）提出一个中间方案：把”订阅某个合约的某类事件”做成链上注册表，事件发生时由任何愿意跑腿的中继者把凭证递过去，触发订阅方的回调。该提案在以太坊标准体系中的状态为 Stagnant（停滞），创建于 2022 年 11 月 9 日，依赖 ERC-712。本文按规范文本讲机制，不构成任何投资建议。

三方各自要做什么

规范把参与者分成三种角色。发布方（Publisher）先把合约地址注册进协议；订阅方（Subscriber）登记自己的钩子（Hook）——即”当某发布方的某类事件发生时，请调用我”，并可以更新或移除。中继者（Relayer）不登记任何东西，靠抢活吃饭：观察到链上事件后，构造一笔包含事件凭证的交易，向协议声明”该触发哪些钩子”，协议验证凭证归属后才执行回调，中继者收取订阅方预先锁定的触发费。

事件凭证怎么防伪

中继者说的”发生了事件”不能空口白话。规范要求钩子携带可验证的数据包，协议用哈希与签名（配合 ERC-712 结构化签名）核对事件确实由注册过的发布方在某个链上发出、没有被篡改。规范还专门讨论了重放攻击：同一事件不能在另一条链上被再次当作触发依据，跨链消息需要额外绑定链标识。

它想替代什么、又没有替代成什么

对比现状：链下自动化监听脚本由项目方自己维护，服务器一挂联动就断；ERC-5902 设想里，费用锁定在协议里，任何中继者都能补位，形成无须信任单一运维方的市场。规范自己也列了隐忧——抢跑（看到钩子要执行，先跑一步改变条件）、烦扰攻击（用高成本触发拖垮订阅者）、中继费定价缺乏拍卖机制时的低效竞争。该提案自创建后未获采纳，状态停留在 Stagnant，说明这些经济与安全问题在当时没有找到共识解法。

用它的替代品时该盯什么

目前 NFT 生态里的跨合约联动——比如铸造完成自动进入抽奖池——大多仍靠链下触发器或应用内直接调用完成。看这类机制时值得问：触发由谁的服务器执行、延迟多久、断了谁来补；如果项目声称”完全链上自动触发”，去查它调用链里是否存在一个中心化中继地址，中继地址被冻结或私钥泄露时联动就停摆。标准没落地不等于需求消失了，只是换成了更朴素的实现。

事件本体长什么样

规范对触发事件有具体规定：发布方合约应从一个函数发出名为 Hook 的事件，携带线程编号、单调递增的随机序号（首个事件的序号必须从 2 开始，用来区分”未初始化”与”显式为零”）、载荷的 keccak256 摘要、载荷字节和一个把摘要与当前区块高度拼接后再哈希的校验值。中继者监听到的就是这套字段；载荷也可以由外部传入发布函数，此时若附带签名，必须签在载荷哈希上、且与注册时登记的公钥对应——这条路径同时被用于跨链场景，因为订阅方没法直接调另一条链上发布方的验证函数。订阅方登记时要写明愿付的触发费、可接受的 Gas 上限与 Gas 价格上限——后者专门用来防恶意中继抬高费用抽干订阅合约。

事件钩子改变的是”谁来跑腿”的经济学，不改变合约逻辑本身；评估自动化功能时以合约代码与触发路径为据，本文不构成任何投资建议。