dAPI：dApp 的 API

原文标题：《dAPIs: APIs for dApps》

作者：Burak Benligiray

编译：ChatCatcher

正如白皮书中所讨论的，API3 的目标是“大规模构建、管理 dAPI 并从中获利”。在这方面，我们一直在进行的所有开发都是因为现有工具无法像我们设想的那样支持 dAPI。那么这些 dAPI 到底是什么？

dApp 是一种应用程序，它被实现为在去中心化区块链上运行的智能合约。出于同样的原因，dAPI 是一种提供给智能合约的类 API 服务。简单来说，就像应用程序使用 API 一样，dApp 也将使用 dAPI。

从用户的角度来看，dAPI 的设计类似于 API：

与用户的关系是事务性的。用户按照透明的定价模式付费，即可享受到完善的服务，无需血缘契约。

它有一个标准化的、用户友好的界面，旨在将技术实现抽象化。

它是一种托管服务，因为操作的复杂性被抽象掉了。用户唯一的责任是不要错过付款。
除了上述之外，dAPI 还具有可量化的安全性，因为它可以避免因故障造成的损失（尽管这甚至可以与 API SLA相提并论）。在这里， dAPI 的第一方性或 API 级去中心化严格用作优化保险风险的工具。此外，dAPI 不一定是实时数据源，而是代表一种更通用的预言机服务。

在这个一般定义之后，让我们研究一下我们将构建的第一代 dAPI，以及它们与Beacons 的关系。正如在最近的 ETHDenver 谈话中介绍的那样，我们的解决方案被设计为一个层次结构：

最低级别由 Airnode 协议（RRP、PSP、中继 RRP、中继 PSP、API 签名数据）组成。允许授权的用户在协议级别向相应的 Airnode 发出请求。Kassandra /Heimdall 用例可以作为这种用法的示例。通常，实现此类用例需要对 Airnode 协议有深入的了解。

中间层由信标等 oracle 原语组成。列入白名单的用户可以阅读相应的信标。为 ETHDenver 构建的 Amberdata Beacons就是一个很好的例子。尽管 Beacons 是建立在 Airnode 协议之上的，但这个事实是从用户那里抽象出来的，这意味着他们不需要了解任何关于为他们使用的 Beacon 提供支持的特定 Airnode 协议的信息。

我们将构建的最高级别解决方案是 dAPI。在实时数据馈送用例中，dAPI 是一个 Beacon 或一组由更高级别接口包装的 Beacon。列入白名单的用户可以阅读相应的 dAPI，而无需指定应该在后台使用什么 Beacon。换句话说，通过使用 dAPI，用户可以卸下管理数据馈送中各个 Beacon 的责任。

这种模块化架构的目标是允许用户为工作选择最合适的工具。如果需要一个交钥匙的、一劳永逸的 oracle 解决方案，他们应该使用 dAPI。如果他们想要完全控制数据源，他们应该使用一个或一组 Beacon。如果他们需要的解决方案非常小众，可以直接在 Airnode 协议之上构建。访问控制和货币化机制在每个级别上实施，这意味着 API 提供商可以实际地产品化他们的服务以涵盖整个范围。

由于大多数读者会熟悉 Beacons，让我们将 dAPI 的用户流与这些进行比较以进一步说明。Beacon 由 ID 寻址，该 ID 源自相应的 Airnode 地址和请求参数。这意味着 ID 为0x49e889871813b16854fd7faecad16b5ba59d33a9669b47f927501136840c021b的 Beacon将始终是Amberdata 报告的 BTC/USD 价格。类似地，Beacon 集由构成它们的 Beacon ID 列表的哈希值寻址，这意味着 Beacon 集 ID 将始终引用特定的 Beacon 组合。这很棒，因为它允许用户指定精确的数据源到请求参数，这消除了 API3 端错误的任何可能性——这可能例如，将白银转化为黄金——并允许 API3 切实可行地服务于市值达 100 倍的项目。这不是很好，因为用户将需要一个强大的去中心化治理机制，该机制可以选择要使用的特定 Beacon 并在必要时更新它们，这通常不适用于尚未完善的项目。

在这里，dAPI 开始发挥作用。dAPI 本质上是一个名称，映射到 Beacon ID 或 Beacon 集 ID。用户通过名称寻址 dAPI，合约将其路由到相应的 Beacon 或 Beacon 集。API3 核心技术团队将在 API3 服务的所有链上进行多重签名，这将做出专家决策以维护覆盖策略给出的安全保证。一旦这个过程成熟，dAPI 管理将转移到我们的分形扩展计划中描述的单独的、链原生的 DAO。对于进行 dAPI 管理的用户来说，这并不重要，因为他们将获得治理事故的保险，无论是谁造成的。因此，任何由 dAPI 管理方案引起的风险都被认为是保险风险的一部分，由 API3 DAO 负责管理。
我们正在快速实现 API3 的存在理由 dAPI，这让我们感到自豪。然而，正如白皮书所说，目标也是“大规模”实现这一目标，这意味着创建一个与整个 Web3 相当的 dAPI 经济。我们的解决方案旨在解决可能限制生态系统增长的瓶颈，因此实现这一目标的方法只是做更多我们一直在做的事情，并让 Web3 空间赶上来。