pa
スマートコントラクトが、ブロックチェーン上の過去の活動を使って意思決定するのに、なぜ今も苦労しているのかを考えていました。
融資プロトコルを例にしましょう。2つのウォレットの現在の残高がまったく同じでも、その履歴は大きく異なる可能性があります。一方は何年にもわたって責任ある借入と返済を続けてきたかもしれませんが、もう一方は昨日作られたばかりかもしれません。
コントラクトは現在の状態を確認できます。では、それ以前に起きたすべてのことを、どう評価するのでしょうか？
そこで私は、@SpaceandTime についてさらに詳しく調べ始めました。
私の関心を引いたのは、単にProof of SQLを使っているということではありません。スマートコントラクトが、データベースの計算を自ら実行せずに、どのように結果を受け取るのかという点です。
ここには重要な違いがあります。
スマートコントラクトが、突然データベースになるわけではありません。事前にコンパイルされたSQLクエリプランを、支払いとコールバック先とともに、Space and TimeのQueryRouterへ送信します。
クエリはSXT Chain上のテーブルに対して処理されます。システムは結果とともにProof of SQLを生成し、結果がリクエスト元のコントラクトに返される前に、その証明がオンチェーンで検証されます。
しかし、コールバックもまた興味深い部分です。
受信側のコントラクトは、応答が認可されたルーター実行者から届いたことを確認し、返されたデータを利用する前にデコードする必要があります。
つまり、データを受信することと、そのデータに基づいて安全に動作することは、別々のステップです。
これによって、アーキテクチャについての私の考え方が変わりました。重い計算はリクエスト元のコントラクトの外部で行われ、暗号学的な検証によって、コントラクトはデータセット全体を自分で処理することなく、返された結果を信頼できます。Space and Time +1
待ってください。見落としたくない点が、もう一つあります。
有効な証明があっても、元の情報が真実だったことにはなりません。
データ取り込み時に誤った情報がデータベースに入った場合、その確定済みデータに対してSQL計算が正しく実行されたことを証明しても、元の誤りが魔法のように修正されるわけではありません。データの完全性とデータの正確性は関連していますが、同じものではありません。証明。

@SpaceandTime #sxt $SXT