BigQuery の Proof of SQL を使用して検証可能なクエリをスマート コントラクトに接続する

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

編集者注: 今回は Space and Time にお話を伺います。同社の分散型データ ウェアハウスと斬新な SQL オペレーションのゼロ知識（ZK）証明が BigQuery と統合されました。Space and Time がどのようにして Web3 スペース向けにブロックチェーン ベースのスマート コントラクトの改善に取り組んでいるかをご紹介します。また同社のテクノロジーを Google Cloud データ エコシステム内で使用する方法についても説明します。

スマート コントラクトによって実行されるブロックチェーン トランザクションは暗号で保護され、ネットワークの参加者であれば誰でも独立して検証できます。したがって、ブロックチェーンは金融サービス、サプライ チェーン、医療など、データの完全性、トレーサビリティ、透明性が不可欠な業界に極めて大きな影響を及ぼします。実際、Space and Time では、ブロックチェーン ベースの Web3 がこれらのセクターのデータ管理、取引の実施、消費者とのやり取りの方法に変革をもたらす可能性を秘めていると考えています。

しかし、スマート コントラクトは、アクセスできるデータの種類、活用できるストレージの量、実行できるコンピューティング機能に制限があります。スマート コントラクトは、外部ソリューションの助けなしではオンチェーンにネイティブに存在する特定のデータポイントに対して、非常に基本的な if / then ロジックしか実行できません。動的なエネルギー価格設定や自動化されたバンキングのコンプライアンスなど、企業のユースケースで効果を発揮させるために、スマート コントラクトはオフチェーン データとコンピューティングにアクセスする方法が必要です。

スマート コントラクトの要因となるデータは、SQL データベースやデータ ウェアハウスにオフチェーンで存在することが多く、そこで分析と集約が行われてからオンチェーンのコントラクトに送信されます。そのため、スマート コントラクトはより効率的かつ大規模に運用できますが、深刻な問題を引き起こす可能性もあります。このデータやその処理を検証する方法がなければ、スマート コントラクトは操作に対して脆弱になり、その結果、コントラクトが正しく実行されず、オンチェーンでの価値損失が発生する可能性があるからです。

ソリューション: BigQuery に Proof of SQL をデプロイする

ゼロ知識（ZK）証明である Proof of SQL を入力することで、改ざん防止されたデータ処理を大規模に実行し、改ざんされていないデータに対してクエリ結果が期待どおりに処理されたことを暗号的に証明できます。Proof of SQL は、ZK テクノロジーと従来のデータベース処理を組み合わせ、たとえば以下のような Web3 のユースケースを推進します。

• 検証可能な資産の取引
• データドリブンな分散型金融（DeFi）
• Web3 の Play to Earn（P2E）ゲームの複雑な収益スキーム
• 動的トークン化された現実世界資産（RWA）

Proof of SQL により、デベロッパーは Google Cloud のデータに対する ZK 検証済みのクエリ処理をスマート コントラクトに接続できます。これによりマート コントラクトは、改ざんという費用のかかるリスクを負うことなく、より複雑でデータドリブンなロジックに基づいて実行できるようになります。

SQL データベースにアタッチされる ZK 証明として、Proof of SQL は、クエリの実行と基となるテーブルの両方が改ざんされていないことをクライアントに暗号で証明します。Proof of SQL では、ターゲットにアタッチされたデータベース内に仮想的な「改ざん防止テーブル」を作成することで、ルート オブ トラストを確立します。クライアントがこれらのテーブルにデータを追加すると、特別なハッシュ（または「コミットメント」）が更新されます。その後、クエリと関連する ZK 証明を検証する際に、これらのコミットメントを使用してその妥当性を確認します。BigQuery で SQL オペレーションの ZK 証明を有効にすることで、お客様はクエリ結果が改ざんされていないデータで正確にコンピューティングされたことを暗号で確認できます。

Proof of SQL は、クエリ実行の証明を生成する Prover と、生成された証明を検証する Verifier の 2 つの相互運用コンポーネントで構成されます。クライアントがデータベースにデータを取り込むと、そのデータが Verifier にルーティングされます。Verifier はデータに対するコミットメントを作成し、後で使用するために保存してから、そのデータをデータベースにルーティングします。

クライアントがクエリ リクエストを送信すると、そのリクエストは Prover にルーティングされます。Prover はクエリを解析し、正しい結果をコンピューティングし、クエリ実行の証明を生成します。その後、クエリ結果と証明の両方を Verifier に送信します。

Verifier がこの証明を取得すると、コミットメントを使用して結果に対する証明をチェックし、Prover がクエリ リクエストに対して正しい結果を生成したことを検証します。このクエリ結果は、「成功」のフラグとともにクライアントにルートバックされます。証明が成功しなかった場合、Verifier は代わりに検証が失敗したことを示すメッセージを送信します。

ソリューションの詳細: アーキテクチャとインテグレーション

Proof of SQL を BigQuery で動作できるようにするために、Space and Time Prover ノードを BigQuery エンジンと隣同士で接続します。改ざん防止 SQL クエリのリクエストが BigQuery に到達し、Prover に送信されると、正確性の証明とともに結果が生成されます。この証明と結果のペアは、Space and Time Gateway またはクライアントサイドのライブラリによって検証されます。後者は、ルート オブ トラストをユーザーに移行するもので、これを好むクライアントもいれば、この役割を代行する Space and Time Gateway に検証を委ねることを選択するクライアントもいます。

Space and Time の Proof of SQL サービスを利用して、BigQuery データに対するクエリが正確に実行され、基となるデータが改ざんされていないことを ZK で証明できるようにする場合、クライアントは次の手順を実行するだけです。

1. Space and Time Gateway をプロキシまたは読み込みサーバーとして BigQuery の前に配置できるようにします。BigQuery ユーザーには、特定のテーブルを「改ざん防止」としてラベル付けできる柔軟性があります。改ざん防止クエリが必要なテーブルの場合、クライアントは Space and Time Gateway を介してデータを読み込みます。このプロセスで、Gateway はデータに暗号のコミットメントを作成し、後で証明の検証に使用します。
2. Prover ノードに BigQuery ストレージ（ローカルまたは外部）へのアクセスを提供します。テーブルが改ざん防止として指定され、データが Gateway 経由で読み込まれたら、次のステップとして、Prover ノードに BigQuery ストレージへの直接アクセスまたは Google Cloud Storage のような外部ストレージへのアクセスを許可します。改ざん防止テーブルがどこで定義されているかにかかわらず、ユーザーは Prover がそのテーブルから読み取ることを承認する必要があります。
3. データを読み込み、BigQuery に対して実行されたクエリを Gateway 経由でルーティングします（クエリの ZK 検証が必要な場合のみ）。Proof of SQL を必要としないクエリ操作では、BigQuery のユーザー エクスペリエンスに違いはありません。改ざん防止クエリの場合、読み込み中に作成されたコミットメントに対して Proof of SQL 証明を検証できるようにするために、リクエストは Space and Time Gateway を経由してルーティングされる必要があります。

これらのステップを行うことで、お客様は ZK で実証済みのクエリを迅速かつ効率的に実行できます。

ZK で実証済みのクエリ: お客様のユースケース

ZK 検証クエリの機能により、Google Cloud のデベロッパーや企業は、検証可能な取引、データドリブンな DeFi、P2E の Web3 ゲームの複雑な収益スキーム、動的トークン化 RWA を含む、検証可能なデータ処理を活用して、新しい Web3 のユースケースを豊富に構築できるようになります。

検証可能な取引

Proof of SQL は、取引所での資産取引に関連するメタデータの完全性を確実にするために活用できます。デジタル資産と現実世界資産両方のための Web3 取引プラットフォームの Golteum は、Google for Startups クラウド プログラムへの参加を近ごろ発表しました。同社の場合、Proof of SQL は取引される貴金属の真正性と証拠管理の連鎖を検証できるため、透明な取引と資産担保型トークンで運用されるプラットフォームにとって最重要事項である、プラットフォーム運用の信頼とセキュリティが高まります。Proof of SQL により、Golteum はその SQL オペレーションの検証可能な暗号証明を投稿して、Golteum で取引される貴金属の管理と出処に関連するデータが正確で変更されていないことを確実にします。

データドリブンな DeFi

分散型金融（DeFi）は急速に進化し続けています。それでもなお、従来の金融システムは、その複雑さと効率性において、DeFi システムを大きく引き離しています。BigQuery の Proof of SQL を使うと、DeFi に対するより細やかなアプローチが可能になります。たとえば、Proof of SQL は、借り手のオンチェーンおよびオフチェーンのローン履歴に基づいて検証可能な動的な信用スコアを作成するために使用できます。これにより、借り手の信用度に合わせ、きめ細かくカスタマイズされた貸出金利が可能になります。さらに、BigQuery の堅牢なデータ処理機能と Proof of SQL を組み合わせることで、返済行動の検証可能な分析が容易になり、融資プロトコルで動的なローン清算の優先順位を設定できるようになります。これは貸出金利の正確性と公平性を高めるだけでなく、融資プロトコルのリスク調整後リターンを高める可能性もあります。

Web3 ゲームの複雑な収益スキーム

BigQuery で Proof of SQL を有効化することで、ゲーム デベロッパーは、Play to Earn（P2E）Web3 ゲームの報酬システムを変換できます。オフチェーンのゲーム テレメトリーを BigQuery で処理して分析できるようにすることで、Proof of SQL ではオンチェーンの報酬システムが、単純な指標ではなく詳細なプレーヤー分析に基づくものになります。これにより、ゲーム デベロッパーはチームの協力や戦略の実装を評価するなど、より複雑な報酬ロジックを作成できます。たとえば、マルチプレーヤー型オンライン バトルアリーナ ゲームでは、実績、プレーヤーの行動、ゲーム内の戦略などの組み合わせに基づいて報酬が与えられます。それらはすべて Proof of SQL によって検証されます。この BigQuery のデータ処理能力と Proof of SQL の検証可能性に支えられたより深いレベルのエンゲージメントは、ゲーム体験を大幅に向上させ、ゲーム内経済の範囲を広げます。

RWA と動的 NFT のトークン化

不動産、イベント チケット、収集品などの現実世界資産（RWA）のトークン化は、BigQuery の Proof of SQL から多大なメリットを得られます。動的なメタデータを持つ資産に対して、BigQuery は変動するデータを保存して処理するための効率的なプラットフォームになります。Proof of SQL はこれらの更新が改ざんされず検証可能であることを確実にします。たとえば、イベント チケットのトークン化では、BigQuery はチケットの価格を保存し、空席状況に基づいて動的に更新できると同時に、Proof of SQL により、基礎となるデータの完全性が保証されます。取引が発生すると、スマート コントラクトはリアルタイムのデータをクエリし、最新の情報に基づいて取引を実行します。このシステムは効率性と透明性を高めるだけでなく、特にイベント チケット販売のような業界で高まる透明性への要求に応え、よりユーザー フレンドリーなエクスペリエンスへの道を開きます。

Space and Time を選ぶ理由

Space and Time は「検証可能なコンピューティング」に焦点を置き、分散型データ ウェアハウスと ZK デベロッパー ツールのフルスタックを組み合わせて、Web3 のデベロッパーが分散型アプリケーションを大規模に構築できるようにします。同社はこのほど Google Cloud とのコラボレーションを発表しました。このコラボレーションは、Proof of SQL（Space and Time の SQL オペレーションにおける新しい ZK 証明）を BigQuery で使えるようにすることと、Space and Time を Google Cloud Marketplace からデプロイできるようにすることが中心になります。

ー Space and Time、共同創設者兼最高技術責任者 Scott Dykstra 氏

ー Google Cloud、カスタマー エンジニア Lucas Fontaine