重い暗号処理ワークロードで報告されている45%〜250%のパフォーマンス差を見ていたのですが、正直なところ、その数値を見るとDuskのアプローチのほうがより興味深く思えました。
一般的な汎用VMの中でZK証明や署名チェックがこれほど重くなるなら、プライバシーは非常に早い段階で高コストになり得ます。
Duskは別の道を選びます。
用途を絞ったzkVMでは、重い暗号処理にはネイティブのホスト関数を利用しつつ、ネットワーク側では実行の決定性を保てます。重要なのは、バリデータが、あらゆるプライベートな計算を「さらに巨大なVMワークロード」として扱う必要がないことです。計算結果として得られる証明は、オンチェーンで検証できるからです。
この45%〜250%という範囲は単なる技術的な統計に見えるかもしれませんが、より大きな課題を示しています。プライベートなスマートコントラクトは「できるかどうか」だけでなく「実用的であること」が必要なのです。
私にとって、ここがDuskが面白くなるポイントです。機密性のあるアプリケーションが本当にスケールするなら、プライバシーそのものと同じくらい効率が重要になり得ます。
では、機関がどれほど追加の計算を許容すれば、用途を絞ったインフラが明らかな選択肢になり始めるのでしょうか?
@Dusk $DUSK #dusk
一般的な汎用VMの中でZK証明や署名チェックがこれほど重くなるなら、プライバシーは非常に早い段階で高コストになり得ます。
Duskは別の道を選びます。
用途を絞ったzkVMでは、重い暗号処理にはネイティブのホスト関数を利用しつつ、ネットワーク側では実行の決定性を保てます。重要なのは、バリデータが、あらゆるプライベートな計算を「さらに巨大なVMワークロード」として扱う必要がないことです。計算結果として得られる証明は、オンチェーンで検証できるからです。
この45%〜250%という範囲は単なる技術的な統計に見えるかもしれませんが、より大きな課題を示しています。プライベートなスマートコントラクトは「できるかどうか」だけでなく「実用的であること」が必要なのです。
私にとって、ここがDuskが面白くなるポイントです。機密性のあるアプリケーションが本当にスケールするなら、プライバシーそのものと同じくらい効率が重要になり得ます。
では、機関がどれほど追加の計算を許容すれば、用途を絞ったインフラが明らかな選択肢になり始めるのでしょうか?
@Dusk $DUSK #dusk