#sxt プロジェクトが速度をひとつの数字で要約するたびに、その数字が何を含んでいないのかを尋ねたくなります。Space and TimeはDeFi向けに検証可能なデータを提供しており、その根拠として最もよく示されるのは、ゼロ知識証明が1秒未満で生成されるという点です。それを受け入れる前に、時計が正確には何を計測しているのか知りたいのです。
飛行時間が55分のフライトを考えてみてください。旅客は自宅を出てから到着ロビーを出るまでを数えるので、誰もその旅を「55分」とは呼びません。Space and Timeの場合、Proof of SQLにおける証明の生成がフライトに当たります。その前に、確定済みのデータに対してクエリを実行しなければなりません。その後、証明を検証し、SXT Chainを通じて結果をスマートコントラクトに届ける必要があります。これらの工程は、空港までの移動、保安検査、そしてタクシー乗り場の列に相当します。
これは他の領域以上にDeFiで重要です。清算やリバランスはブロックごとに変わる市場に反応するため、Space and Timeからの回答が遅れれば、それは実質的に古い問いへの回答となります。フライトが速くても、旅の残りの時間も短くなければ意味がありません。
どのような処理を計測したのかという問題もあります。単純な検索と、数か月分の取引履歴を集計する処理とでは、まったく異なる道のりです。そしてリスクモデルが通常必要とするのは後者です。Space and Timeの速度を示す数値にクエリの種類やデータ量が添えられていなければ、どの処理についての数値なのか判断できません。
ですから、私の見方は単純です。その主張はフライトについては正確ですが、ドアから目的地までの所要時間については何も語っていません。ベンチマークとしては有効です。しかし、DeFiの開発者への約束としては、情報が足りません。
私が信頼できる証拠は、Space and Timeが示す、リクエストからコントラクトが利用できる結果に至るまでのエンドツーエンドの所要時間です。対象となるクエリとデータセットも明示されている必要があります。SXT Chain上のアクティビティから、実際に有料クエリの処理にどれだけ時間がかかるかを確認することもできます。それまでは、この数値をフライト時間として受け取ります。
$SXT @SpaceandTime <>
飛行時間が55分のフライトを考えてみてください。旅客は自宅を出てから到着ロビーを出るまでを数えるので、誰もその旅を「55分」とは呼びません。Space and Timeの場合、Proof of SQLにおける証明の生成がフライトに当たります。その前に、確定済みのデータに対してクエリを実行しなければなりません。その後、証明を検証し、SXT Chainを通じて結果をスマートコントラクトに届ける必要があります。これらの工程は、空港までの移動、保安検査、そしてタクシー乗り場の列に相当します。
これは他の領域以上にDeFiで重要です。清算やリバランスはブロックごとに変わる市場に反応するため、Space and Timeからの回答が遅れれば、それは実質的に古い問いへの回答となります。フライトが速くても、旅の残りの時間も短くなければ意味がありません。
どのような処理を計測したのかという問題もあります。単純な検索と、数か月分の取引履歴を集計する処理とでは、まったく異なる道のりです。そしてリスクモデルが通常必要とするのは後者です。Space and Timeの速度を示す数値にクエリの種類やデータ量が添えられていなければ、どの処理についての数値なのか判断できません。
ですから、私の見方は単純です。その主張はフライトについては正確ですが、ドアから目的地までの所要時間については何も語っていません。ベンチマークとしては有効です。しかし、DeFiの開発者への約束としては、情報が足りません。
私が信頼できる証拠は、Space and Timeが示す、リクエストからコントラクトが利用できる結果に至るまでのエンドツーエンドの所要時間です。対象となるクエリとデータセットも明示されている必要があります。SXT Chain上のアクティビティから、実際に有料クエリの処理にどれだけ時間がかかるかを確認することもできます。それまでは、この数値をフライト時間として受け取ります。
$SXT @SpaceandTime <>
