1本のチェーン上で大量のデータベーステーブルが稼働しているのに、チェーン自体にはほとんどデータが保存されていない。この設計を初めて見たときは手抜きかと思ったが、考えれば考えるほど意図的なものだと感じる。
SXT Chainがオンチェーンに置くのは、各テーブルの暗号学的コミットメントだけだ。テーブルの指紋のようなものだと考えればいい。実際のデータはオフチェーンに置かれ、クエリと証明はProverノードに任せる。検索が終わると、結果と証明をセットで返し、検証者は指紋と照合することで、改ざんの有無を確認できる。重要なのは、この指紋を更新できることだ。新しいデータが入ってきても、古い指紋と新しいデータから新しい指紋を計算できるため、過去のデータを遡って調べる必要がない。だからテーブルは増え続けても、チェーンが肥大化することはない。
私の見立てでは、この抑制こそが最も賢い点であり、最大の賭けでもある。賢いのは、イーサリアムやSolanaと汎用実行の分野で競おうとせず、その競争から手を引き、スマートコントラクトに最も欠けている機能、つまり質問できる能力だけを提供していることだ。賭けなのは、データのコミットメントだけを担うチェーンの価値が、「検証可能なクエリに継続的にお金を払う人がいる」ことに完全に依存している点だ。汎用チェーンなら、閑散としていても他のアプリケーションが支えになり得る。しかし、このチェーンには支えがない。需要がなければ、見た目だけは美しい空のチェーンになる。
もう一つ、過小評価されていると思う点がある。検証者はSXTをステークする必要があり、不正を働けば没収される。対象となるのは、コミットメントの改ざん、クエリ結果の検証不能、応答の遅延などだ。つまり、ここでのセキュリティは二重支払いを防ぐだけではなく、「データがこっそり書き換えられる」ことを防ぐものでもある。これは別のセキュリティ観だ。
だから私は、TPSではなく、二つのことだけに注目している。実際のクエリリクエストが継続的に増えているか、そして実際に料金を払っているのは誰なのか。前者は需要を示し、後者はその需要が補助金で積み上げられたものかどうかを決める。
@SpaceandTime この道がうまくいくかどうか、$SXT の価値獲得はここにかかっている。#SXT
#sxt $SXT
SXT Chainがオンチェーンに置くのは、各テーブルの暗号学的コミットメントだけだ。テーブルの指紋のようなものだと考えればいい。実際のデータはオフチェーンに置かれ、クエリと証明はProverノードに任せる。検索が終わると、結果と証明をセットで返し、検証者は指紋と照合することで、改ざんの有無を確認できる。重要なのは、この指紋を更新できることだ。新しいデータが入ってきても、古い指紋と新しいデータから新しい指紋を計算できるため、過去のデータを遡って調べる必要がない。だからテーブルは増え続けても、チェーンが肥大化することはない。
私の見立てでは、この抑制こそが最も賢い点であり、最大の賭けでもある。賢いのは、イーサリアムやSolanaと汎用実行の分野で競おうとせず、その競争から手を引き、スマートコントラクトに最も欠けている機能、つまり質問できる能力だけを提供していることだ。賭けなのは、データのコミットメントだけを担うチェーンの価値が、「検証可能なクエリに継続的にお金を払う人がいる」ことに完全に依存している点だ。汎用チェーンなら、閑散としていても他のアプリケーションが支えになり得る。しかし、このチェーンには支えがない。需要がなければ、見た目だけは美しい空のチェーンになる。
もう一つ、過小評価されていると思う点がある。検証者はSXTをステークする必要があり、不正を働けば没収される。対象となるのは、コミットメントの改ざん、クエリ結果の検証不能、応答の遅延などだ。つまり、ここでのセキュリティは二重支払いを防ぐだけではなく、「データがこっそり書き換えられる」ことを防ぐものでもある。これは別のセキュリティ観だ。
だから私は、TPSではなく、二つのことだけに注目している。実際のクエリリクエストが継続的に増えているか、そして実際に料金を払っているのは誰なのか。前者は需要を示し、後者はその需要が補助金で積み上げられたものかどうかを決める。
@SpaceandTime この道がうまくいくかどうか、$SXT の価値獲得はここにかかっている。#SXT
#sxt $SXT
