读者定位：有编程经验，理解基本概率、函数、签名和区块链交易，但希望把“预言机”学到可以读论文、审协议和设计系统的程度。

资料边界：本文结合以太坊官方开发文档、Chainlink 官方架构文档、Compound 文档、原始论文与 Crossref 文献元数据整理。官方实现文档用于说明实现方的公开设计，不等于独立安全认证；论文结论仍应以全文、实验数据和审稿版本为准。

0. 先给结论

预言机是把链下信息转换成链上可验证输入的协议、节点集合、证明系统和治理机制的总称。

它解决的不是“智能合约不会计算”，而是：

智能合约如何知道区块链之外发生了什么。

智能合约可以可靠计算：

已有链上输入 + 确定性代码 -> 确定性状态转换

它不能直接可靠计算：

“今天北京下雨了吗？”
“某交易所的 BTC/USD 是多少？”
“现实中的货物是否已经送达？”
“另一条链上的交易是否最终确认？”

原因是验证者必须独立执行同一段代码并得到同一个结果。如果每个验证者自行访问 HTTP API，返回值、时延、地区路由和错误处理都可能不同，链上共识就会被外部网络的不确定性破坏。

因此必须记住：

区块链共识可以证明“大家同意这个报告”，但不能仅凭链上共识证明“报告描述的现实世界事实是真的”。

1. 三种 Oracle：同名但不是同一个概念

1.1 计算理论 Oracle

在计算复杂性理论中，Oracle 是抽象黑盒。图灵机可以在一个步骤中提问，Oracle 返回答案：

输入 x 是否属于集合 L？

带有 Oracle A 的复杂性类可以写作 P^A。这里的 Oracle 不是服务器、节点或区块链组件，而是研究额外查询能力如何改变计算难度的理论工具。

1.2 密码学 Random Oracle

Random Oracle Model（ROM）把哈希函数理想化为公开随机函数：

\[H:\{0,1\}^{*}\rightarrow\{0,1\}^{n}\]

对新输入随机采样，对同一输入保持一致：

if x not in table:
    table[x] = random_n_bit_string()
return table[x]

ROM 用于签名、Fiat-Shamir 变换、身份认证等证明。Bellare 与 Rogaway 的论文《Random Oracles are Practical》推动了这一范式；Canetti、Goldreich 与 Halevi 后续说明了理想模型和具体实现之间存在模型差距。1234

ROM 的边界：

  • 真实哈希函数不是完美随机函数；
  • ROM 中安全不保证具体实例化一定安全；
  • ROM 不提供现实世界数据；
  • ROM 不能替代区块链预言机。

1.3 区块链现实预言机

区块链预言机处理：

  • 交易所价格、汇率、利率；
  • 体育、天气和保险事件；
  • 物联网传感器、物流状态；
  • 链下计算结果；
  • 另一条链的交易、区块和最终性；
  • 随机数；
  • 人类投票和争议裁决。

系统边界通常是：

数据源
  -> 采集节点
  -> 解析和异常检测
  -> 多节点报告
  -> 聚合或争议解决
  -> 签名和提交
  -> 链上验证
  -> 业务合约执行

2. 智能合约为什么不能直接请求互联网

如果合约执行：

price = HTTP_GET("https://example.com/price")

不同验证者可能遇到不同时间的响应、不同地区的 CDN、请求超时、JSON 精度差异或 API 攻击。状态转换因此可能不一致。

以太坊官方文档把不能读取链下数据列为智能合约的设计性限制。5 正确流程是：

  1. 链下节点读取外部数据；
  2. 节点形成报告；
  3. 报告由签名、阈值或证明保护；
  4. 报告作为交易写入区块；
  5. 验证者只验证报告；
  6. 智能合约基于同一报告执行。

API 只回答“给我一个值”，预言机还必须回答：

  • 谁获取；
  • 什么时候获取；
  • 原始来源；
  • 是否独立观察；
  • 是否签名；
  • 是否过期、重放或回滚；
  • 冲突时谁决定；
  • 错误如何纠正；
  • 损失由谁承担。

所以 API 是数据接口，预言机是带有证明、共识、激励和治理的数据结算系统。

3. 形式化模型

设：

  • W_t：时间 t 的现实世界状态；
  • g(W_t)：目标事实，例如某时刻 BTC/USD；
  • S_i：第 i 个外部数据源；
  • D_i(t)：节点从 S_i 获取的观察值；
  • N_i：第 i 个预言机节点；
  • A：聚合算法；
  • R_t：最终发布的链上报告。

观测模型：

\[D_i(t)=S_i(W_t)+\eta_i(t)\]

η_i(t) 可以表示测量误差、延迟、清洗错误或恶意偏差。

聚合模型：

\[R_t=A(D_1(t),D_2(t),...,D_n(t),M_t)\]

M_t 是元数据：

  • feed ID；
  • round ID；
  • 采样时间；
  • 截止时间；
  • 单位和小数位；
  • 数据源版本；
  • 节点签名；
  • 聚合规则版本。

链上验证：

\[Verify(pk_{set},R_t)=1\]

常见策略：

\[timestamp(R_t)\geq now-\Delta\] \[roundId(R_t)>roundId_{last}\] \[value(R_t)\in[min,max]\]

业务合约使用的是 R_t，不是现实状态 W_t。

预言机通常证明“报告流程符合协议”，而不是证明“现实世界事实无误”。

4. 完整数据流

4.1 请求型

用户或合约发起请求
  -> 链上产生 Request 事件
  -> 节点监听
  -> 节点访问外部 API
  -> 解析、校验、签名
  -> 返回结果
  -> 回调合约保存

适用于一次性事件、天气、链下计算和用户指定数据源。

4.2 推送型

节点定期观察
  -> heartbeat 到期或 deviation 超阈值
  -> 形成新报告
  -> 聚合器提交链上更新
  -> 消费者读取最新值

适用于 DeFi 价格、借贷、稳定币和清算。关键参数：

  • heartbeat：最长更新间隔；
  • deviation threshold：变化阈值；
  • min/max answer：有效范围；
  • stale timeout：消费者允许的最大延迟。

4.3 Pull 模型

消费者在需要时拉取带签名的最新报告，适合高频数据、多链部署和低频消费者。

4.4 Off-chain Reporting

Chainlink 官方文档描述的 OCR 思路是：节点先在链下交换观察并运行轻量共识，然后由一个节点提交聚合交易。67

好处是减少 Gas 和链上通信；代价是增加对节点通信、报告协议、传输者、节点治理和签名密钥的依赖。

5. 安全性质

5.1 来源认证

回答“这个值是谁报告的”。常见机制：数字签名、TLS 证明、TEE 证明、API 密钥、链上来源合约、Merkle 证明。

来源认证不等于事实正确。诚实签名的节点也可能读到错误页面。

5.2 完整性

回答“报告从生成到消费是否被篡改”。常见机制：哈希、签名、阈值签名、Merkle 树、单调递增轮次。

5.3 新鲜度

必须防止旧报告重放，检查：

  • timestamp；
  • roundId；
  • nonce；
  • validUntil；
  • 原始数据时间；
  • 观测到上链的时间差。

5.4 一致性

不同消费者是否看到同一轮的同一结果？否则会产生清算顺序差异、跨协议套利、估值不一致和结算分叉。

5.5 可用性和活性

预言机可能不提交错误值，却完全不提交值。原因包括节点离线、Gas 过高、链拥堵、数据源限流、报告者被审查或费用不足。

必须明确失败策略：

  • 使用最后一个新鲜值；
  • 暂停借贷或清算；
  • 切换备用源；
  • 进入治理；
  • 触发保险。

5.6 语义正确性

“比赛结束”必须定义官方来源、是否计入加时、取消比赛、改判、时区、截止时间和争议期间的状态。

很多故障来自事实定义模糊，而非密码学失败。

6. 去中心化的六个维度

  1. 数据源：是否依赖同一 API 或交易所；
  2. 运营者：节点是否由不同组织运营；
  3. 软件：是否存在共同实现漏洞；
  4. 基础设施：是否依赖同一云厂商或地区；
  5. 聚合：是否有单一最终决定者；
  6. 治理：谁能换节点、改参数、升级或暂停。

20 个节点读取同一个被污染的 API，仍然只有一个真实故障域。

7. Oracle Problem 的不可消除性

考虑两个现实世界：

W0：事件没有发生
W1：事件发生了

若二者产生完全相同的链上交易、签名和报告，智能合约就无法区分它们。

系统必须引入额外假设：这些边界也是综述研究所称的 Oracle Problem 核心。89101112

  • 数据源诚实；
  • 诚实节点超过阈值；
  • 经济激励有效；
  • 挑战者及时监控；
  • TEE 未被破坏；
  • TLS 服务内容可信；
  • 现实事件可明确定义和观测。

区块链能对进入系统的事实达成共识，却不能仅凭自身判断链外事实是否真实。

8. 方案比较

方案 主要证明对象 优点 主要失败边界
中心化 API 单个服务返回值 简单、便宜、低延迟 单点故障、可篡改
多节点中位数 多节点报告一致性 抗少数异常值 相关数据源共同错误
阈值签名 至少 t-of-n 节点签名 防单节点伪造 签名不证明事实
乐观预言机 未被及时挑战的声明 成本低 依赖监控和争议
TEE 代码在可信环境运行 可隐藏数据 硬件、密钥、侧信道
TLS 证明 服务器确实返回内容 可验证来源 不证明内容正确
ZK 证明 计算过程和输入关系 计算完整性强 输入语义仍需信任
轻客户端证明 另一条链状态 跨链状态验证强 依赖对方最终性

9. 经典攻击

9.1 现货价格操纵

借贷协议常使用：

\[抵押价值=抵押数量\times预言机价格\]

攻击者可以用闪电贷放大资金，在薄流动性市场推动价格，让预言机读取异常值，借出超过真实抵押能力的资产，再恢复价格。

防护：多交易所、多来源、中位数、TWAP、流动性加权、最大变动、熔断、更新与清算错开、新鲜度检查。TWAP 不能自动消除操纵风险，窗口长度、市场深度和更新延迟仍需单独建模。13

9.2 过期报告重放

防护：

roundId 单调递增
timestamp 在 maxAge 内
nonce 不重复
feedId 匹配
validUntil 未过期

9.3 节点串通和相关性

若 n=7，中位数只在少于约一半节点恶意时有统计鲁棒性。若节点都使用同一个 API，增加节点数量不能消除共同错误；Sybil 抵抗和激励设计必须单独分析。14

9.4 MEV

价格更新交易在内存池公开后，套利者可以抢先交易，再利用其他合约的滞后更新获利。可考虑批量更新、私有交易、排序约束和同区块一致性检查。

9.5 治理和密钥

节点集合更新、阈值配置、价格源配置、升级、暂停和管理员私钥都可能形成系统级单点。审计工作需要把这些治理入口纳入威胁模型。15

10. 价格预言机算例

假设：16

ETH 数量：100
真实价格：2,000 USD
债务：120,000 USD
清算阈值：85%

抵押价值：

\[100\times2000=200000\]

健康度：

\[200000/120000=166.7\%\]

若预言机被操纵为 1,000 USD：

\[100\times1000=100000\]

健康度：

\[100000/120000=83.3\%\]

协议会错误地认为账户可清算。

消费者应至少检查：

function readPrice(Report memory report) internal view returns (uint256) {
    require(report.feedId == expectedFeedId, "wrong feed");
    require(report.roundId > lastRoundId, "stale round");
    require(block.timestamp - report.timestamp <= maxAge, "stale price");
    require(report.answer > 0, "invalid answer");
    require(verifyThresholdSignature(report), "bad signature");
    return uint256(report.answer);
}

这只能落实协议约束，不能单独保证价格真实。

11. 乐观预言机

流程：

提出事实 + 锁定保证金
        |
        v
      挑战窗口
     /       \
无人挑战     有人挑战
   |            |
确认报告       进入争议解决
                  |
             赔偿或惩罚

适合低频、可等待、可争议事实。不适合毫秒级业务、不可逆结算、无人监控或无法客观裁决的事实。

必须回答：挑战窗口多长、谁监控、挑战成本谁支付、仲裁者是否独立、错误能否客观证明、无人挑战是否真的代表正确。

12. TEE、TLS、ZK 与阈值签名

阈值签名

证明至少 t 个授权节点签署报告，不证明报告对应真实事实。

TEE

证明程序在特定隔离环境运行，不自动证明输入数据真实。Town Crier 是这一类系统的经典研究案例。17

TLS 证明

证明 HTTPS 服务返回过某内容，不自动证明服务器内容正确。DECO 研究了如何把 TLS 数据证明用于去中心化预言机。18

ZK 证明

证明某计算对给定输入产生了某输出，不自动证明输入就是现实真相。

轻客户端证明

证明另一条链的状态满足包含证明，不自动证明另一条链的治理和经济系统没有错误。

13. 设计检查清单

  1. 事实的精确定义是什么？
  2. 观察时间和结算时间是什么？
  3. 数据源是否独立？
  4. 是否存在单一 API 或交易所依赖？
  5. 单位和小数位如何统一？
  6. 数据缺失或冲突时怎么办？
  7. 聚合能容忍多少恶意节点？
  8. 节点是否由不同组织和基础设施运营？
  9. 如何防重放和过期？
  10. 消费者是否检查 timestamp 和 roundId？
  11. 错误报告谁能挑战？
  12. 挑战窗口是否足够长？
  13. 错误能否客观判定？
  14. 节点如何奖励和惩罚？
  15. 管理员能否更换源或升级？
  16. 预言机彻底失效时最大损失是多少？

14. 相邻概念区别

预言机与 API

API 返回数据；预言机处理来源、证明、聚合、延迟、争议和结算。

预言机与索引器

索引器把链上数据读到链下；预言机把链下数据写回链上。

预言机与跨链桥

跨链桥重点是状态或资产跨链转移；预言机重点是向合约提供外部事实。桥可以使用预言机，但两者不是同一概念。

预言机与共识

共识决定哪些交易和报告进入区块；预言机决定哪些链下观察被包装成报告。共识可以保证所有节点接受同一个错误报告。

15. 参考文献

16. 推荐学习顺序

第一步：理解确定性

回答：

为什么验证者不能各自访问外部 API？

第二步：理解报告

手写一个包含以下字段的报告：

feedId
roundId
answer
decimals
observedAt
validUntil
sourceHash
signatures

第三步：实现消费者校验

实现签名校验、轮次递增、时间新鲜度、数值范围、feed ID 匹配和异常值拒绝。

第四步：模拟攻击

构造单节点异常、过半串通、旧报告重放、数据源失效、合法格式但错误语义和价格越过清算阈值。

第五步：读论文

先读综述，再读 Town Crier、DECO，最后读随机预言机方法论论文。

17. 最终判断框架

审查任何预言机协议时，不要只问“是否去中心化”，而要连续追问：

  1. 谁观察了什么？
  2. 观察是否独立？
  3. 如何证明观察来源？
  4. 如何处理冲突？
  5. 谁决定最终值？
  6. 报告是否新鲜？
  7. 错误如何挑战？
  8. 错误能否客观判定？
  9. 经济惩罚是否足够？
  10. 失败时协议会损失多少？

最后压缩成一句话：

预言机不是把“真相”搬进区块链，而是把关于数据来源、观察过程、节点行为、密码学证明、经济激励和治理权力的一组假设，编码成智能合约可以执行的报告。

参考资料说明

本文引用的论文标题、作者、年份和 DOI 已通过 Crossref 元数据核验；Ethereum、Chainlink 和 Compound 链接为官方文档。学术论文的具体实验结论应以论文全文、附录和后续复现实验为准。

  1. Bellare, M.; Rogaway, P. Random Oracles are Practical: A Paradigm for Designing Efficient Protocols. ACM CCS, 1993. DOI ↩

  2. Canetti, R.; Goldreich, O.; Halevi, S. The Random Oracle Methodology, Revisited. Journal of the ACM, 2004. DOI ↩

  3. Boneh, D.; Shoup, V. A Graduate Course in Applied Cryptography。 在线教材 ↩

  4. Katz, J.; Lindell, Y. Introduction to Modern Cryptography。重点阅读安全定义、归约证明、数字签名、承诺和 Fiat-Shamir 变换。 ↩

  5. Ethereum.org. Introduction to Smart Contracts: Limitations and Oracles. 官方开发文档。 链接 ↩

  6. Chainlink Documentation. Data Feeds Architecture. 官方架构文档，包含 Basic Request、Decentralized Data Model 和 Offchain Reporting。 链接 ↩

  7. Chainlink Foundation. Chainlink 2.0 and the Future of Decentralized Oracle Networks. 官方白皮书页面。 链接 ↩

  8. Caldarelli, G. Understanding the Blockchain Oracle Problem: A Call for Action. Information, 2020. DOI ↩

  9. Caldarelli, G.; Ellul, J. The Blockchain Oracle Problem in Decentralized Finance—A Multivocal Approach. Applied Sciences, 2021. DOI ↩

  10. Caldarelli, G. Overview of Blockchain Oracle Research. Financial Innovation, 2022. DOI ↩

  11. A Survey on Blockchain Oracle Implementation. ACM Computing Surveys, 2023. DOI ↩

  12. Before Ethereum: The Origin and Evolution of Blockchain Oracles. IEEE Access, 2023. DOI ↩

  13. TWAP Oracle Attacks: Easier Done than Said? IEEE International Conference on Blockchain and Cryptocurrency, 2022. DOI ↩

  14. A Truth-Inducing Sybil Resistant Decentralized Blockchain Oracle. IEEE BRAINS, 2020. DOI ↩

  15. Auditing the Blockchain Oracle Problem. Information Systems Research, 2020. DOI ↩

  16. Compound Labs. Compound Protocol Documentation. 官方开发文档。 链接 ↩

  17. Zhang, F.; Cecchetti, E.; Croman, K.; Juels, A.; Shi, E. Town Crier: An Authenticated Data Feed for Smart Contracts. ACM CCS, 2016. DOI ↩

  18. Zhang, F.; et al. DECO: Liberating Web Data Using Decentralized Oracles for TLS. ACM CCS, 2020. DOI ↩