Chainlink 技術アーキテクチャ

Chainlink の差別化は「単一の oracle 方式」ではなく、 OCR を BFT 実行基盤として 複数プロダクト (Data Feeds、 VRF、 Automation、 CCIP) を同じ運用者集合・合意枠組みに載せられる 点にある。 Chainlink 1.0 白書 (2017) はオンチェーン側に reputation contract、 order-matching contract、 aggregating contract の 3 主要契約を置き、 SLA に基づく oracle 選定と結果集約・評判更新を行う modular 設計を提示した。現行ドキュメントでは Chainlink Nodes、 OCR jobs、 VRF、 Automation、 CCIP が個別サービスとして体系化されている。

OCR — Off-Chain Reporting と BFT 集約

OCR (Off-Chain Reporting) は、 n 個の oracle が独立観測値を集約し、署名付きレポートをオンチェーン契約が検証・公開する BFT プロトコルである。 OCR 仕様では任意の f < n/3 まで Byzantine fault を許容するモデルを採り、クラッシュ等 benign fault を含む拡張モデルでは liveness と safety を分離して議論する。「多数署名で署名された report」をオンチェーン契約が検証し、観測値の中央値 (median) を公開する枠組みが明確に定義されている。

暗号要素として OCR は公開鍵署名 (EdDSA / ECDSA) と PRF (HMAC-SHA256、 Keccak256) を使う。各ラウンドで 1 ノードがまとめて署名を提出するため、 n ノード分の独立 tx を発行する on-chain 集約と比べてガスコストを大幅削減できる。

OCR3 白書 (2025) はプラグインによる汎用化、状態複製、レポート順序付け、バッチ生成を導入し、実運用で インターネット上の end-to-end 遅延が low hundreds of milliseconds、 OCR2 比でレポート生成スループットが 1000 倍改善 し得ると主張している。

ただし、 BFT 合意が保証するのは「任意の観測が採用されない」ではなく、合意値が honest 観測範囲 (convex hull) に入る という validity に近い性質である。 NDSS 2026 はこの validity があっても honest range が広い場合に Byzantine 行動で代表値が実務的に揺れ得ることを示しており、 BFT 数学的正しさと経済的安全性は別問題である。

Data Feeds — Proxy + Aggregator 二段構造

Data Feeds は consumer contract が proxy アドレス経由で AggregatorV3Interface を呼び、その背後に AccessControlledOffchainAggregator のような aggregator contract が存在する二段構造である。 OCR で off-chain 合意した署名済み report が aggregator に書き込まれ、 consumer は proxy を通じて latestRoundData() を取得する。

この proxy 構造の意義は アップグレード時の参照継続性。 aggregator 実装に脆弱性が見つかったり機能拡張が必要な場合、 proxy 背後を差し替えれば全 consumer の参照先を変更しなくて済む。一方、 proxy の admin key 管理、アップグレード手順、変更監視は新たなセキュリティ境界になる。

[Off-chain]
Data Sources → Node Operators → OCR consensus + report signing
                                          │
[On-chain]                                ▼ (signed report)
                          Aggregator Contract
                                  │
                          Proxy Contract (latestRoundData)
                                  │
                          Consumer Contract

VRF — Verifiable Random Function

Chainlink VRF は要求ごとに乱数値とその決定方式を示す暗号学的 proof を生成し、オンチェーンで検証されてから利用される。 VRF は IETF RFC 9381 で標準化された公開鍵版 PRF で、出力と証明を誰でも検証できることが要点である。

設計上の重要な性質は「oracle は結果を操作できず、できるのは応答しないことだけ」。出力は秘密鍵保有者だけが計算可能だが、出力と proof は公開鍵で検証できるため、 oracle が応答する以上は決定論的に正しい乱数を返さざるを得ない。 NFT minting、ゲームの抽選、 fair launch、 governance のサンプリング等で広く使われる。

利用フローは Consumer Contract → VRF Coordinator (requestRandomWords) → VRF Oracle が乱数+proof 生成 → Coordinator が proof をオンチェーン検証 → fulfillRandomWords で consumer に渡す、という Request/Receive サイクル。

Automation — OCR3 駆動の条件実行

Automation (旧 Keepers) は、条件達成の合意を OCR3 で取り、トランザクションを自動実行する仕組み。「監視サーバを自前で持つ中央集権運用」を置き換える価値提案で、清算、リバランス、定期タスク、 cross-chain trigger の自動実行に使われる。複数 oracle が条件評価し合意したうえで実行するため、単一 keeper への依存リスクを排除する。

CCIP — Cross-Chain Interoperability Protocol

CCIP は source chain から destination chain へメッセージ・トークンを運ぶ際、 off-chain 合意 (OCR) と on-chain 実行を組み合わせる。 Off-chain 側は Role DON 上で Commit OCR plugin と Executing OCR plugin が役割分担し、 Commit が message range を合意して Merkle root を構築、 Execute が pending execution を検証・最適化して実行する。

特徴的なのが RMN (Risk Management Network)。追加のセキュリティ層として「cursing 機構」を維持し、異常検知時に特定チェーンまたは全体の CCIP トラフィックを停止できる。 RMN は CCIP 主要系と 別コードベース・別言語 で実装され、 client diversity により共通脆弱性の同時破綻確率を下げる設計を明文化している。

支払いモデルは source chain で feeToken により単一 fee を支払い、 fee 式は「blockchain fee + network fee」(network fee は RMN ノード運用者へ)。 destination chain でのガス高騰には gas-locked な支払い機構で対応する。

Source chain                Off-chain (Role DON)         Destination chain
┌─────────┐                 ┌──────────────────┐         ┌──────────────┐
│ Sender  │──┐              │ Commit plugin    │         │ OffRamp      │
│ Router  │  │              │ (observe events  │  ◄──────│ verify sigs  │
│ OnRamp  │──┴────event────►│  → merkle root)  │         │ + RMN gate   │
└─────────┘                 └──────────────────┘         └──────┬───────┘
                            ┌──────────────────┐                │
                            │ Executing plugin │                ▼
                            │ (validate +      │         ┌──────────────┐
                            │  batch execute)  │────────►│ Receiver     │
                            └──────────────────┘         └──────────────┘

アーキテクチャの統合性

5 つのプロダクト (Data Feeds、 OCR ベース合意、 VRF、 Automation、 CCIP) は独立 service として提供されているが、根底のノード運用基盤・ジョブ実行・鍵管理・ BFT 合意・オンチェーン検証は共通である。新規プロダクトが追加されても運用者は同じ Chainlink Node を回せばよく、ノード運用者経済とエコシステム成長が両立する設計になっている。これが 「単一プロダクト勝負ではなく、運用基盤を中核にしたプラットフォーム戦略」 の技術的裏付けでもある。