Original Post:

https://medium.com/@SpaceandTimeDB/proof-of-sql-101-dd1155cd5481

今月初めに、Space and Timeは、プロジェクトの歴史の中で最も期待されていた瞬間の一つであるSQL操作用の新しいzk-proofであるProof of SQLを発表しました。このプロトコルは現在アルファ版で利用可能となり、最初のプロジェクト群に渡され、それらのプロジェクトはスマートコントラクトに検証可能なクエリを接続するためにこれを使用します。このローンチは、Space and Timeのコアチーム、コミュニティ、顧客にとって興奮に満ちた瞬間であり、「すべてを検証する」という私たちが打ち出した未来への大きな飛躍でした。

Space and TimeやWeb3のニュースサイクルに注目している方であれば、Proof of SQLについて聞いたことがあるかもしれません。しかし、zkに精通しているか、本当に宿題をしていない限り、それが具体的に何なのかまだ疑問に思っているかもしれません。Proof of SQLは、Space and Timeで実行されるクエリが正確であり、クエリと基礎となるデータの両方が検証可能に改ざん不可能であることを暗号学的に証明するzk-SNARKです。この文が完全に直感的に理解できた場合は、ここでProof of SQLの構築方法についてさらに学ぶことができます。そうでなければ、私と一緒にいて、それを分解していきましょう。

複雑な技術を説明するとき、私はそれが解決する問題について話すことから始めるのが好きです。改ざん不可能なクエリの概念は、改ざんされたクエリの意味がすでに理解されていなければ意味をなしません。検証可能性は、システムにそれがない場合の結果をすでに認識していない場合はあまり意味がありません。Proof of SQLは、Web3だけでなく、世界のビジネスと経済のデータ基盤を根本的に変革する可能性を秘めています。しかし、どうやって？

それに答えるために、データ改ざんの長くて財政的に破壊的な歴史を検討しましょう。データ改ざんは、データベースに保存されている情報を操作、変更、または削除することを指します。多くの場合、データ改ざんは外部の悪意のあるアクター（ハッカーと呼ぶ）によって実行されます。ハッキングとそれがビジネスに与える脅威は、データベースがあらゆる政府、業界、組織に普及するにつれて、2兆ドルのサイバーセキュリティ産業が繁栄することを可能にしました。これまで以上に、企業は外部の脅威からデータを保護するためのツール、データベース内暗号化、ロールベースのアクセス制御、多要素認証などに投資しています。

しかし、悪意のある外部アクターだけが企業が心配するべき唯一のことではありません。最も厳格なセキュリティ対策が講じられていても、データは依然として恐らくさらに大きな脅威である内部の人的エラーに対して脆弱です。実際、データ改ざん事件の推定62％は、データにアクセスする権限を持つユーザーによって引き起こされます。悪意のある、不注意な、妥協したユーザーは、組織の安全性、生産性、評判に大きな（そして高価な）脅威をもたらします。ある推定によると、内部ソースによる単一のデータ改ざん事件は、平均して顔面で1,538万ドルの費用がかかり、消費者の信頼の低下による収益損失は含まれていません。

実際のデータ改ざん事件

今年だけで、JPMorgan Chaseは、SECの調査で求められた多くの電子メールのデータストレージを担当することになっていたアーカイブベンダーに責任を負わせて、400万ドルの罰金をSECに科されました。 SECの調査で求められた多くの電子メールのデータストレージを担当することになっていたアーカイブベンダーに責任を負わせて、2021年に他の通信記録の保存に失敗したために1億2500万ドルの罰金を支払った後です。

2月には、Twitterは、従業員がレート制限を処理する内部サービスからデータを誤って削除した後、サイト全体で大規模な停止を経験しました。その結果、大量のユーザーがツイートまたはリツイートすることができず、代わりに1日の制限に達したというエラーメッセージを受け取りました。

2021年4月、ダラス市は、軽率によって20.68テラバイトのダラス警察のデータを削除し、市に50万ドルの費用がかかったITワーカーを解雇しました。データにアクセスするための訓練を受け、許可を得た従業員は、バックアップされているかどうかを確認せずにテーブルを削除したと告白しました。この事件により、推定17,500件の刑事事件の証拠として収集された870万以上のアーカイブが失われました。欠落しているデータのうち3TBのみが回復可能でした。

データが改ざんされていないことを証明する

サイバーセキュリティ業界の急速な進歩により、データが外部アクターによって操作されないようにする方法はたくさんあります。しかし、それらのセキュリティ対策が終了する場所はどうでしょうか？たとえば、承認されたデータベース管理者が、数百万ドルの損失をもたらす間違いを犯さないようにするにはどうすればよいでしょうか？

まあ、それがProof of SQLの出番です。Proof of SQLは2つのことを保証するように設計されています。クエリの時点で取得しているデータが正しく、摂取時から操作されていないこと、および取得しているクエリ結果がそのデータの正確なSQL計算であることです。この設計は、データの状態の証明を1回の時点でのみ提供しますが、データの系譜を簡単に作成するために活用できます。データを検証するために、数日ごと、数時間ごと、または数秒ごとに定期的なヘルスチェッククエリを設定するだけです。これにより、データが常に追跡可能であることを保証する改ざん防止の系譜が作成されます。

Proof of SQLを使用すると、改ざんの事件が発生した直後にそれをキャッチするだけでなく、データを改ざん前の状態に簡単に復元することもできます。DBAが誤っていくつかのテーブルを削除した場合、会社には以前そこにあったデータの改ざん防止監査証跡があります。Proof of SQLにより、データベースはビジネスオペレーションに必要なストレージ、コンピュート、SQLインターフェイスを備えた改ざん防止台帳のように機能します。

スマートコントラクトはデータ駆動型の質問をすることができません。なぜなら、データストレージとコンピュートがWeb3スタックにどのように適合するかについて話しましょう。

限られたオンチェーンストレージとコンピュート

ブロックチェーンは、単一の不変のデータテーブルを含むデータベースにすぎません。新しいトランザクションがミントされるたびに、データがテーブルに追加され、そこに永久に保存されます。ブロックチェーンがオンチェーンストレージである場合、スマートコントラクトはオンチェーンコンピュートです。ブロックチェーンデータ上の非常に基本的なif / thenロジックを実行するように設計されたコードの断片です。「Xが発生した場合、Yを取引します。」それは、オンチェーンでの単純な価値交換に非常に適していますが、オプション取引のようなもっと複雑な計算が必要な場合はどうでしょうか？自体では、スマートコントラクトは「このコレクションから2つのNFTを所有しているすべてのウォレットは何ですか？」のような単純な質問さえ尋ねることができません。スマートコントラクトを「よりスマート」にするには、それらをオフチェーンストレージとコンピュートに接続する必要があります。質問をする方法を与える必要があります。

オフチェーンデータベースは解決策ですか？

SQL（Structured Query Languageの略）は、世界の質問をするプログラミング言語です。それは、MicrosoftからMcDonaldsまでのすべての企業がデータ上で計算を実行する方法です。彼らが質問する方法です。「この製品によって前四半期に生成された総収益は何ですか？」そして、彼らはすべて1つの共通のツールを使用してそれを行います。SQLデータベース。

企業は、dappsがブロックチェーンを活用するのと同じ方法でデータベースを活用します。データを保存、管理、取得するためです。しかし、ブロックチェーンとは異なり、データベースは非常に効率的であり、ビジネスロジックを構築するために必要なより複雑な計算を処理できます。システム内でデータが処理される方法を決定するルールです。一方、データウェアハウスはさらに堅牢です。それらは、分析を処理するために構築された特殊なエンタープライズスケールのデータベースです。データウェアハウスは、トレンド分析、レポート作成、意思決定をサポートするタスクなど、データから洞察を得る手段を企業に提供します。トランザクショナルデータベースと分析データウェアハウスの両方は、企業のデータ管理スタックの重要なコンポーネントであり、スマートコントラクトの限られた容量を補完し、複雑な質問をするために必要なストレージとコンピュートを提供します。

集中型システムには信頼が必要です

残念ながら、PostgreSQLやSnowflakeなどの古いデータベースやデータウェアハウスをスマートコントラクトに接続することはできません。1つには、データベースにはインデックス付きのブロックチェーンデータがプリロードされておらず、スマートコントラクトはチェーン上で何が起こっているかを知ることができる必要があります。より重要なことに、オフチェーンデータベースはチェーンにネイティブに書き戻すことはないため、質問に対する回答をスマートコントラクトに接続する組み込みの方法はありません。おそらく最も重要なことは、今日のデータベースはすべて、ブロックチェーンと根本的に互換性のない1つのものを必要とすることです。信頼。

信頼性はブロックチェーン技術の基礎であり、従来のシステムと区別する重要な要因です。「信頼性がない」という用語は、ブロックチェーンが信頼できないことを意味するのではなく、ユーザーがトランザクションを検証および実施するために中央機関や仲介者を信頼する必要がないことを意味します。信頼性は、金融取引などの価値主導のプロセスを自動化するために不可欠であり、期待される動作からの逸脱が重大な結果をもたらす可能性がある場合に特に重要です。信頼性のある環境で動作することにより、スマートコントラクトは一貫性があり透明性のある結果を保証します。

対照的に、従来のデータベースとデータウェアハウスは、システムを監督および管理する中央機関をユーザーが信頼する必要があります。これらの集中型システムは、潜在的な改ざん、詐欺、および単一障害点に関連するリスクに対して脆弱です。そのようなシステムをスマートコントラクトに接続することは、ブロックチェーン技術のゼロトラストモデルを損ないます。

分散型データベース対ゼロ知識データベース

明らかな答えは分散型データベースのようです。分散型データベース、たとえばSpace and Timeの分散型HTAPデータウェアハウスは、集中化された、信頼が必要な障害点を導入することなく、SQLデータベースの効率的なコンピュート機能をブロックチェーンスタックにもたらします。分散型データベースでは、データはノードのネットワーク全体に分散され、各ノードはデータの一部を担当します。表面上、それはスマートコントラクトの限られたストレージとコンピュートを補完する完璧な補足のように思えます。Web3スペースの多くの企業がこれのために構築しています。

ただし、データとコンピュートが十分な数のノードに分散されていない限り、信頼がまだ要因である効果的なコンセンサスアルゴリズムを保証することはできません。データが単一のノードオペレーターまたはそれらのいくつかによって管理されている場合、オペレーターが何も操作していないことを信頼する必要があります。コンセンサスは、トランザクションが数千のノードに複製されるネットワークのようなEthereumの場合はうまく機能しますが、ノードの数が減少するにつれて効果が低下します。そして、ブロックチェーンネットワークで見られるこの非常に冗長な複製が、そもそもストレージとコンピュートが限られている理由です。それでは、何をしますか？スマートコントラクトに完全に信頼性のある方法でクエリ結果を提供できる効率的な分散型データベースをどのように構築しますか？そのためには、ゼロ知識証明が必要です。

Zk証明されたクエリ結果とそれらが可能にすること

Proof of SQLは、データベースクラスターを実行しているノードオペレーターがデータとクエリ結果を操作していないことを暗号学的に保証するzk証明です。コンセンサスとは異なり、複数のノードがデータの有効性に同意することに依存するのではなく、ゼロ知識証明により、一方の当事者が追加情報を明らかにすることなく声明の正確さを証明できます。Proof of SQLの場合、クエリしているデータが正しく、摂取時から改ざんされておらず、受け取っているクエリ結果がそのデータの正確なSQL計算であることを保証します。

Proof of SQLは、不必要なノードの複製やコンセンサスへの依存なしに、分散型データネットワークの信頼性を保証するために必要です。これにより、スマートコントラクトは複雑なデータ駆動型の質問をし、信頼できる回答を受け取ることができ、その潜在的なアプリケーションと機能を拡張できます。Proof of SQLを使用すると、ブロックチェーンのセキュリティと改ざん防止の系譜を備えたSQLデータベースの効率を実現できます。この技術により、企業とdappsは、スマートコントラクトの限られた容量を補完するためにオフチェーンストレージとコンピュートを自信を持って活用し、Web3アプリケーションの新しい可能性を解き放ち、スマートコントラクトを「よりスマート」にすることができます。

それがどのように機能するか Proof of SQLが解決する2つの主要な問題に対処したので、それがどのように機能するかをもう少し詳しく見ていきましょう。私たちは、Proof of SQLが次のことを保証することを知っています。

1. データが摂取されてからクエリされるまでの間、それが操作されていないこと。

2. 受け取ったクエリ結果が保存されたデータ上の正確な計算であること。

3. クエリ結果自体が返される前に改ざんされていないこと。

しかし、どのように見てみましょう。平均的な人（つまり、暗号学者ではない）が背後にあることを理解するのに必要なほど深くだけ見ていきます。より深いダイビングについては、Space and Timeの共同創設者であり、研究責任者であり、プロトコルの作成者であるJay Whiteによって執筆されたProof of SQLのドキュメントをチェックしてください。

以下は、高いレベルでのSQL証明アーキテクチャを示す図です：

Zk-proofは、信頼されていない証明者が追加情報を共有することなく、ある声明が真実であることを検証者に納得させるプロトコルです。任意のzk-proofアーキテクチャと同様に、SQLの証明は二つのコンポーネントで構成されています：証明者と検証者。コンポーネントはその名の通りに機能し、証明者は証明を生成し、検証者はそれを検証します。つまり、証明者を主張をしている人、検証者をその主張が真実かどうかを確認している人と考えてください。

Space and Timeでは、SQLの証明を使用してクエリを実行するとき、データウェアハウス（データが保存されている場所）が証明者として機能します。それは、クエリ結果が正確であり、改ざんされていないことを示す証明を生成します。この証明は、多大な計算能力を要求する複雑な暗号アルゴリズムを使用して生成されます。幸いなことに、データウェアハウスは、並列処理（対.逐次処理）に設計されたNVIDIA GPU上に構築されており、この種の計算にはCPUよりもはるかに高速です。これは、計算が集中的であっても、証明が比較的迅速に生成できることを意味します。そして、プロトコルが証明者が信頼できなくてもよい（検証者のみが必要）ため、クエリごとに一度だけ行う必要があります。

検証者の仕事は、証明をチェックし、それが正しいことを確認することです。検証は計算的に十分軽量であり、Space and Timeの検証層、分散型オラクルネットワーク、またはスマートコントラクトによって冗長に行うことができ、これらはすべてプロトコルの信頼性を保証します。SQLの証明チームは、検証を非常に軽量に行うことを目指しており、最終的にはiPhoneがクライアントライブラリを実行するようなものでも実行できるようになる予定です。

改ざん防止クエリのプロセスをステップバイステップで見てみましょう。

ステップ1：摂取とコミットメントの作成

Space and Timeにデータが摂取されるとき、それが主要なブロックチェーンからインデックスされたデータであれ、ゲーム、アプリ、または他のデータベースからロードされたデータであれ、まず検証層を通じてルーティングされます。検証者はデータのコミットメント（「指紋」と呼びましょう）をキャプチャし、後で使用するために保存します。（注：以前にスマートコントラクトによって検証も行われると述べました。それは、生データが一度に数ギガバイトになる可能性があるのに対し、指紋は小さく、手頃な価格でオンチェーンに保存できるからです）。次に、検証者は生データをデータウェアハウスに送信し、そこで保存されます。

ステップ2：クエリリクエスト

API、JDBCドライバー、またはSpace and Time Studioを通じてクエリリクエストを送信すると、検証者はそれをデータウェアハウスにルーティングします。（検証者は、クエリがトランザクションか分析かを判断し、適切なOLTPまたはOLAPエンジンにルーティングする責任もありますが、それについてはここで詳しく読むことができます）。

ステップ3：証明の生成とクエリ結果

データウェアハウスはクエリを解析し、正しい結果を計算し、クエリが計算された際に何も改ざんされていないことを証明する暗号証明を生成します。その後、クエリ結果と証明の両方を検証者に送り返します。

ステップ4：証明の検証

次に、検証者は証明、クエリ結果、および保存されたデジタル指紋をチェックして、データが摂取時とクエリ時の間に変更されていないことを確認します。エッ！改ざん防止のクエリ結果が得られました。

この時点で、SQLの証明が何であり、どのように機能し、何を解決するかについて、高レベルながら徹底的な理解を得たはずです。これにより、それに関連するいくつかのユースケースを理解するためのより良い基礎的なコンテキストが得られるはずです。それらのうちの2つを見てみましょう。

分散型オプション取引の例に戻りましょう。このブログ投稿の初めに、次のように読みました：

「[スマートコントラクト]は、オンチェーン上での単純な価値交換には非常に適していますが、オプション取引のようなより複雑な計算を必要とするものについてはどうでしょうか？スマートコントラクト自体は、"このコレクションから2つのNFTを所有しているすべてのウォレットは何か"という単純な質問さえ尋ねることができません。スマートコントラクトを「より賢く」するためには、それらをオフチェーンのストレージと計算に接続し、質問を尋ねる方法を提供する必要があります。」

今、SQLの証明がスマートコントラクトが自身のチェーン上のデータ、他のチェーン上のデータ（Space and Timeのブロックチェーンインデックスサービスについてはこちらを読んでください）、および任意のオフチェーンソースからロードされたデータについてデータ駆動型の質問を尋ねて答えることを可能にする欠けていたピースであることがわかります。これにより、SQLの証明は、分散型オプション取引プラットフォームのようなデータ駆動型のDeFiプロトコルに特に適しています。

オプションの説明

オプションは、特定の時間枠内に予め決められた価格で基礎資産（例えば暗号通貨）を購入または販売する権利をトレーダーに与える金融商品です。Web3では、オプション取引はスマートコントラクトによって自動化されます。SQLの証明により、これらのスマートコントラクトは、取得している情報が正確であり、操作されていないことを保証された状態でリアルタイムで価格情報をクエリできます。

価格情報の検証

オプションの価格を計算することは、スマートコントラクトにとっては計算上非常に重いため、Black-Scholesモデルのような複雑なアルゴリズムを使用してオフチェーンで行う必要があります。ユーザーが暗号トークンに対するデリバティブのインプライドボラティリティまたはオプション価格を計算したい場合、Space and Timeのそれらのトークンの価格履歴を取り、Black-Scholesモデルを実行してオプション価格またはインプライドボラティリティを計算します。このシナリオでは、取引が行われる前にスマートコントラクトがSpace and Timeからリアルタイムのオプション価格をクエリできるように、SQLクエリを用意します。SQLの証明を使用してクエリとその結果の整合性を検証し、入力と出力が改ざんされていないことを確認します。

銀行コンソーシアム台帳

SQLの証明は、Web3の外にある企業が検証可能なデータと計算を活用することも可能にします。これは、金融価値が直接データに結びついている業界、例えば銀行コンソーシアム台帳にとって特に関連性があります。銀行コンソーシアム台帳では、各メンバー銀行は、個々の取引に基づいて自身の損益計算書（P&L）を計算し、それを別のデータベースに保存します。P&Lが計算されると、銀行はそれを共有台帳に記録します。この台帳は、ブロックチェーンのように機能します（トランザクションは追加できますが、削除や変更はできません。コンソーシアムは追加されたデータについて合意に達します）。この台帳は、コンソーシアムにとって単一の真実の源となります。

正確で検証可能な計算

コンソーシアムメンバーは、台帳に追加される前に各銀行の記録されたP&Lが正確であり、操作されていないことを確信する必要があります。SQLの証明により、このプロセスを検証可能な方法で行うことができるため、他の銀行の整合性を信頼する必要はありません。銀行が共有台帳にP&L声明を追加するとき、それはP&Lがそのデータベースの取引に従って正しく計算されたこと、結果や計算に使用されたインストレーダータが操作されていないことを保証する証明を提供します。

透明性と説明責任

この相互説明責任のシステムは、コンソーシアムメンバー間の信頼と透明性を促進します。各銀行は、共有台帳に正確で信頼できる財務データが含まれていることを確信できます。これは、他の機関を信頼することなく行えます。

ここまで付き合ってくださった方なら、これがスマートコントラクト、銀行、データベースよりもはるかに大きなものであることに気づき始めているかもしれません。SQLの証明は、すべての金融、経済、ビジネスプロセスが信頼ではなく検証に基づいて構築される未来を可能にしています。すべてを検証する未来です。

Space and Timeは、検証の時代を開始するために最初のzk-dataウェアハウスを開発しましたが、私たちはSpace and Timeをはるかに超える未来を想像しています。私たちは、世界中のすべてのデータベースがSQLの証明によって検証される未来、SQLの証明が標準となる未来を目指しています。この未来に向けて構築を続けることにわくわくしており、今後数ヶ月でさらなるマイルストーンを共有できることを楽しみにしています。

Original Post:

https://medium.com/@SpaceandTimeDB/proof-of-sql-101-dd1155cd5481

今月初めに、Space and Timeは、プロジェクトの歴史の中で最も期待されていた瞬間の一つであるSQL操作用の新しいzk-proofであるProof of SQLを発表しました。このプロトコルは現在アルファ版で利用可能となり、最初のプロジェクト群に渡され、それらのプロジェクトはスマートコントラクトに検証可能なクエリを接続するためにこれを使用します。このローンチは、Space and Timeのコアチーム、コミュニティ、顧客にとって興奮に満ちた瞬間であり、「すべてを検証する」という私たちが打ち出した未来への大きな飛躍でした。

Space and TimeやWeb3のニュースサイクルに注目している方であれば、Proof of SQLについて聞いたことがあるかもしれません。しかし、zkに精通しているか、本当に宿題をしていない限り、それが具体的に何なのかまだ疑問に思っているかもしれません。Proof of SQLは、Space and Timeで実行されるクエリが正確であり、クエリと基礎となるデータの両方が検証可能に改ざん不可能であることを暗号学的に証明するzk-SNARKです。この文が完全に直感的に理解できた場合は、ここでProof of SQLの構築方法についてさらに学ぶことができます。そうでなければ、私と一緒にいて、それを分解していきましょう。

複雑な技術を説明するとき、私はそれが解決する問題について話すことから始めるのが好きです。改ざん不可能なクエリの概念は、改ざんされたクエリの意味がすでに理解されていなければ意味をなしません。検証可能性は、システムにそれがない場合の結果をすでに認識していない場合はあまり意味がありません。Proof of SQLは、Web3だけでなく、世界のビジネスと経済のデータ基盤を根本的に変革する可能性を秘めています。しかし、どうやって？

それに答えるために、データ改ざんの長くて財政的に破壊的な歴史を検討しましょう。データ改ざんは、データベースに保存されている情報を操作、変更、または削除することを指します。多くの場合、データ改ざんは外部の悪意のあるアクター（ハッカーと呼ぶ）によって実行されます。ハッキングとそれがビジネスに与える脅威は、データベースがあらゆる政府、業界、組織に普及するにつれて、2兆ドルのサイバーセキュリティ産業が繁栄することを可能にしました。これまで以上に、企業は外部の脅威からデータを保護するためのツール、データベース内暗号化、ロールベースのアクセス制御、多要素認証などに投資しています。

しかし、悪意のある外部アクターだけが企業が心配するべき唯一のことではありません。最も厳格なセキュリティ対策が講じられていても、データは依然として恐らくさらに大きな脅威である内部の人的エラーに対して脆弱です。実際、データ改ざん事件の推定62％は、データにアクセスする権限を持つユーザーによって引き起こされます。悪意のある、不注意な、妥協したユーザーは、組織の安全性、生産性、評判に大きな（そして高価な）脅威をもたらします。ある推定によると、内部ソースによる単一のデータ改ざん事件は、平均して顔面で1,538万ドルの費用がかかり、消費者の信頼の低下による収益損失は含まれていません。

実際のデータ改ざん事件

今年だけで、JPMorgan Chaseは、SECの調査で求められた多くの電子メールのデータストレージを担当することになっていたアーカイブベンダーに責任を負わせて、400万ドルの罰金をSECに科されました。 SECの調査で求められた多くの電子メールのデータストレージを担当することになっていたアーカイブベンダーに責任を負わせて、2021年に他の通信記録の保存に失敗したために1億2500万ドルの罰金を支払った後です。

2月には、Twitterは、従業員がレート制限を処理する内部サービスからデータを誤って削除した後、サイト全体で大規模な停止を経験しました。その結果、大量のユーザーがツイートまたはリツイートすることができず、代わりに1日の制限に達したというエラーメッセージを受け取りました。

2021年4月、ダラス市は、軽率によって20.68テラバイトのダラス警察のデータを削除し、市に50万ドルの費用がかかったITワーカーを解雇しました。データにアクセスするための訓練を受け、許可を得た従業員は、バックアップされているかどうかを確認せずにテーブルを削除したと告白しました。この事件により、推定17,500件の刑事事件の証拠として収集された870万以上のアーカイブが失われました。欠落しているデータのうち3TBのみが回復可能でした。

データが改ざんされていないことを証明する

サイバーセキュリティ業界の急速な進歩により、データが外部アクターによって操作されないようにする方法はたくさんあります。しかし、それらのセキュリティ対策が終了する場所はどうでしょうか？たとえば、承認されたデータベース管理者が、数百万ドルの損失をもたらす間違いを犯さないようにするにはどうすればよいでしょうか？

まあ、それがProof of SQLの出番です。Proof of SQLは2つのことを保証するように設計されています。クエリの時点で取得しているデータが正しく、摂取時から操作されていないこと、および取得しているクエリ結果がそのデータの正確なSQL計算であることです。この設計は、データの状態の証明を1回の時点でのみ提供しますが、データの系譜を簡単に作成するために活用できます。データを検証するために、数日ごと、数時間ごと、または数秒ごとに定期的なヘルスチェッククエリを設定するだけです。これにより、データが常に追跡可能であることを保証する改ざん防止の系譜が作成されます。

Proof of SQLを使用すると、改ざんの事件が発生した直後にそれをキャッチするだけでなく、データを改ざん前の状態に簡単に復元することもできます。DBAが誤っていくつかのテーブルを削除した場合、会社には以前そこにあったデータの改ざん防止監査証跡があります。Proof of SQLにより、データベースはビジネスオペレーションに必要なストレージ、コンピュート、SQLインターフェイスを備えた改ざん防止台帳のように機能します。

スマートコントラクトはデータ駆動型の質問をすることができません。なぜなら、データストレージとコンピュートがWeb3スタックにどのように適合するかについて話しましょう。

限られたオンチェーンストレージとコンピュート

ブロックチェーンは、単一の不変のデータテーブルを含むデータベースにすぎません。新しいトランザクションがミントされるたびに、データがテーブルに追加され、そこに永久に保存されます。ブロックチェーンがオンチェーンストレージである場合、スマートコントラクトはオンチェーンコンピュートです。ブロックチェーンデータ上の非常に基本的なif / thenロジックを実行するように設計されたコードの断片です。「Xが発生した場合、Yを取引します。」それは、オンチェーンでの単純な価値交換に非常に適していますが、オプション取引のようなもっと複雑な計算が必要な場合はどうでしょうか？自体では、スマートコントラクトは「このコレクションから2つのNFTを所有しているすべてのウォレットは何ですか？」のような単純な質問さえ尋ねることができません。スマートコントラクトを「よりスマート」にするには、それらをオフチェーンストレージとコンピュートに接続する必要があります。質問をする方法を与える必要があります。

オフチェーンデータベースは解決策ですか？

SQL（Structured Query Languageの略）は、世界の質問をするプログラミング言語です。それは、MicrosoftからMcDonaldsまでのすべての企業がデータ上で計算を実行する方法です。彼らが質問する方法です。「この製品によって前四半期に生成された総収益は何ですか？」そして、彼らはすべて1つの共通のツールを使用してそれを行います。SQLデータベース。

企業は、dappsがブロックチェーンを活用するのと同じ方法でデータベースを活用します。データを保存、管理、取得するためです。しかし、ブロックチェーンとは異なり、データベースは非常に効率的であり、ビジネスロジックを構築するために必要なより複雑な計算を処理できます。システム内でデータが処理される方法を決定するルールです。一方、データウェアハウスはさらに堅牢です。それらは、分析を処理するために構築された特殊なエンタープライズスケールのデータベースです。データウェアハウスは、トレンド分析、レポート作成、意思決定をサポートするタスクなど、データから洞察を得る手段を企業に提供します。トランザクショナルデータベースと分析データウェアハウスの両方は、企業のデータ管理スタックの重要なコンポーネントであり、スマートコントラクトの限られた容量を補完し、複雑な質問をするために必要なストレージとコンピュートを提供します。

集中型システムには信頼が必要です

残念ながら、PostgreSQLやSnowflakeなどの古いデータベースやデータウェアハウスをスマートコントラクトに接続することはできません。1つには、データベースにはインデックス付きのブロックチェーンデータがプリロードされておらず、スマートコントラクトはチェーン上で何が起こっているかを知ることができる必要があります。より重要なことに、オフチェーンデータベースはチェーンにネイティブに書き戻すことはないため、質問に対する回答をスマートコントラクトに接続する組み込みの方法はありません。おそらく最も重要なことは、今日のデータベースはすべて、ブロックチェーンと根本的に互換性のない1つのものを必要とすることです。信頼。

信頼性はブロックチェーン技術の基礎であり、従来のシステムと区別する重要な要因です。「信頼性がない」という用語は、ブロックチェーンが信頼できないことを意味するのではなく、ユーザーがトランザクションを検証および実施するために中央機関や仲介者を信頼する必要がないことを意味します。信頼性は、金融取引などの価値主導のプロセスを自動化するために不可欠であり、期待される動作からの逸脱が重大な結果をもたらす可能性がある場合に特に重要です。信頼性のある環境で動作することにより、スマートコントラクトは一貫性があり透明性のある結果を保証します。

対照的に、従来のデータベースとデータウェアハウスは、システムを監督および管理する中央機関をユーザーが信頼する必要があります。これらの集中型システムは、潜在的な改ざん、詐欺、および単一障害点に関連するリスクに対して脆弱です。そのようなシステムをスマートコントラクトに接続することは、ブロックチェーン技術のゼロトラストモデルを損ないます。

分散型データベース対ゼロ知識データベース

明らかな答えは分散型データベースのようです。分散型データベース、たとえばSpace and Timeの分散型HTAPデータウェアハウスは、集中化された、信頼が必要な障害点を導入することなく、SQLデータベースの効率的なコンピュート機能をブロックチェーンスタックにもたらします。分散型データベースでは、データはノードのネットワーク全体に分散され、各ノードはデータの一部を担当します。表面上、それはスマートコントラクトの限られたストレージとコンピュートを補完する完璧な補足のように思えます。Web3スペースの多くの企業がこれのために構築しています。

ただし、データとコンピュートが十分な数のノードに分散されていない限り、信頼がまだ要因である効果的なコンセンサスアルゴリズムを保証することはできません。データが単一のノードオペレーターまたはそれらのいくつかによって管理されている場合、オペレーターが何も操作していないことを信頼する必要があります。コンセンサスは、トランザクションが数千のノードに複製されるネットワークのようなEthereumの場合はうまく機能しますが、ノードの数が減少するにつれて効果が低下します。そして、ブロックチェーンネットワークで見られるこの非常に冗長な複製が、そもそもストレージとコンピュートが限られている理由です。それでは、何をしますか？スマートコントラクトに完全に信頼性のある方法でクエリ結果を提供できる効率的な分散型データベースをどのように構築しますか？そのためには、ゼロ知識証明が必要です。

Zk証明されたクエリ結果とそれらが可能にすること

Proof of SQLは、データベースクラスターを実行しているノードオペレーターがデータとクエリ結果を操作していないことを暗号学的に保証するzk証明です。コンセンサスとは異なり、複数のノードがデータの有効性に同意することに依存するのではなく、ゼロ知識証明により、一方の当事者が追加情報を明らかにすることなく声明の正確さを証明できます。Proof of SQLの場合、クエリしているデータが正しく、摂取時から改ざんされておらず、受け取っているクエリ結果がそのデータの正確なSQL計算であることを保証します。

Proof of SQLは、不必要なノードの複製やコンセンサスへの依存なしに、分散型データネットワークの信頼性を保証するために必要です。これにより、スマートコントラクトは複雑なデータ駆動型の質問をし、信頼できる回答を受け取ることができ、その潜在的なアプリケーションと機能を拡張できます。Proof of SQLを使用すると、ブロックチェーンのセキュリティと改ざん防止の系譜を備えたSQLデータベースの効率を実現できます。この技術により、企業とdappsは、スマートコントラクトの限られた容量を補完するためにオフチェーンストレージとコンピュートを自信を持って活用し、Web3アプリケーションの新しい可能性を解き放ち、スマートコントラクトを「よりスマート」にすることができます。

それがどのように機能するか Proof of SQLが解決する2つの主要な問題に対処したので、それがどのように機能するかをもう少し詳しく見ていきましょう。私たちは、Proof of SQLが次のことを保証することを知っています。

1. データが摂取されてからクエリされるまでの間、それが操作されていないこと。

2. 受け取ったクエリ結果が保存されたデータ上の正確な計算であること。

3. クエリ結果自体が返される前に改ざんされていないこと。

しかし、どのように見てみましょう。平均的な人（つまり、暗号学者ではない）が背後にあることを理解するのに必要なほど深くだけ見ていきます。より深いダイビングについては、Space and Timeの共同創設者であり、研究責任者であり、プロトコルの作成者であるJay Whiteによって執筆されたProof of SQLのドキュメントをチェックしてください。

以下は、高いレベルでのSQL証明アーキテクチャを示す図です：

Zk-proofは、信頼されていない証明者が追加情報を共有することなく、ある声明が真実であることを検証者に納得させるプロトコルです。任意のzk-proofアーキテクチャと同様に、SQLの証明は二つのコンポーネントで構成されています：証明者と検証者。コンポーネントはその名の通りに機能し、証明者は証明を生成し、検証者はそれを検証します。つまり、証明者を主張をしている人、検証者をその主張が真実かどうかを確認している人と考えてください。

Space and Timeでは、SQLの証明を使用してクエリを実行するとき、データウェアハウス（データが保存されている場所）が証明者として機能します。それは、クエリ結果が正確であり、改ざんされていないことを示す証明を生成します。この証明は、多大な計算能力を要求する複雑な暗号アルゴリズムを使用して生成されます。幸いなことに、データウェアハウスは、並列処理（対.逐次処理）に設計されたNVIDIA GPU上に構築されており、この種の計算にはCPUよりもはるかに高速です。これは、計算が集中的であっても、証明が比較的迅速に生成できることを意味します。そして、プロトコルが証明者が信頼できなくてもよい（検証者のみが必要）ため、クエリごとに一度だけ行う必要があります。

検証者の仕事は、証明をチェックし、それが正しいことを確認することです。検証は計算的に十分軽量であり、Space and Timeの検証層、分散型オラクルネットワーク、またはスマートコントラクトによって冗長に行うことができ、これらはすべてプロトコルの信頼性を保証します。SQLの証明チームは、検証を非常に軽量に行うことを目指しており、最終的にはiPhoneがクライアントライブラリを実行するようなものでも実行できるようになる予定です。

改ざん防止クエリのプロセスをステップバイステップで見てみましょう。

ステップ1：摂取とコミットメントの作成

Space and Timeにデータが摂取されるとき、それが主要なブロックチェーンからインデックスされたデータであれ、ゲーム、アプリ、または他のデータベースからロードされたデータであれ、まず検証層を通じてルーティングされます。検証者はデータのコミットメント（「指紋」と呼びましょう）をキャプチャし、後で使用するために保存します。（注：以前にスマートコントラクトによって検証も行われると述べました。それは、生データが一度に数ギガバイトになる可能性があるのに対し、指紋は小さく、手頃な価格でオンチェーンに保存できるからです）。次に、検証者は生データをデータウェアハウスに送信し、そこで保存されます。

ステップ2：クエリリクエスト

API、JDBCドライバー、またはSpace and Time Studioを通じてクエリリクエストを送信すると、検証者はそれをデータウェアハウスにルーティングします。（検証者は、クエリがトランザクションか分析かを判断し、適切なOLTPまたはOLAPエンジンにルーティングする責任もありますが、それについてはここで詳しく読むことができます）。

ステップ3：証明の生成とクエリ結果

データウェアハウスはクエリを解析し、正しい結果を計算し、クエリが計算された際に何も改ざんされていないことを証明する暗号証明を生成します。その後、クエリ結果と証明の両方を検証者に送り返します。

ステップ4：証明の検証

次に、検証者は証明、クエリ結果、および保存されたデジタル指紋をチェックして、データが摂取時とクエリ時の間に変更されていないことを確認します。エッ！改ざん防止のクエリ結果が得られました。

この時点で、SQLの証明が何であり、どのように機能し、何を解決するかについて、高レベルながら徹底的な理解を得たはずです。これにより、それに関連するいくつかのユースケースを理解するためのより良い基礎的なコンテキストが得られるはずです。それらのうちの2つを見てみましょう。

分散型オプション取引の例に戻りましょう。このブログ投稿の初めに、次のように読みました：

「[スマートコントラクト]は、オンチェーン上での単純な価値交換には非常に適していますが、オプション取引のようなより複雑な計算を必要とするものについてはどうでしょうか？スマートコントラクト自体は、"このコレクションから2つのNFTを所有しているすべてのウォレットは何か"という単純な質問さえ尋ねることができません。スマートコントラクトを「より賢く」するためには、それらをオフチェーンのストレージと計算に接続し、質問を尋ねる方法を提供する必要があります。」

今、SQLの証明がスマートコントラクトが自身のチェーン上のデータ、他のチェーン上のデータ（Space and Timeのブロックチェーンインデックスサービスについてはこちらを読んでください）、および任意のオフチェーンソースからロードされたデータについてデータ駆動型の質問を尋ねて答えることを可能にする欠けていたピースであることがわかります。これにより、SQLの証明は、分散型オプション取引プラットフォームのようなデータ駆動型のDeFiプロトコルに特に適しています。

オプションの説明

オプションは、特定の時間枠内に予め決められた価格で基礎資産（例えば暗号通貨）を購入または販売する権利をトレーダーに与える金融商品です。Web3では、オプション取引はスマートコントラクトによって自動化されます。SQLの証明により、これらのスマートコントラクトは、取得している情報が正確であり、操作されていないことを保証された状態でリアルタイムで価格情報をクエリできます。

価格情報の検証

オプションの価格を計算することは、スマートコントラクトにとっては計算上非常に重いため、Black-Scholesモデルのような複雑なアルゴリズムを使用してオフチェーンで行う必要があります。ユーザーが暗号トークンに対するデリバティブのインプライドボラティリティまたはオプション価格を計算したい場合、Space and Timeのそれらのトークンの価格履歴を取り、Black-Scholesモデルを実行してオプション価格またはインプライドボラティリティを計算します。このシナリオでは、取引が行われる前にスマートコントラクトがSpace and Timeからリアルタイムのオプション価格をクエリできるように、SQLクエリを用意します。SQLの証明を使用してクエリとその結果の整合性を検証し、入力と出力が改ざんされていないことを確認します。

銀行コンソーシアム台帳

SQLの証明は、Web3の外にある企業が検証可能なデータと計算を活用することも可能にします。これは、金融価値が直接データに結びついている業界、例えば銀行コンソーシアム台帳にとって特に関連性があります。銀行コンソーシアム台帳では、各メンバー銀行は、個々の取引に基づいて自身の損益計算書（P&L）を計算し、それを別のデータベースに保存します。P&Lが計算されると、銀行はそれを共有台帳に記録します。この台帳は、ブロックチェーンのように機能します（トランザクションは追加できますが、削除や変更はできません。コンソーシアムは追加されたデータについて合意に達します）。この台帳は、コンソーシアムにとって単一の真実の源となります。

正確で検証可能な計算

コンソーシアムメンバーは、台帳に追加される前に各銀行の記録されたP&Lが正確であり、操作されていないことを確信する必要があります。SQLの証明により、このプロセスを検証可能な方法で行うことができるため、他の銀行の整合性を信頼する必要はありません。銀行が共有台帳にP&L声明を追加するとき、それはP&Lがそのデータベースの取引に従って正しく計算されたこと、結果や計算に使用されたインストレーダータが操作されていないことを保証する証明を提供します。

透明性と説明責任

この相互説明責任のシステムは、コンソーシアムメンバー間の信頼と透明性を促進します。各銀行は、共有台帳に正確で信頼できる財務データが含まれていることを確信できます。これは、他の機関を信頼することなく行えます。

ここまで付き合ってくださった方なら、これがスマートコントラクト、銀行、データベースよりもはるかに大きなものであることに気づき始めているかもしれません。SQLの証明は、すべての金融、経済、ビジネスプロセスが信頼ではなく検証に基づいて構築される未来を可能にしています。すべてを検証する未来です。

Space and Timeは、検証の時代を開始するために最初のzk-dataウェアハウスを開発しましたが、私たちはSpace and Timeをはるかに超える未来を想像しています。私たちは、世界中のすべてのデータベースがSQLの証明によって検証される未来、SQLの証明が標準となる未来を目指しています。この未来に向けて構築を続けることにわくわくしており、今後数ヶ月でさらなるマイルストーンを共有できることを楽しみにしています。