1/ 誇大広告に注意:SNARKとzkVMは大きな期待を寄せていますが、複雑でリスクの高いデプロイメントには対応できていません。バグはいたるところにあり、正式な検証は初期段階にあり、証明はネイティブの実行よりも数十万倍遅くなる可能性があります。

2/ zkVM開発のための構造化されたロードマップを概説する投稿を公開しました。「セキュリティステージ」と「スピードステージ」を分離し、進行状況を透過的に追跡する方法を提供します。ここで読んでください:

3/ セキュリティについては、正式な検証のための3つの段階を特定しています。 • 検証済みプロトコル • 検証済みの検証者 • 検証済みの証明者 ステージ2に到達するまで、zkVMを「安全」と呼ぶことはできず、そこに到達するのはまだ数年先になるでしょう。

4/ パフォーマンスの面では、ネイティブ実行に対するオーバーヘッドは依然として100,000×を超えており、ほとんどのユースケースでは不利です。私の投稿では、そのオーバーヘッドを桁違いに削減し、最終的にはデバイス上での証明を可能にするために、5つの「パフォーマンスステージ」を提案しています。

5/ 重要なことは、証明システムの基本的な効率性を分離しなければならないということです。現在、多くのベンチマークでは、プルーフシステム、エンジニアリング、ハードウェアブースト、手動で調整されたプリコンパイルなど、すべてが1つのトップラインの数値にまとめられており、私たちの本当の立ち位置が不明瞭になっています。

6/ zkVMとSNARKは大きな可能性を秘めていますが、プライムタイムの準備ができているふりをすると、私たちは大惨事に巻き込まれます。私はこれらのステージを使用して、今後数年間のzkVMの進捗状況を追跡します。また、他の人々もそうであることを願っています。ここで私の投稿をチェックしてください: