Witnet: 去中心化预言机

这篇会讲得比较长一点,会从预言机(Oracle) 一路讲到去中心化的预言机Witnet,一般的软件如果需要介接任何Web API时,可以很直觉的用各种工具如JavaScript的fetchAPI或golang的http套件完成。但是区块链上的智能合约(Smart Contract)如果要介接Web API则没那么容易。

举个例子,一个程式时透过Web API 查询特定日期的天气,在今天查询的结果可能跟明天查询时不一致,这是Web API 理所当然的特性,这样每次即使输入参数是一样时但仍有可能产生不同答案的特性称为non-deterministic,绝大多数的API 都是这种类型。反之,有些系统则是deterministic 特性,每次输入相同参数时,一定都会得到相同的结果,Ethereum 区块链就是一种deterministic 的系统。

因为区块链是去中心化的由许多节点共同执行并且验证结果,任何一个节点在固定的时间调用同样的function call都需要得到一样的结果。比如说我需要查Bob的帐号余额还要多少,此时我会呼叫getBalance(account, [blockNumber])来取得余额。呼叫这个函数时,输入的参数除了bob的account address以外,还有另外一个参数是区块编号(或称区块高度),以Ethereum为例约每十五秒就换产生一个新的区块,区块高度则会加一,呼叫函示时不提供时预设则是最新的区块。

这个函数在相同的输入参数包含区块高度时,不管什么时候呼叫回传的结果一定都是一样的。这样的特性导致区块链内的deterministic 程式(也就是智能合约)不能直接呼叫non-deterministic 的Web API。

而当智能合约需要外部的资料时,会透过一种叫做“Oracle” (预言机) 的机制来取得外部资料,简单的说就是把资料从外界带入区块链当中。

中心化预言机(Centralized Oracle)

Oracle 的实作方法有很多种,机制启动后将会到外部撷取资料后写回区块链。当资料写回区块链后就变成deterministic 的资料,不仅可以在智能合约​​中取得资料,就算这个数值更新了,因为呼叫时会需要带入block number,所以带入相同的参数时肯定也可以获得相同的输出。

如果要自行实作一个简易的Oracle,可以在Ethereum 内部署一个Oracle智能合约,另外在外部建立一个daemon 来监控这个Oracle Event,当收到特定Event 的时候呼叫相对应的Web APIs 取得结果后,再把结果透过呼叫智能合约的callback 来将资料带入区块链当中,如下图所示。

至于要如何实作这个外部的Oracle Daemon 作法就很有弹性,简单实作方法可以是架设一台AWS EC2,上面放把可以存取Oracle 智能合约的私钥,监测到新的Event 时去Web API撷取所需资料后写回区块链。

不过如果每次都得要自己实作这一套还是有点麻烦,而市面上也已经有Oracle 服务可以让使用者透过服务存取外部资料,其中最有名的就是Oraclize,现在更名为Provable。

Oraclize / Provable

Provable 提供的机制跟上述自行架设daemon 的机制类似,不一样的是Provable 要提供给不同使用者使用,所以要使用Provable 服务时需要在智能合约​​里面先写入你要怎么让Provable 查询并且解析资料。

以官方的例子来说,如果要从coinbase 查询ETH/USD 的交易资讯,可以在智能合约​​中用以下的语法查询:

此查询会发出事件后,Provable daemon监听到此事件后将会依据查询语法执行查询后,再将得到的结果透过智能合约的callback把资料写回区块链。

在Ethereum 有许多智能合约都是涉及金融服务,其中经常有大量资金流动,而根据不同的判断条件可能会造成将资产转移到不同地方,所以在智能合约​​以及Web APIs 之间的桥梁— Oracle 的正确性就扮演非常重要的角色。服务提供方需要保证Oracle 依据他们所宣称的方式进行,而不会因为牵涉到不同利益而把不同的资料塞回区块链。

Provable 提供了几个方法来证明调用资料的正确性,其中一个方法是透过TLSNotary 证明,简单的来说这边会有一个在AWS 上面一个开源image 的Auditor instance 会负责检验Provable 查询Web API 时的数据是否正确。

去中心化预言机(Decentralized Oracle)

回头来看,为什么我们要使用区块链技术呢?

其中一个原因是区块链是去中心化架构的系统,系统的操作不需要信任中间人也可以进行。不过当我们需要使用Web APIs 去撷取一个特定资料时,我们也需要信任这个Web APIs 回传的结果。在涉及大量利益的状况下,我们可以从不同的Web API 撷取结果并且互相比较之后做出最后的结论是什么。

即使如此,负责撷取Web APIs 的Oracle 仍然有可能是一个安全缺口。试想如果是一个利益涉及十亿美金的结果,不论是自己架设的Oracle 或是使用现成的Oracle 服务,这样的利益都有可能导致自行修改Oracle 给出对自己有利的结果。

举个例子来说,synthetix服务虽然使用了智能合约运行,但此服务曾经直接改变Oracle的参数实质上把一个用户的资金归零,也说明了如果Oracle的权力集中在一个人或组织的手上,就有可能因为其中的利益修改结果,不论他们出自好意与否。

而Decentralized Oracle 是另外一个可以解决问题的方式,Witnet 就是众多去中心化预言机专案的其中之一。

Witnet

Witnet 是一个去中心化的Oracle网络,也是另外一个区块链,但与Ethereum 不同之处是在上面的节点可连结外界资讯,是专门为撷取资料而设计的区块链,可以执行撷取资料、验证以及将资料提供给其他区块链的能力。

我们先从一个使用者的角度来看要如何使用witnet 来撷取资料。还记得上面用Provable 撷取coinbase 价格的例子吗?如果我们在开发一个需要撷取ETH 价格的智能合约,同样的例子在Witnet 首先先写一个JavaScript 如下:

写完之后,透过Witnet 提供的工具rad2sol 编译这个JavaScript 成为一个十六进位的字串,而这个字串所代表的是撷取资料的方法,但是用更精简的格式储存,当我们需要使用时,则将一个智能合约宣告为Witnet Request 并且将该字串放入建构函数当中:

接着我们就可以在合约之中使用UsingWitnet所提供的witnetPostRequest()与witnetReadResult()分别发出请求以及接收结果。

使用起来比起Provable 多出了一个编译的步骤,但其他部分则不会差太多。而之中要如何利用Witnet 去中心化的机制取得Web APIs 的回传结果呢?请见下图:

在Witnet 上面的节点总共有三种工作类型:

  1. 撷取资料:到开放的Web APIs 撷取资料
  2. 桥接:成为桥接到其他区块链如Ethereum 的节点,负责接受以及回传资料
  3. 矿工:接收数个负责撷取资料的节点所回传的资料并且包装成区块发布在witnet 区块链上

而整个运作流程如下。

  1. Ethereum 利用Witnet 提供的合约介面,把撷取资料的请求发出,此时会发出Event 通知。
  2. 经过Witnet 所指定的挑选机制定时挑选出此轮的Bridge 节点,搜集尚未撷取资料的request,将此请求转发送到Witnet 区块链上,而此Bridge 则会收到由Ethereum 区块链这方发起请求那方的奖励(需要附在request 内)。
  3. 根据Witnet 的共识系统每个节点撷取资料后得到的信誉指数,在本轮挑选出一些节点来执行撷取资料工作,同时也根据共识机制选出此轮的矿工。
  4. 负责撷取资料的节点撷取完资料后,会先将撷取到的资料制作成nonced hash 之后先提交给矿工,此份资讯称为commit-pledge transaction,此时还没提交真正撷取到的资料,只有hash。
  5. 等矿工搜集到本轮所有负责撷取资料节点所提供的commit-pledge 后,接下来会通知所有节点,请他们所有人提交真正的撷取结果,再将结果与他们原本提交的commit-pledge 比较来确认他们不是看到其他节点的答案才跟着送的。
  6. 矿工确认完成后,会将本轮的奖励发给这次帮忙撷取资料的节点,本轮就完成了。
  7. 与刚开始相同,挑选机制挑出的Bridge 节点将Witnet 区块链上的结果发送到Ethereum 区块链上,完成整个流程。

由于Witnet 本身也是个区块链,并且利用区块链去中心化的机制,以及信誉系统让节点只有在轮到自己的当下才知道自己在本轮要执行哪种任务,这样的机制避免的节点提前知道自己要执行哪项与自己利益相关的工作,进而改变执行结果。而即使执行结果不同,双阶段的提交工作也可以惩罚提交错误答案的节点以及减低其信誉。

比起集中式的预言机,Witnet 去中心化的机制分散了风险,让预言机不再成为去中心化系统当中的single point of failure。然而去中心化系统并不是零风险,此系统依然有可能透过51% 劫持整个网络来制作错误结果,不过当然这样的攻击成本也会相对地提高,就要看Witnet 运作时的状况了。

本文链接地址:https://www.wwsww.cn/jzb/6287.html
郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

相关文章阅读