レッスン1

オラクルとその進化の理解

このモジュールでは、オラクルが解決する中核的な問題、つまり孤立したブロックチェーンを実世界のデータと接続することを紹介します。オラクル問題を説明し、初期の中央集権的ソリューションをたどり、単一障害点を減らすために分散型オラクルネットワークがどのように登場したかを示します。学習者はまた、さまざまな種類のオラクル、データ検証と配信の仕組み、計算・ランダム性・クロスチェーン通信を追加するプログラマブル設計への移行についても理解します。

ブロックチェーンがなぜオラクルを必要とするのか

スマートコントラクトは決定論的に実行され、すべてのノードが同じ入力から同じ結果に到達します。この特性はコンセンサスを保護しますが、チェーンを外部世界から隔離します。実世界の情報を取り込む方法がなければ、スマートコントラクトはオンチェーンイベントにしか反応できません。市場、保険、物流、ゲーム、アイデンティティ、コンプライアンスはすべてオフチェーンから始まるデータに依存しています。オラクルはこのギャップを埋めるために登場し、外部の事実を収集し、ノードが検証し合意できる方法でコントラクトに提供しました。

オラクル問題

外部データソースを導入すると新たな信頼の境界が生まれます。もし単一の主体がデータを制御すれば、コントラクトはその主体の信頼性やインセンティブを引き継ぐことになります。誤った入力や遅延した入力は清算や誤った決済、プロトコルの停止へと連鎖しかねません。「オラクル問題」とは、集中管理の障害点を再現することなく、正確かつタイムリーなデータを届ける課題です。核心的な問いは、誰がデータを提供するのか、複数の見解をどのように調整するのか、そしてチェーンが受け入れる根拠としてどのような証拠を得るのかです。

初期のオラクル設計

初期のアプローチは、必要に応じて API 応答をプッシュする単純なリレーでした。これらの設計は開発を容易にしましたが、リスクを集中させました。また、混雑時にはレイテンシーに苦しみ、フィードが現実と乖離した場合の責任も不明確でした。分散型金融が成長するにつれ、プロトコルはブロックタイム内で利用可能かつ改ざん耐性のある価格入力を必要としました。その応答として、オラクルの責務を独立したオペレーターに分散し、オンチェーンで彼らの報告を集約する仕組みが生まれました。

オラクルの種類とデータの方向

オラクルは扱う情報の方向と性質によって異なります。インバウンド・オラクルは、市場価格、天候データ、配送スキャン、身元認証といった外部の事実をコントラクトに導入します。アウトバウンド・オラクルは、銀行 API を通じた支払いの実行や物流プラットフォームの更新など、コントラクトから外部システムへのアクションを可能にします。

ソフトウェア・オラクルはウェブサービスからデータを取得し、ハードウェア・オラクルはセンサーやセキュアモジュールなどのデバイスから発信します。クロスチェーン・オラクルは台帳間で状態を伝達し、一方のチェーン上のコントラクトが他方のイベントに反応できるようにします。それぞれのバリエーションは、その文脈において正確性、適時性、改ざん耐性に取り組まなければなりません。

単一のフィードから分散型オラクルネットワークへ

分散型オラクルネットワークは、特定のプロバイダーの影響力を減らすために登場しました。複数のノードが異種のソースからデータを取得し、自らの観測に署名し、それをチェーンにコミットします。コントラクトは中央値や加重中央値といった集計値を読み取ります。このアーキテクチャは、不正確または悪意のあるレポーターの影響を制限し、障害に対する冗長性を提供し、フィード更新の透明な監査を可能にします。ネットワークレベルのインセンティブとペナルティは、正直な報告を報酬し、逸脱を抑制することで行動をさらに調整します。

データ検証と配信のメカニズム

典型的なフローはオフチェーンから始まり、ノードが一次・二次ソースに問い合わせ、フォーマットを正規化し、合理性チェックを適用します。観測結果は署名され、署名を検証して結果を計算するオンチェーンのアグリゲーターコントラクトに転送されます。更新頻度は鮮度とガスコストのバランスを取ります。一部のネットワークは価格乖離の閾値に基づくプッシュ型更新を用い、他のネットワークはオンデマンドで更新をトリガーするプル型読み取りを許容します。しきい値署名やマルチパーティ計算といった暗号技術は、多数の証明をコンパクトな証拠に圧縮し、オンチェーンのフットプリントを削減します。

プログラマブル・オラクルネットワークへの移行

静的なデータリレーは表現力を制限します。プログラマブル・オラクルネットワークは、配信前にオフチェーンコードでデータを変換、検証、または合成できるようにすることでモデルを拡張します。生の天気データを提供する代わりに、オラクルプログラムはポリシー条件を評価し、支払いパラメータを計算できます。単一の API 値を転送する代わりに、複数のソースを調整し、外れ値を除外し、ドメイン固有のロジックを適用し、監査可能な結果を出力できます。このアプローチは、完全なインターネットにアクセスできる環境に一部の計算を移しながら、オンチェーンの利用者への検証可能なリンクを保持します。

検証可能なランダム性という特殊なオラクルサービス

偶然性に依存するアプリケーションは、偏りのない公開検証可能なランダム性を必要とします。ブロック変数から導出されるオンチェーンの擬似乱数は、マイナーやバリデーターに予測可能です。検証可能なランダム関数は、オラクルがランダム値と、その値がコミットされた秘密とリクエストシードに対応することを示す証明を生成することでこの問題に対処します。コントラクトは値を使用する前に証明を検証します。このパターンは、公平な宝くじ、ゲームメカニクス、ランダム化された NFT 特性、操作に耐性を持たなければならない割り当ての基盤となります。

クロスチェーンメッセージングと状態証明

エコシステムが複数のチェーンに分散すると、オラクルはそれらの間でメッセージや状態証明を運ぶようになりました。最も単純な方法は、ソースチェーン上のイベントについて観測に署名するフェデレーションに依存します。より高度な設計は、ライトクライアント証明と委員会の証明を組み合わせ、単一の主体を信頼することなくイベントの包含を証明します。目的は、ソースで最終化された十分な証拠がある場合にのみ宛先チェーンがメッセージを受け入れることであり、単純なブリッジアーキテクチャに共通する攻撃面を減らします。

セキュリティモデルと故障モード

オラクルのセキュリティは、データソースの多様性、ノードオペレーターの独立性、堅牢な集計、透明な更新ポリシーに基づきます。攻撃者は API を狙ったり、オペレーターを侵害したり、流動性の低い市場を操作して報告価格を歪めたり、更新のタイムラグを悪用する可能性があります。防御策には、重複のあるソースホワイトリスト、オペレーターの評判とステーキング、乖離ベースのサーキットブレーカー、範囲チェック、異常検出時に更新を凍結または遅延させるフォールバックロジックがあります。オンチェーン集計コントラクトの形式的検証やフィード動作の継続的モニタリングも運用リスクをさらに低減します。

経済的インセンティブとガバナンス

信頼できるオラクルには持続可能な経済設計が必要です。ネットワークはデータ取得と報告を行うオペレーターに報酬を支払い、不正行為が証明された場合には担保を没収することもあります。料金モデルは、データ取得、暗号的オーバーヘッド、オンチェーンのガスをカバーしつつ、利用者にとって手頃でなければなりません。ガバナンスは、フィードがどのように作成されるか、どのソースが承認されるか、オペレーターがどのように参加または交代するか、緊急時にどのような手続きが発動されるかを決定します。明確で事前に定められたポリシーは、インシデント時の裁量を減らし、統合者に予測可能性を提供します。

性能、レイテンシー、コストのトレードオフ

高い分散化は、多数の署名を収集し、オンチェーン検証を増やすことを意味し、それはレイテンシーとコストを増加させます。逆に、小規模な委員会や単一リレーは費用を削減しますが、信頼の前提を拡大します。更新頻度も重要です。頻繁なプッシュは鮮度を高めますが、ガス使用量を増やし、まばらな更新はボラティリティ時に古くなります。プログラマブル設計はオフチェーン計算を追加し、柔軟性を提供しますが、証明や監査が必要な別の表面を導入します。各アプリケーションはリスク許容度とタイムリーな要件に基づいて、これらのトレードオフの中から位置を選びます。

コンプライアンス、データ権利、プロベナンス

オラクルは、ライセンス、規制、プライバシーに関わる可能性のあるデータと相互作用します。プロバイダーは利用規約を尊重し、プロベナンス記録を維持し、場合によっては個人を特定できる情報を編集または集約して公開台帳に掲載する必要があります。規制された場面では、ID制限付きフィードや許可制の配信が求められる場合があります。プロベナンスのメタデータと監査証跡は、下流ユーザーが値が適切な条件下で生成されたかを評価するのに役立ちます。

信頼性エンジニアリングと運用

実際の導入では、オラクルネットワークを厳格な可観測性を備えた本番システムとして扱います。オペレーターは地域にまたがる冗長インフラを運用し、ソースの健全性を監視し、フェイルオーバー経路をテストします。カナリアフィード、影の報告、シミュレーションされたストレスシナリオは、利用者に影響が及ぶ前に弱点を明らかにします。インシデント対応手順は、更新を一時停止する、キーをローテーションする、フォールバックソースに切り替えるための閾値を定義します。事後レビューは、構成、ソース選択、オペレーターポリシーにフィードバックされます。

オラクル進化の軌跡

オラクルは、重大な信頼を導入するアドホックなブリッジとして始まりました。それは独立した報告を集約する分散型ネットワークへと進化し、さらにオンチェーンに結果を固定しながらオフチェーンでドメインロジックを実行するプログラマブルシステムへと発展しました。検証可能なランダム性やクロスチェーンメッセージングといった専門サービスは、データ提供からシステム間の調整へとその役割を拡張しました。共通のテーマは、単独の支配を最小化しつつ、実世界のユースケースが要求する即時性と表現力を提供することです。プログラマブル・オラクルネットワークが成熟するにつれ、それはアクセサリーではなく、オンチェーンコントラクトを補完する並列実行レイヤーのように機能し、分散型アプリケーションが外部データや計算と安全かつ予測可能に相互作用できるようになります。

免責事項
* 暗号資産投資には重大なリスクが伴います。注意して進めてください。このコースは投資アドバイスを目的としたものではありません。
※ このコースはGate Learnに参加しているメンバーが作成したものです。作成者が共有した意見はGate Learnを代表するものではありません。