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

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

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

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

认识预言机

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

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

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

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

Truora设计理念

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

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

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

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

1)数据源可信:多数据源+引入可信数据源

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

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

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

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

2)预言机中心化部署

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

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

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

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

硬件上:将预言机置于可信执行环境(可信硬件),预言机程序部署在安全TEE环境中,程序的完整性得到保障;屏蔽其他进程访问,可有效防止oracle 服务方作恶。然而,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的场景。