编者按：链接，以太预言机项目，最近成为世界第九大市场价值项目，最近被做空，引起了业界的关注和热烈讨论。今天，通过ArcBlock技术社区[1]于今年2月28日发布的《Chainlink 技术讨论》 [2]和中信出版集团最近发布的第8章《区块链实战：从技术创新到商业模式》 [3]的最后一部分，我们分享作者如何从技术和产品的角度讨论和分析链接和预言机的价值和现状。

链环的技术探讨

Chainlink是一个旧项目。我在2017年就注意到了。除了链接之外，我还关注了奥拉里兹(现在改名为可证明的)。两者都很相似，都解决了以太博物馆的甲骨文问题。

外部应用编程接口的预言机

以太网的设计使EVM和智能契约成为一个完全封闭的沙箱，而智能契约不能访问外部应用编程接口。这也是为了确保智能契约代码的执行的确定性，因为一旦有了外部的应用编程接口调用，不同的以太网节点可能在不同的时间运行，并且外部的应用编程接口可能返回不同的结果(例如，应用编程接口最初返回的结果不同或者出现了临时错误)，因此无法达成一致。

解决方案是建立一个外部(离线)程序，向链中写入一些需要的外部数据，这样当智能契约需要外部应用编程接口时，它实际上从链中读取数据，从而解决了确定性问题。这个链接外部数据的程序被称为预测机器(定义松散)。如果您想从链中触发一些外部动作，您可以类似地进行。

上述工作原理显示在链节中。chaink与Oraclize的相似之处在于，它设计了一个框架，其中一个是链上的智能契约代码模板，另一个是在链下提供API调用的程序。这样做是为了简化开发，应用程序只需要在链上调用它的智能契约。

去中央预测机器

有些人可能会想，如果上面的预测机器是人为操纵的呢？首先，这些预测机器通常访问外部的API，这些API在某种程度上是相当集中的，也就是说，不管预测机器有多分散，你仍然会得到集中的数据，这实际上是非常尴尬的。然而，这种用法已经在互联网应用中使用了这么多年，为什么没有问题呢？这是一个非常好的问题。首先，因为没有办法，这是现实，有些API现在只能集中；其次，互联网应用程序本身也是一个集中的设计，并采用许可设计。互联网应用程序本身通常在安全的环境中直接访问权威的外部应用程序接口，所以这不是一个大问题。然而，区块链需要使用预言机(相当于中间人)来访问权威数据，这导致在链上获得的数据是二手的，但是失去了它的权威。

chaink和Oraclize解决的主要问题是如何使这些二手数据更具权威性。Chainlink使用大量社区节点(相当于挖掘者)随机选择一些部分，并寻求共识来解决一些问题。这当然解决了一些问题，但是最好的方法是直接访问权威的应用编程接口，而不需要中间人。然而，在类似的建筑设计下，这是不可能实现的，所以必须采用这样的结构。

链环

链链接的逻辑是吸引大量参与者运行链链接节点，链链接节点是从链中调度来执行一些应用编程接口调用的，而链链接则调度和选择不同的节点来防止甲骨文作恶。他们使用链接通行证作为激励：应用程序开发人员支付链接，节点运营商获得链接。

这种设计与ArcBlock的小积木多么相似！这是真的，因为当我们设计积木时，我们受到了许多优秀设计的启发，包括链环。

ArcBlock需要一个像链接一样的预言机器吗？

没必要。因为我们的设计不是以太网的虚拟机架构，所以Blocklet可以完全采用与互联网应用程序相同的架构，这样应用程序就可以直接访问外部应用程序接口，根本不需要像预言机那样使用中间代理机制。

“等一下，这说明你不够分散？你叫外部中心的API，大哥，怎么分散？”

我们的设计允许你直接访问权威的应用编程接口，没有中间人可以作恶，所以不需要像链接这样的预言机器。只要理解前面的原理介绍。

那么甲骨文一文不值吗？

不，甲骨文是有价值的。但是，链接等Oracle只是一个用于访问外部应用编程接口的Oracle，这在ArcBlock体系结构中是不必要的。

Oracle在区块链通常指的是能够从链中获得可靠且确定性数据的机制，这比Oracle访问外部API要广泛得多，也更困难。事实上，到目前为止，还没有好的、有效的机制。

免责声明：当然，以上是我家人的声明，这意味着我目前对甲骨文和甲骨文外部应用编程接口类型的认知和判断可能完全错误。欢迎讨论和指正。

区块链作战：智能契约在应用中的地位

当我们越来越了解区块链和智能合同时，我们会发现区块链和智能合同实际上只是一个完整应用程序的一小部分。要构建一个具有完整用户体验的应用程序，仅仅依靠区块链和智能合同是远远不够的。从这个角度来看，区块链和智能合同在系统中的地位类似于数据库和存储过程。它们都是整个系统的核心，但是要形成一个完整的用户友好的应用程序，其他部分必须合作。

在以太网的完整Dapp中，以太网和智能合同仅占一小部分。在此图的示例中，这基本上是一个完整的网络应用程序，加上与智能契约的交互。

上图显示了使用以太网的典型区块链应用程序的体系结构。除了传统的网络服务器和数据库服务器，部署在区块链的智能合同是一个关键。如果没有这个关键部分，这个应用程序可能与传统的网络或移动应用程序没有什么不同。

在这个设计中，我们可以看到，实际上，完整的应用逻辑的一小部分是在“链”中完成的，即智能契约，而另一部分是传统的应用实现模式，即“链”下的逻辑。事实上，区块链的几乎所有应用都包括“链上”部分和“链下”部分。

一些逻辑可能被放在链下，因为它们是不必要的，例如与接口相关的逻辑，但是一些逻辑不能通过智能契约来实现。例如，有人设计了一个聪明的合同，和一个朋友打一个简单的赌，“如果中国足球队赢了，我该怎么办？”这听起来简单容易实现，但实际上，最大的问题是没有可靠的方法知道“中国足球队赢了”是否是事实。

以邰方的智能合同为例，它只能访问自己链上的状态，不能主动获取链外的数据。智能契约不能简单地调用应用编程接口或访问网络服务来获取链下的数据。这种设计不是以太博物馆的限制，而是刻意设计的。智能契约的代码逻辑强调“确定性”，也就是说，无论它运行多少次，在什么环境下，它都应该返回相同的结果。一旦引入外部应用编程接口，外部应用编程接口可能是不确定的，或者由于网络故障暂时无法访问，或者访问结果是错误的。此时，智能契约无法获得确定性结果。

EVM的沙箱机制：沙箱是一个运行环境，限制应用程序对系统资源的访问。沙箱通常在虚拟机中实现。EVM是一个相对封闭的环境，不支持直接访问网络和文件系统。

甲骨文是解决这一问题的方法之一，也是区块链业界的热门话题。业界希望在这方面有所突破，从而实现链、链和链之间数据状态一致的目标。甲骨文一词起源于古希腊宗教，意思是“甲骨文、先知和预言”。块链预测机是一个能够提供“可靠”外部信息的平台，预测机本身也可以被视为一个特殊的智能契约。

在理想情况下，预测者可以提供一种不信任或至少近乎不信任的方式来获取外部数据(“真实世界”或“离线”)，如竞争结果、天气信息、黄金价格等。然而，要达到这样一种理想的情况，仍然没有解决办法。如何实现一个分散的预测机器是一个非常具有挑战性的问题。一个想法是让网络中的大量用户组合作，并结合一些激励机制，以区块链预测机的形式提交来自外部世界的数据。另一种想法更“集中”，但实施难度要低得多。选择集中方式，信任该数据源，采用各种技术手段防止单点故障或减少临时错误的可能性，并采用随机选择参与数据提供节点。目前，许多所谓的“预测市场”预测机器采用前一种方法，但实际上迄今为止还没有大规模的成功案例；后一种方法被更多让区块链获得外部网络服务数据源的预测者所采用。

一种理想的假设预测机器设计：即用户的智能契约向链上的预测机器契约发出请求，并通过链下的API接口获取外部数据，更准确地说，外部预测机器契约将数据提供给链预测机器契约，然后预测机器契约将数据提供给用户的智能契约。在互联网世界中，像这样调用数据应用编程接口是很常见的。然而，区块链与外界数据交互的最重要原因之一是外部API的“不确定性”返回。

2018年11月6日，中国人民银行发布的《对智能合约和虚拟机的误解》报告将预言机定义为“将区块链以外的信息写入区块链的机制，一般称为预言机”。显然，这是基于以太博物馆设计架构的预言机的定义。预测机器是区块链和现实世界之间数据交互的桥梁。有许多应用场景。可以说，所有需要与链下的数据进行交互的应用程序都需要一种类似于预测机器的机制。因此，目前制约智能合同处理任何业务逻辑的一个重要技术难点是预测机。

目前，互联网上很多关于预言机的产品或讨论基本上都是基于以太网的区块链或类似的设计，那么，与以太网有不同设计理念的区块链是否也存在同样的问题呢？基于以太区块链或类似体系结构的预言机一般先将链下的数据写回到链中，这样智能契约就可以访问这些链上的数据，预言机负责确保这些链和链上的数据一致；但是，在区块链，智能契约并不完全由虚拟机机制执行，例如Hyperledger，智能契约的执行环境可能允许直接访问链下的数据，因此实现会更简单。本质上，无论区块链采用什么架构，都会有同样的问题。——因为外部数据不能保证其确定性，而智能合同需要它具有确定性，这是不可避免的矛盾。

虽然到目前为止还没有完善的分散预测机，这使得智能契约在处理我们的日常逻辑时仍然存在一些困难和不完善之处，但不可否认的是，这一趋势是我们从过去选择以信任为中心的服务的互联网服务时代向前迈出的一大步。今天，我们不需要高估智能合同的能力，但也不要低估未来10年智能合同的巨大进步和应用前景。

参考

[1]https://community.arcblockio.cn/ArcBlock技术社区：

[2]《区块链能做什么？不能做什么？》 : https://community.arcblockio.cn/t/topic/242

[3]《Chainlink 技术讨论》 : https://books.arcblock.io/