@SpaceandTimeDBをフォローしているなら、SQL の証明 (私たちの小説 zk 証明) についてよく聞いたことがあるでしょう。 そこで今日は、DeFi、オラクル、クロスチェーンインフラ、流動性プロビジョニング、さらには機関にまたがる例を交えて、SQL の証明の実際のユースケースを説明します。 まず、トークンを起動したいとします:$XYZ。 それでクジラに近づき、取引を結びます... 「ねえ、Uniswapの私の流動性プールに$1MのUSDTを追加すれば、$XYZ供給量の1%をあげます。」 この取引はスマートコントラクトに書き込まれていますよね? しかし、今の課題は、このコントラクトがこのクジラが報酬を受け取るために約束したものを実際に入金したことを照会して検証する必要があることです。 したがって、次のようなスマートコントラクトが必要です。 - このクジラが実際に$1M USDTを追加したことを確認します。 - ウォレット + タイムスタンプを追跡します。 - 1%のトークン報酬を強制します。 しかし、その $1M USDT は実際にはオフチェーンに存在します。prolly は DEX サブグラフまたは Uniswap API で使用されます。 ここで、SQL の証明を取り入れたいと思います。 したがって、クジラの流動性預金はSQLを介して照会され、暗号的に検証され、最終的にゼロトラストの前提でスマートコントラクトに入力されます。 2つ目は、ノードオペレーターの説明責任(スラッシング/報酬)です。 @chainlink などのネットワークや DePin では、複数のノードがジョブ (価格の取得、ID の検証、コンピューティングの実行など) を実行します。 各ノードは、公平かつそれに応じて報酬を受け取る必要があります。 不正行為をしたりオフラインになったりした場合は、削減されなければなりません。 しかし、問題があります。 スマートコントラクトは、どのノードがどのような仕事をしたかをどのように知るのでしょうか? オペレーターのアクティビティはオフチェーン (多くの場合、ログやデータベースに保存される) であるため、ノード オペレーターとして、データが正確であることを望んでいませんか? もしあなたが切りつけられそうになったら、あなたは本当に理由で切りつけられていることを確信したいものです。 繰り返しになりますが、ここに SQL の証明が役に立ちます。 Proof of SQL を使用すると、ネットワークは次のことが可能になります。 - ジョブ完了ログを照会します。 - ノードのパフォーマンスの検証可能な証明を生成します。 - オンチェーンにフィードして、報酬またはスラッシングのロジックを自動化します。 したがって、最終的に、スラッシュされた場合、それが本当の理由によるものであることを証明する暗号化領収書を見ることができるため、その理由がわかります。 クロスチェーンの担保検証に関しては、依然として SQL の証明が必要です。 ユーザーが両方のチェーンに担保を預ける Base と Ethereum 上に融資プロトコルを構築しているとします。 総TVLをどのように証明しますか? 両方のチェーンにわたるユーザー担保をどのように監視しますか? また、二重カウントや詐欺をどのように防ぐのでしょうか? SQL の証明がなければ、次のことを行う必要があります。 - カスタム API を信頼します。 - ブリッジングデータに依存します。 - バックエンドを一元化します。:/ しかし、SQL の証明を使用すると、次のことができます。 - 両方のチェーンのデータからクロスチェーンの状態を照会します。 - それを暗号的に証明します。 - 単一のビューを使用して、貸付、清算、および金利を強化します。 最後。あなたが資産のトークン化を検討している大手 TradFi 銀行だとします。 次のことを行うことができます。 - RWA を起動します。 - 資産に対して貸し出す。 - 顧客への支払能力または担保を証明します。 しかし、資産データはオフチェーンデータベースにあります。 機密情報をオンチェーンにダンプするのではなく、SQL の証明を使用して内部 DB にクエリを実行し、残高の暗号化証明を生成し、実際のデータを明らかにすることなく資産の所有権や裏付けを証明できます。 本質的に、ZK + SQL = 機関レベルのプライバシー + 透明性です。 流動性取引でトークンを構築したり、DePIN やオラクル ネットワークを実行したり、マルチチェーン レンディングを展開したりする場合は、検証可能なオフチェーン データが必要になります。 そして、それが @SpaceandTimeDB による Proof of SQL が提供するものです。