爲什麼說 ChainAPI 是對預言機 API 市場 Honeycomb 的一次重大迭代?

撰文:LeftOfCenter

作爲一種全新的預言機模型,專注於第一方的預言機解決方案 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 配置,就可以使用雲託管服務提供數據,也無需後續和日常操作。

5 分鐘瞭解 API3 新推出的 API 集成平臺 ChainAPI
和預言機節點一樣,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 加速擴張和增長,此外,去掉了第三方節點角色後的兩方模式不僅可最小化信任,而且去掉了中間人後可降低預言機成本。

參考來源:
https://medium.com/api3/airnode-the-api-gateway-for-blockchains-8b07ff136840
https://www.clcg.io/whitepaper/
https://medium.com/api3/hello-chainapi-e1b386a74f1d
https://medium.com/clc-group/sunsetting-honeycomb-and-a-retrospective-ba3f58268024