预言机与可信上链
# 预言机与可信上链
上链不等于真实：区块链让已确认的记录难以被单方篡改，但不能把假数据变成真数据。例如，冷链传感器能自动记录温度，但设备也可能故障或被篡改，所以自动采集和上链都不能替代源头校验。
# 预言机：把链外数据提供给智能合约
智能合约不能像普通后端一样直接调用外部 HTTP 接口，否则不同节点可能拿到不同结果。预言机（Oracle） (opens new window)负责获取外部数据，经过验证后供合约使用；它不是预测未来的工具，也不是自动判断真假的机器。
例如，借贷合约通过预言机获取 ETH 价格，计算抵押品价值，再判断是否允许清算。预言机提供数据，合约按规则处理业务；实际执行仍需要交易触发。
可靠性需要分层保证：多数据源、多独立节点交叉验证，降低单点造假风险；签名校验确认数据来自谁、是否被改动；业务合约检查更新时间和异常值，拒绝使用过期或明显异常的数据。这些措施能降低风险，但不能保证源头数据永远真实。
# Relayer：代为提交链上交易的服务
Relayer（中继服务）是负责接收任务、组织并提交链上交易的后台程序。它是一类服务角色，可以自己编写，也可以使用第三方提供的中继服务。实现时可以选择不同的编程语言、运行平台和签名方式，核心职责都是把待执行的操作组织成交易并提交到链上。
# 一次交易怎样送上链
例如定时结算：后台定时任务生成结算请求，Relayer 检查条件，组织并提交调用结算合约的交易。一次写链通常包含这些步骤：
- 接收任务：从接口、链上事件或任务队列中取得待处理请求，核验是否允许执行。
- 组织交易：确定目标链、合约和方法，填写参数、交易序号 nonce 和 Gas 费用等信息。
- 请求签名：使用本地密钥、硬件签名设备或 KMS 等签名服务，对交易签名。
- 广播并确认：通过区块链 RPC 节点提交已签名交易，保存交易哈希并查询回执，确认执行成功后才将任务标记为完成。
拿到交易哈希只表示交易已被提交，不保证执行成功。回执暂时查不到时，也不能直接认定失败并重新发一笔；应先核对原交易和链上业务状态。进一步说明见 交易生命周期。
# 谁签名、谁支付 Gas，谁决定权限
在普通以太坊交易中，交易发送账户负责签名并支付 Gas。Relayer 用自己的账户提交交易时，由该账户支付链上费用；私钥可以交给签名服务保管，但 ETH 余额仍属于对应的链上账户，签名服务不会自动替它充值或支付 Gas。
另一种场景是用户签署操作授权消息，由 Relayer 用自己的账户发送外层交易并先支付 Gas。这通常需要合约支持元交易，并核验用户授权。若 Relayer 只是转发用户已经签好的普通交易，发送账户仍是用户，Gas 也仍由用户账户支付，不能仅凭 “经过了 Relayer” 就认为费用被代付。
Relayer 不能绕过合约的权限检查。例如某个方法要求管理员权限，Relayer 的交易发送地址就必须具备这项权限；用户签署的授权消息也必须按合约规则验证，不能把任意后台请求当作授权。
# Relayer 与 RPC、KMS、预言机怎样分工
| 角色 | 负责什么 |
|---|---|
| Relayer | 决定何时处理任务，组织交易，调用签名与广播接口，跟踪结果和处理失败 |
| 区块链 RPC | 提供查询链上状态、提交已签名交易等接口，不替应用决定是否应该执行某项业务操作 |
| AWS KMS (opens new window) | 签名服务的一种选择，保护签名密钥并检查调用权限，不判断业务操作是否符合规则 |
| 预言机 | 获取并提供可验证的外部数据；可信程度取决于数据来源、验证方式和参与节点 |
这些角色可以配合使用。Relayer 可以读取预言机提供的数据再触发交易，也可以先核验外部结果再提交，承担中心化预言机的部分职责；使用 KMS 则主要改善密钥保护，不会自动让业务数据真实或执行过程去中心化。
# 面试时怎样解释 Relayer
建议回答：Relayer 是代为提交链上交易的后台服务。它接收业务任务，检查条件，组织交易、请求签名，再通过 RPC 广播并确认结果。例如定时结算，后台到时间后提交任务，Relayer 检查是否满足结算条件，再调用合约。Gas 由发送交易的账户支付，合约仍会检查权限和业务规则；服务还要处理失败和重复请求，不能把交易提交成功等同于业务执行成功。
使用云端签名服务的实现示例见 使用 AWS KMS 签署以太坊交易 (opens new window)。
# 预言机与 Relayer：区别与可信度
合约不能主动查询外部接口，但链下程序可以查询后，通过交易把结果提交给合约。所以不一定要使用 Chainlink，自建后台服务也能完成这件事。
- Relayer（中继服务）侧重代为提交交易。它可以先查询接口、核验条件，再调用合约，但是否核验以及怎样核验取决于具体实现。运行平台和签名服务提供基础设施，不会让合约获得访问外部接口的能力。
- 预言机侧重为合约提供可验证的外部数据。它可以是中心化服务，也可以由多个独立节点组成网络。因此两者不是完全互斥的产品：核验并提交外部结果的 Relayer，也承担了中心化预言机的部分职责。
去中心化预言机的优势是减少对单一参与方的信任，不是自动保证数据真实。例如获取 BTC 价格，自建服务只读取一家交易所，需要信任该接口和自己的后台；采用多源、多节点聚合的预言机，则能降低单个来源出错或单个节点作恶的影响。代价是额外的服务费用、接入与验证成本，仍需检查数据时效。
但如果物流状态只来自一家公司的数据库，即使多个节点都读到 “已签收”，也不能证明货物真的送到了收件人手中。多节点能增强执行过程的可信度，不能把同一个数据源变成多个独立证据。
选型看信任边界：市场价格等需要独立外部依据的数据，优先评估可靠的预言机服务；业务本身接受由指定运营方确认的结果时，可以由受控 Relayer 提交。引入多节点执行网络，可以减少对单个执行服务的依赖，但数据源仍需要独立核验。
# 常见预言机与适用场景
| 预言机 | 主要特点 | 适合什么场景 |
|---|---|---|
| Chainlink (opens new window) | 既提供现成的数据服务，也支持由去中心化预言机网络执行自定义工作流 | 资产价格读取、链外 API 与链上合约联动 |
| Pyth (opens new window) | 聚合交易所、交易机构等提供的价格，侧重低延迟金融数据 | 永续合约等对价格更新速度敏感的应用 |
| RedStone (opens new window) | 模块化价格预言机，覆盖质押、再质押等资产 | 需要相关资产价格的借贷与 DeFi 应用 |
| UMA (opens new window) | 先提交结果，留出质疑期，有争议再裁决 | 预测市场、保险等事件结果确认，不是高频价格源 |
Chainlink 中这两项能力用途不同：
- Data Feeds (opens new window)：读取现成数据。多来源数据经预言机网络聚合后发布到链上，例如借贷合约读取 ETH/USD 价格来估值抵押品。
- CRE（Chainlink Runtime Environment） (opens new window)：编排完整流程。用 TypeScript 或 Go 编写由事件或定时任务等触发的工作流，调用链外 API、处理数据并读写合约；例如 “收到订单事件 → 查询物流状态 → 将结果写回链上” 。
Data Feeds 和 CRE 是不同能力，不是改名或替代关系；CRE 也能用于构建自定义数据源。选型时重点检查目标链与资产是否支持、更新频率是否满足业务、费用及异常处理机制；合约侧的安全检查见 预言机、滑点与 MEV 各自保护什么。
课程原文见 区块链基础：可信上链。