@SuccinctLabs 和 @RiscZero 在实时证明方面取得的进展令人印象深刻。 QT-ing 不是为了批评，而是因为我认为这些问题非常有趣（我希望看到 RTP 在以太坊上实现！）。 1. 在 12 秒内证明所有历史以太坊区块并不足以覆盖最坏情况下的证明时间。 这很重要，因为可能存在病态（"证明杀手"）区块，其中证明成本 >> 燃气成本（证明成本是延迟或 $ 的衡量标准）。 第一步是在 12 秒内证明所有历史区块。但这还不够。我们需要努力识别尚未出现在以太坊上的病态案例。不确定 SP1 的成本安排是什么，但像整个区块充满 extcodehash 这样的情况在延迟方面可能会很昂贵。 2. 形式验证也需要覆盖编译器 😱 @argumentxyz 有一篇关于发现编译器错误频率的好文章（简而言之，有一类特定的 "误优化错误" 可能在 zkVM 中被利用，从而产生健全性问题。这些错误相对频繁地被发现。 @drakefjustin 认为我们可以通过许多 zkVM 实现来规避这个问题。但如果这些 zkVM 共享相同的编译器工具链并且容易受到相同错误的影响，这就行不通了。 3. 不需要在家证明 我认为我同意在家证明不是必要的。我们已经依赖于像构建者这样的额外协议参与者来构建区块。我们想要的保证是 *某人* 始终可以生成证明。 将 RTP 推迟到所有证明者离线的 WW3 情景似乎有些过头。也许在这种情况下，以太坊可以默认回到一种模式，在这种模式下，燃气限制降低，区块被重新执行而不是通过 ZKP 验证。 4. 将燃气限制提高 100 倍可能会造成问题 并行证明确实有帮助，但时间非常紧迫，我们需要考虑见证生成（在许多 zkVM 中不可并行化）和递归。 递归开销应该以对数方式缩放，但如果燃气限制增加 100 倍，证明时间可能会超过区块时间。 附加 - 我认为以太坊减少区块时间和最终性时间非常重要，以帮助用户上链到 L2，跨越 CEX 等。这增加了对证明的延迟需求。 如果我们无法将区块时间缩短到 1 秒，因为最坏情况下 RTP 延迟的下限是 10 秒，那将是次优的。