5 分钟了解 API3 新推出的 API 集成平台 ChainAPI

作为一种全新的预言机模型，专注于第一方的预言机解决方案 API3 于 1 个月前推出了一款名为 ChainAPI 的新服务，同时宣布废弃之前的 Honeycomb Marketplace，API3 的开发团队称，ChainAPI 是对 Honeycomb 的一次重大迭代。

那么，ChainAPI 是什么？原来的 Honeycomb 到底有什么问题？ChainAPI 的推出对 API3 意味着什么？

ChainAPI 是什么？

ChainAPI 是 API3 推出的一个新的 API 集成平台，可以让 API 提供者更便捷地集成第一方预言机，也就是说，借助 ChainAPI ，API3 生态中的 API 提供者可以更轻松地自助集成 API 至 API3 预言机系统 。

这意味着，API3 提供了一种标准化的 API 集成方案，而 API 提供者可以自主完成 API 对 Airnode 的集成。当然，如有必要，API3 的专职人员也可代表 API 提供者使用 ChainAPI 接口进行集成，从而大大提高预言机集成效率和准确性。

除了提供优化的集成体验外，ChainAPI 还简化了「API 提供者」和「请求者」两者基于跨链与多个 Airnode 协议交互的流程（例如，为预言机端点设置自定义授权策略，对指定钱包提供资金以满足请求等）。

Honeycomb 是什么？

那么，为什么说 ChainAPI 是对 Honeycomb 的一次重大迭代呢？首先得弄明白 Honeycomb 是什么？以及提供哪些功能？

Honeycomb 由 CLC Group 团队开发，诞生于大约 2 年前，作为一个预言机 API 市场，它专注于连接智能合约开发者、Chainlink 节点运营商和 API 提供者，旨在以一种软件即服务的模型，为 Chainlink 节点运营者提供外部适配器。

也就是说，API3 的开发团队 CLC Group 原先是为 Chainlink 预言机服务的，且希望通过建设一个涉及多方参与者的生态系统，引导和激励外部数据提供商将高质量的数据提交到 Chainlink 中，最终实现规模扩张和网络效应，而 Honeycomb 在该模型中充当的是一个中立的预言机 API 市场，也是该系统中的中心。

Honeycomb 的好与坏

但在两年后，CLC Group 宣布将废弃 Honeycomb ，取而代之的是，启动一项新的服务 ChainAPI ，并称 ChainAPI 是对 Honeycomb 的一次重大迭代。那么，Honeycomb 到底存在什么问题？

说问题之前，先看看 Honeycomb 有哪些值得肯定的地方？

根据 CLC Group 发布的官方告示，虽然 Honeycomb 即将被废弃，但 Honeycomb 也为 API3 提供了非常有用的实践经验，在多方面取得了不错的成绩，也为推出新的 ChainAPI 奠定了基础。

在过去两年的实践中，Honeycomb 在预言机集成上取得了一些不错的成绩，比如用户友好的无缝集成体验，不仅将预言机和 dApp 的集成简化到最低限度，而且可通过工具集实现预言机节点和 Honeycomb 的无缝集成，这直接为设计 Airnode 部署程序用户体验提供了前车之鉴。

Airnode 是专为第一方预言机设计的一种节点，本质上是一种区块链的 API 网关。作为轻量级的云服务基础设施，它对 API 后端进行了封装，并抽象了全部功能，允许用户通过互联网访问。此外，它还提供其他功能，包括授权、缓存和速率限制等。

和预言机节点一样，Airnode 网关提供的功能也是将 API 数据提供给智能合约，只不过对于 API 提供者来说，这种方式更加简单易用，特别是那些本身就很熟悉部署云服务托管的人来说。Airnode 可为 API 数据提供者提供统一的服务，数据所有者自助设置 API 网关连接 Airnode，只需一次单击和进行一次 DNS 配置，就可以使用云托管服务提供数据，也无需后续和日常操作。

和预言机节点一样，Airnode 网关提供的功能也是将 API 数据提供给智能合约

不过，在这两年的试错中，团队也逐渐发现，原先那种需要三方都加入的模式存在架构上的缺陷，这种架构不仅非常复杂，而且无法以最小化信任的方式实现集成，更为关键的一点，该模式在业务模型上也存在缺陷。

在 API3 原先的架构中，包含预言机节点、dApp （需求方）和 API 提供者三方，其中，Honeycomb 担任的是一个中间人角色，旨在通过强大的市场力量联结「API 提供者」和「预言机节点」实现集成，团队希望以此作为初始模型引导平台实现冷启动，之后逐步转型成为一种无需信任的集成路径解决方案。但团队后来发现，在三方均需参与的模式中，每次必须确保 3 个不同的参与方协调参与，这种模式被证明是非常复杂的，而以最小化信任集成预言机的唯一选择就是由 API 提供者自行操作预言机全节点，此外，Honeycomb 还验证了团队之前的一个假设「将预言机和 dApp 应用作为最高优先级考虑的两方」并不是完全正确的，取而代之的是，应该将「API 提供者视为预言机方案中关键组成部分」。这直接导致诞生后来的第一方预言机模式的 API3。

更为关键的一点是，Honeycomb 在定价模型上存在一些缺陷：

• 该预言机节点需要支付数据请求者的 gas 成本，而该成本是不确定的。

• 与以上相关，Honeycomb 采用的是静态服务定价模型，但 gas 费价格、ETH 价格和实施链上动态定价的 gas 成本开销都是不确定的

• 需要链下协调，来更新定价参数（这对于这种三方模型尤其困难）

• 使用代币付款会产生摩擦，与传统的 API 提供者定价模型相比定价模型不够灵活，且不能对其进行自定义

这让团队意识到，小修小补的迭代根本没有用，只能从架构上彻底改进，从头开始实现预言机节点 / 协议才能从根本上解决问题。

ChainAPI 做出了哪些改变？

在改进版的架构中，原先作为中间人的预言机节点操作者被去除，从包括 3 方（预言机节点、dApp「需求方」和 API 提供者）的模式简化为只需两方参与的模式（API 提供者 和 dApp），自然而然也就不再需要作为联结 API 提供者和预言机节点的预言机 API 市场 Honeycomb 了，新推出的 ChainAPI 充当的是 API 集成工具，为 API3 生态中的 API 提供者提供简单易用的自助式集成方案将其集成至 Airnode 中，创建第一方预言机。这不仅极大降低了复杂性，由 API 提供者自行运行节点也可将信任降至最小化。

综上，Honeycomb 的落幕以及 ChainAPI 的启动，意味着 API3 团队正在逐渐完善围绕第一方预言机模式和功能开发和交付，这将极大简化 API 提供者集成至 Airnode 中，有利于 API3 加速扩张和增长，此外，去掉了第三方节点角色后的两方模式不仅可最小化信任，而且去掉了中间人后可降低预言机成本。