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 空間趕上來。