超越预言机：IC HTTPs OutCalls如何塑造L1与Web2的无中间件的无缝交互

文章来自于/D Plus

投稿、转载请联系/D Plus小助手

无论是在拥有庞大规模数据产出体系，并与我们生活息息相关的Web2世界，还是在进一步满足我们数据主权需求的Web3世界中，数据都是一个没有上限的价值金矿，但如何将数据的价值挥发，这往往取决于数据源和对数据进行商业化的业务模型。而在现有的Web3体系中，数据体系因去中心化分散特性、主权属性下正处于对成熟化业务模型的探索阶段。

而在如何挥发Web3数据价值这条道路上，将Web3数据与具有对成熟化处理体系的Web2数据结合，一度成为L1区块链们一直所在尝试的方向。

经过多年的技术迭代更新，目前也产生出一些成熟化的解决方案，但本质上因区块链与Web2底层技术栈和系统的差异化实现，实现双方的可信、安全的交互又成为了一大难题。

在Web2.0世界中的大多数价值数据都在传统数据中心和云计算基础设施中生成，并都遵循一个应用层协议/HTTP协议实现交互通信。这意味着如果要实现L1区块链与该区块链外的数据交互， 需要使智能合约能够向外输出HTTP(s)请求，这对于任何区块链都是一个挑战，如果一个智能合约发送的HTTP(s)请求，通过不同节点发出后，可能会接收到不同的响应，（例如响应中包含的时间或编号）。

不同节点接收到的不同响应后，再基于不同的响应的进一步处理，将导致节点间的状态出现不一致，从而破坏计算的确定性，无法达成共识。

因此，智能合约不能通过节点直接向外部服务发出 HTTP(S) 请求，这会给共识造成重大问题。

目前大部分L1区块链对此问题的解决方案是通过引入一个称为预言机的外部组件实现与链下数据（基于HTTP的服务）的交互。虽然预言机起到了使链上与链下数据的交互关键作用，但也拥有一些痛点，一是作为第三方数据代理商存在外部信任风险；二是预言机作为第三方需要支付一定的费用，增加了开发成本；三是预言机的编程模型增加了复杂性和间接性。

在今年的2月，由DFINITY基金会和社区拟议的HTTPs OutCalls功能设计提案通过了NNS治理投票，相关技术已在近期上线，并供于开发者开发使用。

与其它许多L1区块链不同的是，在整合Web3数据和Web2数据这条道路上，IC并没有采用经典的预言机方案，而是秉承去中间件化、减少复杂性和间接性的直接整合策略，设计了一套契合IC底层技术栈开发的解决方案，以此实现IC与Web2无缝交互，无需任何中间件（例如预言机）。

简而言之来说，在此前传统区块链的一贯做法是，L1区块链要与Web2交互（例如DEX和CEX），必须要借助一个区块链系统外的第三方组件来实现。即为，当你在使用L1区块链与Web2交互服务的时候，你除了要相信A和B是可信之外，你还要相信链接A与B之间的桥梁C也是可信，并不会作恶。

而在IC的方案中，C不存在，你只需相信A和B是正常运行的。这不仅很大程度增加了安全性，还减少了信任成本。

设上述L1区块链为A、Web2数据源为B、第三方组件为C。

如上所述，IC与Web2实现无缝交互的功能被称为Canister HTTPs OutCalls功能，它与BTC集成功能方案类同，作为IC协议栈的扩展实现，这主要得益于IC协议栈和共识协议的强大架构。

以下内容我们将从DFINITY基金会提供的HTTPs OutCalls技术文档中原文的底层逻辑出发，带各位小伙伴们一起解读和探讨HTTPs OutCalls功能的实现，由于下文可能会涵盖部分IC技术术语，我们会在下文中做出部分注解，便于小伙伴们理解与阅读。

如您在阅读本文时还遇到其它问题或不解的地方，可通过下方二维码找到我们进行进一步探讨和交流。

如下图所示，图中展示了IC智能合约Canister如何发出HTTPs请求，并安全可信的根据请求响应的数据执行响应的操作，以及为此功能添加在协议栈的新组件。

流程解读：

1、某子网上的IC Canister向执行层/Execution中的管理Canister发出HTTPs请求，请求存储在该子网上的复制状态/Replicated State中，由该子网的每个节点向目标服务器发出固定的HTTP请求后；

2、由共识层/Consensus中的一个新组件HTTPs请求池管理器/HTTP Pool Manager读取状态更新，以及跟踪未完成的HTTPs请求；

3、每当HTTP请求池管理器看到一个由Canister发起的新HTTP请求时，他会转发到网络层中一个名为HTTP适配器Shim组件/HTTP adapter Shim中，它负责与HTTP适配器/HTTP adapter进行通信，HTTP适配器是与副本进程一起运行的单独进程，但处于安全考虑是被隔离的；

4、HTTP适配器Shim使用RPC将请求转发到HTTP适配器；

5、每个节点上的HTTP适配器向目标服务器发出远程HTTPs请求；

6、响应从目标服务器返回到每个节点的适配器；

7、每个适配器都将响应返回给HTTP适配器Shim组件；

8、HTTP适配器Shim组件根据所有节点得到的响应结果能否达成一致，决定是否调用Canister上的可选转换函数。该函数的作用在下方将详细解释，但简单来说，它帮助所有返回的响应达成共识；

9、HTTP适配器Shim组件根据转换函数转换后的响应转发到HTTP请求池管理器；（前提是出现了返回响应值不一致的情况下）；

10、然后共识层将响应的份额分配给所有对等节点，以便区块创建者节点/Payload Builder可以看到足够多对等节点接收到与其收到的响应是否相同；

11、然后区块生成器将达成共识后的响应包含在最新高度的区块中；

12、响应对执行层可用；

14、调用回调以将响应一步返回到Canistar中，执行Canister对返回响应定义的操作更新。

PS：整个IC区块链由多个子网区块链组成，这些子网有点像分片链的角色，托管着组成Dapp的不同Canister智能合约，并相互协作通信，组成一个供所有人访问且不受单一人控制的区块链平台。

转换函数如何将不同响应值达成共识

在上述流程中，每个节点向目标服务器发出的固定HTTP请求并接收响应，但在此过程中会因为多种原因导致同一API查询的响应返回到节点上是不一致的。为了使子网节点们以某一个响应值达成共识，建立了一个由Canister开发者可以自己定义的“转换函数”机制，使每个节点在其接收到的响应上调用该转换函数，然后根据转换后响应达成共识，进行下一步操作。

以下是如何通过一个天气API示例说明如何通过转换函数达成共识的⬇️

情况1：在最简单的情况下，所有节点收到的响应都是相同的，在这种情况下，不需要直接调用转换函数，因为返回的响应值本身就相同。

情况2：假设有少于三分之一节点收到的响应不同，并且其他响应都相同，不同的响应可能是因为服务器响应不同或者恶意节点伪造造成，这种情况的处理方式与情况1相同，不需要转换功能，IC的共识协议会处理偏离响应的子集，遵循三分之二节点得到的相同响应做进一步处理。

情况3：最常见的情况是由于情况2进一步造成的原因，在下方例子中，每个节点都收到了不同的响应（时间戳上），在这种情况下，需要一个Canister公开的转换函数来“规范化”响应成对等（对于至少三分之二的节点），通过下方例子的转换函数，所有不必要的结果（时间戳等）都去除了，只留下了转换后的核心结果多云/Partly cloudy，然后协议根据转换后的响应达成共识，基于该转换后响应达成共识。 

PS：Canister HTTPs OutCalls的信任模型基于被调用HTTP服务器（调用数据源）和IC协议栈的信任模型实现：

• 信任假设前提上建立在HTTP服务器是诚实的，否则，它可以对子网的任何调用节点提供任何恶意响应；

• IC协议栈的信任模型假设建立在单个子网中至少2/3的节点是诚实的，在这种情况下，诚实的节点将相同的响应（可选转换后）达成共识，并提供容器回调。

不管是从IC的技术栈设计、BTC整合方案、HTTPs OutCalls功能等方面出发，我们都不难看出IC正在迈向打破当前区块链固有边界和数据孤岛效应这条道路上，做出了很大的努力和尝试，也期待开发者们基于这些愈来愈强大和丰富的IC基础设施和功能构建更具广阔边界以及更具应用场景的创新用例和功能。