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 プロトコルに関する深い理解が必要です。

中間層は、信号などのオラクル原語で構成されています。ホワイトリストに登録されたユーザーは、対応する信号を読むことができます。ETHDenver のために構築された Amberdata Beacons は、良い例です。Beacons は Airnode プロトコルの上に構築されていますが、この事実はユーザーから抽象化されており、彼らは自分たちが使用する Beacon をサポートする特定の Airnode プロトコルに関する情報を理解する必要はありません。

私たちが構築する最上層のソリューションは dAPI です。リアルタイムデータフィードのユースケースでは、dAPI は Beacon またはより高レベルのインターフェースでラップされた Beacon のセットです。ホワイトリストに登録されたユーザーは、バックグラウンドで使用する Beacon を指定することなく、対応する dAPI を読むことができます。言い換えれば、dAPI を使用することで、ユーザーはデータフィード内の各 Beacon の管理責任を軽減できます。

このモジュラーアーキテクチャの目標は、ユーザーが作業に最も適したツールを選択できるようにすることです。ターンキーで一度限りのオラクルソリューションが必要な場合、彼らは 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 空間を追いつかせることです。