Chainlink 与预言机
2020-07-20
作者： 冒志鸿（ArcBlock 首席执行官、首席架构师）
编者按： 以太坊预言机项目 Chainlink 最近跻身全球第 9 大市值项目，且日前遭人做空，一时令业内瞩目、热议纷纭。今天，通过ArcBlock 技术社区 今年 2 月 28 日发表的《Chainlink 技术讨论》与中信出版集团新近出版的《区块链实战：从技术创新到商业模式》第 8 章《对智能合约和虚拟机的误解》最后部分，分享一下作者如何从技术和产品角度探讨分析 Chainlink 及预言机的价值和现状。
Chainlink 技术讨论
Chainlink 是老牌项目，我在 2017 年就关注过，除了 Chainlink，还关注过 Oraclize（现在改名为 provable.xyz）。两者类似，都是解决以太坊上的预言机（Oracle）问题。
外部 API 的预言机
以太坊的设计使得 EVM、智能合约是全封闭的沙盒，智能合约无法访问外部 API，这么做也是为了保证智能合约代码执行的确定性，因为一旦有外部 API 调用，不同以太节点在不同时候运行可能外部 API 返回不同结果（比如 API 本来就返回不同，或者临时出错了），因此无法达成共识。
解决方法是搞个外部的（链下）程序，把一些需要的外部数据写到链上，这样智能合约需要外部 API 的时候，实际上是从链上读取数据，这样就解决了确定性问题。 这种把外部数据上链的程序就是预言机（非严谨定义）。同样想从链上触发一些外部动作，也可以类似进行。
上述工作原理在 Chainlink 这张图得以展示。Chainlink 和 Oraclize 类似，都是设计了一个框架，其中一部分是一个链上的智能合约代码模版，一个是链下提供 API 调用的程序，这么做是为了能简化开发，应用在链上只需要调用其智能合约即可。
去中心预言机
可能有人怀疑，上面的预言机如果被人为操纵怎么办？首先一般这些预言机都是访问外部的 API，这些外部 API 某种角度而言都是相当中心化的，也就是无论预言机如何去中心化，你拿到的还是中心化数据，这点其实非常尴尬。不过这种用法互联网应用都搞这么多年了，为什么没问题？这个问得非常好。首先，因为没办法，这就是现实，一些 API 现在只可能中心化；其次，互联网应用本身也是中心化设计，并且采用准入（Permissioned）设计，互联网应用本身通常在安全环境下直接访问权威的外部 API，因此反而问题不大。而区块链需要用预言机（相当于中间人）去访问权威数据，因此导致获得的链上数据是第二手的反而失去了权威性。
Chainlink 和 Oraclize 的更主要解决的问题其实是如何让这些二手数据更权威一些。Chainlink 采用大量社区节点（相当于矿工）随机选择部分，并寻求共识的方式来部分解决问题。这当然解决了一定的问题，但是最好的办法还是不要中间人，可以直接访问权威 API。然而在以太坊类似架构的设计下，这是不可能实现的，因此必须采用这样的结构。
Chainlink
Chainlink 的逻辑是吸引大量参与者运行 Chainlink 节点，这些节点从链上调度来执行一些 API 调用，Chainlink 则调度选择不同的节点，来防止 Oracle 作恶。他们采用 link 通证作为激励：应用开发者付出 link，节点运行者获得 link。
这个设计与 ArcBlock 的 Blocklet 多么相像！的确如此，因为我们设计 Blocklet 的时候接受了包括 Chainlink 在内诸多优秀设计的启发。
ArcBlock 是否需要 Chainlink 类似的预言机？
不需要。因为我们的设计不是以太坊的虚拟机架构，Blocklet 可以完全采用和互联网应用一样的架构，使得应用直接访问外部 API，完全不需要通过预言机这样的中间代理机制。
“等一等，这样说明你们不够去中心化啊？，你调用外部中心 API 啊，大哥，怎么去中心化？”
我们的设计让你直接访问权威 API，不存在中间人，没有中间人可以做恶，因此不需要 Chainlink 类似的预言机。看明白前面的原理介绍即可。
那么是否说 Oracle 没价值？
并不是， Oracle 是有价值的。 然而 Chainlink 这类 Oracle 只是一种解决访问外部 API 的 Oracle，在 ArcBlock 架构中没有必要。
而区块链的 Oracle 是泛指一种能把链下数据可靠、确定性从链上获得的机制，这比解决访问外部 API 的 Oracle 要广泛很多，也困难很多。其实到现在还没有很好的有效率的机制。
声明： 当然，以上是我的一家之言，代表了我现在对 Oracle，对外部 API 类型的 Oracle 的认知以及判断，完全有可能是错的。 欢迎讨论和指正。
区块链实战：智能合约在应用中的位置
当我们对区块链和智能合约越来越了解，就会发现其实区块链和智能合约其实只是一个完整应用中的一小部分，要构建一个完整用户体验的应用，光靠区块链和智能合约本身还远远不够。从这个角度而言，区块链和智能合约在一个系统中的地位类似数据库和存储过程（Stored Procedure）在系统中地位，它们都处于整个系统的核心关键，但要形成一个完整的用户友好的应用必须要其他部分的配合。
一个完整的以太坊的 Dapp 中，其实以太坊和智能合约只是占了一小部分，在这张图的例子中这基本是一个完整的 Web 应用再加上和智能合约交互的部分。
上图展现了一个典型的采用以太坊的区块链应用的架构方式，除了传统的 Web 服务器、数据库服务器外，部署在区块链上的智能合约是一个关键。如果没有这个关键的部分，这个应用可能和一个传统的 Web 或移动应用没有任何区别。
在这样的设计里，我们可以看到其实完整的应用逻辑有一小部分是在“链上”也就是智能合约里完成的，而另一部分是传统的应用实现方式，也就是“链下”的逻辑。 实际上几乎每个区块链的应用都包含了“链上”的部分和“链下”的部分。
一部分逻辑放在链下可能是因为不必要，比如和界面相关的逻辑，但还有一些逻辑是无法用智能合约来实现的。比如有人设计一个智能合约来和朋友打一个简单的赌“如果中国足球队赢了，我就如何如何”，听起来很简单很容易实现，但实际上最大的问题是区块链没有一个可靠的方法来知道是否“中国足球队赢了”是一个事实。
用以太坊的智能合约为例，它只能访问自己链上的状态，链外数据是无法主动获取，一个智能合约并不能简单地调用一个 API 或者访问某个 Web 服务来获取链下的数据，这样的设计并不是以太坊的局限性，而是故意这么设计的。智能合约的代码逻辑最强调的是“确定性”，也就是无论运行多少次、在什么环境下运行，都应该确定地返回相同结果。一旦引入外部的 API 后，外部的 API 可能是不确定性的，或者因为网络故障暂时无法访问，或者访问结果出错，这时候智能合约就无法获得确定性结果。
EVM 的沙盒机制： 沙盒就是一个限制应用程序对系统资源的访问的运行环境，沙盒很多情况下都是实现在虚拟机（VM）之中。EVM 是一个相对封闭的环境，不支持对网络和文件系统的直接访问。
解决这一问题的方法之一是预言机（Oracle）， 这也是目前区块链行业的热门课题，业界希望在此取得突破，以达到链上链下、链和链的数据状态一致的目的。Oracle 这个词最初是来源于古希腊宗教，意为“神谕、先知、预言”。区块链预言机，则是一个能提供“可靠的”外部信息的平台，预言机本身也可以认为是一种特殊的智能合约。
在理想情况下，预言机能提供一种无信任（Trustless）或至少近乎无信任的方式来获取外部数据（“真实世界”或“链下”），例如比赛结果、天气信息、黄金价格等等，然而要实现这样的理想状况至今仍然是无解的。如何实现一个去中心化预言机是个非常有挑战的问题，有一种思路是让网络中大量的用户群体协作，结合一些激励机制来作为一个区块链预言机提交来自外部世界的数据，另一种思路则更“中心化”一些，但实现的难度要低很多，选择一种中心化的方式并信任此数据来源，采用各种技术手段来防止单点故障或降低临时错误的可能性，采用例如随机选择参与的数据提供节点的方法来防止恶意或合谋的攻击等。目前很多的所谓“预测市场”的预言机采用前一种做法，实际上迄今未有大规模成功的案例；而更多的让区块链获取外部 Web 服务数据源的预言机采用后一种做法。
一个理想中的假想预言机设计： 即用户的智能合约把请求给链上预言机合约，通过链下的 API 接口获得外部数据，更确切的说是外部把数据给链上的预言机合约，然后预言机合约再把数据给用户的智能合约。在互联网世界里，这样的调用数据 API 是非常普遍的。但区块链与外部世界的数据交互，却不能进行这样的简单的操作——一个最重要的原因就是外部 API 的“不确定性”返回。
2018 年 11 月 6 日，中国人民银行发布的《区块链能做什么？不能做什么？》报告中对预言机定义是“区块链外信息写入区块链内的机制，一般被称为预言机 ”，显然这是在以太坊设计架构的基础上给预言机的一种定义。预言机是区块链与现实世界进行数据交互的桥梁，应用场景非常多，可以说一切需要与链下进行数据交互的应用都需要类似预言机的机制。因此目前制约智能合约处理任何业务逻辑的一个重要技术难点就是预言机。
目前网络上很多关于预言机的产品或论述基本都是基于以太坊或类似设计的区块链的，那么对于和以太坊设计思路不同的区块链是否存在相同的问题呢？基于以太坊或者类似架构的区块链的预言机一般是把链下的数据首先写回到链上，这样智能合约就可以访问这些链上的数据，预言机负责保证这些链上数据和链下是吻合的；而对于智能合约并不是完全采用虚拟机的机制来执行的区块链，例如 Hyperledger 等，有可能智能合约的执行环境允许直接访问链下数据，那么实现起来会更为简单。本质上无论采用何种架构的区块链都会存在相同的问题——由于外部数据不能保证其确定性，而智能合约需要其具备确定性，这是一个必然存在的矛盾。
虽然迄今为止还没有出现过完美的去中心化预言机，从而使得智能合约在处理我们日常逻辑的时候仍然存在一定困难和不完美，但不可否认这个趋势离我们过去只能选择信任中心化服务的互联网服务时代又向前迈进了大大的一步。我们在今天不必高估智能合约的能力，但也绝对不能低估在未来 10 年里智能合约可能取得的巨大进展和应用前景。
