ブロックチェーンオラクルと価格フィード

オラクル問題とは何か

スマートコントラクトは、全ノードがビット単位に同一の状態遷移を得る決定性の上に成り立ちます。この要請ゆえに、コントラクトは実時間・乱数・ネットワークI/O といった非決定的な入力を一切観測できません（詳細は /blockchain/smart-contracts-evm/ を参照）。ところが現実のアプリケーション——貸付、デリバティブ、保険、予測市場——は「1 ETH は今いくらか」「この便は遅延したか」といったチェーン外の事実を必要とします。

ここに根本的な緊張が生まれます。台帳の外にある事実を、決定性を壊さずにオンチェーンへ持ち込む方法が要る。この橋渡しを担うのがオラクルです。オラクルは外界のデータを取得し、それをトランザクションとしてオンチェーンに書き込むことで、以後は全ノードが同一の確定値として参照できるようにします。

これがオラクル問題です。どれだけコントラクト本体が堅牢でも、それが依存する外部データが虚偽なら、正しく実行された結果として誤った清算や不正な引き出しが起きます。実際、DeFi の大型被害の多くはコントラクトのバグではなくオラクルの操作に起因します。

なぜ単一オラクルでは不十分か

最も素朴な実装は、信頼する 1 者（プロジェクト運営や単一データ業者）がAPIから価格を取り、コントラクトの setPrice を呼ぶ方式です。これは単一障害点であり、同時に単一の攻撃対象でもあります。

要点は、オンチェーンの検証機構（署名検証やファイナリティ）は「誰が送ったか」は保証できても「送られた値が正しいか」は保証できないことです。署名が正しくても中身が嘘なら意味がない。したがって、オラクルの安全性は暗号ではなくデータ供給の構造——誰から、いくつのソースから、どう束ねるか——で作るしかありません。

分散オラクルネットワーク

分散オラクルネットワーク（DON: Decentralized Oracle Network） は、この構造を多重化して操作耐性を得ます。単一提供者の代わりに、独立した多数のオラクルノードがそれぞれ独立にデータを取得し、その報告を集約して1つの値に束ねます。少数のノードが故障・虚偽を働いても、多数の正直な報告が結果を支配するように設計します。

[外部ソース群]  取引所A  取引所B  取引所C ...
                  │       │       │
        各ノードが独立に取得・観測
                  ▼       ▼       ▼
[オラクルノード]  N1      N2  ...  Nk     （各自が署名した報告を作る）
                  └───┬───┴───────┘
                      ▼  集約（オフチェーン or オンチェーン）
                 中央値などで1値に束ね、まとめて署名
                      │
                      ▼  1トランザクションでオンチェーン更新
[ブロックチェーン]  価格フィード契約が確定値として保持

集約をオフチェーンで実行し、結果と各ノードの署名だけをオンチェーンへ書き込む方式（オフチェーン報告, OCR）が主流です。理由はコストで、k 個の署名を個別に検証・記録するとガスが k 倍かかる。オフチェーンで合意・集約し、1 トランザクションにまとめて提出すれば、ガスを提供者数に依存させずに済みます。集約結果の正当性は各ノードの署名（署名・鍵の原理は /blockchain/signatures-wallets-keys/）で担保し、オンチェーン側は「規定数以上の既知ノードが署名したか」だけを検証します。

価格フィードと集約の実務

DeFi で最も使われるオラクルが価格フィードです。設計上の勘所は、単なる「最新価格」ではなく操作しにくい価格を提供することにあります。ここには2系統のアプローチがあります。

TWAP（Time-Weighted Average Price, 時間加重平均価格） は、瞬間値ではなく時間窓（例: 30 分）にわたる平均を用いる手法です。ある時刻に価格を一瞬だけ歪めても、窓全体の平均への寄与は小さいため、攻撃者は歪んだ価格を長時間維持し続ける必要が生じます。維持コスト＝攻撃コストを引き上げるのが狙いで、瞬間操作に対する構造的な防御になります。ただし平滑化の代償として、正当な急変動への追随が遅れます。

さらにプッシュ型フィードは更新の起動条件を工夫します。毎ブロック更新はガスが嵩むため、実務では「逸脱閾値（deviation threshold）（前回値から一定率ずれたら更新）」と「心拍（heartbeat）（最大でもこの間隔で必ず更新）」を併用します。平時は逸脱があったときだけ書き込み、変動が乏しくても心拍で鮮度を保つ設計です。

オラクルを狙った攻撃と防御

オラクル攻撃は、データが辿る経路のどこを突くかで分類できます。データ源そのものを歪めるか、伝送経路で改竄・遅延させるかです。

フラッシュローン価格操作が代表格です。攻撃者は無担保で巨額を一時借用し、流動性の薄いDEXプールで大量売買して瞬間的に価格を歪めます。もし被害コントラクトがその単一プールの瞬間価格を担保評価に使っていれば、歪んだ価格を根拠に過大な借入や不当な清算を実行し、同一トランザクション内で借入を返済して利益だけを抜きます。ここで効くのが前述の防御です。単一プールではなく複数取引所の中央値を参照していれば、1 プールを歪めても集約値は動かない。TWAP を使っていれば、瞬間スパイクは時間平均に埋もれる。攻撃コストを跳ね上げることで、割に合わなくする発想です。

伝送経路側の攻撃には暗号が効きます。各報告に署名とラウンド識別子を付ければ、経路上での改竄は署名検証で弾かれ、過去報告のリプレイはラウンドIDの単調増加で拒否できます。ここは「誰が送ったか」を保証する領域で、オンチェーンの署名検証がそのまま防御になります。一方、データ源の操作には暗号は無力です。正規のノードが正規に署名した「正しく取得された虚偽価格」は、暗号的にはすべて正当だからです。だからこそデータ源の防御は集約と多重化に依存します。

検証可能なランダム性という近縁問題

価格だけでなく乱数もオラクルの守備範囲です。ブロックチェーンは決定性ゆえ真の乱数を内部生成できず、block 由来の値を乱数に使うとブロック提案者による操作（都合の悪い結果のブロックを破棄する等）に晒されます。

これを解くのが検証可能ランダム関数（VRF: Verifiable Random Function） です。オラクルが秘密鍵で乱数とその正当性の証明を生成し、オンチェーンで公開鍵により検証します。誰も——オラクル自身すら——結果を事前に予測・選択できず、かつ生成された値が規定の手続きに従うことを証明付きで確認できる。「チェーン外で作り、証明付きでオンチェーン検証する」という構図は価格フィードと同型で、証明技術の観点は /blockchain/zk-proofs-snark-stark/ と地続きです。

まとめ

• スマートコントラクトは決定性のため外界を観測できず、外部データはオラクルが署名付きでオンチェーンへ運ぶ。その真偽はチェーンの合意で検証できず、信頼は消えず提供者へ移る（オラクル問題）。
• 単一オラクルは単一障害点かつ攻撃対象。分散オラクルネットワークは独立ノードの報告を中央値で集約し、少数の虚偽・故障を多数決で吸収する。集約はガス削減のためオフチェーンで行い、結果と署名のみを1トランザクションで提出する。
• 価格フィードは「最新値」より「操作しにくい値」を目指す。複数取引所の中央値、瞬間操作を平滑化する TWAP、逸脱閾値／心拍による更新制御、そして鮮度チェックが定石。
• 攻撃はデータ源（フラッシュローンで薄い板を歪める）と伝送経路（改竄・リプレイ・更新停止）に分かれる。伝送は署名・ラウンドIDで、データ源は集約と多重化で守る——署名が正しくても値が正しいとは限らない。
• 乱数も同型の問題で、block 由来値は提案者に操作される。VRF が証明付きの乱数を提供し、価格フィードと同じ「チェーン外生成＋オンチェーン検証」の構図を取る。