IT资讯 微众开源“联盟链可信预言机Truora”,让互联网数据安全轻松可信上链

tj · 2021-01-29 12:00:06 · 热度: 8

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

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

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

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

微众开源“联盟链可信预言机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”,让互联网数据安全轻松可信上链

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

微众开源“联盟链可信预言机Truora”,让互联网数据安全轻松可信上链

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

 

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代码库地址

 

gitee代码库地址:

 

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

猜你喜欢:
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册