Oracle の基礎と一般技術要件

Blockchain oracle は、 ブロックチェーン上の Smart Contract が外部データや外部イベントを参照・トリガとして利用できない制約を補うために、チェーン外データの取得・検証・伝達を担う middleware / プロトコル群である。 単一主体の中央集権 oracle は単一点障害になるため、複数参加者で合意を形成して配信する分散 oracle が学術・実装の両面で発展してきた。学術 survey ではこれを 「oracle problem (現実世界データをブロックチェーンへ／から移送する実装上の未解決問題)」 として位置づけ、投票ベース (stake による最終化) と評判ベース (性能指標＋真正性証明) などで分類している。

10 項目の技術要件

oracle 設計は次の要件を多目的に最適化する必要がある。要件の優先順位は use case (DeFi 価格、 RWA、 prediction market、 cross-chain) ごとに異なるが、列挙そのものは共通の checklist として機能する。

(A) Security: Byzantine ノード (恣意データ注入、遅延、停止)、データソース改ざん (取引所 API 異常、 DNS/HTTPS 攻撃)、チェーン側の再編成や最終性遅延、 DeFi 下流への経済攻撃 (清算誘発、価格操作裁定) の複合攻撃面に対応する。 BFT 合意で「f < n/3 までの不正ノード許容」を保証し、更新条件・外れ値除去・複数ソース参照で「データ分散」を制御し、異常時にフェイルセーフへ移行できることを要件にする。

(B) Decentralization: 単一点信頼を避けるための冗長性。「参加者数」だけでなく、ノード選定権限構造、運用同質性 (同一クラウド・同一実装・同一運用者依存)、鍵管理集中も評価軸に入る。

(C) Data integrity & provenance: 「取得データが改ざんされていない」だけでなく、「どのソースから、どの時点の観測として得たか」を含む。 HTTPS/TLS は盗聴・改ざんを防ぐが、 Smart Contract が TLS セッションを直接検証できないため、 TEE や暗号学的証明で「TLS で得たデータの provenance」を提示する研究 (DECO、 Town Crier) が生まれた。

(D) Latency & scalability: 高頻度データ (価格、株式・FX・指数) は更新遅延と更新頻度に強く依存する。 On-chain 集約はガスコストが O(n) に膨らむため、 Off-chain 合意 → On-chain 1 回の書き込みへ移す設計が主流となった (Chainlink OCR がその代表)。

(E) Availability: 「常に最新値がある」ではなく、 (1) 更新停止 (staleness) を検出できること、 (2) 下流が安全に degrade できること (清算停止、ヘアカット拡大)、 (3) 復旧手順化 を含む。 OCR は fault 数が閾値を超えると liveness を失うが safety は守る、という設計目標を明言する。

(F) Privacy: オンチェーンは原則公開のため、 oracle 入力 (API キー、個人情報、取引所認証) や非公開データを秘匿しつつ「正しさ」だけを示す機構が要る。 Town Crier は暗号化パラメータによる private request、 DECO は zero-knowledge での性質証明を扱う。

(G) Incentive alignment: 正しい報告に報酬、誤り・不正に罰 (担保没収・スラッシュ) を与えて経済的に補強する。 Optimistic oracle では提案者・異議申立者の bond と challenge window 設計が安全性と遅延・コストを規定する。

(H) Verifiability: 署名 (単一・マルチ・集約)、 Merkle root と包含証明、 VRF 証明、 ZK 証明により Smart Contract がデータ真正性を検証できること。 VRF は IETF RFC 9381 で標準化された公開鍵版 PRF で、出力と証明を誰でも検証できる。

(I) Upgradeability: 脆弱性修正や機能追加のため契約更新が不可避。利用者側の参照先を頻繁に変えずに内部実装を更新するため、 proxy 参照やインタフェース固定が多用される (Chainlink Data Feeds の proxy 構造が代表)。

(J) Interoperability: マルチチェーン時代では、単一チェーン内のデータ供給に留まらず、 cross-chain messaging や異なる実行環境 (EVM/SVM/Move) への対応が要件。 CCIP のようにルータを統一インタフェースとし、各チェーン実装差分を吸収する設計が現れている。

典型的 Oracle パターン

oracle の設計空間は次の軸で分類される。実装はこれらの組み合わせとして理解できる。

信頼モデル:

• Centralized oracle — 単一 API / 単一運用者が署名して配信。構築簡単、低遅延だが単一点障害が致命傷。
• DON (Decentralized Oracle Network) — 複数ノードが独立観測し、合意・集約結果をオンチェーンへ提出。 BFT で f < n/3 を許容することが多い。
• TEE-based — Intel SGX 等の信頼実行環境で attested data を生成 (Town Crier 系)。
• ZK / Proof-based — DECO のように zero-knowledge で TLS セッション由来の事実を証明。

集約モデル:

• On-chain aggregation — Chainlink 1.0 白書の commit/reveal 案。簡素だがガスコストが O(n)。
• Off-chain aggregation — OCR のように閾値署名で 1 つの認証メッセージをオンチェーンへ。現在の主流。

配信モデル:

• Push — oracle 側が周期的にオンチェーンへ値を書き込む。参照は安いが更新が高コスト。
• Pull — 利用者が必要時に更新 tx を発行してフレッシュな値を得る。 Pyth が代表で、 EVM では updatePriceFeeds 呼び出し時に getUpdateFee で算出した手数料を支払う。
• Optimistic — 提案 → liveness window → dispute (異議があれば仲裁)。 UMA Optimistic Oracle は bond と liveness window のトレードオフを一般化。

機能タイプ:

• Data oracle — 価格、 FX、 イベント結果、 Proof of Reserve など参照データ。
• Computation oracle — VRF (検証可能乱数)、 off-chain 計算 → on-chain 検証、 Automation (条件達成で tx 自動実行)。
• Cross-chain oracle — メッセージング、トークン移転 (Chainlink CCIP、 LayerZero、 Wormhole 等)。

なぜ「複合的な設計」が必要か

これら 10 要件と 4 軸は独立に最適化できない。 latency を下げると security 検証段数が削れる、 privacy を強化すると verifiability が落ちる、 decentralization を増やすと latency が悪化する、といった trade-off が常に存在する。実際の oracle プロトコルは各軸でどこに positioning するかを設計判断として明示し、その判断と下流プロトコルのリスク許容度を整合させる必要がある。 BFT validity の数学的保証だけで安心するのではなく、観測データの分布・更新条件・下流のガード機構までを 一体の安全システム として評価することが、 NDSS 2026 のような最新研究が一貫して指摘する点である。