MatometaX

Decentralized APIs for Web 3.0

概要

分散型金融などの分野で分散型アプリケーションが有意義なサービスを提供し始めており、これらのアプリケーションが従来のWeb APIを使用してデータを受信したり、イベントをトリガーしたりする必要性が高まっています。
しかし、一般的なオラクルソリューションは、一般化されすぎた誤ったアプローチにより、API接続の問題に適切に対処できていません。

この問題を解決するために、API3は新世代のブロックチェーンネイティブな分散型API、略してdAPIを作成するための共同作業を推進しています。
dAPIはAPIプロバイダーによって運用されるファーストパーティオラクルで構成されているため、中間業者を使用した代替ソリューションよりも安全でコスト効率に優れています。
このイニシアチブのガバナンス、セキュリティ、価値取得の仕組みの中核となるのがAPI3トークンである。このトークンをステークすることで、API3 DAOの完全な統治権とそれに伴う全ての報酬が保有者に与えられる。
ステークされたAPI3トークンは、dAPIユーザーに定量的で信頼できるセキュリティ保証を提供するオンチェーン保険サービスの担保として使用される予定です。
これらの仕組みにより、エコシステムレベルでの中央当局の必要性がなくなります。その結果、API3プロジェクトは、スマートコントラクトプラットフォームが、真に分散化された信頼最小の方法で有意義なアプリケーションを構築するためにAPIを活用することを可能にします。

はじめに

私たちは、現実世界と相互作用することができる分散型アプリケーションの誕生を目撃しており、それは即座に彼らが獲得する価値に反映されます。
この現象の最も顕著な例は、最近DeFi（分散型金融）に流れ込んだ価値の急増で、2021年11月現在、$100B以上の総額が様々なアプリケーションに固定されています[1]。DeFiアプリケーションは、通常、データフィードを通じてそのスマートコントラクトプラットフォームに資産価格を配信することを要求します[2]。
このデータフィードは、アプリケーションと現実世界との相互作用を促進し、最終的にはデリバティブ取引や融資などの有意義なサービスを提供することを可能にします。
今展開されているのは、DeFiの台頭だけでなく、現実世界と有意義に相互作用できる分散型アプリケーションの台頭であり、DeFiは氷山の一角に過ぎないのです。
企業は、資産価格データの提供から伝統的な金融取引の実行まで、さまざまなサービスをウェブAPI上で提供しています。分散型アプリケーションが現実世界と対話するためには、Web APIが提供するサービスにアクセスできることが重要ですが、これらのAPIは分散型アプリケーションとネイティブな互換性がありません。既存の仲介業者ベースのインターフェースソリューションは、中央集権的で安全性に欠け、高価であるため、より良い代替手段がない場合にのみ使用されています。
API3では、APIのコンセプトが次の進化を遂げ、サードパーティの仲介を受けずにWeb 3.0の必然的で厳しい分散化の要求を満たすことを目指しています。私たちは、この新世代の分散型APIを指すためにdAPIという言葉を使うつもりです。

dAPIは、スマートコントラクトに従来のAPIサービスを分散型で提供するための、安全でコスト効率の良いソリューションです。以下の要素で構成されています。

• 複数のAPI。APIという用語は、技術的なインターフェースだけでなく、現実のビジネスが提供するサービスも指す。
• ファーストパーティオラクル、つまりAPIプロバイダ自身が運営するオラクルの分散型ネットワーク。
• オラクルネットワークを監督する分散型運営主体。

API3は、dAPIを大規模に構築、管理、マネタイズするための共同作業です。
完全な分散型でこれを実現するため、参加者のインセンティブはAPI3トークンのガバナンス、セキュリティ、価値獲得ユーティリティによって調整されている。

プロジェクトは完全にオープンで直接的なガバナンスモデルを持ち、API3トークン保有者は誰でもAPI3 DAOで直接投票権を得るためにステークすることができる。
さらに、ステークホルダーは、インフレ的なステーク報酬やDAOが将来決定する追加的な利益を通じて、dAPIの利用から利益を得ることができます。
ステークされたAPI3トークンは、オンチェーン保険サービスを担保として、dAPIユーザーに定量的かつ信頼性の高いセキュリティ保証を提供します（図1参照）。

既存のオラクルソリューションの根本的な欠陥の1つは、データソースとの寄生的な接続を確立し維持しようとすることであり、持続可能なエコシステムを生み出すことはできないのです。これに対し、私たちはAPIプロバイダーがこのプロジェクトのエンジンであるという認識から出発します。従って、彼らは抽象化されるのではなく、彼らの利益がより大きなAPI3エコシステムの利益と完全に一致するように帰属し補償されることになる。我々は既に、APIプロバイダーが有料APIの無料テストネット呼び出し[3]やハッカソンの賞金提供[4]を通じて、分散型アプリケーションによる彼らのサービスの採用に意欲的であることを目撃してきた。
この協力関係をさらに発展させることが、API3の主な強みの一つである。

分散型オラクルネットワークソリューションでは、APIプロバイダーが独自のオラクルノードを運用することが現実的でない場合が多いため、サードパーティ製のオラクルを採用しています。このため、サードパーティーオラクルは高価な中間業者として位置づけられ、新たな攻撃対象として形成される。
これらの問題を解消し、APIプロバイダがさらにエコシステムに関与するために、API3データフィードはAPIプロバイダが運用するファーストパーティオラクルで構成される。
これは、APIプロバイダがノウハウやメンテナンス、維持管理を必要としないように設計された完全サーバレスのオラクルノード、Airnodeによって実現される予定だ。その結果、dAPIはコスト効率に優れ、中間層の第三者からの攻撃に対しても安全なものとなります。
万が一、不具合が発生した場合、dAPIユーザーは事前に交渉された金額を上限として、ステーキングプールから補償を請求することができるようになる。その際、提示された証拠に基づき、オンチェーン紛争解決プロトコルであるKleros[5]が請求の可否を決定するために使用される予定です。
これにより、ステーカーは、dAPIが透明でセキュリティリスクを最小化する方法で管理されていることを保証するために、ガバナンスに積極的に参加するインセンティブを得ることができます。ガバナンスの成功、つまり保険金支払いにつながるようなミスを避けながらdAPIの収益化に成功すれば、API3トークンで報われ、ガバナンスを継続的に改善する正のフィードバックループが生まれることになる。

dAPIは、従来のAPIサービスを分散型かつブロックチェーンネイティブな方法で提供するファーストパーティーオークルのネットワークである。
API3 DAOは、dAPIを大規模に構築、管理、収益化する。
分散型アプリケーションは、API3トークンを使用してdAPIにアクセスする。API3トークン保持者は、DAOで報酬と投票権を受け取るためにプールに出資します。
このステークプールは、dAPIユーザーに定量的なレベルのセキュリティを提供するオンチェーン保険サービスの担保として使用されます。API3は、分散化、コスト効率、セキュリティ、透明性、エコシステムの成長性などの面で、既存のオラクル・ソリューションを改善するものです。

API接続の問題

アプリケーションプログラミングインターフェース（API）は、特定のアプリケーションと通信し、そのアプリケーションからサービスを受けるために使用される、標準化され文書化されたプロトコルである。
これらのサービスは、データの受信やイベントのトリガーという形で提供されます。
アプリケーションはAPIを通じて互いに通信することができ、それらを統合してより複雑なアプリケーションを構築することができる。このため、APIはデジタルワールドをまとめる接着剤と呼ばれています。

企業がAPIを利用してデータやサービスを収益化するようになった結果、APIの概念は当初の意味を超越するようになった。この用語は、もはやインタフェースの技術的実装を指すのではなく、それが包むサービスを含む本格的な製品を指すのである [6]。APIを提供するグローバル企業は、平均して組織の収益の25％をAPIから生み出している[7]。
Salesforce、Expedia、eBayのような企業は、収益の大部分をAPIで生み出していると報告されており[8]、完全にAPI中心のビジネスモデルの入り口に立っている[9]。
銀行のような定着した産業でさえ、この動きによって破壊されることが予想される[10]。

既存のサービスをAPIを通じて自社のアプリケーションに統合することで、開発者はますます複雑で高機能なアプリケーションを構築できるようになり、巨大なWebサービスやモバイルアプリケーションの台頭を招いたのです。しかし、企業がサービスを提供するこれらのAPIは、2.1節で説明する技術的な理由により、スマートコントラクトと直接互換性がなく、有意義な分散型アプリケーションの開発を抑制してきました。
したがって、現実世界と対話できる分散型アプリケーションを構築する上で我々が直面している困難は、現在のところAPI接続性の問題と表現するのが最も適切であると思われます。この問題を誤って解釈すると、最適とは言えない解決策を導くことになる。

オラクル問題：ソースにとらわれない誤った解釈

分散化はWeb 3.0を定義するもので、計算を分散させ、あらかじめ決められたコンセンサスルールによって結果を解決することを特徴とする[11]。
分散型アプリケーションのビジネスロジックは、スマートコントラクト[12]として実装され、ブロックチェーンベースのスマートコントラクトプラットフォーム[13]で実行されます。
分散化により、参加者は相互信頼や信頼できる第三者を必要とせずに協力することができ、攻撃や検閲に対する堅牢性を提供することができます。

コンセンサスルールを実施するために、スマートコントラクトプラットフォームのノードは、ローカルに計算を繰り返すことによって、各コントラクトの呼び出しが正しい結果をもたらしたことを検証する必要があります。
これを可能にするために、スマートコントラクトは、すべてのスマートコントラクトプラットフォームノードがアクセスでき、かつ合意した情報に対してのみ動作することができます。もっと簡単に言うと、スマートコントラクトはブロックチェーン内で容易に入手できる情報に対してのみ動作可能であり、外部と直接対話することはできない。
これは「オラクル問題」として広く知られており、ブロックチェーンに任意に定義された真実の断片を提供できる理想化されたエージェントを指します。
オラクル問題は、その名前からして不可能な解を示唆しているように、非論理的な問題です。
例えるなら、A地点からB地点に移動する問題を「テレポーテーション問題」としてアプローチするようなものです。
それにもかかわらず、第一世代のソリューションは、質問を投げかけ、その答えをクラウドソーシングすることによって、この文字通りの神託を実装しようとしました。これは、数日で測定できる解決時間と、行われる必要があるトランザクションの数による極度のガスコスト[14]を生み出し、DeFiや予測市場などの使用例には理想的ではありません。
このアプローチは、配信される情報が主観的である場合に適していることに注意する必要があります。例えば、裁判の紛争解決[5]が良い例であろう。

第2世代のソリューションは、プログラム的にアクセス可能な事実情報のみに範囲を絞り、「相互運用性問題」に行き着いた。
これらのソリューションでは、任意の2つのシステム（ブロックチェーンとAPI、2つのブロックチェーンなど）に統合されたオラクルノードが、両者間の自動仲介役として機能します[15-18]。
このようなオラクルノードを複数使用し、あらかじめ決められたコンセンサスルールによって結果に決着をつけることで、基盤となるブロックチェーン技術を補完するセキュリティ保証を提供します。
これらのソリューションは、クラウドソースのオラクルと比較して高速かつ安価であり、結果としてより多くのユースケースで実行可能ですが、目下の問題を過度に一般化して設計されていることに苦しみます。
相互運用性ソリューションには、3つの当事者が関わっています。APIプロバイダ、オラクル、そしてデータ消費者です[19]。
しかし、彼らはデータがどこから来たかを無視し、オラクルとデータ消費者のみで構成されるエコシステムをモデル化するという落とし穴に陥っている。
言い換えれば、彼らのモデルはオラクルノードを真実の源である神話上の神託として扱っている。このように問題の3分の1が見えないことで、非現実的なソリューションが実現可能であると認識される結果となるのです。

相互運用性ソリューションがソースにとらわれないものであることは、次のような結果をもたらす。

• 安全でなく高価なサードパーティーオークルの中間層。これはAPIプロバイダーが運営するオラクルに取って代わられたかもしれない。
• 実際のデータソースを排除し、レントシーキングを行う中間業者を育成するエコシステム。
• データフィードにおいて、異なるソースから受信したデータを無差別に扱うこと。

また、相互接続ソリューションに共通する問題として、低レベルのプロトコルであるため、インターフェイスを完全な製品ではなく、技術的なコンポーネント、あるいはミドルウェアとして捉えていることが挙げられます。その結果、インターフェイスのガバナンスは蚊帳の外に置かれることになります。しかし、分散化されたインタフェースは、独立した競合するパーティが協力する必要があるため、ガバナンスは些細な問題とは言い難い。
現在利用されている解決策は、信頼できる中央集権的な組織がインターフェースを管理することですが、これは分散化の主目的とは相反するものです。つまり、分散化されたオラクルネットワークと中央集権的なガバナンスは、余分なステップを含む中央集権的なオラクルであることを意味する。

図2：分散型相互運用ソリューションは、ネイティブにソースを明らかにしないサードパーティのオラクルを採用している。dAPIはファーストパーティのオラクルで構成されており、APIプロバイダが自身のAirnodeを操作することを意味する。
さらに、dAPIはどのように管理されるかが分散化されており、結果としてエンドツーエンドの分散化を実現している。

分散型APIについて

前世代の相互運用性ソリューションの問題点は、新しい視点に立つことでしか解決できないのです。目下の問題は、要するに分散型アプリケーションが従来のAPIプロバイダーからサービスを分散的に受けられないという問題なのです。
実際、今日の相互運用性ソリューションの主な用途は、中央集権的な取引所APIからDeFiアプリケーションにキュレーションされた資産価格を配信することであり、予測市場[20]やパラメトリック保険[21]などの新しい使用例はすべて同様の要件を持っています。
したがって、問題定義をこのようにさらに特定することで、実世界の相互接続ソリューションの次世代に到達することができるようになります。
この新しい問題定義は、分散型アプリケーションが特定のWeb APIサービスをブロックチェーンに提供し、これを完全に分散化されたコスト効率の良い安全な方法で行うことを意味しています。要件を決定することで、それを最適に満たす完全な製品を設計することができます。分散型API、略してdAPIは、APIプロバイダーが運営するファーストパーティーオークルのネットワークで、分散型の方法で管理されている。
これに対して、分散型相互運用ソリューションは、中央集権的なエンティティによって管理されるサードパーティのオラクルネットワークで構成されており、その問題定義が不十分であるために必要なものである。
視覚的な比較は図2を参照してください。

中間支援者としての第三者オラクルの問題点

既存のソリューションは、任意のシステムが、その技術的インターフェースを通じて別の任意のシステムと非常に一般的な意味で相互運用できる必要があるという抽象的な問題を想定しています。
この過剰な汎用性により、サードパーティのオラクルによってのみサポート可能な、常に柔軟なインターフェースが必要とされます。しかし、問題の実際的な範囲ははるかに制約が多いため、この解決策は最適とは言えません。
ほとんどの場合、分散型相互運用性問題とは、実際には、従来のAPIプロバイダーからサービスを分散的に受け取るという問題なのです。
このように問題をより限定的に定義することで、インターフェース経路にサードパーティの中間層を必要としない最適解を得ることができる。このセクションの残りの部分を通じて、相互運用性ソリューションの一部として中間業者に依存することの結果について説明します。

脆弱性（Vulnerability）

分散型オラクルネットワークは、オラクルの報告を1つの答えにまとめるために集約関数を使用します。この関数は本質的にコンセンサスアルゴリズムであり、すべてのコンセンサスアルゴリズムと同様に、ある比率の不正な行為者に対して影響を受けやすいものである。

つまり、悪意のあるオラクルの集団が結託して結果を歪め、完全にコントロールすることさえ可能なのである。さらに、一人の行為者が複数のオラクルノードオペレータの身元を捏造することができ、また、自分自身で同じ種類の攻撃を行うのに十分な誠実な操作の実績を築くことができるため、これはシビル攻撃として知られています[22]。
インターフェース経路に関係者の層が増えることの最も重大な欠点は、まったく新しい攻撃対象が形成されることです。つまり、追加された中間者の各層は、上述の共謀攻撃やSybil攻撃を独立して実行することができるようになるのです。
そうなると、セキュリティの観点からは、中間税を完全に排除することが究極の解決策となります。

中間税

オラクルは、正直に報告するか、誤った報告（サービスの拒否を含む）をするかというゲームをしています。
正直に報告することはペイオフの増分にしかならないが、オラクルはゲームを続けることができる。
一方、虚偽の報告をした場合、報告内容に応じて契約によって確保される価値に比例した一回限りのペイオフが発生するが、ゲームは終了する（図3参照）。そして、取引tiから始まるoracleが受け取ることができる最大累積ペイオフは

合理的なオラクルは、攻撃から得られる量が、攻撃を行わなかった場合に得られる潜在的な利益よりも大きい場合、最終的に誤報することになる。
つまり、ある合理的オラクルに対して以下が成立する場合、それは最終的に誤報となる。

• 時間選好理論[23]によれば、オラクルノード演算子は将来の報酬をより低く評価する（すなわち、viはiの増加とともに減衰する）。
• 実際には、オラクルが正直に行動してもゲームの継続は保証されず、このリスクは将来の報酬の価値をさらに低下させる。
• 例えば、オラクル・ソリューションの失敗で減価する資産のショート・ポジションを開くなど、攻撃を行うことで勘定に入らない追加的な利益があるかもしれない。

この不確実性のために、必要なviを過大評価する、つまり、攻撃しないためにオラクルに過剰な支払いをする必要があるのです。

このモデルは、分散型オラクルネットワークに拡張することができる。オラクルのレポートやその成果物はオンチェーンで記録されるため、共謀したオラクルに信頼なく報酬を与えるスマートコントラクトを実装することは些細なことです。これは、攻撃から利益を得ることができる第三者が、共謀した場合に決定論的な金額が支払われることを保証してオラクルを採用できることを意味します。
高レベルでのオラクルの仕事は、基本的に以下の通りです。(1)オンチェーンリクエストを聞き、(2)それぞれのオフチェーンAPIコールを行い、(3)レスポンスをオンチェーンに書き戻すことです。
したがって、サードパーティのオラクルは基本的に仲介役である。提供されるサービスは最小限であるが、上記の理由により、これらの仲介者はデータフィードによって確保される量に比例して支払わなければならず、DeFiのような高価値のユースケースでは特に問題となる。私たちはこの現象を “中間者税 “と呼んでいますが、サードパーティーオークルを避けることで完全に排除することができ、ユーザーにとって非常に大きなコスト削減となります。

効果的でない冗長性

サードパーティのオラクルに依存するデータフィードでは、オラクルレベルで過剰な冗長性が要求されます（図4参照）。これは、サードパーティのオラクルはAPIプロバイダよりもはるかに信頼性が低く、後者には伝統的なオフチェーンビジネスとそれぞれの評判を維持する必要があるからです。通常、各APIプロバイダーはこのようなデータフィードで2-3個のオラクルに提供される。
この分散化はデータソースレベルで追加のセキュリティを提供するものではなく、サードパーティのオラクルを使用することによって引き起こされる追加の脆弱性を減少させるだけであることに注意してください。残念ながら、この結果、運用コストが多くのレベルで増大することになります。例えば、データフィードは基本的にオラクルノードを操作するすべての技術者を雇用しており、これらのノードをより多く持つことは、より多くの人をサポートすることを意味します。
さらに、オラクルの数が増えれば、ガス代が直接的に増加する。具体的には、オラクルのリクエスト・レスポンスのガスコストはオラクルの数に対してリニアに増加し、組み合わせ演算を行う集計関数（medianなど）のガスコストは超リニアに増加する。

透明性の欠如

APIレベルの分散とオラクルレベルの分散は互いに独立しており、システム全体は2つのうちより中央集権的なもの、すなわち最も弱いリンクと同じだけ分散化されているに過ぎないのだ。しかし、一般市民や分散型オラクルネットワークの利用者ですら、この事実を見落とし、オラクルレベルの分散とシステム全体の分散を混同しているのが現状です。
これは主にオラクルが使用するデータソースに関する透明性の欠如が原因であり [24]、データソース（API）レベルで分散化が著しくボトルネックになっている事実を隠蔽しています。
サードパーティのオラクルで構成されたデータフィードは、実際よりも分散化されているように見えます。また、データフィードのデータソースが透明でない場合、開発者はデータフィードの完全性を評価することができず、運営主体を信用するしかない。しかし、データソースが透明でない場合、運営主体が低価格や利便性よりも品質を選ぶインセンティブはすぐに得られず、一般に「garbage in, garbage out」と呼ばれる結果になりかねない。

興味深いことに、運営主体にとって有利な戦術、すなわちデータソースの隠蔽は、サードパーティのオラクルにとっては非常に必要なことなのです。ほとんどのAPI利用規約はAPIデータの再販や無許可の配布を禁じており、このようなAPIを提供するオラクルノードオペレータは利用規約に違反し、APIプロバイダーからのクレームを含む幅広い法的責任を負う可能性がある[25]。
この問題は、APIの呼び出し時間、応答、支払のすべてがパブリックブロックチェーンに記録されることによって悪化する。これは個々のノード・オペレーターを訴訟リスクにさらすだけでなく、スケールで調整された法的措置が既存のサードパーティオークルを直ちに運用停止に追い込み、新しいオラクルが参加することを抑制するため、オラクルネットワーク全体にシステムリスクを生じさせることになる。
なお、データソースの透明性の欠如や抽象化は当たり前のことですが、全く必要ないわけではありません。特にAPIプロバイダーとエコシステムのインセンティブが一致している場合、APIプロバイダーの明示的な同意を得て、オラクルがユーザーにAPIデータを提供することは完全に可能であり、オラクルはそのデータソースをユーザーに開示することができる[3]。
これはAPIプロバイダーにとって有益であり、彼らのデータに対するオンチェーン需要を増加させるからです。

Airnode: A Node Designed for First-Party Oracles

ファーストパーティオークルは、API3ソリューションに不可欠なものです。つまり、各APIはサードパーティではなく、APIを所有するエンティティによって運営されるオラクルによって提供されるのだ。
このセクションでは、ファーストパーティーオラクルを使用する利点と、API3がどのようにAPIプロバイダがAirnodeで独自のオラクルを運用することを可能にするかを説明します。

Benefits of disintermediation

ファーストパーティオラクル、つまりAPIプロバイダー自身が運営するオラクルである。APIプロバイダーが自分自身のオラクルを操作するということは、スマートコントラクトプラットフォームのプロトコルレベルで彼らのプライベートキーで彼らのレスポンスに署名するということであり、これはデータが改ざんされていないことの最高の証明である。さらに、ファーストパーティーオラクルは、処理中のAPIからの生データを第三者が観察できないため、デフォルトでプライベートであり、より幅広いユースケースでネイティブに使用することができる。
ファーストパーティオラクルで構成されたデータフィードは、ミドルマンを採用したものと比較して、より費用対効果が高くなります。なぜなら、ミドルマンにそのサービスに対する対価とデータフィードを攻撃しないようにするインセンティブ（セクション 3.2 でミドルマン税と呼ばれる）の両方を支払う必要があるためです。
さらに、ファーストパーティのオラクルで構成されるデータフィードは、サードパーティからの攻撃から保護するためにオラクルレベルで過剰な分散化を必要としないので、より少ないオラクルを必要とします。各APIが少なくとも2つのサードパーティオラクルによって提供されると仮定すると、控えめに見積もっても、ファーストパーティオラクルによるデータフィードはガスコストの面で少なくとも50%効率が向上します。
また、ファーストパーティオークルは、データソースと分散化の度合いという点で、必要な透明性を提供します。各APIプロバイダーはオラクルを運用し、オンチェーンで見ることができます。オラクルとデータソースが一対一で対応するため、データフィードを提供するオラクルの数は、それがどれだけ分散化されているかを正確に表しています。さらに、APIプロバイダーはオフチェーンチャネルを通じてオンチェーンIDを公開するため、ユーザーはある時点で誰のデータを消費しているのかを確認することができる。

最後に、APIプロバイダーがオラクルを操作することで、APIサービスを第三者にライセンスする必要がなくなり、APIプロバイダーが全収入を受け取るため、セクション3.4で述べた法的問題を解決することができる。さらに、これはレントシーキング的な第三者のオラクル問題を解決し、重い仕事をこなしているグループ、APIプロバイダーに資金を振り向けることを可能にする。
APIプロバイダにインセンティブを与えることで、彼らの経済的利益とAPI3エコシステムの利益を一致させ、結果として両者の間に強い相互の結びつきを持たせることができるのだ。

データのオフチェーン署名

サードパーティのオラクルに依存しながらも、サードパーティにデータの改ざんをさせないハイブリッドなソリューションもあります。この方式では、APIプロバイダは自分のデータをオフチェーンで秘密鍵に署名し、通常のAPIエンドポイント上で提供する。サードパーティーオラクルはこのエンドポイントを呼び出して署名されたデータを取得し、チェーンにポストする。

データの信頼性-サードパーティのオラクルによって改ざんされていないこと-は、その後APIプロバイダの公開鍵を使ってオンチェーンで検証される[26]。
オラクルレベルでのデータ改ざんのリスクは排除されるものの、このソリューションは本質的に中途半端なものです。サードパーティのオラクルに依存することで、サードパーティのオラクルに依存することで生じるエコシステムの問題を抱え続け、さらに、オフチェーン署名を実装するためにAPI側で修正を必要とします。

この結果、通常のサードパーティーオラクルベースのソリューションと比較しても、APIの選択肢が著しく制限され、このソリューションのエコシステムの成長可能性がアプリケーションスケールに制限されることになります。

APIプロバイダがオラクルを運用する際の障壁

Honeycomb API Marketplace [19]での作業中、我々はAPIプロバイダーと広く連絡を取り、オラクルのオンボーディングと運用に以下のような障壁があることを確認した。

1. 従来のAPIプロバイダーは、一般消費者ほどブロックチェーン技術に精通していないのが普通です。これは、暗号通貨市場データのキュレーションを行う企業にも当てはまります。彼らの主な業務は、取引所のAPIからデータを収集し、それを処理し、その結果を自社のAPIで提供するというもので、ブロックチェーンに特化したノウハウは必要とされません。そのため、社内のリソースではオラクルノードを容易に運用することができないのが一般的です。
2. オラクルノードオペレーターの求人市場もない。仮に一部のAPIプロバイダーが、数少ないノードオペレーターを雇用して必要な特定のノウハウを入手したとしても、これはスケーラブルな解決策とは言えません。
3. オラクルノードの運用は工数やインフラコストなど多くのリソースを消費する。多額の補助金や将来の利益が保証されていない限り、オラクルノードの運用は金銭的に不可能である。
4. オラクルノードを運用するには、APIプロバイダーが暗号通貨で取引する必要がある。具体的には、ガス代を自国通貨（例えばETH）で支払い、1つ以上の暗号通貨で支払いを受けなければならない。これは、コンプライアンス、法律、会計上の理由から、大多数のAPIプロバイダーが失格となる。さらに、APIプロバイダーに資金の出資を求めるスキームも、同様の財務リスク関連の理由から、断固として拒否される。

Airnodeの特徴

Airnodeは、APIプロバイダが独自のオラクルを運用するために特別に設計された、完全サーバレスのオラクルノードです（図5を参照）。これはセクション4.2のオラクルノード関連の問題すべてに対処している。

1. 操作に特別なノウハウは必要ありません。実際、Airnodeは完全にセット・アンド・ゲットで設計されているため、運用と言うことすら難しい。
2. また、フルマネージドサーバーレス技術により、OSのアップデートやノードの稼働監視などの日常的なメンテナンスも不要です。また、ステイタスを持たないように設計されているため、恒久的なダウンタイムを引き起こし、ノードオペレーターの介入を必要とするような問題に対して非常に強い耐性を持っています。
3. また、オンデマンド型のサービスであるため、ノードオペレーターはノードが使用された分だけ課金されます。このため、APIプロバイダーは無料でオラクルを実行し、収益を上げ始めてから支払いを開始することができる。
4. また、ノードオペレータが暗号通貨を扱う必要は全くない。そのプロトコルは、要求者がすべてのガスコストをカバーするように設計されている。

Airnodeは、オーバーヘッドや支払トークンの摩擦なしにスマートコントラクトプラットフォームと通信することを可能にするWeb APIの軽量ラッパーであるという見方ができます。
APIプロバイダーから必要な関与のレベルについて、Airnodeを使用することは、サイドビジネスとしてブロックチェーンノードを操作するのではなく、ウェブ上でAPIにアクセスできるようにするAPIゲートウェイを利用することにたとえることができます。実際、私たちはAirnodeがAPIゲートウェイを使うのと同じくらいAPIにとってユビキタスでありふれたものになることを目指しており、それによって膨大な種類のファーストパーティオークルがAPI3から利用できるようになります。
APIプロバイダーは、可用性の高いインフラを構築するために多大なリソースを投じています。
そして、オラクルノードの実装には、ダウンタイムの原因となる単一障害点を含まないことが重要である。サードパーティ製オラクルを使用する既存のソリューションは、これをカバーするためにオラクルレベルでの過剰な冗長性に依存しており、3.3節で述べたように過剰なコストとなっている。API3は各APIがファーストパーティのオラクルによってのみ提供されることを想定しており、冗長性は個々のAirnodeのレベルで実装されなければならないことを意味する。ノードは完全なサーバレスであるため、単一のクラウドプロバイダの異なるアベイラビリティゾーン、あるいは複数のクラウドプロバイダにまたがっても、これを簡単に実行することができる。なお、Airnodeのコンテナ版をオンプレミスで運用することも可能ですが、ほぼすべてのユースケースでサーバーレス版の利用が推奨されます。
Airnodeは、MITライセンスでオープンソース化されており、ファーストパーティーオークルを使用することができます1。
API3は、Airnodeの開発資金を助成金で賄い、コア技術チームが現在のメンテナーを務めています。

Airnodeプロトコル

私たちがオラクル問題よりもAPI接続問題をよりよく規定することを好むのと同様に、オラクルノードは、想像しうるあらゆる目的に使用できると称するサンドボックスとしてではなく、APIとスマートコントラクトプラットフォームを非常にうまくインターフェースするように設計されるべきだと考えています。この哲学に基づいて、Airnodeプロトコルは、できるだけ透明で摩擦のないAPI-スマートコントラクトプラットフォームのインターフェースを実現するために、APIによって使用される自己創発パターンに従うように設計されています。

最初の、そして最も一般的に使用されるAPIスタイルは、ユーザーがパラメータでリクエストを行い、APIができるだけ早く応答する、リクエスト-レスポンスパターンに従っています。これは、同じパターンに従っている既存のAPIとの標準化と統合が容易であるため、Airnodeがサポートする最初のパターンとなります。
この方式の使用例としては、特定の試合の結果を配信するように要求し、それぞれの予測市場を解決するために使用することができます。
さらに、Airnodeは、パラメトリックな条件が満たされたときに特定のメソッドをコールバックするようにユーザーがオラクルに要求する、パブリッシュ・サブスクライブのパターンをサポートするように計画されています。
例えば、分散型取引所は、ETH価格が4000ドルを下回ると、レバレッジをかけたポジションを持つユーザーのために清算イベントをトリガーするようオラクルに要求することができます。
これらのパターンのいずれかを使用して、今日DeFiアプリケーションが使用するライブデータフィードを実装することができますが[2]、dAPIの形でより多くの多様なユースケースをサポートすることもできます。
セクション4.3で述べたように、Airnodeプロトコルは、リクエスト履行トランザク ションを含めて、すべてのガスコストを要求者が引き受けるように設計されてい る。
これは、各Airnodeが各リクエスタのために別々のウォレットを持つことによって達成されます。これは、暗号通貨取引所が自動的にユーザーのために資金を入金するためのウォレットを指定するのと似ています。
依頼者はこのウォレットに、一括または依頼ごとのマイクロトランザクションを通じて、ネイティブ通貨（ETHなど）で資金を供給します。このウォレット内の資金は、依頼主が行った次のすべての依頼を満たすために使用されます。
この方式には大きな利点があります。

• ガスコストや決済トークン価格（LINKなど）が変動するため、オラクルが収益性が高く、かつ競争力のある価格を設定することは事実上不可能です。オンチェーンで動的に価格を計算するには、複数のデータフィードが必要で、リクエストごとにかなりのガスのオーバーヘッドが追加されます。Airnodeプロトコルで、APIプロバイダーはガスコストを気にする必要がなく、毎月のサブスクリプション料金のような典型的な価格設定モデルを使用することができます。
• セクション4.2で述べたように、APIプロバイダーが日常業務の一環として不換紙幣を暗号通貨に変換し、ノードウォレットに資金を供給できることを期待するのは合理的ではありません。この方式では、ノードオペレータは自分のノードウォレットの残高について考える必要がない。
• Chainlinkデータフィードで最近行われた攻撃[27]に見られるように、リクエストを満たすために共通のウォレットを使用するオラクルノードは、攻撃者がウォレットを消耗させるためにリクエストをスパミングする影響を受けやすくなっています。これに対する解決策は、ノードオペレータが、リクエストを受け入れる 信頼できるアドレスのホワイトリストを維持することである。この状況では、どのコントラクトが信頼できるかを判断するのが難しいことに加え、このことは、あらゆる種類のパブリックリストサービスを実質的に実現不可能なものにしています。これは、わずかな独立したエコシステムの成長を足踏みさせてしまうという意味で、非常に重要な問題です。Airnodeは、要求者のウォレットがその要求者からの要求を満たすためにのみ使用され、他の人が流出することができないので、このタイプの攻撃の影響を受けません。
• 従来のオラクルノードは、非常に高いガス価格ですべての要求を満たす必要があり、低いガス価格で行われた単一のトランザクションによってトランザクションキューがブロックされることを許容できないためです。Airnodeプロトコルでは、各リクエスタが個別のトランザクションキューを持つため、これはもはや懸念事項ではありません。そして、タイムクリティカルでない要求者は、要求パラメータとして履行ガス価格を提供することができ、より低いガスコストでサービスを享受することができるようになるのです。この方式は、特にEIP-1559[28]と相性が良い。

最後に、Airnodeのプロトコルがどのようにマネタイズに取り組んでいるかについて簡単に触れておきます。

プロジェクト固有のトークンが必要であることを保証するために、プロトコルのコアに組み込まれるのが一般的です。しかし、これは重要なガス価格のオーバーヘッドを誘発し、代替のマネタイズオプションを著しく制限し、全体的な摩擦を生み出します。これらの理由から、Airnodeプロトコルは、意図的にそのようなトークンを使用しないようにしています。代わりに、ノードオペレータは、基本的に要求者がオンチェーンで実装することができる任意の基準に基づいて応答されるべきかどうかを決定する彼らのオラクルエンドポイントにカスタム承認者契約を関連付けることが許可されています。
認可者契約は、ホワイトリスト、ブラックリスト、月額サブスクリプションの支払い、またはコールごとの料金を強制するために使用することができます。この方式は非常に柔軟であり、ガスコストのオーバーヘッドを追加しない方法で実装されています。dAPIの収益化は完全に独立した問題ですが、Airnodeが提供する柔軟性は、例えば、既存のオラクルソリューションでは不可能な、ユーザーがすべてのガスコストを負担するdAPIを実装することが可能になることを引き継ぎます。

APIの統合

オラクルにAPIを統合する場合、鶏と卵の問題があります。
もしオラクルのエコシステムにAPIに対する既存の需要がなければ、誰も統合を行うインセンティブを得られない。統合されていないためにAPIが利用できなければ、誰も需要を生み出すようなアプリケーションを開発しない。これは Chainlink エコシステムの重要な摩擦点として特定され、Honeycomb API Marketplace が解決策として提案された[19]。ハニカムは多数のプレミアムAPIをChainlinkオラクルに統合しており、その結果、このマーケットプレイスは当時のどのオラクルエコシステムにもないAPIの多様性を提供していました。
ハニカムはユニバーサルな外部アダプタと、宣言的な方法でAPIをChainlinkオラクルに統合する新しい方法を使用し、コードを記述する必要がなかったのです。

この方法は、API操作ごとに外部アダプターを開発するよりも優れており [29]、その統合はより速く、エラーが起こりにくく、専門家でなくても行うことができます。
これらの独自ツールを使って、ハニカムは数ヶ月で何百ものユニークなAPI操作を統合することができ、最も近い競合他社を一桁も違わずに凌駕している。

API3がその潜在能力をフルに発揮するためには、新しいdAPIのセットアップや既存のdAPIの再構成が簡単にできるように、数千とは言わないまでも数百のファーストパーティーオークルが必要だ。
これは、APIがさらにスケーラブルな方法でAirnodeに統合される場合にのみ達成できます。
この目的のために、上記で説明した独自の統合ツールの改良版がAirnodeのためにオープンソース化されています。
OpenAPI仕様の形式を借りて、Oracle Integration Specifications (OIS)は、APIの操作、オラクルのエンドポイント、そして2つがどのようにお互いにマッピングするかを定義しています。Airnodeユーザーは、そのOISをノードに提供するだけで、そのオラクル上でAPIを提供することができます。
この標準化されたフォーマットで作られた統合は、収集、バージョンアップ、配布が非常に簡単です。
OISはJSONファイルで、主にAirnodeが使用する統合仕様を記述するために設計されています。これは、まず人間が読めることを目的としておらず、統合を指定するために手動で作成することは困難であることを意味します。この問題は、ChainAPIという統合プラットフォームによって解決され、ユーザーは使いやすいグラフィカルなインターフェースを通じて、APIのOISを生成することができるようになります。これは、ノードダッシュボードやエンドポイントを一覧できるマーケットプレイスなど、Airnodeユーザーの生活の質を向上させるための他の改善と一緒に行われる予定です。その結果、API3はdAPIを構成するファーストパーティのオラクルの幅広い選択肢を持ち、エコシステムの成長はもはや統合能力によってボトルネックになることはないだろう。

トークノミクスによるガバナンスの分散化

単一障害点とは、システムの重要な構成要素で、障害が発生した場合、それを補う冗長性がなく、システム全体が故障することである。
中央集権は単一障害点を生み出し、分散化はそれを排除することを目的としている。

ブロックチェーンベースのアプリケーションは暗黙のうちに分散化を主張していますが、大半はまだいくつかの側面、特にガバナンスにおいて中央集権的です[31]。
このセクションでは、中央集権的なガバナンスから生じる問題と、API3がうまく設計されたトークノミクスによる分散型自律組織（DAO）[32]によってこれらを解決する方法について説明します。

オラクルネットワークガバナンスを一元管理

分散型オラクルネットワークが中央集権的な主体によって設定可能である場合、そのガバナンスは中央集権的なものとなる。そのため、ガバナンスのミスに気付かず、基盤となるAPIやオラクルが正しく機能していても、データフィードが誤報を起こす可能性がある。例えば、チェーンリンク[15]の銀価格データフィードは、ヒューマンエラーによるガバナンスミスで一定期間、金価格を報告していました[33]。デリバティブの分散型取引所であるSynthetix [34]は当時このデータフィードを使用しており、その結果、一部のユーザーが利益のためにエラーを悪用することになりました[35]。中央集権的なガバナンスは、その本質的な不透明さゆえに、必然的にそのような結果をもたらす標準以下の手法の使用を可能にします。しかし
しかし、今回の事件が示したより顕著な問題は、中央集権的な管理組織は、その権限を利用して悪意を持って誤報を行うことができるということである。
管理主体は、データフィードを再構成する権限を持っています。これは、オラクルとそれぞれのデータソースを入れ替えたり出したりすることを意味します。これはデータフィードの長期的なメンテナンスのために必要ですが、データフィードのユーザーを統治主体による様々な悪用や攻撃にさらすことになります。そうなると、ユーザーは中央集権的な統治主体を信頼するか、データフィードの統治をセキュリティに有利なインセンティブを持つ分散型にするか、どちらかにしなければならない。
データフィードユーザーが中央の統治機関を完全に信頼できると感じる場合、分散型オラクルネットワークを使用することは不合理であり、統治機関が運営する中央集権のオラクルを使用する方がユーザーに良いサービスを提供できるだろう。

まず、セクション 3.1 で論じたように、この集中型オラクルは攻撃対象としてサードパーティのオラクルを持たず、より安全であると考えられる。さらに、多数のオラクルノードオペレータを調整することは困難であり、データフィード レベルの停止を引き起こすことがあるため、中央集中型のオラクルは可用性の点ではるかに優れたパフォーマ ンスを提供することになります[36]。最後に、このような集中型オラクルの運用コストは、オラクルネットワークよりもはるかに低くなるであろう。したがって、オラクルネットワークの中央集権的ガバナンスが正当化されるような状況は存在しないと、我々は主張する。

資金管理

ブロックチェーンプロジェクトの資金調達方法として、ICO（Initial Coin Offering）は一般的に、開発資金を開発チームに全面的に託すことが多い。これは表面上は賢明なのですが、トークン価格が投機的に上昇し、投資家が最初に託した金額よりもはるかに大きな金額を開発チームが支配することになると、この問題は解決されません。中央集権的なガバナンスが腐敗と強く結びついていることはよく知られているので[37]、これは、出口詐欺から、トークン価格をさらに操作するために開発資金が悪用され、持続不可能な成長に至るまで、ごまかしの結果につながる可能性を持っていると言えます。
このリスクは、残念ながら常態化している予算の透明性の欠如によって、より高まっています。技術開発資金に加え、プロジェクトによっては、さらにエコシステム開発資金を設けているものもあります。開発チームはエコシステムの一部に過ぎず、必ずしもエコシステムを代表し、全体としての利益を共有しているわけではないため、これらの資金の管理権を開発チームに与えることを正当化するのはさらに困難です。
DAICO（DAOとICOという用語の合併）は，これらの問題の解決策として提案されており，これは投資家のDAOが開発チームに俸給を割り当てるもので，DAOによって規制されたり，完全に切り離されたりすることもある[38]。
今日、DAOが成功裏に採用しているより柔軟なアプローチは、助成金によって開発全体を実施することです[39]。この方式では、DAOは開発チームを持たず、むしろやるべき仕事を持ち、その都度第三者と契約して仕事をさせます。これにより、通常、開発資金やエコシステム資金が実際の市場レートで正直に効率的に配分されます。

API3 DAO

dAPIとプロジェクト全体のガバナンスを分散化するため、API3はDAO2によって統治されています。
このガバナンスは完全に分散化されたオープンなもので、すべてのステークホルダーがプロジェクトのガバナンスに直接参加できることを意味する。
これは、API3トークンによって実現され、セクション5.4で説明したメカニズムによってAPI3 DAOに投票権を付与する。

DAO は、ステーキングインセンティブや担保設定などの仕組みに関するハイレベルなパラメータに投票します。さらに、DAOは助成金を授与し、その結果、プロジェクトの一般的な方向性を決定する。より細かいタスクは、スケーラブルなガバナンスのために、階層的なチーム構造を通じて行われます。
期待されるワークフローは、人々がオフチェーンチームを形成し、API3に利益をもたらす一回限りのプロジェクトや継続的なオペレーションを実行するために助成金を申請することである。
チームは、チームメンバーをユーザーとして割り当てたマルチシグ（例えばGnosis Safe [40]）で助成金申請を行い、助成金申請が受理されればDAOはマルチシグに資金を付与する。さらに、DAOは割り当てられたタスクに応じて、チームmultisigに特定の取引（例えば、個々のユーザーに対するdAPI利用料の設定など）を行う権限を与えることができます。重要な責任と大きな予算を伴うプロジェクトでは、チームメンバーは、その資格を確認し、潜在的なシビル攻撃を避けるために、実際の身分を開示しなければならないかもしれないことに注意してください。
テクニカルグラントのテーマの例を挙げると、以下のようになります。

• Airnode、dAPIコントラクト、API3 DAOコントラクトの技術開発
• API3のフロントエンド開発（ステーキング、保険など） API3エコシステムのプロジェクト開発
• 新規API、dAPIユーザー、スマートコントラクトプラットフォームの統合
• 特定のAPIやdAPIに対する統計的・定性的なリスク評価
• dAPIの管理
• 記事、チュートリアル、ビデオによる開発者への働きかけ
• 技術監査、セキュリティ監査
• バグバウンティプログラム、ハッカソンなどの立ち上げ

また、補助金によって実施される非技術的な業務も豊富である。

• 新規APIプロバイダー、dAPIユーザー発掘のための事業開発
• 特定のdAPIユーザーに対するサブスクリプションや保険の価格設定
• 業務・財務監査
• 決済処理
• UI/UXデザイン
• マーケティング
• 法律相談

このチーム型ガバナンスの仕組みは、DAOレベルで投票する議案が少ないため、ガスコストの面でもスケーラブルです。また、統治者全員が多種多様な細部に常に注意を払う必要がないため、実用面でもスケーラビリティがあります。さらに、dAPI管理などの重要な業務を、専門家の意見に基づき迅速に実行することが可能になります。API3運用の規模が拡大するにつれ、このガバナンス階層はさらなるレイヤーを要求する可能性があり、それはサブDAOを意味する（図6参照）。
このスキームが有効であるためには、DAOは2つの原則に従わなければならない。まず、悪意のある、あるいは無能なチームが引き起こすかもしれない損害の量を制限するために、そのチームが持つ権限は最低限に抑制されなければなりません。これは「最小特権の原則」としても知られています。
例えば、dAPI管理チームは、使用中のdAPIを完全に再コンパイルすることはできませんが、個々のオラクルの出し入れは、その権限が大きく乱用されないよう、十分なクールダウン期間を置いて行うことができるようにするだけでよいとします。同様に、マイルストーンや成果物も、その時々の具体的な責任を果たすために必要な資金のみをチームに与えるために利用されるべきです。
第二の原則は、透明性です。DAOがそのパフォーマンスを評価できるようにするために、チームはDAOに非常に詳細に報告しなければなりません。これらの報告には説明責任を果たすという利点もあり、dAPIユーザーや一般市民はAPI3の運営状況を常に監査できるようになります。

図6：メインDAO、サブDAO、チェーンに分散したチームからなる階層的なガバナンス構造の例。メインDAOは、選択的に資金を配分し、権限を委譲することで統治する。あるタスクがチームでは対応できない規模になると、サブDAOに割り当てられる。

API3 tokenomics

分権型ガバナンスには、プラスとマイナスの両方の結果を正確にモデル化する、バランスのとれたインセンティブ・メカニズムが必要である。言い換えれば、統治主体は良い結果には報酬を与え、悪い結果にはペナルティを与えるべきです。
API3トークンは、3つの主要なユーティリティを通じて、これを促進するように設計されている。

1. ステーキング。インフレの報酬を与え、API3のサービスと引き換えに、燃焼や時間ロックトークンなどのデフレのメカニズムでバランスをとる。
2. 担保。dAPIの不具合による損害からユーザーを守る保険サービスをバックアップする。
3. ガバナンス（Governance）。API3 DAOの直接の代表権を付与する。

ステーキング・ユーティリティは、API3に参加し、そのサービスの利用拡大に貢献することで、金銭的なインセンティブを与えるものである。担保ユーティリティは、API3の運用リスクを参加者が共有し、リスクを最小化するためのインセンティブを与える。最後にガバナンス・ユーティリティは、こうしたインセンティブを実現するための究極の手段を参加者に提供する。
なお、これら3つのユーティリティが一致することが重要である。すべての統治主体が、利用を最大化するような統治を行うためには、賭け金報酬を受け取らなければならない。
すべての統治主体がセキュリティリスクを最小化する方法で統治するためには、その資金が担保として使用されなければならない。このため、API3は単一のステーキングプールを持つことになる。
このプールでAPI3トークンをステークすることで、代行やステーク報酬が付与されるが、同時にステークされたトークンは必要に応じて保険金支払いの担保として使われる。

Staking

堅牢なコンセンサス・メカニズムは、実現された機能から得られる価値によって参加者に報酬を与え、ポジティブ・フィードバック・ループを生み出す。例えば、Ethereumはトラストレスアプリケーションを実現します。このようなアプリケーションの正しい動作を検証する採掘者は、ユーザーから支払われる取引手数料の全額を受け取ることができます。
我々の場合、API3のステーカーはプロジェクトを管理するコンセンサスメカニズムの参加者であり、dAPIのマネタイズの主要な受益者であることを意味する。この類推から、EIP-1559[28]に関する最近の研究は、我々のデザインに関連している。
最近のロンドンフォーク[41]まで、イーサリアムのユーザーは自分の取引がチェーンに含まれるように鉱夫に直接支払っていました。EIP-1559は、主に取引手数料に基づく採掘者のインセンティブ付与スキームが経済的な不安定さを引き起こしたことを提起しました[42]。
アップデートにより、ユーザーはネットワーク使用量に応じて変動する基本料金を支払うようになり、この料金は燃やされるようになりました。採掘者は取引手数料の全額を受け取る代わりに、安定したインフレ性のあるブロック報酬を受け取ります。(EIP-1559には、おじさんブロックやブロックサイズ制限といったイーサリアム特有の問題に対抗する優先料金メカニズムも含まれているが、このアナロジーでは直接対応することはない)。
ステイカーに収益を分配するDAOは、不安定さをもたらすという点で、EIP-1559以前のマイニング報酬に似ています。各収益分配イベントは、インセンティブという点で不連続なジャンプを生み出し、それが利益のために悪用されることになります。
例えば、ステイカーのグループは、dAPIの購読料を毎月ではなく毎年支払うよう提案し、購読料が支払われ収益が分配されると同時にステイキを解除することができます。この場合、長期参加者を罰するだけでなく、定期的な購読料の支払いによってステークされた総額は変動することになります。
問題がアナログであるのと同様に、解決策もアナログである。API3 DAO は、ユーザーがサービスを受けるために API3 トークンを燃やすかタイムロックすることを要求し、間接的にステーク報酬受領者に利益をもたらすデフレ・メカニズムを効果的に作り上げるだろう。
API3 サービスが利用されると API3 の供給が不足し、ステークホルダーだけでなく全てのトークン保持者に利益がもたらされる。つまり、ステーク報酬はAPI3トークン保有者の一定割合がステークするよう規制されるべきであり、それによってプロジェクトのガバナンスが確保され、保険商品の担保となる。
このため、API3 DAOはトークン総供給量に対するパーセンテージである「ステークターゲット」を設定する。毎週、報酬額は繰り返し更新されます。つまり、ステークされた額がステーク・ターゲットを下回ると増加し、その逆もまた然りです3。

堅牢なコンセンサス・メカニズムは、実現された機能から得られる価値によって参加者に報酬を与え、ポジティブ・フィードバック・ループを生み出す。
例えば、Ethereumはトラストレスアプリケーションを実現します。このようなアプリケーションの正しい動作を検証する採掘者は、ユーザーから支払われる取引手数料の全額を受け取ることができます。
ガバナンスの質は容易に定量化できないため、ステーク報酬によって優れたガバナンスをインセンティブすることは困難である。
例えば、一般的に参加することが望ましいとされていますが、既に可決されている議案に投票することはほとんどの場合冗長であり、積極的に棄権することは正当な姿勢であると言えます。
その解決策として、私たちは長期的な成果に対してのみ報酬を与えることにしています。具体的には、賭け金の報酬は毎週支払われますが、各支払いは丸1年後にのみ引き出しが可能になります。これにより、すべてのステークホルダーが1年後のトークン価格を最大化するために協力するインセンティブが生まれ、またこのリリースのローリング性により不安定さを防ぐことができるのです。

図7：API3トークンのステーキングと保険担保のユーティリティは、バランスのとれたガバナンスインセンティブをもたらす。
(a) より多くのユーザーでdAPIをロードすると、保険金支払いの可能性が高まり、負のフィードバックが発生し、システムのバランスが取れる。Bはループがバランスしていることを示す。
(b) システムがバランスしているため、dAPIの負荷は無制限に増えるわけではなく、DAOがdAPIがサポートできる最大負荷以下と推定したレベルに落ち着く。

担保

もしAPI3のステーキングで報酬しか得られないとしたら、唯一のガバナンスインセンティブは支払額を最大化することだろう。これは、dAPIのユーザー数を積極的に増やし、それに伴ってdAPIが確保する量を増やすことによって行われるでしょう。
セクション3.2において、我々はdAPIが受ける総負荷が攻撃による誤動作の可能性を高めることを示しました。したがって、これは分散型データフィードの持続可能なガバナンス戦略とは言えない。
私たちが避けようとしているリスクに統治者を晒すことは、彼らのインセンティブをDAOのそれと一致させることになります。それから、dAPIの誤動作が発生したときに、統治当事者にペナルティを与える必要があります。
私たちはさらに一歩進んで、dAPIユーザーに定量的で信頼性の高いセキュリティ保証を提供するオンチェーン保険サービスを設計しました。
この保険サービスは、API3トークンのステーキングプールを担保としており、紛争解決プロトコルを通じてdAPIの不具合が確認された場合、ユーザーの損害はステーキングプールからカバーされることになります。
この保険サービスの実装方法については、第6章を参照されたい。
ステーキングプールを担保とガバナンスの両方に利用した場合の効果を、図7aのシステム図で見てみよう。DAOが追加リスクを許容する場合、新しいdAPIユーザーを受け入れ、dAPIの負荷が増加する。
その結果、dAPIの故障確率、保険金支払いの可能性、そして全体的な担保リスクが増加します。担保リスクの増加により、DAOのリスクアペタイトが抑制される。つまり、保険サービスによる負のフィードバックが、自己破壊的な成長を防ぐのである。このことから予想されるdAPI負荷の挙動については、図7bを参照してください。DAOはdAPIの障害閾値を推定し、この値に収束するようにユーザーを搭載しますが、それを超えないようにします。なお、DAOがこの閾値を過大評価した場合、dAPIは誤動作し、影響を受けたdAPIユーザーによる保険金の支払いに賭け金が使われるため、管理者は処罰されることになります。
つまり、どちらの場合でもdAPIユーザーは保護されるのです。

Governance

API3 DAOで代表権を得る唯一の方法は、保険担保プールにAPI3トークンを出資することである。そのため、統治者はAPI3のすべてのリスクと報酬にさらされ、それらを最適化するように統治することになる。
インフレ報酬と、ステークされたガバナンストークンが担保として使われることで、ガバナンスの質という点でポジティブなフィードバックループが生まれます。トークン保有者は、インフレで価値を失いたくないのであれば、ステークしてリスクに晒す必要がある。
ガバナンスを誤り、保険金請求によって担保を失った場合、これらのトークンは公開市場に戻され、そこから新しいガバナンスパーティが獲得することになる。一方、最初のトークン保有者がうまく統治し、市場でトークン不足を引き起こした場合、代表権の分配は保護されることになります。
つまり、ガバナンス・トークンが担保として使われることで、自ら改善し、失敗から回復することができる強固なダーウィン的構造が生まれる。

保険による定量的な安心感

API3は、dAPIユーザーにオンチェーン保険サービスという形で定量的なセキュリティを提供します。これは2つの目標を達成するものです。(1）保険は、dAPIが誤動作した場合に、ユーザーにとって明確に定義された信頼できないセーフティネットとして機能する、（2）dAPIの誤動作に対して管理者に責任を持たせ、より安全なdAPIに向けて管理するよう動機付けるのです。

定量的なセキュリティの必要性

エンジニアリングとは、我々が完全に理解していない材料を、正確に分析できない形状にモデリングし、我々が適切に評価できない力に耐えられるようにし、我々の無知を疑う理由がないようにする芸術である。

Dr. A. R. Dykes

もし、技術者に「あなたの橋はどれくらいの荷重を支えることができますか」と尋ねたときに、「最高品質の鋼鉄を使った21本の梁があると断言できます」という答えが返ってきたら、その橋は使いたくないですよね。最大荷重を提供できないのは、技術的に赤信号なのですから。セクション3.2では、単一のオラクルとその派生であるデータフィードがどの程度サポートできるかの単純化されたモデルを紹介しました。

網羅的ではないが、このモデルは分散型オラクルネットワークが任意に大きな金銭的価値を確保できないことを実証している。オラクルによって安全に確保される金額は、境界を設けなければならない。つまり、全てのブロックチェーン技術と同様に、分散型オラクルネットワークは無条件に信頼できるものとして扱われるのではなく、ある範囲までしか信頼されるべきでない[43]。そして、データフィード-中央集権型[44]または分散型[15]-は、それが確保できる量を定量化する責任を負うべきである。
この問題に対する最もよく認識された解決策の1つは、UMAプロトコル[45]について提案されています。
提案されたスキームは、ゲーム理論の原理を使用してデータフィードによって確保できる量の定量化を可能にするだけでなく、この限界を正確に設定することも可能にします。
著者らは、過度に安全なデータフィードはユーザーにとって不必要にコストがかかるため望ましくなく、セキュリティの程度を最小限の要件に設定できればコストを削減できると鋭く指摘している。
しかし、彼らはこの後、自分たちが提案した方法が最適なコスト効率であると主張するが、これは実際には極めて不正確である。この間違いは、データソースを無視した方法で問題に取り組むこと、つまりAPI接続問題ではなく、オラクル問題を解決しようとすることに起因します。提案されたソリューションは、すべてのオラクルが信頼できないと考える場合にのみ、最適なコスト効率となります。これは、サードパーティのオラクルに対して十分に近似したものです。
一方、ファーストパーティーオラクルの信頼性を利用すれば、APIプロバイダーが攻撃を試みても失うものが多すぎるため、非常に低コストで極めて安全なデータフィードを構築することができます。
信頼できる単一の中央集権的な取引所から提供されたデータによって、高価値のDeFi製品がうまく保護されていることは、この事実を非常によく証明しています[44]。したがって、実証された信頼性を無視し、実際にコスト効率の良いソリューションに行き着くことは望めません。

API3のビジョンに沿った理想的なソリューションは、オフチェーン情報によってのみ評価可能なAPI提供者の信頼性を引き出し、定量的なセキュリティ保証を提供することである。
そのためにAPI3は、dAPI利用者に対して、故障による損害をあらかじめ決められた金額まで保証する保険サービスを提供する。ゲーム理論的な解決策では、モデル化されていないインセンティブや計算されていないインセンティブにより、予期せず失敗する可能性があるため、この解決策はユーザーにとって望ましいものです。

dAPI保険

5.1 節で、Chainlink 社のデータフィードが Synthetix 社に誤報告したセキュリティインシデントに言及した。この事件では、事件当日にChainlink社から4万ドル弱の損害が発生し[33]、翌日にはSynthetix社から約36,000ドルの損害が発生したと報告されています[35]。
さらにその後、Synthetix社はChainlink社から損害賠償の申し出があり、それを受け入れたと発表している。
この事件は、次のようなことを実証している。

1. 損害賠償を行う保険は、データフィードの不具合に対する当然の解決策である。
2. データフィードの不具合は、運営主体が責任を負うと一般的に理解されています。
3. データフィードの不具合とその原因、その結果生じる損害を数日で特定することが可能。

この事件は、表面的には何ら問題なく解決した。この事件は、表面的には何の問題もなく解決したように見える。
しかし、両プロジェクトが一元的に管理されているため、一般市民や関係者は正確な和解内容を知ることができない。そこで、「もし損害賠償額が桁違いに大きかったらどうなっていたのか？
完全な分散型プロジェクトは、そのような事態にどのように対処すればよいのだろうか？
保険の利用はマクロ経済の成長と相関があるばかりでなく、その原因でもあることが示されている[46]。
それにもかかわらず、保険はブロックチェーン空間ではほとんど利用されていません。その主な理由の一つは、保険は当然ながら保険紛争の解決に第三者を必要とし、この目的のために相互に信頼できる第三者を利用することは、分散化の精神に反するということです。しかし、Kleros[5]という汎用的なオンチェーン紛争解決プロトコルが登場したことで、信頼性の高い保険商品を構築することが可能になったのです。

API3は、Klerosと共同でオンチェーン保険サービスを開発し、dAPIユーザーに定量的で信頼性の高いセキュリティ保証を提供する予定です。この保険サービスは、特定のdAPIの不具合による損害から、支払限度額までdAPIユーザーを保護するものです。なお、我々がこのサービスを提供しない場合でも、dAPIユーザはサードパーティソリューション[47]を用いてオンチェーン保険サービスを受けることが可能であった。
そのようなソリューションでは、dAPIのリスクを正確に評価するための情報や専門知識を利用できないため、非常に高い保険料を請求する傾向があります。
さらに、セクション 5.4.2 で述べたように、提案された保険サービスは、API3 DAO の運営当事者によって賭けられた資金によって担保されるという点で特別である。したがって、dAPI利用者にセキュリティ保証を提供するだけでなく、dAPIのセキュリティが最大化されるようにガバナンスされる非常に強いインセンティブを生み出し、保険コストをさらに低下させることができます。

保険の手続き

ユーザーはdAPIへの加入を要求し、オフチェーンチャネルを通じてそれぞれのサービスに対する特定の保険金を受け取ることができる。
カバーできる総額は担保プールのサイズによって制限され、DAOは既存の保険ソルベンシーに関する文献[48]に基づいて担保比率を管理することになります。各API3チームは、dAPIの誤作動リスクとユーザーの特定のユースケースを調査し、保険料を計算し、支払いを管理するコントラクトにユーザー固有の手数料を入力します。保険料を契約者に支払うことで、dAPIユーザーはdAPIにアクセスできるようになり、各支払い期間の保険に加入する。

dAPIユーザーは、故障に気づいた場合、損害賠償を請求し、オンチェーン保険に加入することになります。
ステークの引き出しには十分なリードタイムがあるため、ステーカーがフロントランニング請求、つまりdAPIが故障するとすぐに引き出し、請求を回避することを防ぐことができます。一方、被保険者は、不正使用を抑制するために、請求ができるように資金をステークする必要があります。API3 DAOは、クレームを直接支払うか、クレームをクレロス裁判所にエスカレートさせ、クレーム額がdAPIユーザーに支払われるかどうかを判断します。
請求が受理されると、トークンはdAPIユーザーに譲渡されることになります。
これは、ステークホルダーがステークした額に比例して損害賠償を負担することに相当し、つまり、プール全体のp%を占めるトークンをステークしたユーザーは、認められた請求のp%を支払うことになります。

上記のスキームでは、すべての金額がAPI3トークン建てであることを想定している。
ユースケースによっては、他の暗号通貨タイプ、例えばETHで保険をかける必要があるユーザーもいるかもしれない。この場合、流動性供給者が自動的にETHに変換するだけでは、請求から支払いまでの間にAPI3/ETHの為替レートが変動し、スリッページが発生するため、十分とは言えません。解決策として、API3 DAOは追加のETHリザーブ（担保プールと同じソルベンシー考慮の対象）を維持し、価格変動を吸収して、支払いがユーザーが当初請求した金額を満たすことを保証することができます。

Risk Assessment

データフィードが提供できるセキュリティの量を定量化することは、非常に難しい問題である。
しかし、この問題を保険という確立された領域に組み込むことで、従来の保険サービスから容易に調達可能な様々な文献やスキルを利用することができます。したがって、API3は、アクチュアリー、統計学者、データサイエンティスト、レートメーカー、アナリスト、法律家などのサービスを十分に活用し、定量的なセキュリティ保証という難題に挑むことができるのです。
リスク評価は、保険料の最適化や正しいソルベンシーの見積りを行うために不可欠なステップです。これには主に2つの要素が含まれます。

• 内部 dAPIの誤動作はどの程度あるのでしょうか？
• 外的要因 dAPIが故障した場合の損害賠償の期待値は？

ここで最も重要な内部リスク要因は、オラクルレベルでの障害であり、これは個々のAPIを定性的に調査し、そのパフォーマンスを統計的に分析することで推定することができる。例えば、定性的な調査によって、あるAPIプロバイダーは5年前から事業を展開しており、重大なシビルアタックリスクにはならないと結論付けることができる。同様に、統計的な分析により、APIプロバイダーから提供されるデータがしばしばコンセンサスと乖離することが示されるかもしれない。これは、データ利用者が高い精度を要求する場合に問題となる可能性がある。
これらの評価は、APIプロバイダーの数と選択に関するdAPIを設計する際の指針にもなる。例えば、過負荷のdAPIにさらにAPIを追加すれば、保険リスクを減らすことで結果的にコストを削減できることが分かる。
運用リスクも重要な要素であり、これは運用プロセスを調査する監査によって評価することができる。この調査はAPI3チームによって行われ、DAOに公に報告されるので、ユーザーに比類のない透明性とセキュリティ保証を提供することになることに注意してください。
外部リスク要因は、不具合が発生した際の損害賠償の期待値を決めるものであり、データがどのように利用されているかが重要なポイントになる。

図8を参照してください。ここでは、様々な仮想的なDeFiアプリケーションにおけるデータエラーのコストを図解しています。
図8aでは、dAPIが通常の取引所に価格データを提供し、エラーが発生した場合、取引当事者の利益と損失は直線的に比例します（損失のみを考慮していることに注意してください）。これを図8bと比較すると、レバレッジをかけたポジションをサポートする同様の取引量を持つ取引所が表示されます。この場合、虚偽の報告によって損害が発生する可能性ははるかに大きくなります。最後に、ユーザーがショートポジションを建てた図8cをご覧ください。
報告されたデータのわずかな上方への傾きは、清算の引き金となり、不釣り合いな影響を引き起こす可能性があります。これらの例は、特定のユーザーがdAPIから受け取るデータを具体的にどのように使用するかを考慮しなければ、保険リスクを見積もることはできないことを示している。
また、保険にはより定性的な側面もある。具体的には、API3とdAPIユーザーが保険契約書に合意し、dAPIの不具合とは何か、損害賠償額の算出方法などの用語を定義する。クレロス陪審員は、この保険証券を参考にしながら、保険金が支払われるかどうかを判断することになる。
具体的な条件は、保険料がどのように決定されるかについて重要である。

例えば、ダウンタイムに対する保険よりも、あらゆる故障をカバーする保険の方が割高になる。

ソリューションと保険の規模を拡大

DeFiが普及するような価値の高いユースケースは、イーサリアムのネットワークが混雑する原因となります。その結果、取引手数料が増加し、データフィードの運用コストに影響する。そうなると、dAPIサービスを適正なコストで提供するために、スケーリングソリューションを活用できることが重要になる。
既存の分散型オラクルソリューションは、オフチェーンスケーリングソリューションを使用することを提案しています[15,16]。しかし、これらのソリューションは、ユーザーが正確に評価することができない不明瞭なセキュリティの影響を伴います。まず、スケーリングソリューションは一般的にセキュリティ保証が緩い傾向にあり、ユーザーがその結果をしっかりと理解することを期待するのは妥当ではありません。さらに、カスタム暗号関数の実装に伴うセキュリティ問題、セカンドレイヤーソリューションのサービス拒否など、運用上のリスクも追加される。その結果、ユーザーはスケーリングソリューションに依存したデータフィードの利用を危惧すると考えるのが妥当だろう。

dAPI保険は、その柔軟性により、この問題に対する予想外の解決策として登場しました。
API3 DAOが、あるユースケースに対してスケーリングソリューションが合理的に信頼できると判断した場合、それぞれのdAPIはそのスケーリングソリューションを利用でき、その保険はスケーリングソリューションに起因する潜在的な損害をカバーすることになる。

最終的に重要なのは、サービスがdAPIユーザーに正しく提供されるかどうかであるため、保険請求プロセス全体はまったく同じように機能します。

結論

API3は、分散型アプリケーションと従来のWeb APIが提供する豊富なデータやサービスを接続し、分散性を犠牲にすることなくブロックチェーンの適用可能性を拡大します。
これはdAPI-完全に分散化されたブロックチェーンネイティブなAPI-によって実現され、API3 DAOによってスケールアップして設定、管理、収益化されることになる。
API3ソリューションは、デザインによって様々な品質を体現している。dAPIは、代替ソリューションで常に重要なリスク要因となっているサードパーティのオラクルに依存しない。
また、dAPIの保険サービスは、ユーザーに対して定量的で信頼できるセキュリティ保証を提供し、API3が分散型アプリケーションとしてAPIサービスを受けるための最も安全なソリューションであることをさらに強固なものにしています。

API3ソリューションの2つ目の品質は、複数レベルでの堅牢性です。Airnodeはサーバーレス技術を採用しており、ダウンタイムに対して高い耐性を持つ。
バグやネットワークの悪条件に影響されにくいステートレスノード設計と組み合わせることで、API3オラクルは堅牢性を高めるよう設計されている。さらに、dAPIは、よく設計されたインセンティブによってリスクと報酬のバランスを自己調整するDAOによって管理され、堅牢なリスク軽減の枠組みを提供します。

dAPIは中間業者を排除することで、3つ目の品質であるコスト効率を付与しています。
dAPIは中間業者税を支払う必要がありません。これは、第三者のオラクルに攻撃を試みないようにインセンティブを与えるために支払われるものです。
また、ファーストパーティーオラクルで構成されるデータフィードは、オラクルレベルでの過剰な冗長性を必要としません。より少ないオラクルで同レベルの分散化を実現することで、dAPIは非常に大きなガスコスト削減を実現します。
最後に、API3ソリューションは、ガバナンスの完全な分散化により柔軟性を実現し、実際にゲームに参加する関係者に提供します。その結果、このプロジェクトは、この論文に書かれていることに決して制限されることなく、新しい課題やニーズに応えるために常に進化していくことでしょう。
第一世代の分散型アプリケーションは、ブロックチェーンの枠内に限定されていました。今日では、限定的かつ擬似的にオフチェーンの世界と対話できる分散型アプリケーションが登場しています。API3は次の進化の波、つまり真に分散化され信頼を最小化する方法でAPIを活用し、オフチェーンの世界と価値ある相互作用をする分散型アプリケーションの第3世代を後押しするものです。

https://drive.google.com/file/d/1GzkLKc6DYxImgeDhoKLA4wHGlE0eGGgo/view