预言机调研

预言机

1. 概述

预言机主要承担两个工作，一是验证信息可靠性，二是传递信息。

如果没有预言机，区块链的信息来源将仅限于其内部数据，其广泛使用的潜力和可能性将会大大降低。

区块链预言机是区块链与外部世界之间的桥梁。它们使区块链上的智能合约可以访问链外数据。

区块链预言机可以被认为是一个区块链层，用于查询、验证外部数据源。

虽然区块链预言机没有解决数据可用性问题，但它们可以使用外部数据源将链下数据传输至链上。

2. 预言机分类

2.1 按信任产生机制分：

根据信任产生机制的不同，预言机可以分为几种不同的种类：

详解预言机

2.1.1 中心化预言机（比如 Provable , 原 Oraclize）

中心化预言机由单个中心化机构为智能合约提供数据。这种情况下，数据需求方需要相信这个预言机不会欺骗他们，所以这个中心化预言机需要证明自己是值得信任的。

中心化预言机因其中心化的思想，需要引入第三方可信机构，如国家或能提供背书的大型企业，验证方式也是通过第三方独立验证。

（1）中心化预言机有两种实现机制：

• 第一种：是通过算法等真实性证明机制来证明自己运行在可信的执行环境中，提供的数据是数据源在某个时间点真实的、未被篡改的数据。数据使用者无需信任中心化的机构本身，只需要信任中心化机构使用的技术和机制即可。
• 第二种：是由数据源提供的官方预言机。这些数据源通常是一些链下世界可靠可信的机构，自身拥有比较好的信用和声誉，数据使用者只需要信任机构本身。这种模式比较类似于传统的互联网，用户使用机构提供的服务，并全权信任这些服务商。

（2）优势和劣势

• 劣势：由于数据由单一机构提供，用户对机构的信任决定了预言机的信用，单一数据源无法避免单点故障，对作恶行为也无法进行约束，安全性难以保证。另外，中心化预言机通常也很难连接到其他的预言机，因而提供的数据范围受限。
• 优势：由于无需多节点进行协调和博弈，节省了大量的时间，提升了效率，同时因为不需要多个节点来支撑服务，也就无需支付多节点网络的费用，使用费用较低。

2.1.2 去中心化预言机（比如 Chainlink）

去中心化的预言机符合区块链去中心化的设计精神，通过机制的设计，来保障数据的可信。

去中心化预言机秉持着与区块链相同的去中心化原则，通常使用多重签名或分布式算法保证数据的正确性、一致性，不需要引入第三方机构，但在实现上会更困难，性能也会成为瓶颈。

在去中心化预言机中，众多节点组成分布式节点网络，一起合作来提供数据，相互博弈和制约，通过经济模型减少作恶的可能性，提升整个系统的容错能力。

因为需要多节点共同工作，去中心化预言机的节点网络的规模会影响其提供的数据的可靠性，规模更大的网络提供的数据具有更高的可信度，所以系统通常会提供一些经济激励来鼓励更多节点参与。

参与提供服务的节点在提供数据时通常也被要求质押一部分代币（一般是项目代币本身），一旦系统发现节点有作恶行为，质押的代币就会被没收。

去中心化预言机在设计时需要考虑以下几个问题：

1. 节点共谋问题，如果多个节点联合起来作恶，应该如何应对；
2. 数据隐私，在节点数据开放传输和查询的情况下，如何保障这些数据的私密性；
3. 数据获取的时效性，如何减少多个节点之间数据的协调和确认时间；
4. 节点从其他节点复制数据的问题，如何防止节点直接获取其他节点的数据而非从数据源处提取数据；

去中心化节点网络可以避免产生中心化预言机的单点故障，但是相应的，由于需要向多个节点支付服务费用，去中心化预言机使用起来也更加昂贵。

2.1.3 联盟预言机（比如 Maker 的预言机）

联盟预言机是去中心化预言机的一种特殊形式。组成节点网络的不止有普通节点，还有一些指定的可信机构作为节点。

联盟预言机的信任来源相比前面两种更加复杂，既包括了对作为节点的有业内声誉的机构的信任、也包括了对整个网络制衡机制的信任，还包括了对预言机项目方挑选节点的机制的信任，数据使用者需要信任所有这些相关方不会因为利益而选择作出伤害自身信誉的行为。

这种节点网络的组成方式带有某种程度上的中心化的特性，但是作为高性价比的 trade-off，在行业发展的初期，不失为一个不错的选择。只是这种带有中心化色彩的信任机制，可能难以承载价值过大的智能合约的需求。

从上述描述中不难看出联盟预言机面临的问题：

1. 可信节点的身份保密程度会影响到节点是否会被勒索或者贿赂，进而影响网络的安全运行；
2. 可信节点提供的数据是否具有很大的自身利益相关性，毕竟如果涉及到自身利益，很难避免数据被恶意操控的可能。

2.2 按作用分

钟摆协议（Pendulum Protocol）安全、可扩展的去中心化数据

2.2.1 数据预言机：

根据请求将外部数据提供给智能合约，并使得业务层智能合约和链下事件之间可以交互。

2.2.2 计算预言机：

在链下执行用户定义的运算密集型任务，为现有的区块链提供无限的运算能力，为传统的计算市场带来去中心化的通证经济。

2.3 其他

2.3.1 软件预言机

这种形式的预言机通常包括易于访问的在线信息源，例如网站和公共数据库。它们通常提供以下信息：温度读数，公共交通信息以及各种金融资产的当前价格。

软件预言机可能是目前最强大的预言机类型，因为它们与互联网具有固有的互连性。这种连接允许软件预言机向智能合约提供最新信息。

2.3.2 硬件预言机

这种形式的预言机通常负责物理世界中发生的事件，并将数据发送到智能合约上。例如，在供应链管理中，如果带有 RFID 标签的物体要到达特定的仓库，则可以将该数据发送到智能合约，硬件预言机系统可以在整个供应链中进行货物跟踪。

2.3.3 输入式预言机

这种形式的预告机具有简单地向智能合约提供数据的功能。所提供的数据在智能合约的外部，并且在接收信息后开始执行。上面提供比特币价格的新闻网站，可以被归入为输入式预言机。

2.3.4 输出式预言机

这些预言机将智能合约数据传送到外部源。就上面的例子而言，一旦张三被确定为赢家，智能合约便可以将此信息传达给钱包提供商，以便自动更新其余额以反映资金的增加。在这种情况下，智能合约本身就可以作为输出式预言机运作。

2.3.5 基于共识的预言机

这种预言机的功能是查询多个信息源，并根据它们的共识得出结果。例如，可以使用 4 个网站来查询比特币的价格。如果所有预言源（网站）返回的值都相同，则智能合约可以成功执行。

3. 区块链预言机的作用

外部数据源的输入确定性

区块链预言机是将区块链安全连接至链下系统的中间层，区块链可以通过预言机连接至数据提供商、web API、企业后端、云服务商、物联网设备、电子签名、支付系统以及其他区块链等各种链下环境。

预言机具有几大关键功能：

• 等待响应------监控区块链网络，扫描网络中是否有来自于用户或智能合约的链下数据请求。
• 获取数据------从一个或多个链下系统获取数据（比如由第三方web服务器运行的链下API）
• 格式化------将来自API的数据转换成区块链可读的格式，并将链上数据转换成外部API兼容的格式，以此打破链上链下的交流屏障。
• 验证------使用数据签名、区块链交易签名、TLS签名、可信执行环境（TEE）证明以及零知识证明等各种工具为预言机服务提供加密证明。
• 计算------对数据进行运算，比如基于多个预言机提交的数据计算出中位数，或基于不同类型的数据（如：个人风险情况、市场费率和资金成本等）生成保险报价。
• 广播------通过在区块链上签名并广播交易将数据和相关证明发送至链上智能合约。
• 数据输出（可选）------在智能合约执行时向链下系统发送数据，比如将支付指令发送至传统支付网络，或与信息物理系统进行交互。

4. 使用场景

预言机作为区块链与现实世界进行数据交互的桥梁，应用场景非常多，可以说一切需要与链下进行数据交互的 DApp 都需要预言机。许多业务比如金融衍生品交易平台、借贷平台、IoT、稳定币、游戏、保险、预测市场等需要与外界进行交互。

预言机保护区块链及其外部交互，审查在混合智能合约中来回传输的数据并提供安全许可。

4.1 去中心化衍生品

衍生品是两方或多方之间的金融合约，其价值基于相关资产。衍生品允许人们对标的资产提出不同的视角(长期或短期)，从实质上促进金融稳定。公共智能合约平台可以创建和交易金融衍生品，包括基于区块链的资产。预言机可以通过提供价格馈送，结算价值和合约到期来确定参与方的收益或损失，从而在去中心化衍生品中发挥重要作用。

4.2 稳定币

获取有关稳定币和它们所固定的资产之间的汇率的外部数据是预言机的一个重要场景之一。

4.3 去中心化预测市场

像Augur和Gnosis这样的去中心化预测市场利用人群的智慧来预测现实世界的结果，如总统选举和体育博彩结果。如果投票结果受到用户的质疑，预言机可用于快速和安全的解决方案。

4.4 智能合约保险

在免信任且可靠的信任源加持下，保险产品可以通过智能合约的形式实现。当前的商业案例比如Etherisc的去中心化的保险应用(如航班延误保险和作物保险)平台，FlyingCarpet 的人工智能和地理数据的新型可编程保险等。

4.5 去中心化贷款平台

像SALT Lending和ETHLend这样的去中心化点对点借贷平台允许匿名用户在区块链上抵押加密资产，以换取法定或加密贷款。可以应用预言机在创建贷款时引入市场利率，并监控加密抵押品与贷款金额的比率，如果贷款周期到了，则触发清算事件。

4.6 去中心化预言机案例

去中心化预言机
DOS Network 运行机制与代币经济

• DeFi 和储备证明
  大量集中式和分散式加密协议需要用预言机来访问外部数据。交易所、货币市场等利用数字资产的协议，使用预言机来确定特定稳定币资产的储备以及去中心化借贷中借方的抵押品。与外部市场现货价格挂钩的其他资产使用预言机来更新价格，而自动货币市场用预言机的价格汇总来执行限价单。
• NFTs 和 GameFi
  预言机还支持动态NFT等混用NFT。NFT于区块链上铸造，是一种完全独特的代币，可在不同钱包之间交易，不能分割或交换任何其他实物。动态NFT还可根据外部事件或成就（如当前天气、体育比赛得分或解锁游戏成就）而变化。
• SocialFi & DAO
  预言机还能够在SocialFi和DAO的应用场景中充当去中心化的身份验证工具。通过利用集成链下和链上的活动数据，预言机在可以帮助用户在web3中验证和管理自己的身份凭证，同时也可以为个人信息管理以及公会管理方面获取性能仪表盘数据，增加信息管理效率。
• 企业/供应链管理
  预言机还可以帮企业和供应链管理者实现Web2到Web3的通信，将前端和后端系统连接到他们选择的区块链网络。当然，许多人会选择定制的私链，这就需要预言机提供的跨链互操作性和通信。
  由于系统可互操作的成本历来很高，共享敏感数据或访问内部流程也会有安全风险，因此预言机非常重要。有了预言机通过强大的加密原语来保护数据，大型规模经济便能够更有效地部署其资产并降低交易对手风险。
• 医疗保健和保险
  保险协议使用输入和输出预言机，加上Web API、卫星图像、物联网式传感器、警察和医疗报告与法律文件，在索赔过程中验证可保事件，然后再触发赔付。农业、汽车、家庭、洪水、火灾和健康领域的保险公司的应用程序将使用混合智能合约，并利用预言机来协助合约工作。欺诈检测、索赔处理和审计部门也会利用许多新工具和资源以获得更高回报。
• CBDC
  在 CBDC 和公共区块链势不可挡地成为主流的世界中，Visa 和 Mastercard 正在研究的私有 CBDC 区块链通过通信渠道和跨链桥以安全和高性能的方式与公共区块链通信，并通过合约跨多个加密货币对各种法定外汇价格进行准确、实时的链上定价。在整个 CBDC 和跨链 DeFi 的加密货币交互过程中，预言机是必不可少的媒介。

5. 预言机架构设计调研
   一文了解预言机的起源、定义、原理和发展

5.1 蚂蚁链

5.1.1 实现原理

蚂蚁链预言机，外部数据源服务使用 TEE 技术实现，对于每笔外部数据请求都将在可信硬件环境中执行。可信硬件环境会验证外部数据源的 TLS 通讯证书以确认数据源的身份，通过 TLS 协议确保拿到的数据没有被第三方篡改。可信硬件环境得到数据后，会使用硬件私钥对数据进行签名，并返回给智能合约，智能合约将自动验证可信硬件的签名，确保数据是可信硬件执行结果，没有被第三方篡改，从而安全可靠地获取来自指定外部数据源的数据。

可信执行环境（Trusted Execution Environment，TEE）,TEE 是一个安全隔离的执行环境，提供隔离执行、可信应用的完整性、可信数据的机密性、安全存储等安全特征，使预言机服务数据服务安全可信。

5.1.2 功能特性

• 数据安全可信
  区块链预言机底层使用 TEE 技术实现，TEE 是一个安全隔离的执行环境，提供隔离执行、可信应用的完整性、可信数据的机密性、安全存储等安全特征，使预言机服务数据服务安全可信。
• 支持 HTTPS 协议
  通过 HTTPS 协议，区块链预言机会与目标数据源建立端到端的安全通行通道，并且可以完成对数据源的证书校验以确定身份，从而安全、可靠地获取来自指定外部数据源的数据。
• 支持 JSON API
  JSON 是一种轻量级的数据交换格式，广泛地被采用为 API 的数据交换格式。区块链预言机内置 JSON 解析器，如果请求的 URL 响应格式是 JSON 格式，可以在请求命令中设置 jsonpath 命令，使区块链预言机根据 jsonpath 读取部分 JSON 数据，只返回这部分数据上链。
• 支持访问要权限认证的 API
  一些 API 需要认证授权访问，例如使用 OAuth 2.0 协议实现的 API，需要在请求中携带服务端认证鉴权需要的参数，但这些参数属于私密信息不可泄露。这种情况下，利用 TEE 技术提供的机密性，与区块链预言机的 TEE 环境建立端到端的加密信封，使得请求只在 TEE 硬件可信执行环境里面解密，从而不会泄露请求机密。
• 高可用预言机集群
  区块链预言机服务使用集群架构实现，为合约提供高可用的数据访问服务。

5.1.3 使用场景

• 智能合约需要可信访问 Web 数据。
• 智能合约通过调用 Open API 使用互联网服务。
• 智能合约需要与外部系统交互。
• 智能合约依赖公共现实事件，如天气、赛事信息、航班信息等。

5.1.4 预言机合约接口定义

定义用户合约与预言机合约的通信接口，其中用户通过 curlRequest 接口调用预言机合约。

用户合约需要实现 oracleCallbackCurlResponse 接口，用于接收预言机合约的请求结果回调。

interface OracleInterface {
    /**
     * function： 发送 CURL 请求
     * parameters：
     *         _biz_id            ：用户自定义的业务请求 ID
     *         _curl_cmd          ：CURL 命令，参考 CURL 命令使用文档进行构造
     *         _if_callback       ：是否需要预言机将请求结果回调用户合约
     *         _callback_identity ：预言机请求结果回调的合约 ID，可以是发送请求的合约，也可以是其他合约
     *         _delay_time        ：该特性未激活，填 0 即可
     * return value          ：预言机请求 ID，是预言机合约为本次请求生成的唯一请求 ID
     */
    function curlRequestDefault(bytes32 _biz_id, string _curl_cmd, bool _if_callback, identity _callback_identity, uint256 _delay_time) external returns (bytes32);
 
    /**
     * function: oracleCallbackCurlResponse
     * parameters:
     *         _request_id        ：预言机合约请求 ID（在发送请求时预言机合约会返回此 ID）
     *         _biz_id            ： 用户合约的业务请求 ID
     *         _error_code        ：请求结果码，如果值是 0，则表示预言机请求处理成功；如果是其他值，则为请求处理失败，详见合约错误码表
     *        _resp_status       ：HTTP 响应的状态码，一般 200 表示 HTTP 请求处理成功，5xx 表示服务端处理错误，调用者可根据自己的使用场景做判断
     *        _resp_header       ：HTTP 响应的 header，如果 CURL 中指定了要返回 HTTP 响应的 header，则回调时会返回对应的值
     *        _resp_body         ：HTTP 响应的 body
     *        _call_identity     ：发起该请求的合约 ID
     * return value            ： 无
     */
    function oracleCallbackCurlResponse (bytes32 _request_id, bytes32 _biz_id, uint32 _error_code, uint32 _resp_status, bytes _resp_header, bytes _resp_body, identity _call_identity) external returns (bool);
}

5.2 趣链

5.2.1 实现原理

预言机服务实现过程：

1. 用户调用HVM合约请求Oracle服务（与用户发生交互）
2. HVM执行合约以及Oracle服务，并返回uuid（uuid表示本次Oracle请求的唯一ID，绑定回调交易哈希）；
3. Oracle服务执行成功，平台发起回调交易；
4. 在回调交易中执行用户编写的回调逻辑（与用户发生交互）
   

5.2.2 功能特性

• 支持java的HVM合约 和 HVM的预言机
• 支持 HTTPS 协议
  通过 HTTPS 协议，区块链预言机会与目标数据源建立端到端的安全通行通道，并且可以完成对数据源的证书校验以确定身份，从而安全、可靠地获取来自指定外部数据源的数据。
• 支持 JSON API
  JSON 是一种轻量级的数据交换格式，广泛地被采用为 API 的数据交换格式。区块链预言机内置 JSON 解析器，如果请求的 URL 响应格式是 JSON 格式，可以在请求命令中设置 jsonpath 命令，使区块链预言机根据 jsonpath 读取部分 JSON 数据，只返回这部分数据上链。

5.2.3 使用场景

• 获取外部接口的数据

5.2.4 预言机接口定义

public interface IOracleContract extends BaseContractInterface {
    // 用户编写的回调函数
    // callOracle() 方法来使用Oracle服务
    String oracleRequest();

    // 根据uuid获取回调交易的哈希
    String getTxHashByUuid(String uuid);
}
public class OracleRequest {
    String url; //请求资源的web网址，必须是支持https的服务站点
    RequestMethod method = RequestMethod.GET; //RequestMethod是一个默认方法，包括GET、POST，默认为GET方法
    Map<String, String> header; //请求资源时想要带上的自定义http请求头
    String body; //请求资源时想要带上的请求体
    String bizId; //用户针对业务需求自定义的唯一标识ID
    String callBackAddress; //回调函数所在的合约地址
    String callBackMethod;  //回调函数名，回调函数声明格式为: <return_type> <method_name>(OracleResponse response);
}
public class OracleResponse {
    private int code;
    private String message;
    private Map<String, String> repHeader;
    private String repBody;
    byte[] uuid; //由平台计算出的每次Oracle请求的唯一标识
    String bizId; //用户针对业务需求自定义的唯一标识ID
    byte[] callerContract; //发起Oracle服务请求的合约地址
}

5.3 长安链

5.3.1 实现原理

预言机服务整体可以分为四个模块。由监听到的链上预言机智能合约事件进行驱动,各个模块配合运行完成取数据功能。服务将运行中所需数据保存到本地的mysql数据库中。

• 预言机状态流转模块
• 取数据模块
• 预言机接口模块
• 预言机告警模块

整理流程：

1. 用户在智能合约中调用预言机智能合约中的取数据方法，预言机智能合约校验相应参数，发送相应的链事件
2. 预言机服务监听到链上取数据事件，根据合约中指定的取数据配置，进行数据的获取
3. 预言机服务将取到数据通过调用预言机智能合约方法来将数据回传，预言机智能合约通过回调用户智能合约告知用户数据取到，用户合约做相应业务处理即可

5.3.2 功能特性

• 获取链下的接口数据（HTTP/HTTPS方式获取JSON、XML、TEXT、HTML格式，比较丰富）
• 指定的mysql数据源取数据
• 支持VRF数据取/验（可验证随机数数据）
• 支持跨链（长安链）调用链上合约查询数据
• 注册查询topic/按照topic查询的功能

5.3.3 使用场景

• 获取外部接口数据
• 获取mysql数据库数据

5.3.4 合约接口定义

预言机docker_go合约和普通合约一样，需要暴露调用合约的方法，按照自己业务去实现预言机合约和用户合约

6. 以 chainmaker 预言机为例，分析技术原理实现的过程：

(1)第一步，通过预言机服务部署预言机合约

为什么要通过预言机服务来部署预言机合约？部署合约的功能和从我们baas的接口部署是相同的。

从预言机服务部署完合约之后，在后台就会启动协程开始监听预言机合约的事件了，如果从别的地方部署了预言机合约，不会启动监听预言机合约的事件（或者说，可以操作通知让预言机服务启动监听事件就行）
(2)第二步，发起调用用户合约：

1. 发起调用用户合约方法，用户合约内部跨合约调用预言机合约，这里都跟调用普通合约一样，按照合约方法和参数定义写好就行
   

2. 预言机合约计算得到一个requestId，即为Hash返回给用户合约调用的结果
   

(3)第三步，预言机合约执行：

1. 请求参数保存上链，key为固定的字符串"request_tx", field为 requestId
   

2. 触发"chain_query"事件，这个topic是在预言机服务里面定义好的，后台服务在部署预言机合约的时候，就会启动监听预言机合约的事件，从这个topic中订阅预言机合约的事件然后去消费
   

3. 预言机服务一直在后台监听"chain_query"事件从中去消费
   

4. 开始处理query事件
   

5. 这里的fetch是http,mysql等不同的类型去判断的，从这里的实现中真正拿到了外部的数据
   
   

6. 获取数据成功之后，将数据保存在数据库，更新事件状态，更新锁状态
   

7. 获取数据完成之后，执行调用预言机合约的callback回调方法，回调成功，更新事件状态
   

8. 回调成功，删除监视的任务，在预言机回调方法中会发送finished事件，预言机服务还会收到在后续处理，事件发送成功后，删除了之前在链保存的request_tx，requestId的的记录
   

9. 处理finished事件，删除定时任务，更新事件状态表event_state中的状态
   

10. 处理上链成功后，删除监视的定时任务
    

7. 预言机的困境

区块链本质上是去中心化的，由于分布式网络节点构造，破坏一个或多个节点不会危及系统，区块链因此具有减少单点故障，保证安全的优势，也就是说，为了提高安全性，我们需要建立尽可能多的网络节点，以提升预言机网络去中心化程度。

但是网络节点越多，多轮共识耗时就越长，如果网络拥塞，用户交易的阻力就越大。这不仅会导致最终确定性和性能下降，导致数据可用性延迟，还会影响刷新率，增加了使用陈旧数据执行智能合约交易时发生滑点的可能性。此外，不断刷新数据的成本、维护预言机网络节点络正常运行的能力、实现快速交易和较高吞吐量，这些对预言机开发来说也是大难题。如果预言机不适当去中心化，便可能会被试图操纵网络中的数据阻塞点以谋取利益的攻击利用。

7.1 如何保证获取的外部数据源真实可信？如何避免被中心化操纵？

• 恶意的 oracle 可能会抄袭别人的数据。
• 单一的 oracle的情况，如果数据有损坏，那么在链上是很难检测的。

最核心的问题:

没有绝对可信，只能做到相对可信。我们主要在数据源认证、数据获取标准流程、数据格式统

一等方面进行约束：

（1）数据源选取和可信认证。预言机需要谨慎选择外部数据源，必须保证对每个选取的外部数据源，都可以验证是可信的。例如：对于web的数据获取，需要持有相关证书。

（2）数据获取有标准流程。开发者必须明确执行引擎、用户、外部数据源与预言机的数据交换流程，且对于不同的数据源类型要能够统一或明确区分数据的交互流程，确保交互方案可执行可落地。

（3）数据交互格式统一。不同的数据源类型有不同的数据交互格式，以传感器作为数据源和以Web作为数据源获取到的数据格式是不一样的，针对不同情况，明确统一的数据编解码层，以对不同数据源的数据进行请求和解释。

7.2 如何保证数据在传输和处理过程中的安全？

预言机通过两个阶段对进行中的数据实现可靠保证。

（1）数据从网上到本地，采用HTTPS协议（底层采用TLS协议）去保障连接和数据的正确性、完整性。

（2）数据从本地到链上，预言机采用可信执行环境 ( TEE ) 技术，TEE是CPU内一块安全区域，和操作系统独立运行，可以确保数据处理过程中的机密性、可靠性，趣链区块链平台研发了基于SGX的TEE实现以及基于国产芯片的TEE实现，进行预言机的安全保护。

7.3 时效性、成本？

后续补充。。。

8. 值得思考和讨论的点：

• 预言机的作用不是提供【真实的数据】，而是提供【可信的数据】。【真实】是一个主观的概念，也是一个难以评估的概念，世界上或许没有任何工具能保证输出【真实】，而让预言机去完成这样的功能也并不现实。我们无法设计一套机制来确保真实，但可以设计机制来提高可信程度。如果要求预言机提供真实，就容易陷入预言机无用论与区块链无用论之中，因为它们确实无法满足我们对真实的要求。
• 不同的应用场景对信任的需求是不一样的。并不是所有的数据都要在最高程度的可信保障下上链，这涉及到信任的成本问题，也与数据可信的重要性、数据造假的动机等等维度相关。
• 不同的应用场景，信任的来源 / 支撑是不一样的。也就是说，并不能认为某种信任生产机制实现的信任就是最优的，而某些机制实现的信任就是不好的。
• 数据源的问题，即预言机中的数据提供者从哪儿获取数据。可以分为两种类型，一种是从单一数据源获取数据，一种是从多个数据源获取数据。
  关注点：它是如何生产信任的，以及它提供的信任能否满足它所服务的应用场景的需求。

9. 总结

• 功能角度看：预言机的功能比较纯粹，主要解决区块链内外数据可信连通问题。针对不同的信任场景，预言机也采取了中心化和非中心化的两种方式提供服务。
• 应用场景看：链外数据是一个很大的生态，预言机可以应用在公开网站信息、物流追踪、保险自动赔付、获取跨链信息等多场景...预言机的发展一方面依赖于区块链/智能合约技术的发展，一方面又助力区块链/智能合约的业务延伸，随着区块链在金融、保险、物联网等行业生态规模的扩大，预言机未来的生态价值也很值得期待。
• 商业角度看：预言机模式其实类似一个数据服务提供商，中心化预言机的商业模式本质上是一个数据服务平台，而去中心化预言机是一个多元的数据服务生态，两者发展方向各有千秋。

10. 实现自己的预言机