ERC-7615 推式数据源：合约不查价，让发布者把数据推进来

绝大多数预言机是拉取式：合约需要价格时调用查询接口，数据随调用返回。这套模式有个结构性滞后——没人查询时，最新数据不会主动进入任何合约状态。ERC-7615（Atomic Push-based Data Feed Among Contracts）换一种拓扑：把“谁关心这个函数”登记在发布者合约上，函数被调用的那一刻，发布者反向调用每个订阅者的 exec，把选择器和数据当场推进去，整个过程在同一次交易里原子完成。按以太坊 ercs 仓库的记录，提案状态为 Draft，创建于 2024 年 2 月 3 日。

四步流程与两种订阅条件

标准把推送分成四步：外部调用发布者合约的某个函数；发布者按该函数的选择器查出订阅者名单，必要时把数据放进 inbox 暂存；发布者逐个调用订阅者的 exec，传入选择器与数据；订阅者在 exec 里处理，也可以回身调用发布者的 inbox 取明细。订阅条件有两档：无条件推送，凡是调这个选择器就触发；条件推送，只有满足配置条件的调用才触发。同一个选择器允许挂多个、多种类型的订阅者，发布者会挨个调用它们的 exec。标准的兼容性护栏很具体：取消订阅前，发布者必须检查订阅者的 isLocked 是否返回真——防止把一个正在依赖推送的合约悄悄摘掉；同时提供 forceApprove、forceCancel 与配套的 renounceForceApprove、renounceForceCancel，也就是强制批准、强制取消及其永久放弃接口，事件层的 Approve、Cancel、RenounceForceApprove 等把每一步留在日志里。

原子性的红利与代价

安全考虑部分把攻击面列得相当坦率。exec 是公开函数，任何人都能直接调用它注入伪造的推送数据，订阅者实现绝不能不经校验就采信传入参数，更不能在 exec 里放任调用方驱动状态变更；发布者调用订阅者的过程本身是重入入口，恶意订阅合约可能在 exec 里反打发布者，推送路径上的状态写入顺序必须按重入防御来编排；批准类接口的访问控制若放水，路人可能被诱导为与自己无关的订阅关系多付 gas。标准特别点名借贷协议：把一个正参与清算的预言源取消订阅会造成异常清算损失，退订前那一问是保险丝而不是礼貌动作。

与拉取式预言机的选择其实是一道架构题：更新频率低、消费者少时，拉取模型够用且攻击面小；状态敏感、消费者多的清算场景，推式的一致性收益才开始值得付订阅治理的成本。还有一条工程提醒藏在事件语义里——推送发生在发布者交易内部，排障时别只在订阅者自己的交易记录里找更新痕迹，数据的入场凭证在发布者那笔交易的事件日志中，两边日志要拼起来才是完整时间线。评估预言机依赖时顺手画一张订阅表，谁在推、推给谁、谁有权改表，一屏就能看清这个组件的权力结构。

红利是即时与一致：所有订阅者在同一次交易里看到同一份数据，不存在“A 已更新、B 还在用旧值”的时间差，对 NFT 借贷、抵押品估值这类依赖实时状态的组合场景很友好。代价同样直白：发布者被迫在业务执行路径上调用外部合约，订阅者代码的错误会阻断发布者的调用；订阅者若能反向影响发布者状态，重入窗口就会出现，标准也正是为此设计了 isLocked 与双阶段批准。读这类合约时要点很明确：订阅表由谁维护、能不能被单方面清空；exec 实现是否对所有选择器都有兜底处理；强制类函数是否仍在生效、是否已被 renounce。推式架构把复杂度从查询方搬到了发布者与订阅表上，审查重心也必须跟着搬。标准仍是草案，函数细节以仓库当前文本为准。本文为机制说明，不构成任何投资建议。