ブロックチェーンオラクルとは？外部データ・価格更新・遅延の仕組みを解説

スマートコントラクトは、決められた条件に従ってプログラムを動かせます。では、暗号資産の価格や今日の天気のように、ブロックチェーンの外で起きた出来事をどこから知るのでしょうか。その役割を担うのが「オラクル」です。

オラクルは便利な一方、情報が古い、取得元が偏っている、サービスが停止するなどの問題があれば、プログラム自体が正しくても意図しない結果になることがあります。この記事では架空の価格データを使い、データの取得、検証、掲載、利用の四段階を追います。

先に結論：オラクルは「外の情報をチェーンへ届ける仕組み」

ブロックチェーン上のスマートコントラクトは、同じ入力を与えれば同じ結果を返すことが重要です。多くのノードが同じ規則で取引を検証するため、各ノードが好きなニュースサイトを開いて別々の価格を取得してしまうと、結果が食い違うおそれがあります。

そこで、オラクルと呼ばれる仕組みが、取引所の相場、現実世界の出来事、外部システムの情報などを一定の方式で取り込み、スマートコントラクトから使える形にします。ただしオラクルは「外部情報を必ず真実に変える魔法」ではありません。情報源、更新速度、運用者、停止時の処理に新しい信頼関係が生まれます。Ethereum公式のオラクル解説もこの信頼の課題を説明しています。

なぜブロックチェーンは外の価格を直接読まないのか

まず、スマートコントラクトを「誰が実行しても同じ答えを出す電卓」と考えてください。電卓に100と5を入れて引き算すれば、全員が95を得られます。ところが「今この瞬間のA取引所の価格」をインターネットで調べる命令は、通信時間や利用したデータベースによって異なる答えになる可能性があります。

Ethereumなどでは、ネットワークの参加者が同じ取引を同じ規則で実行できることが重要です。チェーン外の情報を直接好きな時刻に取りに行く設計では、参加者間で状態がそろいません。オラクルは外部で集めた値を、チェーン上で参照できるデータとして渡すことに意味があります。

これは「スマートコントラクトが勝手に毎秒価格をチェックする」という意味でもありません。値を更新するための外部トランザクションや、利用側の処理を起動する仕組みが必要です。スマートコントラクトの基本と自動実行の限界では、誰が処理を呼び出すかを説明しています。

架空の例：担保の価値を監視するサービスは何を読む？

ある架空のDeFiサービスでは、利用者が「ALF」というトークンを担保にして別のトークンを借りられるものとします。これはサービスを勧める説明ではなく、オラクルがなぜ必要かを見るための作り話です。ALFの残高や預入数量はチェーン上で確認できます。しかしALFの円換算価格を算出するには、どこかの相場情報が必要です。

最初に、利用者はALFを10枚預けます。説明用の価格を1枚1,000円とすると担保評価額は10,000円です。仮にサービス独自のルールで担保評価額の50%までしか借りられないなら、この時点の計算上の上限は5,000円相当です。どれも架空条件であり、実在サービスの借入条件ではありません。

ここで重要なのは、担保数量が10枚のままでも、価格情報が1,000円から800円へ変われば評価額が動くことです。しかし相場が800円になっても、オラクルが1,000円という古い値を出し続けていれば、スマートコントラクトから見える評価額は更新されないかもしれません。反対に間違った極端な値を受け取れば、利用者に不利な条件判定が起きる可能性もあります。

この例に出てくる「担保率」「清算」などのサービス固有の規則は別問題です。本記事の焦点は、コードが読む入力データの出どころです。貸借の全体像はDeFiの仕組みで整理しています。

価格データはどのように集められる？

一つの取引所の値だけを読む方式は簡単ですが、その市場で一時的に約定が偏ったり、取引所が停止したりすると影響を受けます。複数の取引所やデータ提供者から値を集め、異常値の影響を抑える仕組みを持つオラクルもあります。たとえば5件の架空の観測値が「990、995、1,000、1,005、1,600円」のとき、単純平均は1,118円ですが、中央の値である中央値は1,000円です。

この比較は中央値という考え方を理解する例です。実際のオラクルで採用される集計・重み・外れ値処理は製品ごとに異なります。中央値を採れば必ず不正に強くなる、とも言えません。複数の提供者が同じ誤った元データを参照する場合、見かけ上の多数決でも誤りが残る可能性があります。

Chainlinkなどは複数のデータソースやノードを利用する設計を公開しています。プロジェクトによっては自前のオラクル、集中管理型の情報提供、ネットワーク分散型の情報提供があり、いずれも運用・更新の条件を確認しなければなりません。オラクルのブランド名だけでサービス全体の安全性が保証されるわけではありません。

更新間隔と遅延：相場と画面の値が違っても即バグとは限らない

実際の相場は秒単位で変わり得ますが、チェーン上にデータを書き込むと取引処理や費用が発生します。そのためオラクルは、決められた時間が経過した場合や、基準から一定以上価格が動いた場合に更新する方式を取ることがあります。ここで使う言葉が「ハートビート」と「乖離しきい値」です。

ハートビートは、おおむねどのくらい時間が経ったら更新を促すかという条件です。乖離しきい値は、前回値からどれほど変化したら更新対象とするかという価格差の条件です。ただし特定の数値が全銘柄・全チェーン共通に設定されているわけではありません。Chainlinkの更新方式の説明では、push方式とpull方式でデータが書き込まれるタイミングが異なる点を案内しています。

ある時間の例を追う

架空の価格フィードが10:00に1,000円を記録し、10:02に市場が980円、10:03に970円になったとします。フィードの更新条件を満たすまでは、スマートコントラクトが10:02に読んだ値が1,000円のままでも不思議ではありません。10:04に970円が更新されたあとで、はじめて最新のチェーン上の値が変わります。

これは実在フィードの更新実績ではありません。実際のデータでは更新ブロック、報告時刻、どの市場を参照しているかを見て判断します。価格差が常に誤表示というわけでもありません。DEXの取引価格とオラクルの参照価格は目的が異なり、同時刻に完全一致する必要はありません。取引価格が決まる仕組みと区別してください。

Push型とPull型：値を書き込むタイミングの違い

Push型は、オラクルの仕組みが継続的にチェーン上の参照値を更新する方式です。利用するコントラクトは、すでにチェーンへ載った直近の値を読み取れます。Pull型は、必要な場面で報告を取り込み、検証・利用する形を取ります。ここでいうPullも、ブラウザが勝手に適当なWebサイトを参照するという意味ではありません。

どちらも更新の遅延や利用条件を設計しなければなりません。たとえば日次の参考情報を表示する用途と、価格が急変する取引の清算判定では、必要な新鮮さが違います。さらにネットワークの混雑やデータ提供者の停止、更新トランザクションの失敗が重なると、期待した時刻に値が届かない可能性があります。

オラクルを使うサービスで読者が確認したい五つの項目

最初に、そのサービスがどんな外部データを必要とするのか確認します。価格か、天候か、資産証明かによって情報源の確認方法は変わります。次に、データの発行元が一社なのか複数なのか、更新ルールが公開されているかを見ます。さらに最新の更新時刻、異常時の停止・代替処理、運用主体の変更権限を調べます。

たとえば価格を使う金融サービスなら、公開ドキュメントの「Oracle」「Price Feed」「Data Source」「Heartbeat」「Deviation」などの項目が手掛かりです。専門用語があるから安全なのではなく、何を参照し、いつ更新し、値が異常ならどうするかを具体的に説明しているかが大切です。資料が見つからない、あるいはサービス側が参照元を明かさない場合、一般利用者が信頼性を十分に判断することは難しくなります。

オラクルが原因で起こり得る問題を分けて考える

第一に「誤った値」です。価格集計元の誤りや攻撃により、真の市場状況と大きく異なる値が取り込まれる可能性があります。第二に「古い値」です。情報そのものは当時正しくても、更新が止まれば今の判断には使いにくくなります。第三に「届かないこと」です。サービス停止やネットワーク障害で、コントラクトの処理が遅延・停止する場合があります。

さらに、元の市場が流動性不足で価格操作を受けやすい場合、オラクルの設計だけで問題を完全に取り除けないことがあります。スマートコントラクトには入力データの検証や異常時の停止などの設計が必要ですが、それがあると宣伝されていてもリスクゼロにはなりません。利用者が損失を被る可能性は残ります。

Oracleという単語が書かれたアカウントからDMが来ても、復旧や価格訂正のために秘密鍵を渡す必要はありません。オラクルの導入は利用者が第三者にウォレットを預けることとは別です。詐欺の見分け方も合わせて確認しましょう。

オラクルと価格チャート、取引所の板はどう違う？

チャートは過去の取引価格などを人間が見るために描いたものです。取引所の板は買いたい価格・売りたい価格の注文を集めたものです。一方、オラクルはスマートコントラクトが参照するデータを提供します。数字が同じように見えても、参照目的と算出基準が異なります。

「画面のBTC価格が100万円だから、コントラクトも100万円を使うはず」と決めつけず、そのサービスがどのフィードを採用しているか確かめます。USD建ての価格をJPYへ直す場合は、為替データが別途必要になることもあります。価格の単位、基準通貨、更新時刻の三つをそろえない比較は誤解のもとです。

古いデータが見つかったら「遅れの長さ」と「使われ方」を見る

たとえば架空の価格データが14:00に更新され、利用者が14:20にサービスを開いたとしましょう。画面上の参照価格と市場の最新価格が違っていても、20分前の値を使う設計なのか、更新処理が停止しているのかは、その一画面だけでは分かりません。まず最終更新時刻と現在時刻を同じタイムゾーンで比較し、基準通貨がUSDなのかJPYなのかを確認します。

次に、その値が「参考表示」にしか使われないのか、実際の貸付上限や清算条件を決めるのかを区別します。単なる参考値が古い場合と、資産の強制処理を左右する入力が古い場合では、利用者にとっての重要性が違います。サービスの公式仕様にデータが古い場合の停止条件があれば、その条件と現在の状態を照合します。仕様が見つからなければ、見つからないという不確実性が残ります。

さらに、データが複数のチェーンへ配信される場合、Ethereum上の値が更新されていても、別のL2に置かれた同名フィードが同じ瞬間に更新されたとは限りません。閲覧中のチェーン、参照コントラクト、更新ブロックを確認して比較します。「オラクルが更新済み」という一言は、すべてのチェーンの全データが最新という意味ではありません。

よくある質問

オラクルはAIが価格を予測する仕組みですか？

いいえ。一般的な価格オラクルは、外部の市場データなどを取得・集約してオンチェーンへ届ける仕組みです。将来価格を的中させる機能ではありません。

オラクルの価格が取引所と違ったら危険ですか？

必ずしも不正とは限りません。参照市場、通貨建て、更新時刻の違いがあります。ただし不自然な差が継続するなら、利用を急がずサービスの公式資料と更新履歴を確認してください。

分散型オラクルなら間違いませんか？

間違いがなくなるわけではありません。複数ノードが同じ誤った情報を受け取る場合や、通信・設計の問題などは残ります。運用・監視・異常時対応まで見て評価する必要があります。

オラクルが止まったら資産は必ず失われますか？

必ずではありません。利用するコントラクトの設計次第で、一部操作が止まる場合もあれば、不適切な値が処理に影響する場合もあります。サービスごとの対応規則を調べる必要があります。

まとめ：スマートコントラクトの正しさは入力の正しさと別

オラクルはブロックチェーン外の情報をコントラクトが使える形にする仕組みです。何のデータを、どこから、誰が、どの時点で届けたかを理解すると、価格差や遅延を冷静に読めます。データが古くてもプログラムは規則どおり動くことがあるため、コードの自動実行を安全性や正しい判断の保証だと考えないことが重要です。