让预言机替你跑一段代码：外置计算的信任边界与账单

测试这类服务时，有两个专属于外置计算的回退分支一定要专门压测，普通合约测试覆盖不到。第一个是「超时与不返回」：链下执行天然可能永远等不到法定数量的节点返回，你的合约如果假设请求总有回执，就会在某个请求上永远挂起，等它的是一个没人按的门铃；正确做法是给每个请求配可推进的过期路径，超时后状态机能退回旧值或安全模式。第二个是「结果迟到」：链下网络不保证顺序，一个旧请求的结果可能晚于新请求到达，合约必须按请求编号认领结果，晚到的旧答案要么丢弃要么按业务规则处置。把这两个分支写进检查单，比研究节点数量更能决定你的集成在真实网络上是否体面地失败。

智能合约有个先天限制：它不能主动上网。链上的合约想知道外面的世界，只能等别人把数据送进来——传统预言机送的通常是「一个现成结果」，比如某币对价格。但有一类需求，送结果不够用：我需要把三个 API 拼起来做一次计算、按我的参数聚合、再把结论带回来，而这个计算逻辑我不想交给喂价网络预设的模板。于是出现了「外置计算」这一层：你提交一小段代码，预言机网络在链下替你运行它，多个节点各自算完再互相比对，结果签名送回链上，合约验签后采纳。 这个模式的零件可以按信任链条拆开看。输入端，你的代码声明要访问的外部资源：链下 API、链上历史数据、甚至你随代码附带的参数；执行端，网络的每个节点在受控的链下运行时里独立执行同一份代码，各自取数、各自算，不存在一个「总执行器」说了算；裁决端，协议要求足够多个节点返回一致结果才提交上链，少数派算歪了会被丢弃。到链上这一步，合约做三件事：验节点签名的门槛、核对结果与你声明的请求是否对应、把采纳与否写进自己的状态机。 它与传统喂价、与「让合约自己去查」（即链下读取回退那一类）分别是什么关系？传统喂价是推送型公共服务，数据格式与更新节奏由网络定，适合高频标准化的价格；链下读取回退是拉取型，合约遇到查不到的数据时现场指路去问外部端点，但那条路没有多节点交叉验证，信任落在端点运营方；外置计算介于两者之间——把「计算逻辑」从合约代码里搬出去执行，但用多节点冗余与签名门槛来对冲单点造假。三种方式各占一角，没有通吃。 成本模型同样要看三眼。第一眼是执行计费：这类网络通常按运行步数或计算单元计价，你塞进循环、重试、大响应体，费用随之上涨，运行时还会给执行时长和数据体积设硬上限，超限直接失败；写这类代码的心法和写智能合约相反——不是越优雅越好，而是越短平快越省钱。第二眼是链上提交费：结果最终要一笔交易写回，失败的那笔照样扣 gas。第三眼是延迟：跨节点执行加聚合，天然比读一笔现成喂价慢，它适合「分钟级可接受」的任务，不适合每次兑换都要问一遍的高频路径。 DeFi 里的典型用法有：把外部利率、指数或审计数据换算成协议参数再喂给合约；触发与链下事件联动的动作，比如到期结算核对、违约认定；给风险模型补充链上查不到的元数据。写这些逻辑时记住一条铁律：外置计算保证的是「多数节点算出一样的结果」，不保证「结果符合现实」——你的代码有 bug，节点们会一致地把 bug 执行得很漂亮。上线前的模拟环境与真实外部数据回测，一步都省不掉。 本文描述的是这一层基础设施的通用工作方式，并以公开文档中对该类服务的描述为参照，具体字段与计费随版本演进；不构成投资建议，也不构成对特定实现的性能承诺。