オラクル

暗号資産におけるオラクルとは？

オラクルとは、外部データ、オフチェーン情報、現実世界の出来事をブロックチェーンアプリケーションに取り込み、スマートコントラクトがオンチェーンに保存されていない情報を利用できるようにするシステムです。

暗号資産では、オラクルが資産価格、金利、準備金証明、気象データ、スポーツの結果、本人確認情報、乱数、クロスチェーンメッセージ、支払い確認など、スマートコントラクトに必要なデータを提供する場合があります。

Ethereumのオラクルのドキュメントでは、スマートコントラクトは初期設定ではオフチェーン情報にアクセスできず、外部データをオンチェーンで利用できるようにするにはオラクルが必要だと説明されています。

これは、ブロックチェーンがすべての検証ノードで同じ方法により確認できるデータに基づいて合意を形成するよう設計されているためです。

スマートコントラクトが必要に応じて通常のWebサイトのAPIを直接呼び出すことはできません。ノードごとに異なる結果、異なるタイミング、または応答なしとなる可能性があるためです。

オラクルは、ブロックチェーン外でデータを収集、確認、整形、署名し、ブロックチェーンが処理できる形でスマートコントラクトに届けることで、この問題を解決します。

暗号資産におけるオラクルの最も一般的な用途は、DeFiでの価格データです。

融資プロトコルでは、担保が安全な状態にあるか、強制決済すべきかを判断するために価格オラクルが必要となる場合があります。

デリバティブプロトコルでは、市場価格に基づいて契約を決済するためにオラクルが必要となる場合があります。

ステーブルコインシステムでは、担保の評価やリスク管理のためにオラクルが必要となる場合があります。

オラクルがなければ、多くのスマートコントラクトはブロックチェーン内にすでに存在するデータしか扱えません。

オラクルがあれば、スマートコントラクトは市場、出来事、外部世界のデータに応じて動作できます。

オラクルの要点

• • オラクルはスマートコントラクトを外部データやオフチェーンの出来事につなぎます。
  • スマートコントラクトは初期設定では通常のWeb APIや非公開データベースに直接アクセスできないため、オラクルが必要です。
  • DeFiにおけるオラクルの最も一般的な用途は価格フィードです。
  • オラクルは、融資、デリバティブ、ステーブルコイン、保険、トークン化資産、予測市場、ゲーム、自動化、クロスチェーンアプリケーションを支援できます。
  • オラクルには、中央集権型、分散型、許可型、パーミッションレス、ファーストパーティ、サードパーティ、プッシュ型、プル型、ハイブリッド型があります。
  • 不正確なデータによってスマートコントラクトが誤った判断を自動的に実行する可能性があるため、オラクルのリスクは重大です。
  • 価格オラクルの操作は、OWASPが主要なスマートコントラクトセキュリティリスクとして挙げています。
  • 優れたオラクル設計では、複数のデータソース、強固な検証、透明性の高い手法、更新ルール、フォールバックロジック、監視を利用します。
  • オラクルがオフチェーンデータを魔法のようにトラストレスにするわけではありません。
  • オラクルは、ブロックチェーンのロジックと外部世界の間に、信頼と検証のレイヤーを構築します。

ブロックチェーンにオラクルが必要な理由

スマートコントラクトは設計上、外部世界から隔離されているため、ブロックチェーンにはオラクルが必要です。

この隔離により、ブロックチェーンの決定性が保たれます。

決定性とは、誠実な各ノードが同じトランザクションを実行し、同じ結果に到達できることを意味します。

コントラクトが任意のWebサイトを直接呼び出せる場合、ノードごとに異なる回答を受け取る可能性があります。

あるノードはデータを遅れて受け取るかもしれません。

あるノードはWebサイトによってアクセスを拒否されるかもしれません。

あるノードは操作された応答を受け取るかもしれません。

こうした状況は、ブロックチェーンの有用性を支える共通の合意を損なうおそれがあります。

オラクルは、オフチェーン情報とオンチェーンでの実行をつなぐ、管理された橋渡しの仕組みを構築します。

外部情報をスマートコントラクトが読み取れるオンチェーンデータに変換します。

オラクルの仕組み

オラクルは通常、データのリクエストまたは定期的なデータ更新から始まります。

オラクルは、ブロックチェーン外の1つ以上のソースから情報を収集します。

データソースには、市場、データプロバイダー、API、センサー、サーバー、報告者、バリデーター、その他のブロックチェーンネットワークなどがあります。

オラクルは設計に従ってデータを確認、フィルタリング、集約、検証します。

次に、結果に署名するか、オンチェーンのコントラクトに送信します。

スマートコントラクトはオラクルの値を読み取り、独自のロジックに利用します。

たとえば融資コントラクトは担保価格を読み取り、借り手のポジションが健全かどうかを判断できます。

デリバティブコントラクトは決済価格を読み取り、最終的な支払額を決定できます。

ゲームコントラクトは乱数を読み取り、結果を決定できます。

オラクルの品質は、データソース、更新ルール、セキュリティモデル、インセンティブ、障害対応の品質によって決まります。

オラクル問題

オラクル問題とは、過度な信頼、操作リスク、単一障害点を持ち込まずに、現実世界のデータをブロックチェーンに取り込む課題です。

ブロックチェーンはデジタル署名、残高、スマートコントラクトのルールを検証できます。

しかし、オラクルから情報が提供されない限り、現実世界の価格、気象情報、法的な出来事、スポーツの結果が正しいかどうかを独自に検証することはできません。

つまり、スマートコントラクトが分散型であっても、完全に分散化されていないデータソースに依存する場合があります。

オラクルが誤っている、更新が遅れている、操作されている、またはオフラインの場合、スマートコントラクトが誤って実行される可能性があります。

金融コントラクトが価格データに基づいて自動的に動作することが多いため、オラクル問題は特にDeFiで重要です。

誤った価格によって、不適切な強制決済、不公正な取引、誤った支払い、プロトコルの債務超過が発生する可能性があります。

オラクル問題の解決とは、通常、信頼を完全になくすことではなく、信頼への依存を減らすことです。

強固なオラクルシステムは、不正確なデータの提供を高コストにし、検出しやすく、悪用しにくくすることを目指します。

オラクルの種類

暗号資産には、いくつかの種類のオラクルがあります。

インバウンドオラクルは外部データをブロックチェーンに取り込みます。

アウトバウンドオラクルはオンチェーンデータやスマートコントラクトのイベントを外部システムに送信します。

ソフトウェアオラクルは、API、Webサイト、データベース、市場データシステムなどのデジタルソースからデータを収集します。

ハードウェアオラクルは、センサー、スキャナー、チップ、インターネット接続機器などの物理デバイスからデータを収集します。

ヒューマンオラクルは、個人や機関による結果の報告に依存します。

クロスチェーンオラクルは、ブロックチェーン間で情報を中継します。

計算オラクルは、オンチェーンで直接実行するとコストが高い、または現実的でない処理を実行または検証します。

乱数オラクルは、ゲーム、抽選、NFTのミント、その他のアプリケーションに利用できる、予測困難で検証可能な乱数を提供します。

価格オラクルは、取引、融資、担保、強制決済、決済に使う資産価格を提供します。

実際のオラクルシステムの多くは、こうした仕組みを複数組み合わせています。

価格オラクル

暗号資産で最も広く利用されているオラクルは価格オラクルです。

価格オラクルは、資産または取引ペアの価値をスマートコントラクトに報告します。

DeFiの融資市場では、担保価値の計算に価格オラクルが使われます。

デリバティブプラットフォームでは、契約の決済や証拠金の管理に価格オラクルが使われます。

ステーブルコインシステムでは、担保や債務比率の監視に価格オラクルが使われます。

Vaultやストラクチャード商品では、持分、手数料、リバランスのトリガーを計算するために価格オラクルが使われる場合があります。

価格オラクルは複数の市場からデータを取得し、結果を集約する場合があります。

更新しきい値、ハートビート間隔、サーキットブレーカー、信頼度の確認を組み込む場合もあります。

Pyth Networkの価格フィードのベストプラクティスでは、価格フィードの不確実性をプロトコルが把握しやすくするため、価格と信頼度の値を利用する方法が説明されています。

優れた価格オラクルは、価格だけでなく、現在の市場環境におけるその価格の信頼性もプロトコルに伝える必要があります。

データフィード

データフィードとは、スマートコントラクトに最新または直近の情報を提供する定期的なオラクル更新です。

データフィードは、価格、金利、指数、準備金、気象情報、ボラティリティの値、その他の測定値を配信する場合があります。

Chainlinkの分散型データモデルのドキュメントでは、データフィードを、コンシューマー、プロキシ、アグリゲーターのコントラクト要素からなる分散型オラクルネットワークとして説明しています。

コンシューマーコントラクトはデータを読み取ります。

プロキシコントラクトは、現在のアグリゲーターを参照できます。

アグリゲーターコントラクトは、報告された値を保存し、更新します。

このような設計は、開発者によるアップグレードやデータ利用を容易にする場合があります。

データフィードが有用なのは、スマートコントラクトが外部サーバーを直接呼び出さずに、公開済みの最新値を読み取れるためです。

ただし、フィードの堅牢性は、データソース、オラクルノード、集約ロジック、ガバナンス管理の品質に左右されます。

開発者は高価値のロジックに利用する前に、フィードがどのように更新されるかを理解する必要があります。

プッシュ型オラクルとプル型オラクル

プッシュ型オラクルは、一定の条件が満たされるとオンチェーンに更新を送信します。

たとえば価格フィードは、価格が設定されたしきい値を超えて変動した場合や、最大時間間隔が経過した場合に更新されます。

プル型オラクルでは、ユーザーやアプリケーションが必要なときに最新の署名済みデータをオンチェーンに取り込みます。

プッシュ型オラクルは、最新値がすでにオンチェーンで利用できるため便利な場合があります。

プル型オラクルは、ユーザーやアプリケーションが必要とする場合にのみデータを送信するため、不要なオンチェーン更新を減らせる場合があります。

多くのコントラクトが同じ公開値を頻繁に読み取るプロトコルには、プッシュ型システムが適している場合があります。

市場の動きが速く、ユーザーが最新の署名済みデータを自分のトランザクションとともに送信できる場合は、プル型システムが適している場合があります。

どちらの設計にもトレードオフがあります。

開発者はデータの鮮度、コスト、レイテンシ、セキュリティ、ガス使用量、障害モードを比較する必要があります。

中央集権型オラクル

中央集権型オラクルは、主に1つのデータソース、運営者、または信頼された報告経路に依存します。

この設計はシンプルで高速にできます。

一方で、1つの障害がアプリケーション全体に影響するため、危険を伴う場合があります。

中央集権型のソースがオフラインになると、スマートコントラクトが重要なデータを得られなくなる可能性があります。

中央集権型のソースが侵害されると、コントラクトに誤ったデータが届く可能性があります。

中央集権型の運営者が手法を変更すると、ユーザーの想定とは異なる動作になる場合があります。

信頼の前提が明確に開示される場合、中央集権型オラクルは低価値の実験、社内ツール、アプリケーションで許容されることがあります。

1つのデータ経路が金融上の結果を左右するため、高価値のDeFiシステムでは通常、リスクが高くなります。

ユーザーがその信頼前提の安全性を検証できない限り、中央集権型オラクルをトラストレスと宣伝すべきではありません。

ユーザーは、オラクルを誰が管理し、その関係者に障害が起きた場合に何が起こるかを必ず確認してください。

分散型オラクル

分散型オラクルは、複数のノード、データソース、報告者を使って、1つの運営者への依存を減らします。

目的は、オラクルの信頼性を高め、操作を困難にし、単独の悪意ある行為者による障害の可能性を減らすことです。

分散型オラクルは、複数の独立したソースからデータを収集する場合があります。

複数のオラクルノードに署名済みの観測値の送信を求める場合があります。

中央値、加重平均、信頼区間、その他の手法で値を集約する場合があります。

誠実な報告を促すため、経済的インセンティブ、ステーキング、評判、ペナルティを組み込む場合があります。

分散化によってオラクルリスクを軽減できますが、完全になくすことはできません。

すべてのノードが似たデータソースに依存している場合、共通のソース障害にさらされる可能性があります。

チェックなしにガバナンスがフィードをすぐ変更できる場合、ユーザーはガバナンスリスクに直面する可能性があります。

集約方法が不十分であれば、流動性の低い市場で攻撃者がフィードを悪用する可能性があります。

ファーストパーティとサードパーティのオラクル

ファーストパーティオラクルは、データの元となる情報源自体が運営します。

たとえば、市場データプロバイダーや発行者が、スマートコントラクト向けに署名済みデータを直接公開する場合があります。

サードパーティオラクルは、他の情報源からデータを収集、検証、中継します。

ファーストパーティオラクルでは、データが情報源そのものから提供されるため、データライセンスや解釈に関する問題を軽減できる場合があります。

ただし、1つの情報源が回答を管理している場合、信頼上の懸念は残ります。

サードパーティオラクルは複数の情報源を組み合わせ、データを集約または検証できます。

ただし、サードパーティの管理体制が弱い、または手法が不明瞭な場合はリスクが生じます。

一部のオラクルシステムは、ファーストパーティのデータと分散型の検証または集約を組み合わせます。

最適なモデルは、用途、リスクにさらされる価値、データの種類、更新速度、法的要件によって異なります。

開発者は、すべての課題に最適なオラクルの種類が1つだけあると考えるべきではありません。

オンチェーンオラクル

オンチェーンオラクルは、すでにブロックチェーン上に存在するデータを利用します。

たとえば、プロトコルが自動マーケットメイカーのプール価格、時間加重平均価格、ステーキング率、ブロックデータ、トークン残高を利用する場合があります。

オンチェーンデータはすでにブロックチェーン環境内にあるため、スマートコントラクトから簡単にアクセスできます。

ただし、オンチェーンデータも操作される可能性があります。

流動性の低いプールの価格は、大口取引によって一時的に動かされる場合があります。

フラッシュローンにより、1回のトランザクション中に価格を歪めるための資金を調達できる場合があります。

時間加重平均価格は短期的な操作リスクを軽減できますが、期間、流動性、情報源の設計が不十分であれば、依然として脆弱です。

AMM型オラクルの操作コストに関する最近の研究では、流動性の厚みや集約方法が、オンチェーン価格オラクルの操作コストにどう影響するかが検討されています。

オンチェーンオラクルは透明性が高いものの、透明性が自動的に安全性を意味するわけではありません。

操作に必要な経済的コストが、リスクにさらされる価値に対して十分に高い必要があります。

オフチェーンオラクル

オフチェーンオラクルは、ブロックチェーン外から情報を収集します。

情報源には、取引所、データプロバイダー、企業システム、Web API、ハードウェアデバイス、決済ネットワーク、公式記録などがあります。

オラクルは署名済みのトランザクションまたはデータコミットメントを通じて、結果をオンチェーンに取り込みます。

多くの重要な事実は自然にはオンチェーンに存在しないため、オフチェーンオラクルが役立ちます。

例として、法定通貨の為替レート、現実資産の価格、気象事象、コモディティ価格、準備金証明、スポーツの結果が挙げられます。

課題は、オフチェーンデータが正確であることを証明することです。

オラクルは、複数の情報源、暗号署名、監査、評判、経済的インセンティブ、紛争解決システム、透明性の高い報告によって対応する場合があります。

オフチェーンオラクルの設計では、速度、信頼、コスト、信頼性のバランスを取ることがよくあります。

操作が容易であれば、高速なオラクルでも役に立ちません。

非常に安全なオラクルであっても、アプリケーションに対して更新が遅すぎれば適切ではない場合があります。

クロスチェーンオラクル

クロスチェーンオラクルは、ブロックチェーン間でデータ、メッセージ、状態を中継します。

あるチェーン上でイベントが発生したことを、別のチェーンに伝える場合があります。

クロスチェーン融資、流動性の移動、トークン移転、ガバナンス、アプリケーション間の連携を支援する場合があります。

暗号資産の活動が多数のネットワークに分散しているため、クロスチェーンオラクルは重要です。

ただし、クロスチェーンオラクルの設計は複雑で、リスクを伴う場合があります。

メッセージが遅延、順序変更、検閲されたり、チェーンごとに異なる解釈を受けたりする可能性があります。

セキュリティは、バリデーター、リレーヤー、マルチシググループ、ライトクライアント、証明、外部ネットワークに依存する場合があります。

チェーン間におけるオラクル抽出可能価値に関する2026年の研究は、オラクル更新のタイミングの差が、投機的な強制決済行動の機会につながる可能性を指摘しています。

これは、クロスチェーンオラクルのリスクが正確性だけの問題ではないことを示しています。

タイミング、レイテンシ、誰が先に行動できるかも関わります。

乱数オラクル

乱数オラクルは、スマートコントラクトに予測困難な値を提供します。

乱数は、ブロックチェーンゲーム、抽選、NFTの属性割り当て、バリデーターの選定など、公平な不確実性が必要なアプリケーションで役立ちます。

安全な乱数をオンチェーンで直接生成するのは困難です。

Solidityのグローバル変数のドキュメントでは、ブロックタイムスタンプやブロックハッシュが、ブロック生成者によってある程度影響を受ける可能性があると警告しています。

そのため、高価値の結果に対する安全な乱数として、単純なブロック値を使うべきではありません。

乱数オラクルは、検証可能なランダム関数やCommit-Reveal方式などの暗号技術を利用する場合があります。

目的は、乱数が生成される前は予測困難にし、提供後は検証可能にすることです。

不適切な乱数によって、攻撃者が結果を予測または操作できる可能性があります。

ゲームやNFTのミントでは、弱い乱数が公平性やユーザーの信頼を損なう可能性があります。

金融システムでは、弱い乱数が直接的な経済損失につながる可能性があります。

準備金証明オラクル

準備金証明オラクルは、発行者、カストディアン、プロトコル、金融商品の保有資産に関する情報を報告します。

暗号資産では、準備金証明によって、トークン、ラップド資産、ステーブルコイン、担保型商品が報告された資産によって裏付けられているかをユーザーが把握しやすくなる場合があります。

準備金証明オラクルは、ウォレット残高、カストディに関する証明、銀行記録、資産評価、その他の準備金情報を報告する場合があります。

ブロックチェーン上の残高は公開されているため、オンチェーンの準備金はオフチェーンの準備金より検証しやすい場合があります。

オフチェーンの準備金については、監査人、カストディアン、銀行、法的文書、報告システムへの追加の信頼が必要です。

準備金証明は有用ですが、すべてを証明するわけではありません。

負債を示さずに資産だけを示す場合があります。

特定時点の残高を示しても、継続的な支払能力を証明するとは限りません。

ユーザーが完全には確認できない法的・運用上の管理に依存する場合があります。

準備金証明オラクルは完全な保証ではなく、リスクを判断するための1つのシグナルとして捉えてください。

自動化オラクル

自動化オラクルは、一定の条件が満たされるとスマートコントラクトの操作を実行するためのトリガーとなります。

こうしたシステムは、Keeper、自動化ネットワーク、実行ボットと呼ばれることもあります。

スマートコントラクトは、適切なタイミングで関数を呼び出す外部の実行者を必要とする場合があります。

たとえば、コントラクトがVaultのリバランス、強制決済の実行、オークションの決済、報酬の更新、期限切れ市場の終了を必要とする場合があります。

コントラクトはルールを定義できますが、トランザクションを送信する主体は依然として必要です。

自動化オラクルは条件を監視し、必要に応じてトランザクションを送信する役割を担います。

自動化によって手作業を減らし、信頼性を高められる可能性があります。

一方で、タイミング、ガス、インセンティブに関するリスクが生じる可能性もあります。

自動化が失敗すると、プロトコルが想定どおりに更新されない場合があります。

自動化が過度に中央集権化されていると、1つの運営者が重要なタイミングを管理する可能性があります。

DeFi融資におけるオラクル

DeFi融資プロトコルは、オラクルに大きく依存しています。

融資市場では、担保資産と借入資産の価値を把握する必要があります。

担保価値が必要な安全水準を下回ると、プロトコルは強制決済を認める場合があります。

オラクル価格が高すぎると、担保が不十分でもリスクの高い借り手が強制決済を免れる可能性があります。

オラクル価格が低すぎると、健全な借り手が不当に強制決済される場合があります。

このため、価格オラクルの信頼性は融資の安全性に直結します。

融資プロトコルでは、保守的な担保係数、強制決済バッファー、価格フィードの検証、緊急時の管理機能を利用することがよくあります。

流動性が低い資産や、信頼できる価格データがない資産の上場を避ける場合もあります。

オラクル設計はリスク管理と切り離せません。

借り手と貸し手の安全性、プロトコルの支払能力に直接影響します。

デリバティブにおけるオラクル

暗号資産デリバティブでは、契約の決済や証拠金の管理にオラクルが必要です。

無期限契約や先物形式の契約では、インデックス価格が必要となる場合があります。

オプション契約では、決済価格、ボラティリティデータ、満期データが必要となる場合があります。

合成資産では、外部資産の価値を追跡するためにオラクルが必要となる場合があります。

オラクルが誤っていると、トレーダーへの支払いが不正確になる可能性があります。

オラクルの更新が遅れると、強制決済が早すぎたり遅すぎたりする場合があります。

オラクルを操作できる場合、攻撃者が他のユーザーの損失を利用して利益を得る可能性があります。

そのため、デリバティブプロトコルには、堅牢な価格ソース、明確な手法、代替策、監視が必要です。

レバレッジが高くなるほど、オラクルの品質が重要になります。

レバレッジを利用したポジションでは、小さな価格誤差が大きな金融上の影響をもたらす可能性があります。

ステーブルコインにおけるオラクル

ステーブルコインシステムでは、担保の評価、市場価格の監視、償還ロジックの管理、リスク管理のトリガーにオラクルを利用する場合があります。

担保型ステーブルコインでは、発行した債務を支えるのに十分な担保価値があるかを把握する必要があります。

アルゴリズム型またはハイブリッド型のシステムでは、ペッグの状態や市場シグナルを追跡するためにオラクルを使う場合があります。

ペッグへのストレスは急速に発生する場合があるため、ステーブルコインのオラクルには信頼性が必要です。

古い価格データはリスクを見えにくくする可能性があります。

操作された価格は不公正な措置を引き起こす可能性があります。

価格データが欠落すると、重要な機能が停止する場合があります。

ステーブルコインシステムは、重要な判断を1つの脆弱なデータソースだけに依存すべきではありません。

流動性、市場ストレス、準備金、償還手段、法的リスクも考慮する必要があります。

オラクルは価格を報告できますが、ステーブルコインの安全性を保証することはできません。

オラクルの操作

オラクルの操作とは、攻撃者がスマートコントラクトの信頼するデータ経路を変更、歪曲、または悪用することです。

OWASPの価格オラクル操作に関するガイダンスでは、外部データフィードに依存するコントラクトにとって、これは重大な脆弱性だと説明されています。

DeFiでは、借入、貸付、スワップ、強制決済、担保計算に使われる価格を操作しようとする攻撃がよく見られます。

攻撃者は、流動性の低いプールで取引し、スポット価格を動かす場合があります。

フラッシュローンを使い、一時的な価格変動のための資金を用意する場合があります。

更新頻度が不十分な古い価格を悪用する場合があります。

単一の情報源だけを信頼するプロトコルを狙う場合があります。

チェーンやフィード間のタイミングの違いを悪用する場合があります。

不正なデータが受け入れられると、スマートコントラクトが誤ったロジックを自動実行する可能性があるため、オラクル操作は危険です。

コントラクト自体が悪意を持つわけではありませんが、現実を認識する基盤が改ざんされています。

古いオラクルデータ

古いオラクルデータとは、現在の市場状況に対して安全に使うには古すぎるデータです。

公表時点では正確な価格でも、市場が急変した後は危険な値になる場合があります。

古いデータを使う融資プロトコルは、担保を誤って評価する可能性があります。

古いデータを使うデリバティブプロトコルは、不公正な契約決済を行う可能性があります。

古いデータを使うステーブルコインプロトコルは、必要なリスク対応が遅れる場合があります。

データのタイムスタンプや更新時刻が利用可能な場合、データ利用者はそれらを確認する必要があります。

重要なフィードについて、許容できる最大データ経過時間を定める必要があります。

データが古い場合にコントラクトがどのように動作するかを決めておく必要があります。

対応策として、一部の操作を停止する、代替フィードを使う、リスクバッファーを広げる、トランザクションを拒否する方法などがあります。

古いデータが常に誤りとは限りませんが、高価値の処理に使うには不確実性が大きすぎる場合があります。

オラクルのレイテンシ

オラクルのレイテンシとは、現実世界の出来事が発生してから、その情報をオンチェーンで利用できるようになるまでの遅延です。

レイテンシは、データ収集、集約、署名、トランザクションの送信、ブロックへの取り込み、承認から生じる場合があります。

市場の動きが速いシステムや強制決済に敏感なシステムでは、低レイテンシが重要です。

日次報告、ガバナンス上の出来事、長期的な指数など、更新の遅いデータでは高レイテンシが許容される場合があります。

信頼性を高めたり、操作リスクを減らしたりするのであれば、レイテンシが必ずしも悪いとは限りません。

たとえば、時間加重価格は更新が遅くなるものの、単一ブロックでの操作が難しくなる場合があります。

適切なレイテンシはアプリケーションによって異なります。

高頻度取引ツールでは、非常に新しいデータが必要となる場合があります。

長期的な担保報告では、速度より監査可能性が重視される場合があります。

開発者は、コントラクトの経済的リスクに合わせてオラクルのレイテンシを設定する必要があります。

オラクル抽出可能価値

オラクル抽出可能価値とは、オラクルの更新前後に行動することで取得できる価値です。

たとえば価格更新によって借り手のポジションが強制決済の対象となる場合、サーチャーは更新直後に強制決済トランザクションを送信しようとする可能性があります。

サーチャーがオラクル更新のタイミングを予測、観察、フロントランできる場合、優位に立つ可能性があります。

トランザクションの順序やタイミングによって、誰が機会を得るかが決まるため、これはMEVと関連しています。

EthereumのMEVのドキュメントでは、ブロックへのトランザクションの取り込み、除外、順序変更によって価値が抽出される可能性があると説明されています。

オラクル更新によって価格、強制決済の対象となる条件、担保比率、裁定取引の条件が変わるため、新たなMEVの機会が生じる場合があります。

クロスチェーンオラクルでは、あるチェーンが別のチェーンより先に情報を受け取る可能性があり、さらに複雑になります。

プロトコルは、オラクル更新のタイミングによって誰が利益を得るのか、ユーザーが不公正な執行にさらされていないかを検討する必要があります。

したがって、オラクル設計は市場構造の設計でもあります。

安全なオラクルシステムでは、データの正確性だけでなく、データが届くタイミングも考慮する必要があります。

ガス代とオラクル更新

オラクルの更新にはブロックチェーントランザクションが必要な場合が多く、ガス代やネットワーク混雑の影響を受ける可能性があります。

Ethereumのガスのドキュメントでは、ユーザーが基本手数料を支払い、トランザクションを早く取り込んでもらうために優先手数料を追加できると説明されています。

ネットワークが混雑すると、オラクル更新のコストが高くなる場合があります。

更新へのインセンティブが弱い場合、データが古くなる可能性があります。

オラクル更新をめぐって多くのユーザーが競合すると、ガス代が急騰する可能性があります。

オラクルシステムには、市場のボラティリティが高い局面でも適時に更新するための十分なインセンティブが必要です。

市場のボラティリティが高い時こそ、プロトコルが最も正確な価格を必要とするため、これは特に重要です。

開発者は、平常時だけでなくネットワーク混雑時にオラクル更新がどのように動作するかをテストする必要があります。

通常の状況で機能するフィードでも、市場がストレスにさらされた際に失敗する場合があります。

優れたオラクル設計には、ストレス時の対応計画が含まれます。

オラクルのセキュリティに関するベストプラクティス

リスクにさらされる価値が大きい場合は、独立した複数のデータソースを利用します。

流動性の低い単一の取引プールを価格ソースとして使うことは避けます。

適切な場合は、中央値などの堅牢な集約方法を利用します。

タイムスタンプを確認し、古いデータを拒否します。

極端な価格変動に備えてサーキットブレーカーを使用します。

オラクルの不確実性が高い場合は、保守的な担保係数を設定します。

オラクルの更新を監視し、フィードの遅延や異常を検知した場合にチームへ通知します。

不適切なフォールバックは新たな攻撃経路となる場合があるため、慎重に設計します。

ボラティリティ、ネットワーク混雑、流動性の低い状況でオラクルの動作をテストします。

ユーザーや監査人がリスクモデルを理解できるよう、オラクルに関する前提を文書化します。

オラクルに関する一般的なリスク

最も大きなリスクの1つ目は、不正確なデータです。

2つ目は、古いデータです。

3つ目は、データソースの操作です。

4つ目は、オラクルノードの障害です。

5つ目は、不十分な集約です。

6つ目は、ガバナンスの乗っ取り、または安全でない設定変更です。

7つ目は、クロスチェーンの遅延です。

8つ目は、オラクル更新をめぐるMEVです。

9つ目は、データ欠落への対応が不十分なことです。

10個目は、オラクルが信頼を完全になくすと考えることです。

ユーザーがオラクルを評価する方法

オラクルがどのようなデータを提供するか確認します。

データがどこから取得されるか確認します。

データがどれくらいの頻度で更新されるか確認します。

複数の情報源を利用しているか確認します。

データがどのように集約されるか確認します。

データが古くなったり利用できなくなったりした場合の対応を確認します。

誰がオラクルをアップグレードまたは停止できるか確認します。

オラクルの公開ドキュメントや監視情報があるか確認します。

オラクルにどれほどの価値が依存しているか確認します。

オラクルの設計がプロトコルのリスクに見合っているか確認します。

オラクルとトークン化された現実資産

トークン化された現実資産は、その価値や状態がオフチェーンの事実に依存する場合があるため、オラクルが必要になることがよくあります。

トークン化された債券では、金利、支払い状況、満期日、発行者情報が必要となる場合があります。

トークン化されたコモディティでは、価格データ、カストディデータ、保管情報が必要となる場合があります。

トークン化された請求書では、支払い確認が必要となる場合があります。

トークン化された不動産商品では、評価額、所有権記録、法的な出来事に関するデータが必要となる場合があります。

こうした用途では、法的な事実や物理的資産の検証はオンチェーン残高の検証より難しいため、オラクル設計が複雑になります。

オラクルがカストディアン、監査人、管理者、銀行、裁判所、公式登録機関に依存する場合があります。

この仕組みによってトークン化資産の有用性が高まる一方、信頼やコンプライアンスに関する前提も増えます。

ユーザーは、オラクルが何を証明し、何を証明しないのかを理解する必要があります。

オラクルはオフチェーンの事実を報告できますが、それだけで弱い法的主張を確かなものにすることはできません。

オラクルとAIデータ

暗号資産アプリケーションの中には、AIに関連する出力や検証済みの計算結果を配信するためにオラクルを使うものもあります。

オラクルは、モデルのスコア、計算の証明、コンテンツ分類、本人確認情報、リスクスコアなどを報告する場合があります。

こうした仕組みは、自動コンプライアンス、ゲーム、予測市場、レピュテーションシステム、データ駆動型スマートコントラクトを支援できます。

モデルの出力は確率的で、偏りがある、または検証しにくい場合があるため、AI関連のオラクルデータには特別な注意が必要です。

スマートコントラクトは、すべてのAI出力を客観的な真実として扱うべきではありません。

開発者は必要に応じて、許容する信頼度、人による異議申し立て手段、フォールバックロジック、人間による確認を定める必要があります。

ブロックチェーンがオフチェーン計算と接続するにつれて、AIオラクルの重要性が高まる可能性があります。

同時に、透明性と監査可能性の必要性も高まります。

データの主観性が高いほど、オラクルを慎重に設計する必要があります。

外部から得たすべての回答が、取り消せないスマートコントラクトのロジックに適しているわけではありません。

オラクルの用途

オラクルは、DeFi融資で担保を評価するために使われます。

デリバティブで契約を決済するために使われます。

ステーブルコインでペッグや担保の状態を監視するために使われます。

保険型アプリケーションで出来事を検証するために使われます。

予測市場で結果を報告するために使われます。

ゲームで乱数を提供するために使われます。

NFTで動的メタデータや公平なミントを支援するために使われます。

トークン化資産で、トークンとオフチェーン記録をつなぐために使われます。

クロスチェーンアプリケーションで、メッセージや状態を中継するために使われます。

自動化システムで、時間に敏感なコントラクト関数を実行するために使われます。

オラクルのメリット

オラクルの大きなメリットの1つは、スマートコントラクトの用途を広げられることです。

オラクルがなければ、多くのコントラクトはオンチェーンの残高や内部状態に利用範囲が限られます。

2つ目のメリットは自動化です。

スマートコントラクトは、その都度人が手動で介入しなくてもデータに反応できます。

3つ目のメリットはコンポーザビリティです。

複数のアプリケーションが同じデータフィードを利用し、関連するサービスを構築できます。

4つ目のメリットは透明性です。

オラクルの更新やコントラクトの反応をオンチェーンで確認できる場合があります。

5つ目のメリットは、プログラム可能なリスク管理です。

プロトコルはデータフィードを利用して、担保、証拠金、決済、緊急時の管理機能を扱えます。

DeFiが単純なトークン送金を超えて機能できる大きな理由の1つがオラクルです。

オラクルの限界

オラクルは真実を保証するものではありません。

特定の設計、情報源、手法に基づいてデータを報告します。

誤り、遅延、操作、利用不能が生じる可能性があります。

信頼された関係者が重要な設定を変更できる場合、ガバナンスリスクが生じる可能性があります。

オフチェーンデータが規制対象の機関や非公開契約に依存する場合、法的リスクが生じる可能性があります。

データ報告によって機密性の高い活動が明らかになる場合、プライバシーリスクが生じる可能性があります。

更新によって利益機会が変わる場合、MEVが生じる可能性があります。

頻繁な更新が必要な場合、ガス代が増加する可能性があります。

設計が不十分だと、単一障害点になる可能性があります。

オラクルは強力なインフラですが、完璧な真実の情報源ではありません。

オラクルを利用する開発者向けのベストプラクティス

リスクにさらされる価値に合ったオラクルを選びます。

金融ロジックには高品質なデータソースを使います。

価格を使う前に、データが最新であることを確認します。

異常な価格変動に備えてサーキットブレーカーを使用します。

重要な担保ロジックには、流動性の低い市場の単一ブロックのスポット価格を使わないようにします。

適切な場合は、時間加重価格または分散型フィードを使います。

緊急事態が起きる前にフォールバックロジックを設計します。

オラクル設定を変更できる管理者権限を制限します。

コアとなるプロトコルロジックだけでなく、オラクル統合コードも監査します。

デプロイ後もフィードを継続的に監視します。

ユーザー向けのベストプラクティス

プロトコルがオラクル設計を説明しているか確認します。

単一で不明瞭なデータソースに依存するプロトコルには注意してください。

新規上場資産や流動性の低い資産には特に注意してください。

ボラティリティの高い担保を使って借り入れる前に、強制決済リスクを理解します。

オラクル価格が、常に実際に取引可能な市場価格と同じだと思い込まないでください。

フィードの停止、古いフィード、異常な価格更新に注意します。

オラクルリスクが不明確な場合は、ポジションを小さくします。

多額の資金を預け入れる前に、プロトコルのリスク文書を読みます。

プロトコルのセキュリティ評価の一部として、オラクルの品質を考慮します。

オラクルに関するよくある誤解

よくある誤解の1つは、オラクルは通常のAPIと同じだというものです。

通常のAPIはWebアプリケーションにデータを提供しますが、オラクルはスマートコントラクトが安全に利用できる方法でデータを配信する必要があります。

もう1つの誤解は、分散型オラクルは常に安全だというものです。

分散化は役立ちますが、不適切な情報源、集約、ガバナンス、統合の問題は解決しません。

3つ目の誤解は、価格オラクルが常にユーザーの実際の取引価格を示すというものです。

オラクル価格は、約定可能な価格ではなく、指数、中央値、遅延した値、集約値の場合があります。

4つ目の誤解は、オラクルリスクの影響を受けるのは開発者だけだというものです。

オラクルシステムが機能しなくなると、ユーザーは強制決済されたり、不当に少なく支払われたり、過剰請求されたり、コントラクトの失敗にさらされたりする可能性があります。

5つ目の誤解は、オラクルデータが最終的な真実だというものです。

オラクルデータは、特定の信頼モデルに基づいて報告された値です。

オラクルを一言で表すと

オラクルは、暗号資産アプリケーションが自らのネットワーク外の情報に対応できるよう、外部データ、現実世界の出来事、オフチェーン計算、クロスチェーン情報をスマートコントラクトに届けるブロックチェーンインフラです。

FAQ

暗号資産におけるオラクルとは何ですか？

オラクルとは、ブロックチェーンが直接アクセスできない外部データやオフチェーン情報をスマートコントラクトに提供するシステムです。

スマートコントラクトにオラクルが必要なのはなぜですか？

スマートコントラクトは初期設定では通常のWebサイト、API、データベース、現実世界のシステムを直接呼び出せないため、オラクルが必要です。

価格オラクルとは何ですか？

価格オラクルとは、融資、デリバティブ、ステーブルコイン、スワップ、担保、決済のロジックに使う資産価格をスマートコントラクトに報告するものです。

オラクルは分散型ですか？

分散型のオラクルもありますが、データソース、ノード構成、集約方法、ガバナンスによって、中央集権型またはハイブリッド型のものもあります。

オラクル問題とは何ですか？

オラクル問題とは、過度な信頼、操作リスク、単一障害点を生じさせずに外部データをブロックチェーンに取り込む課題です。

オラクルは操作される可能性がありますか？

はい。データソースが脆弱な場合、流動性の低い市場の価格が使われている場合、更新が古い場合、またはスマートコントラクトが危険なデータ経路を信頼している場合、オラクルは操作される可能性があります。

古いオラクルデータとは何ですか？

現在の市場状況に対して安全に利用するには、十分な頻度で更新されていないデータです。

分散型オラクルネットワークとは何ですか？

分散型オラクルネットワークは、複数のノード、情報源、報告者を使って、単一の運営者やデータ経路への依存を減らします。

DeFiでオラクルは何に使われますか？

担保価格の算定、強制決済、ステーブルコインシステム、デリバティブの決済、Vaultの会計、保険のトリガー、市場指数などに使われます。

オラクル抽出可能価値とは何ですか？

オラクル更新の前後に行動することで取得できる価値です。特に、更新によって価格、強制決済の対象となる条件、裁定取引の機会が変わる場合に生じます。

オラクルなしでもスマートコントラクトは動作しますか？

はい。オンチェーンデータだけを利用し、外部情報を必要としないスマートコントラクトはオラクルなしでも動作します。

ユーザーはオラクルリスクをどのように判断できますか？

データソース、更新頻度、分散化の程度、集約方法、フォールバックロジック、監視体制、フィードに依存する価値を確認して判断できます。

結論

オラクルは、スマートコントラクトを同じブロックチェーン上にないデータにつなぐため、現代の暗号資産アプリケーションに不可欠なインフラです。

DeFi融資、デリバティブ、ステーブルコイン、トークン化資産、予測市場、保険、ゲーム、自動化、クロスチェーンアプリケーションを可能にします。

オラクルの価値は、スマートコントラクトに価格、出来事、準備金、乱数、外部システムなどのデータを利用できる形で提供することにあります。

リスクは、スマートコントラクトがオラクルの報告内容に基づいて自動的に動作する可能性があることです。

オラクルのデータが正確で、最新かつ安全であれば、アプリケーションは想定どおりに機能できます。

オラクルのデータが誤っている、古い、遅延している、または操作されていると、アプリケーションはブロックチェーンの速度で有害な判断を下す可能性があります。

そのため、オラクル設計は単なる付随的なデータ機能ではなく、スマートコントラクトのセキュリティの一部として扱う必要があります。

強固なオラクルシステムは、信頼できる情報源、分散型の報告、堅牢な集約、明確な更新ルール、サーキットブレーカー、監視、慎重な統合を取り入れています。

脆弱なオラクルシステムは、壊れやすい単一のデータソースに依存し、古いデータを無視し、流動性の低い価格を信頼する、または市場ストレスへの備えを怠ります。

オラクルが外部データを魔法のようにトラストレスにするわけではないことを、ユーザーは理解する必要があります。

オラクルは、信頼を最小化したブロックチェーンのロジックと、複雑な外部世界をつなぐ橋を構築します。

暗号資産プロトコルを評価する際は、オラクルの品質を重要な要素として捉えることが最も安全です。

開発者にとって、適切なオラクル統合は、操作、不公正な強制決済、決済の失敗、プロトコル損失の防止に役立つ可能性があります。

ユーザーがオラクルを理解すれば、価格、強制決済、スワップ、自動化されたコントラクト操作がそのように動作する理由を把握できます。

オラクルによってスマートコントラクトの機能は強化されますが、データ設計を慎重に行う重要性も高まります。

暗号資産では、コントラクトの信頼性は、コントラクトが信頼するデータの信頼性に左右されます。