在区块链应用中，大家往往希望业务逻辑可以尽可能在智能合约上自动执行，以降低信任成本，实现业务流程智能化和自动化。因此，智能合约需要将更多互联网世界的数据上链，以满足复杂多变的应用场景。由于区块链共识机制及虚拟机固有特性，智能合约无法访问链下数据，这极大限制了智能合约的应用范围。

为了解决这些问题，微众银行区块链在多年技术研究和应用实践的基础上，积极分析、总结行业需求，研发了一套联盟链可信预言机解决方案Truora。

Truora，取Trust（可信）、Oracle（预言机）的涵义命名，可读为 [tru ɔ:rə]。作为连接联盟链和互联网的桥梁，Truora致力于让互联网数据安全可信地上链，已应用在国家信息中心顶层设计的区块链服务网络BSN中。

为助力全行业伙伴低门槛地使用安全可信的预言机解决方案，进一步扩宽联盟链应用场景，促进联盟链生态繁荣，微众银行区块链秉持一贯开源开放的理念，将Truora面向社区和公众完全开源，诚邀各行业伙伴携手共建。

认识预言机

中国人民银行发布的《区块链能做什么？不能做什么？》报告中，对预言机的定义是：

“区块链外信息写入区块链内的机制，一般被称为预言机 (oracle mechanism)。”

区块链只能访问区块链本身的数据，闭环地解决系统内信任问题。一旦涉及到获取链下数据，其功能就会受限。主要原因是，智能合约不管何时何地运行，都必须保持结果一致，因此虚拟机不能让智能合约进行网络调用，否则结果就是不确定的。

如何将区块链和互联网世界连接起来？预言机可以扮演连接器的角色。作为一个可信任的中间件，预言机能将互联网世界的数据输入到区块链上，为智能合约提供与互联网世界的连接性。

Truora设计理念

预言机设计需考量诸多因素，如数据响应时效性、数据准确性、使用成本，以及服务安全性等。

中心化预言机一般成本较低，时效性更高；多中心化预言机安全性、数据准确性相对更高。不同的应用场景需求各不相同，用户需要对以上特性做相应取舍。

基于此，Truora的整体设计思路为：作为一整套中心化和多中心化技术方案的集合，用户可以根据不同的业务场景，以及对信任的要求度选择适合的技术方案。

为了给联盟链提供安全可信的数据，Truora从数据源和部署方式解决可信问题：

1 ）数据源可信：多数据源+引入可信数据源

确保链下数据源可信是数据可信的关键一环，用户在使用预言机时，需要确保所访问的数据源是安全可靠的。当用户访问到一个不安全数据源时，不安全数据很可能导致链上逻辑出现问题。

Truora在设计时，采用了多数据源+引入可信数据源的方式，解决数据源可信问题。

多数据源：通过使用多数据源访问数据，用户可以在一定程度上防止数据源作恶。对于需获取的数据，用户可以指定多个权威或可信的数据源获取结果，Truora可支持用户实现采集多数据源结果，并反馈给用户。

引入可信数据源：Truora可结合联盟链具体场景，制定数据提供商提供数据的规范，如数据格式规范、治理规范等，从源头上提高数据可信度。同时，Truora对数据提供商进行准入控制和认证管理，通过引入优质数据服务提供商，来提供优质可信可验证的数据服务。

2 ）预言机中心化部署

数据源的可信问题解决后，针对预言机中心化部署，我们需要解决一个核心问题：怎么保证预言机不在抓取数据和上链数据时作恶。

预言机中心化部署方案的特点是简单高效，适用于请求时延低的场景，可快速获取数据并上链。但随之而来的问题是，中心化预言机可能出现单点故障，或中心化机构中途篡改数据作恶。

针对单点故障问题，Truora支持集群部署，即多个Truora同时监听链上事件，共用同一个数据库和私钥。

针对中心化机构中途篡改数据作恶问题，如恶意伪造和篡改数据，Truora在设计时从软件和硬件两个维度来进行规避：

• 硬件上：将预言机置于可信执行环境（可信硬件），预言机程序部署在安全TEE环境中，程序的完整性得到保障；屏蔽其他进程访问，可有效防止预言机服务方作恶。然而，TEE的有效性依赖TEE硬件设备自身的安全性，需要依赖可信的第三方设备白名单认证服务，在跨机构实施时，可能会遇到一定的挑战，用户可以结合自己实际情况酌情使用。

• 软件上：Truora基于安全传输层协议TLS（Transport Layer Security）进行优化，采用真实性证明，暴露TLS连接细节，保证数据确实由数据源发出。软件上解决中心化预言机作恶问题是Truora重点研究方向。

3） 预言机多中心化部署

对于信任要求等级较高的场景，如金融、政务等，Truora提供多中心化预言机部署方案。多中心化预言机部署核心是：分布式预言机服务需要对各自采集的数据做某种程度的"共识"。

Truora通过多预言机获取数据，进行数据聚合后反馈给用户合约。数据聚合分为链上聚合和链下聚合：

• 链上聚合： 用户可以指定特定数量的预言机节点列表和结果聚合方式（取最大值、最小值、中位数、平均数等），预言机获取数据后，一旦有足够的公开结果响应，链上聚合合约则将各预言机结果聚合，回写到用户合约。

• 链下聚合：链上聚合需多次与链交互，为提高聚合效率、降低成本，Truora引入p2p网络及密码学套件，使用BLS门限签名技术，实现链下聚合功能。

此外，多中心化部署鼓励机构参与搭建预言机，涉及预言机服务商治理问题。联盟链治理委员会会审核预言机服务方的资质，并维护全局的注册中心合约，管理各个预言机服务。

 

Truora应用场景

涉及到将链下数据上传到区块链上的各种应用场景，都可以考虑使用Truora。潜在场景列举如下：

 

• 场景1：快递

场景：用户通过某电商平台下单购买衣服，购买成功后，用户将资金存入智能合约。正常情况下，用户签收快递后，用自己的私钥签名并将签名信息上链，智能合约会自动将钱转给商家。

但如果快递中途丢失，用户如何申请赔付呢？

解决思路：可以通过 Truora 将快递状态信息传递到链上智能合约，如用户超过一定时间未收到快递，则用户发起赔付流程，智能合约根据预言机获取的快递状态判断是否将资金返还用户。

 

• 场景二：公正摇号

场景：部分城市在购房过程中，采取摇号方式以保证公平性，其公开透明和公平性成为很多人关注的焦点。然而，购房者对摇号过程知之甚少，只能默默等待摇号结果。

封闭状态的链上无法产生安全的随机数，如何在链上产生安全的随机数以实现摇号公平？

解决思路：地产公司可以部署一个摇号智能合约，链下核实客户购房资格后，将有购房资格的客户身份标识上链，通过Truora从公证处网站或随机数网站获取随机数，或使用Truora的VRF（可验证随机数）功能产生随机数。随机数产生后，智能合约根据事先编好的摇号逻辑决定中签者，购房者则可以在链上全流程查看摇号信息。

 

• 场景三：慈善公益

场景：利用区块链技术的不可篡改性和可追溯性，可以解决慈善中的资金流向问题，比如追溯善款去向。同时，利用智能合约可有效解决传统慈善公益项目中流程复杂的问题。我们希望智能合约能对符合条件的申请者进行善款自动划拨。

为保证申请者信息的真实性，慈善机构除了在链下简单验证申请者的信息之外，还需要通过智能合约验证申请者的个人相关信息，如病例信息、房产信息、工作信息等。如何让智能合约自动校验这些信息呢？

解决思路：指定查询申请者个人信息相关的链下网站，通过Truora将申请者个人信息上链，智能合约根据这些信息判断申请者是否有资格申请、是否符合善款自动划拨条件，如核验通过后则向申请者发起自动转账，不通过则将申请者记录至黑名单。

 

即刻体验Truora

Truora提供容器化部署方式，帮助用户屏蔽安装环境的复杂性，目前提供两种安装方式：快速体验和独立部署。

• 快速体验

此部署方式会同时部署 Truora和相关依赖，相关依赖包括：4个FISCO BCOS节点，WeBASE-Front，MySQL，Nginx服务。

部署成功后，即可在WeBASE-Front的合约IDE中开发、调试预言机合约，适合想要快速体验Truora的开发者。

• 独立部署

此部署方式只部署Truora和MySQL（可选）服务，适合已有FISCO-BCOS节点和 WeBASE-Front的场景。

 

  开源地址

 

github代码库地址

• 后端代码库：https://github.com/WeBankBlockchain/Truora-Service

• 前端代码库： https://github.com/WeBankBlockchain/Truora-Web

 

gitee代码库地址：

• 后端代码库: https://gitee.com/WeBankBlockchain/Truora-Service

• 前端代码库：https://gitee.com/WeBankBlockchain/Truora-Web

 

文档地址：https://truora.readthedocs.io/