ERC-1154 预言机接口：一个 resultFor 函数如何定义链下数据的取用契约

智能合约看不到链下世界。价格、天气、比赛结果进入区块链，都要靠预言机这类中间层转递。ERC-1154 创建于 2018 年 6 月 13 日，尝试给这层中间设施定一个统一接口，让不同的预言机实现可以互换。仓库记录的当前状态是 Withdrawn，但它的接口设计浓缩了预言机系统最核心的两个问题：数据怎么取、什么时候算取到了，至今读来仍然是理解链上数据依赖的入门范本。

全部接口只有两个方向

标准给两个角色各规定了一个函数。数据提供方是一个只需要视图函数的合约：resultFor 接收一个字节数为 32 的编号，返回字节流形式的结果。数据消费方则实现 receiveResult，接收预言机、编号和结果三个参数，供推送式系统调用。取数模式因此分成两类：拉取式是消费方在需要时主动查询 resultFor，推送式是预言机在数据就绪时主动调用 receiveResult 把结果塞进来。

标准明确说了两种模式可以互相转换：想把推送改拉取，就部署一个消费合约把收到的结果存下来，再让存储合约实现 resultFor；想把拉取改推送，就在预言机上加一个方法，传入消费方地址并回调它的 receiveResult。换句话说，推拉之争不是接口之争，同一套语义从两边都能搭。

两条 MUST 条款的分量

接口定义后面跟着两条强制约束，是整份标准最有价值的部分。第一条：当某个编号的结果尚未就绪时，resultFor 必须回滚，而不是返回零值或旧值。这条规则把”还没有答案”和”答案是零”区分开——对依赖数据做清算、结算的合约来说，把缺数据当成零值使用，后果可能是整条交易链路的连锁错误。第二条：某个编号的结果一旦就绪，resultFor 必须永远返回同一个值。编号对应的是一次提问，提问的答案不许漂移，这让任何事后的链上验证都能复现当时的判断依据。

把这两条合起来看，标准实际上定义了”确定性取数”的底线：要么明确告诉你没有，要么给一个永不反悔的有。后来各类预言机产品在这条底线之上竞争的是签名聚合、去中心化报价、更新频率这些维度，但”缺数回滚、给数不改”始终是同一层语义。

编号体系与消费侧的代价

用 bytes32 做编号意味着编号格式完全由部署方自定：可以是查询字符串的哈希、序列号，也可以是任何能唯一定位一次请求的标识。灵活的另一面是标准化止步于此——标准没有规定编号怎么生成、结果怎么编码字节流，跨项目仍然要靠约定。这也是这类极简接口的共同局限：它统一了”怎么问”，统一不了”问什么、怎么答”。

消费侧的 receiveResult 同样挂着两条 MUST 条款，和 resultFor 的约束互为镜像。第一条：如果 msg.sender 不是被授权为该编号供数的预言机，函数必须回滚——结果的来源身份和结果内容同等重要，未授权地址塞进来的数据即使碰巧正确也必须拒绝。第二条：同一个编号不得被重复调用第二次，收到即定稿，杜绝同一提问先后得到两个答案的可能性。把四条 MUST 排在一起看，标准实际上给”一次提问、一个答案、一个来源、不许反悔”画出了完整的状态闭环，接口虽小，语义密度极高。

留一个贴近本栏目的观察角度。NFT 合约里越来越常见的动态元素——可变属性、竞价状态、链上随机结果——背后多半有某种”等一个结果”的结构：合约发出一个请求编号，等待外部把结果送回来。ERC-1154 的四条 MUST 恰好构成这类结构的验收清单：编号是否唯一对应一次请求、缺数时是否显式回滚、结果是否永不漂移、来源是否经过授权核验。索引器或钱包显示某枚 NFT 的属性为空时，先分清它对应的是”尚未产生结果”还是”结果本身为空值”，两种状态在劣质实现里长得一模一样，处置方式却完全不同。

对 NFT 与铭文场景来说，这份标准提醒的是一个更朴素的问题：动态 NFT 的元数据若依赖链下喂价或链下状态，其可靠性取决于背后的取数契约。一个连”没有结果”和”结果为零”都不区分的喂数接口，会让链上逻辑在数据缺位时静默出错。核验工具链、索引器报出的”无数据”到底是回滚语义还是零值语义，值得在排障时先问清楚。本文为机制说明，不构成任何投资建议。