发布 L1 zkEVM #1：实时证明

发布 L1 zkEVM #1：实时证明

感谢 Kevaundray Wedderburn、Alex Stokes、Tim Beiko、Mary Maller、Alexander Hicks、George Kadianakis、Dankrad Feist 和 Justin Drake 提供的反馈和审核。

以太坊正在全力投入 ZK。最终，我们希望迁移到在堆栈的所有层级使用 ZK 证明，从共识层签名聚合到使用客户端证明的链上隐私等等。但第一步将是 L1 zkEVM。

我们如何在不到一年的时间内发布 L1 zkEVM

发布 L1 zkEVM 最快且最安全的方法是首先让验证者可以选择运行客户端，这些客户端不重新执行执行负载，而是无状态地验证由不同 zkVM 生成的多个（比如三个）证明，每个证明都证明不同的 EVM 实现。由于证明验证速度非常快且证明大小非常简洁，因此下载和验证多个证明是非常合理的，并且允许我们将与现有客户端多样性相同的深度防御应用于 zkVM。

为了最初离线验证执行证明，我们从协议中需要的是 Glamsterdam 中的某种形式的流水线，以允许更多的证明时间。

最初，我们预计很少有验证者会运行 ZK 客户端。随着时间的推移，它们的安全性将在生产中得到证明。随着以太坊基金会也将资源投入到形式验证、规范编写、审计和漏洞赏金中；我们预计采用率会缓慢增加。

当绝大多数 stake 对运行 ZK 客户端感到满意时，我们可以将 gas 上限提高到一定水平，这将要求运行合理硬件的验证者验证证明，而不是重新执行区块。一旦所有验证者都在验证执行证明，相同的证明也可以被 用于原生 zk-rollups。

定义 L1 的实时证明

我们执行此计划的最大优势在于能够利用整个 zkVM 行业，使以太坊成为迄今为止世界上最大的 ZK 应用程序。许多 zkVM 已经在证明以太坊区块，并且每周都会宣布性能突破。

为了维护 L1 的安全性、活跃性和抗审查性，以太坊基金会正在提议一个标准化的实时证明定义，供 zkVM 团队努力实现。

在证明系统方面，以实时证明为目标的 zkVM 应该以 128 位的安全性为目标，我们认为这是以太坊 L1 的正确长期目标。但是，我们愿意在部署的最初几个月接受至少 100 位的安全性，以适应达到 128 位安全性的短期工程挑战。证明大小应保持在 300KiB 以下，并且不得依赖使用可信设置的递归包装器。我们希望证明系统在 ZK 客户端投入生产时能够达到 128 位的安全性，并随着证明时间的减少进一步收紧安全要求（例如，关于猜想）。

考虑到当前 12 秒的 slot 时间和在网络上传播数据的最长时间约为 1.5 秒，实时意味着 10 秒或更短。我们希望 zkVM 能够在这个窗口中证明至少 99% 的主网区块，其余部分（以及合成的 DOS 向量）将在未来的硬分叉中得到缓解。

为了保持最高水平的活跃性和抗审查性，我们对实时证明的定义旨在实现“家庭证明”，其理念是目前在家中运行验证器的一些 solo staker 将选择加入证明。即使我们希望通过 在强制验证 ZK 证明之前加强抗审查性，家庭证明也是一个重要的最终保障。

由于在云中使用多 GPU spot 实例进行证明已经非常便宜，因此以实时证明为目标的 zkVM 团队的重点将主要放在优化在规范受限得多的本地运行证明器。本地实时证明需要的最大资本支出应为 10 万美元（在撰写本文时，运行验证器需要大约 8 万美元的 stake）。我们预计即使 gas 上限增加，这种情况也会随着时间的推移而下降。

与硬件成本相比，使用 GPU 进行家庭证明的最大限制是能源消耗。大多数住宅至少有 10kW 的电力从街道进入，有些住宅会有用于电器或为电动汽车充电的电路，容量为 10kW。因此，实时证明必须可以在 10kW 或更低的硬件上实现。

这使我们得出了实时证明的工作定义：

• 延迟：<= 10 秒，适用于 99% 的主网区块
• 本地 CAPEX：<= 10 万美元
• 本地功耗：<= 10kW
• 代码：完全开源
• 安全性：>= 128 位
• 证明大小：<= 300KiB，无可信设置

实时竞赛

从现在到 Devconnect Argentina，我们希望看到 zkVM 团队继续朝着实时家庭证明的方向创新，并希望领先的 zkVM 成为以太坊未来的核心基础设施。

• 原文链接： blog.ethereum.org/2025/0...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～