@SuccinctLabs と @RiscZero によるリアルタイム証明に向けた進歩は、非常に目覚ましいものでした。 QTは重要ではありませんが、これらの質問が本当に興味深いと思うからです(そして、RTPがイーサリアムにヒットするのを見たいです! 1. すべての過去のイーサリアムブロックを12秒以内に証明するだけでは、最悪のケースの証明時間をカバーするには不十分です。 これは、証明コストがガスコスト>>可能性のある病理学的(「証明キラー」)ブロックがあるため、重要です(証明コストはレイテンシまたは$の尺度です)。 最初のステップは、すべての履歴ブロックを12秒以内に証明することです。しかし、これだけでは十分ではありません。私たちは、イーサリアムにまだ現れていない病的な症例を特定するために努力する必要があります。SP1のコストスケジュールがどうなっているかはわかりませんが、extcodehashでいっぱいのブロックのようなものは、レイテンシの点で高くなる可能性があります。 2. フォーマル検証は、コンパイラ😱もカバーする必要があります @argumentxyzコンパイラのバグが見つかる頻度についての良い記事を持っていました(tl;dr ZkVMsで悪用され、健全性の問題を引き起こす可能性のある特定のクラスの「誤最適化バグ」があります。これらのバグはかなり頻繁に見つかります。 @drakefjustin、多くのzkVM実装でこれを回避できると主張しています。しかし、これらのzkVMが同じコンパイラツールチェーンを共有し、同じバグに対して脆弱である場合、それは機能しません。 3. 自宅での証明は不要 自宅での証明は必要ないという意見には同意すると思います。私たちはすでに、ブロックを構築するためにビルダーのようなプロトコル外のアクターに依存しています。私たちが望む保証は、*誰か*が常に証明を生成するために利用可能であるということです。 すべての証明者がオフラインになるWW3シナリオでRTPを延期するのはやり過ぎのように思えます。おそらく、このシナリオでは、イーサリアムはガス制限が減少し、ブロックがZKPで検証されるのではなく、再実行されるモードにデフォルトで戻る可能性があります。 4. ガスリミットを100倍にすると、問題が発生する可能性があります 並列化された証明は確かに役立ちますが、タイミングが非常に厳しいため、witness の生成 (多くの zkVM では並列化できません) と再帰を考慮する必要があります。 再帰オーバーヘッドは対数的にスケーリングする必要がありますが、ガス制限が 100 倍に増加すると、証明時間がブロック時間を超える可能性があります。 ボーナス - イーサリアムがブロック時間とファイナリティまでの時間を短縮することは、ユーザーがL2sにオンボードしたり、CEXからブリッジしたりするために非常に重要であると私は主張します。これにより、証明に必要なレイテンシが増加します。 最悪の場合のRTPレイテンシの下限が10秒であるため、1秒のブロック時間に移行できない場合は最適ではありません。