DeFi のオラクル: 分散型アプリケーション向けに信頼できるデータフィードを構築する方法

※この投稿は米国時間 2025 年 10 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

分散台帳技術（DLT）は、信頼関係のないピア間で検閲に抵抗しながら支払いを行う方法として、ビットコインとともに登場しました。その後、従来の金融機関は、不変性、分散性、プログラマビリティが金融商品やワークフローの再設計に役立つ可能性を認識し、このテクノロジーの調査を開始しました。

しかし、根本的な問題が原因で、多くの企業向けブロックチェーン プロジェクトがパイロット段階で停滞しています。それは、データの完全性の問題です。管理されたテスト環境から本番環境システムに移行すると、従来の中央集権型システムには存在しなかった攻撃ベクトルや障害モードが導入されます。これは、企業向け DLT の導入を先駆けて行っている DZ BANK のような機関にとっては特に差し迫った課題です。

これらの課題を解決するため、DZ BANK と Google Cloud は、ブロックチェーン アプリケーションへの信頼できるデータ配信のためのアーキテクチャ ソリューションを構築しました。この投稿では、Google Cloud テクノロジーを使用して、市場データを DZ BANK のスマート デリバティブ契約（SDC）に安全にフィードする方法について説明します。

2025 年は戦略的エンゲージメントの年

分散台帳技術（DLT）は、成熟の転換点を迎えました。規制の枠組みは安定化し、スケーラビリティの制限も解消されつつあります。また、ユーロシステムの検証作業により、スマート コントラクト プロトコルによって、別々の DLT インフラストラクチャ間で効率的な決済が可能になることが実証されています。探索フェーズは終わりに近づいています。パイロット プロジェクトから先に進んでいない機関は、競合他社が本番環境のブロックチェーン システムをデプロイするにつれて、取り残される恐れがあります。

このテクノロジーのコアとなる価値提案（不変、プログラマブル、分散型の実行）により、これまで実現不可能だった新しいデジタル金融商品が可能になります。スマート コントラクトは、カウンターパーティ リスクを排除し、複雑な決済手続きを自動化し、従来の仲介業者なしでピアツーピアの金融取引を可能にします。しかし、これらのメリットを実現するには、初期のブロックチェーン システムが回避するように設計されていた根本的な課題を解決する必要があります。

ユーロシステムの調査によると、スマート コントラクト プロトコルにより、金融商品の効率的な決済と、個別の DLT インフラストラクチャ間の機能的な相互運用性が実現します。これらの結果に基づき、ユーロシステムは、調和のとれたデジタル欧州金融市場インフラストラクチャの構築を目指し、この分野での活動を強化する計画を最近発表しました。

信頼できるデータの必要性

DLT は「コードが法」であるテクノロジーとして概念化されましたが、銀行、アセット マネージャー、清算機関は外部ソースからのオフチェーンデータを必要とします。これには、価格フィード、金利フィード、KYC/AML 認証、法的イベント トリガー、準備金の証明、IoT センサーデータ、支払い確認などが含まれます。

DLT システムでは、データの信頼性が最も重要です。誤ったデータはどのシステムでも意図しない結果をもたらす可能性がありますが、DLT トランザクションは多くの場合、元に戻すことができません。従来のシステムでは、誤った利率を使用した支払いはキャンセルできますが、DLT トランザクションは通常、最終的なものです。特に、参加者が匿名で、法的介入によって連絡が取れない場合はそうです。これにより、新たな攻撃ベクトルが生まれます。オフチェーン データを操作する攻撃者は、オンチェーン アセットの盗難など、重大な金銭的損害を引き起こす可能性があります。

信頼できる Oracle アーキテクチャの構築

オフチェーン データは、オラクルを介して DLT システムに提供されます。オラクルは、外部情報をスマート コントラクトに配信するインターフェースです。信頼できるオラクル サービスには、次の 3 つの重要な側面に対処する必要があります。

1. データはソースで正確である必要があります。基盤となるシステムが正確な情報を生成する必要があります。

2. また、データは、転送中および処理中に改ざんされないようにする必要があります。

3. データはタイムリーかつ確実に配信される必要があります。

Google Cloud の安全かつ高可用性のインフラストラクチャと、標準化された決定論的な金融プロトコルに対する DZ BANK のビジョンを組み合わせることで、これらの要件を満たすことができます。Google のグローバル技術インフラストラクチャは、情報処理ライフサイクル全体にわたってセキュリティを提供し、ソースと転送中のデータの完全性と信頼性を確保します。DZ BANK は、金融商品にテクノロジーに依存しない決定論的パターンを適用することに重点を置いており、信頼性が高く自動化可能な金融イノベーションを実現しています。このアプローチを組み合わせることで、改ざんされていないデータをタイムリーに DLT システムに配信するための基盤が提供され、安全なデジタル金融サービスのためのスケーラブルなプロトコル標準が確立されます。

このアーキテクチャ パターンは、同様の課題に直面している他の機関の青写真となり、さまざまな金融スマート コントラクトやブロックチェーン ネットワーク間で信頼できるデータ配信のための再利用可能なコンポーネントを作成します。

スマート デリバティブ契約: 信頼できるデータに依存する DLT ベースの金融商品

スマート デリバティブ契約（SDC）のユースケースは、外部データに大きく依存する、完全にアルゴリズム化された金融商品のライフサイクルを対象としており、Google Cloud で生成され、スマート コントラクトで使用されるオラクルベースの金融データフィードの原型として機能します。確定的な決済サイクルでは、決済額を決定するため、堅牢なオラクル サービスが必要です。主な機能には、OTC 取引におけるカウンターパーティ クレジット リスクを排除するための、確定的な評価、自動マージン計算、ネッティング、取引終了処理などがあります。これらのプロセスは、オラクルからの信頼できるリアルタイムの市場データに依存して、正味現在価値（NPV）と決済額を決定します。

基盤となるプロトコルは、Ethereum Request for Comments（ERC）6123 として公開されています。このオープン プロトコルに基づき、DZ BANK は法的拘束力のあるパイロット トランザクションを複数実施し、ドイツ連邦銀行の DLT インフラストラクチャ（トリガー ソリューション）でのユースケースを検証しました。

デリバティブが最も難しいテストケースであるのはなぜですか？決済の NPV を決定するには、現在の市場データを使用した正確な数学的計算が必要です。たとえば、金利スワップでは、決済金額を計算する前に、現在のスワップ相場を使用して割引率とフォワード レートのカーブをブートストラップする必要があります。プロセス全体は、決定論的で改ざん防止されている必要があり、パイプライン全体でデータの完全性の暗号化された証拠が必要です。安全なオラクル サービスは、SDC のライフサイクルと自動決済に不可欠です。

技術基盤: セキュリティ レイヤ

オラクル システム アーキテクチャは、それぞれ異なる技術的対策を必要とする、さまざまな脅威モデルに対応しています。

ソフトウェア サプライ チェーンの問題を軽減する

SDC の場合、攻撃者は NPV 計算を決定するコードを改ざんする可能性があります。たとえば、デフォルトで人工的に低い値を返すように機能を変更するなどです。これにより、決済金額は誤ったものになります。こうした問題を軽減するために、Google は安全なソフトウェア サプライ チェーンのプラクティスに従い、Binary Authorization を活用して、有効な証明書を持つコンテナ イメージのみをデプロイできるポリシーを適用しています。この証明書は、コンテナ イメージが、信頼できる CI パイプラインによるビルド検証などのチェックに合格し、ビルドの来歴を生成したことを証明します。最大限のセキュリティを確保するには、SLSA レベル 3 の保証が望ましく、デプロイ時にこの証明書を検証することで、Binary Authorization は不正なイメージや改ざんされたイメージをブロックし、悪意のあるコードが実行されるのを防ぎます。

データソースへの安全な接続

NPV を計算する Oracle 関数は、関連する市場データにアクセスする必要があります。このデータは、Cloud SQL などのクラウド データベースに保存されている可能性があります。ワークロードは Private Service Connect 経由で接続できるため、独自の VPC ネットワーク内のプライベート内部 IP アドレスを使用して Cloud SQL インスタンスにアクセスできます。これにより、すべてのトラフィックが Google Cloud ネットワーク内に留まり、公共のインターネットを経由せずに安全にデータにアクセスすることが可能です。

TEE 構成証明

オラクルデータの正確性を確保するには、特定の改ざんされていないソフトウェア バージョンによってデータが生成されたことを証明する必要があります。SDC の場合、これは値の計算を担当するソフトウェアに適用されます。Confidential Space（高信頼実行環境）を使用することで、承認された変更されていないソフトウェア ワークロードのみがデータを処理できるようになります。

これは、リモート アテステーションによって実現されます。データ所有者は、コンテナ化されたソフトウェア イメージの特定のダイジェストなど、承認されたワークロード属性の検証に基づいてアクセス条件を設定します。コードの身元確認は、オラクルのビジネス ロジックに対する信頼を補完します。検証可能なアテステーション トークンは強力な保証を提供し、オラクル データ出力とパッケージ化して、起源と正確性を証明できます。

Transport Layer Security

Transport Layer Security（TLS）は、ブロックチェーンへの送信中にオラクル データ出力を暗号化することで、追加のレイヤを提供します。TEE 認証は、安全な環境内で承認された、未変更のソフトウェアによってデータが生成されたことを証明しますが、TLS はネットワーク転送中の傍受や改ざんからデータを保護します。

デリバティブ以外の応用

SDC 向けに開発されたアーキテクチャ パターンは、信頼できる外部データを必要とする他のエンタープライズ ブロックチェーンのユースケースにも適用できます。たとえば、クロスチェーンのアセット転送では、二重支払い攻撃を回避するために、信頼できる支払い確認データが必要です。サプライ チェーン アプリケーションでは、センサーの読み取り値の検証と物流の確認が必要です。

安全なクロスチェーン プロトコルは、金融の相互運用性、特に別々のネットワーク間でのアセットと現金のレッグの決済に不可欠です。しかし、HTLC などの現在のプロトコルはタイムアウトに依存しているため、セキュリティの脆弱性が生じます。ERC-7573 で提案されているより安全なアプローチでは、支払いが成功した場合に暗号鍵をリリースするステートレス オラクルを使用して、アセット交換を完了するか、資金を返金します。スマート コントラクトの指示に従って鍵を復号することで、オラクルはセキュリティと効率の両方を強化します。信頼できるオフチェーン オラクルがスマート コントラクトを可能にする例です。

本番環境に対応したブロックチェーン インフラストラクチャの構築

DZ BANK と Google Cloud のコラボレーションは、企業によるブロックチェーンの導入が環境によって制限される時代は終わったことを示しています。成功するかどうかは、セキュリティと信頼性の基準を維持しながら、分散型アプリケーションを既存のビジネスシステムと統合できるかどうかにかかっています。

企業向けブロックチェーン プロジェクトに取り組むデベロッパーやアーキテクトにとって、このコラボレーションは、模倣すべき技術パターンと活用すべきインフラストラクチャ コンポーネントの両方を提供します。課題は、ブロックチェーン アプリケーションを構築することではなく、企業が重要なビジネス プロセスを信頼できるブロックチェーン アプリケーションを構築することです。

これらのアーキテクチャ アプローチがブロックチェーン インフラストラクチャの要件をどのようにサポートできるか、ぜひご確認ください。このコラボレーションを通じて開発されたフレームワークとパターンは、企業のセキュリティと信頼性の基準を満たす、信頼できる Oracle システムを構築するための実用的な出発点となります。

また、DZ BANK の Christian Fries 氏、Google の Chris Diya、Yuriy Babenko、Latif Ajouaoui の各氏にもご協力いただきました。

-DZ Bank、キャピタル マーケット、デジタル トランスフォーメーション マネージャー Peter Kohl-Landgraf
-Google Cloud、キャピタル マーケット テクノロジー マネージャー Moritz Platt