#sxt $SXT @SpaceandTime
昨年コーヒーにいくら使ったか確認しようとするたび、銀行アプリは90日を超えてスクロールするとフリーズします。それより古い明細を見るには、月ごとのPDF明細書を請求して待たなければなりません。ほとんどのステートシステムが高速性を保つ仕組みは、そんなものです。最近のよく使うデータは窓口に置き、履歴は冷たい地下室に押し込んでおく。リアルタイムの決済中に、過去3年分の記録を計算する必要がある人などいないだろう、という前提です。

スマートコントラクトも、まさにこの制約のもとにあります。レンディングプロトコルやUniswapのフックが参照できるのは現在の状態変数だけで、6か月前にウォレットが何をしたかは見られません。自動化エージェントやトークン化ファンドが複数のプールにまたがる過去の取引量を必要とする場合、通常はオフチェーンのインデクサーが数値を計算し、検証されていない結果をオンチェーンに送り返すのを待つことになります。

Space and Timeは、Proof of SQLを使ってこのボトルネックを回避しようとしています。コントラクトやアプリケーションが過去の記録を対象とするクエリを要求すると、オフチェーンの証明者がコミット済みのテーブルメタデータに対してSQL計算を実行し、GPUハードウェア上でゼロ知識証明を生成します。結果と暗号学的証明は、オンチェーンの検証コントラクトに返されます。証明者が行を飛ばしたり、計算を偽ったりすれば、検証に失敗し、コントラクトは出力を拒否します。

最初は、これによってスマートコントラクトが瞬時に無料で記憶を得られるのだと思っていました。しかし処理の流れを見ると、これは状態保存の問題を、連携とレイテンシのトレードオフに置き換えるものです。検証コントラクトは証明をすばやく確認しますが、オフチェーンの証明者が多項式計算を組み立てる間、呼び出し元は非同期コールバックを待たなければなりません。また、送信先チェーンでその証明を検証するためのガス代も誰かが支払う必要があります。履歴を読み取るコストをなくすのではなく、恒久的なオンチェーンストレージから、クエリごとの計算コストとコールバックの遅延へ移しているだけです。DeFiのスワップが証明生成を追い越す前に、ブロックの時間枠をどこまで短くできるのか、まだ気になっています。

免責事項：SXTの購入にはリスクがあります。SXTまたはその他の暗号資産を購入する前に、ご自身で調査（DYOR）を行い、専門家に相談することをお勧めします。