以太坊L1-zkEVM路线图2026-从重新执行到零知识证明验证的架构跃迁

摘要

以太坊自诞生以来，全节点验证交易的方式始终依赖"重新执行"——每一个验证者必须独立重放区块内的全部交易，才能确认状态转换的正确性。这一模型在链上吞吐量有限的早期尚可运转，但随着Gas上限的持续上调与Layer 2数据发布需求的增长，重新执行的负担正逼近硬件瓶颈。2026年初，以太坊基金会zkEVM团队发布了L1-zkEVM正式路线图，标志着这一根本性问题的解决方案从理论探讨迈入工程实施阶段。核心思路是：用零知识证明替代重新执行——验证者不再逐笔重放交易，而是验证由Prover生成的zkEVM执行证明。这一架构变革需要多个协议层改进的协同推进：Execution Witness标准化（EIP-8025）使无状态输入成为可能；ePBS（EIP-7732）将证明窗口从1-2秒扩展至6-9秒；Block-Level Access Lists（EIP-7928）为证明消除状态访问盲区；Guest Program与zkVM-Guest API定义了证明生成的标准化接口。本文逐一拆解这些子主题的技术机制，分析端到端工作流管道、性能权衡与安全假设，并对路线图的可行性与潜在风险给出独立判断。

一、引言：重新执行的宿命与突围

以太坊的共识模型中，任何一个全节点若要确认某个区块的合法性，唯一的方法就是拿到区块体中的全部交易列表，从头到尾逐笔执行一遍，将最终的状态根与区块头中声明的状态根比对。这个"重新执行"（re-execution）范式在架构上是简洁的——它不需要信任任何第三方，只要自己的机器跑出来的结果与声明一致，就认可该区块。

然而简洁的代价是昂贵的。当以太坊的Gas上限从早期的300万提升至6000万（截至2025年底），单个区块内包含的交易数量和计算复杂度水涨船高。运行一个全节点的硬件门槛持续攀升：从一块普通SSD就能搞定的轻量验证，到如今需要高性能CPU和大容量NVMe存储才能跟得上链的节奏。节点运营成本的增加直接威胁着以太坊去中心化的根基——如果只有数据中心级别的机器才能做验证，"任何人都可以验证"的承诺就成了一句空话。

零知识证明技术的引入为这个问题提供了一条截然不同的突围路径。核心思想并不复杂：与其让每个验证者都重新执行一遍，不如让一个（或多个）Prover执行计算并生成一个简洁的证明，验证者只需检验这个证明即可。证明的验证耗时远低于重新执行，而且证明的尺寸远小于原始交易数据——这正是zk-SNARKs"简洁性"的含义。

但这套方案要落地到以太坊L1共识层，远非"把zk-SNARKs套上去"那么简单。从交易执行到证明生成，再到证明的共识层验证，每一个环节都需要协议级改造。这正是2026年L1-zkEVM路线图试图解答的核心问题。

二、范式转换：从重新执行到证明验证

2.1 当前模型的全节点负担

在当前的以太坊架构下，验证者的工作流如下：收到新的区块后，从本地状态数据库中读取交易所涉及的所有账户和存储槽，按照EVM规则逐笔执行交易，更新状态树，计算新的状态根。如果计算出的状态根与区块头中声明的一致，则投票赞成该区块。

这个过程存在几个硬性约束：

计算量与交易复杂度线性相关。一笔涉及大量SLOAD操作的合约调用，其执行时间可能比一笔简单的ETH转账高出数百倍。Gas上限的设定在一定程度上限制了单区块的计算总量，但无法消除线性增长的本质。
状态访问的随机性。EVM执行过程中的状态访问模式取决于交易逻辑，对缓存极不友好。一次合约调用可能跳跃式地访问存储树中相距甚远的槽位，导致大量的随机I/O。
多客户端冗余。以太坊运行着多个独立的客户端实现（Geth、Nethermind、Besu、Prysm等），每个客户端都需要独立完成全部重新执行。这虽然带来了多样性安全增益，但也意味着计算资源的成倍消耗。

2.2 zkEVM证明作为替代方案

L1-zkEVM的愿景是：将上述"重新执行→比对状态根"的验证模型，替换为"验证zkEVM证明→接受状态转换"的新模型。具体而言：

Prover（证明者）执行区块内的全部交易，并生成一个zk-SNARK证明，声称"我已经按照EVM规则正确执行了这些交易，得到了声明的状态根"。
Verifier（验证者）不再执行交易，而是检验这个zk-SNARK证明。验证的计算量远小于重新执行——通常在毫秒级，而重新执行可能需要数百毫秒甚至秒级。

这一转换的安全基础在于zk-SNARKs的可靠性（soundness）：如果Prover声称的执行结果是错误的，那么它以不可忽略的概率无法生成一个能通过验证的证明。换句话说，只要证明通过验证，验证者就可以以极高的置信度相信状态转换的正确性。

EIP-8025（Optional Execution Proofs）是这一范式转换在协议层的关键提案。它引入了"可选执行证明"的机制：信标节点可以选择通过验证ZK证明来确认执行载荷的有效性，而无需运行EL客户端重新执行交易。选择这条路径的验证者被称为zkAttester（或无状态验证节点），它们不执行交易，而是接收并验证由Prover生成的zkEVM证明。zkAttester与传统重新执行的验证者可以共存，形成混合验证模型。

这种可选的设计是一个重要的务实选择。zkEVM证明系统本身也需要经过充分的实战检验，不可能一蹴而就地完全替代重新执行。允许两种模式并存，既为新技术的引入提供了缓冲期，也保留了传统验证方式作为安全兜底。

三、端到端工作流管道解析

理解L1-zkEVM的技术架构，最直观的方式是跟踪一个区块从产生到验证证明的完整生命周期。下面的流程图展示了这一端到端管道：

flowchart TD
    A[EL客户端接收新区块] --> B[执行区块内全部交易<br>生成状态转换]
    B --> C[提取Execution Witness<br>无状态化输入数据]
    C --> D[打包区块+Witness<br>输入zkEVM Guest Program]
    D --> E[Guest Program执行无状态验证<br>确认状态转换正确]
    E --> F[Prover生成zk-SNARK证明<br>证明执行正确性]
    F --> G[证明提交至共识层]
    G --> H{CL客户端验证证明}
    H -->|证明有效| I[接受区块<br>状态转换确认]
    H -->|证明无效| J[拒绝区块<br>触发惩罚机制]

    style A fill:#1a1a2e,color:#e0e0e0
    style E fill:#16213e,color:#e0e0e0
    style F fill:#0f3460,color:#e0e0e0
    style I fill:#1a472a,color:#e0e0e0
    style J fill:#6b0f1a,color:#e0e0e0

管道各环节详解

环节一：EL客户端执行与状态转换生成。 执行层（EL）客户端在收到新区块后，按传统方式执行所有交易，生成状态转换。这一步与当前以太坊的运行方式完全一致。关键区别在于，EL客户端执行后不仅仅产出新的状态根，还需要提取一份"Execution Witness"——这是后续证明生成所必需的无状态化输入。

环节二：Execution Witness提取。 这是整个管道中最关键的数据转换环节。Execution Witness是一份"自包含"的数据包，包含了验证区块内所有交易所需要的全部状态数据，但不依赖任何外部状态数据库。具体来说，它包含：

区块执行前所有被访问账户的状态（余额、Nonce、代码哈希、存储根）
所有被读取的存储槽的值
区块执行后所有被修改账户的新状态
所有被写入的存储槽的新值

有了这份Witness，任何一个实体都可以在不持有以太坊完整状态的情况下，验证该区块的执行正确性——这正是"无状态验证"的含义。提取Witness的RPC端点debug_executionWitness已在多个EL客户端中实现。

环节三：Guest Program无状态执行。 zkEVM Guest Program是一个运行在zkVM内的程序，它接收"区块数据 + Execution Witness"作为输入，在不访问任何外部状态的情况下执行所有交易，并验证最终状态根是否匹配。Guest Program的执行是确定性的——相同的输入必定产生相同的输出——这是生成零知识证明的前提。

环节四：Prover证明生成。 在Guest Program执行完毕后，Prover（证明后端）为这次执行生成一个zk-SNARK证明。证明的生成是计算密集型的，涉及大量的多项式运算和FFT计算。当前Prover的实现主要基于RISC-V指令集目标，使用GPU加速来缩短证明时间。

环节五：共识层证明验证。 生成的证明被提交至共识层（CL），CL客户端调用验证算法检验证明的有效性。验证的计算量极低，通常在毫秒级完成。如果证明通过验证，CL客户端接受该区块的状态转换；如果验证失败，则触发相应的惩罚机制。

这个管道的设计体现了"关注点分离"的架构思想：EL负责执行和Witness提取，Guest Program负责确定性无状态验证，Prover负责证明生成，CL负责证明验证。每一层的职责边界清晰，但数据流的衔接需要严格的标准化。

四、六大子主题的技术深度拆解

L1-zkEVM路线图包含六个子主题，每个子主题都对应一组独立的工程挑战。下面的架构图展示了它们的相互依赖关系：

graph TB
    subgraph 数据层
        EW[Execution Witness<br>数据结构标准化]
        BAL[EIP-7928 BALs<br>区块级访问列表]
    end
    subgraph 证明层
        GP[Guest Program<br>无状态验证程序]
        API[zkVM-Guest API<br>标准化接口]
        PI[Prover基础设施<br>GPU/ASIC实现]
    end
    subgraph 共识层
        CI[共识层集成<br>EIP-8025/zkAttester]
        FV[形式化验证<br>Guest+Prover+Verifier]
    end

    EW --> GP
    BAL --> EW
    GP --> API
    API --> PI
    PI --> CI
    GP --> FV
    PI --> FV
    CI --> FV

    style EW fill:#2d3436,color:#dfe6e9
    style BAL fill:#2d3436,color:#dfe6e9
    style GP fill:#0c2461,color:#dfe6e9
    style API fill:#0c2461,color:#dfe6e9
    style PI fill:#0c2461,color:#dfe6e9
    style CI fill:#6a0572,color:#dfe6e9
    style FV fill:#6a0572,color:#dfe6e9

4.1 Execution Witness数据结构标准化

Execution Witness不仅是Guest Program的输入，更是整个L1-zkEVM管道中数据标准化的基石。如果不同EL客户端生成的Witness格式不一致，Guest Program就无法跨客户端工作，证明的可移植性也将无从谈起。

当前标准化的核心工作集中在以下方面：

Witness数据格式规范：定义统一的RLP/SSZ编码格式，确保所有EL客户端产出的Witness可被任何zkVM消费。
debug_executionWitness RPC端点：提供标准化的调试接口，允许外部工具提取任意区块的Witness。这对开发者调试和基准测试至关重要。
Witness完整性校验：需要确保Witness包含了所有必要的状态访问数据。遗漏任何一项都会导致Guest Program执行结果与实际不一致，进而使证明无效。

一个容易忽视的细节是：Witness中不仅需要包含成功的状态访问，还需要包含"失败路径"中的访问——例如，一个SLOAD操作读取了一个从未被写入过的存储槽，此时返回的默认值为零。如果Witness不记录这类"零值访问"，Guest Program就无法区分"槽位值为零"和"槽位不存在"两种情况，可能导致验证偏差。

4.2 Guest Program与zkVM-Guest API

Guest Program是运行在zkVM内的确定性验证程序。它的设计目标是：给定"区块 + Witness"，独立验证区块执行的正确性，不依赖任何外部状态。

zkVM-Guest API的标准化工作正在推进中，核心内容包括：

最小硬件目标定义：规定Guest Program可用的内存空间、指令集扩展等。当前RISC-V 32-bit是最主要的目标架构，但32-bit地址空间的限制（4GB）可能在处理大型区块时成为瓶颈，64-bit扩展也在讨论中。
公共C头文件：提供标准化的C语言接口，使Guest Program可以跨不同的zkVM实现编译运行。这类似于操作系统为用户态程序提供的系统调用接口——Guest Program通过API与zkVM交互，但不依赖特定zkVM的内部实现。
内存布局与未对齐访问规范：EVM的内存模型允许未对齐访问（如MLOAD可以从任意偏移量读取32字节），而RISC-V的标准规范对未对齐访问的处理取决于具体实现。标准化规范需要明确：Guest Program中的未对齐访问应如何被zkVM处理。

Guest Program的正确性是整个证明系统的安全根基。如果Guest Program本身存在逻辑错误（例如对某个EVM操作码的语义实现不正确），那么即使证明系统本身是安全的，生成的证明也只能证明"错误的执行是正确的"。这正是形式化验证不可或缺的原因。

4.3 共识层集成与zkAttester

证明生成后，需要在共识层被验证和接受。当前共识层集成的核心工作围绕EIP-8025的机制设计展开，同时需要修改信标链共识规范（consensus-specs）以支持证明的提交、验证和接受的完整流程。

zkAttester是共识层的关键新角色。在传统的以太坊共识中，Attester（投票验证者——指对区块进行投票的验证者，与零知识证明中的Prover是完全不同的概念）通过重新执行来验证区块。引入zkEVM后，部分Attester可以选择运行zkAttester客户端，即通过验证zk-SNARK证明来确认区块的正确性，而不需要执行交易。

zkAttester的引入带来一个微妙的共识安全问题：如果网络中同时存在传统Attester和zkAttester，而两者对同一个区块的有效性判断不一致（例如传统Attester认为区块有效而zkAttester认为证明无效），共识层应如何处理？当前的方案是：在过渡期，传统Attester的判断优先——如果重新执行的结果与区块声明一致，则即使证明验证失败，区块仍可被接受。这相当于传统验证作为"安全兜底"，zk验证作为"效率增强"。随着证明系统的成熟和安全增益的验证，zkAttester的权重将逐步提升。

不过，这种"传统优先"的原则也存在需要关注的安全维度。当zkAttester的证明验证失败而传统Attester接受区块时，存在两种可能性：其一是证明系统本身的实现缺陷导致有效证明无法通过验证（假阴性），此时传统验证兜底是合理的；其二是Prover未能及时生成证明，或证明确实揭示了执行中的错误——后者意味着区块可能存在问题，但传统验证因实现了相同的错误代码路径而接受了它。区分这两种情况在当前设计中尚未解决，需要随着zkAttester客户端的成熟而引入更精细的否决信号机制，使zkAttester的"否决"可以被网络识别和评估。

4.4 Prover基础设施

Prover是整个L1-zkEVM架构中计算开销最大的组件。当前的主要进展包括：

Ethproofs与Ere集成：Ethproofs是以太坊基金会的证明生成服务，负责为以太坊主网区块生成zkEVM证明。Ere是eth-act下的统一zkVM接口与工具包（Unified zkVM Interface & Toolkit），提供编译、执行、证明、验证的统一Rust API，使不同zkVM后端实现可以互换使用。两者的集成意味着证明生成的基础设施正在从实验阶段走向生产化，开发者和运营者可以通过Ere的统一接口适配多种zkVM，而不必为每种实现单独开发集成代码。
GPU实现开源化：多项式运算和FFT是证明生成的计算瓶颈，GPU的大规模并行计算能力可以显著加速这些操作。将GPU实现开源，有助于降低Prover运营的门槛，避免证明生成被少数拥有专用硬件的实体垄断。
证明可靠性指标：定义标准化的度量指标来评估Prover的性能，包括：证明生成时间、证明大小、验证时间、证明成功率（成功生成的证明占尝试总数的比例）。这些指标对于比较不同Prover实现、追踪性能改进至关重要。

证明生成延迟是当前最关键的性能瓶颈。以太坊的出块时间为12秒，如果证明生成时间远超12秒，Prover就无法为每个区块实时生成证明。当前的实际数据显示，标准区块的证明生成时间仍在数十秒到数分钟级别，远未达到实时性要求。ePBS的引入是缓解这一问题的关键——它将证明的时间窗口从当前Attester验证窗口中扣除执行验证后的约1-2秒，扩展至6-9秒，但即便如此，要实现每个区块的实时证明仍需要Prover性能的数量级提升。

4.5 基准测试与度量

理解Prover性能的瓶颈，需要建立从"EVM操作"到"证明时间"的完整性能模型。这涉及三个层次的映射：

操作码使用→原生周期计数：统计区块执行中每种EVM操作码的调用次数，然后根据zkVM的实现，将每种操作码映射到对应RISC-V指令的周期数。这一层映射相对直接——每种EVM操作码在RISC-V上的实现是确定的。
原生周期计数→证明时间：将Guest Program的RISC-V执行周期数映射到Prover的证明生成时间。这一层映射更加复杂，因为证明时间不仅取决于执行周期数，还取决于多项式度数、FFT大小等证明系统参数。

当前的基准测试数据显示，对于典型的以太坊区块，Guest Program的RISC-V执行周期数在数亿级别，而证明生成时间与周期数大致呈超线性关系。这意味着：减少Guest Program的执行周期数（例如通过优化EVM操作码的RISC-V实现）是缩短证明时间的有效途径，但收益会随周期数的减少而递减。

4.6 安全与形式化验证

形式化验证是L1-zkEVM安全保证的最后一道防线。需要验证的组件包括：

Guest Program的正确性：验证Guest Program对每个EVM操作码的语义实现与以太坊黄皮书规范一致。由于EVM操作码数量众多且部分语义极其复杂（如CREATE2的地址计算规则），这一验证工作量巨大。
zkVM的正确性：验证zkVM的执行模型忠实反映了RISC-V规范。这包括指令解码、寄存器读写、内存访问等基础操作。
SNARK Prover/Verifier的正确性：验证证明系统的可靠性——即恶意Prover无法伪造证明。这涉及算术化方案（如Plonk的copy constraint）、多项式承诺方案（如KZG）的安全性证明。

形式化验证的难度在于：这些组件之间存在深度的交互依赖。Guest Program的正确性依赖zkVM的正确性，zkVM的正确性依赖底层算术化的正确性，而算术化的正确性又依赖密码学假设（如Knowledge Soundness）。形式化验证需要将这一整条信任链完整覆盖，才能提供端到端的安全保证。

五、关键依赖：ePBS与证明时间窗口

5.1 没有ePBS时的不可行性

在当前的以太坊区块构建流程中，Attester在收到完整区块后需要在约4秒的投票窗口内完成共识验证和执行状态转换验证。扣除执行验证本身的耗时后，留给证明生成和验证的时间窗口仅有约1-2秒。对于zkEVM证明生成而言，这个时间窗口远远不够——当前Prover生成一个标准区块的证明需要数十秒甚至更长。

这意味着，如果要在现有的区块构建流程中集成L1-zkEVM，证明生成必须在区块构建之前完成（即对前一区块的证明），或者证明生成必须异步进行。但这两种方案都会引入新的复杂性：前者要求Prover的速度跟得上出块节奏，后者则需要在共识层引入证明提交的异步机制。

5.2 ePBS如何扩展证明窗口

ePBS（enshrined Proposer-Builder Separation，EIP-7732）的核心改动是将Proposer和Builder的角色在协议层分离。在ePBS下，区块构建的时序如下：

sequenceDiagram
    participant Proposer as Proposer
    participant Builder as Builder
    participant Attester as Attester
    participant Prover as Prover

    Proposer->>Builder: 广播slot分配
    Builder->>Builder: 构建区块体
    Builder->>Proposer: 提交区块头+出价
    Proposer->>Proposer: 选择最高出价
    Proposer->>Attester: 广播已签名区块头
    Note over Attester: Attester投票确认区块头<br>（此时区块体尚未揭示）
    Builder->>Attester: 揭示区块体
    Note over Prover: Prover开始生成证明<br>（6-9秒窗口）
    Prover->>Attester: 提交zkEVM证明
    Attester->>Attester: 验证证明<br>确认状态转换

时序详解

这个序列图展示了ePBS下Proposer-Builder-Attester的交互时序，以及Prover在其中获得的6-9秒证明窗口。逐步拆解如下：

步骤一：Proposer广播slot分配。 当轮值的Proposer被确定后，它向网络广播自己即将负责的slot编号。这是ePBS流程的起点。

步骤二：Builder构建区块体。 收到slot分配信息后，注册的Builder们开始各自构建区块体。Builder从交易池中选取交易、排序、执行，形成完整的区块体（包含交易列表和执行后的状态根）。这个过程中Builder的竞争逻辑与当前的MEV-Boost类似——Builder通过优化交易排序来最大化MEV提取，并将部分收益以出价的形式传递给Proposer。

步骤三：Builder提交区块头和出价。 各Builder将自己的区块头（不含区块体）连同出价金额提交给Proposer。区块头包含状态根、交易根、receipt根等承诺值，但不暴露具体交易内容。

步骤四：Proposer选择最高出价。 Proposer从所有提交中选择出价最高的Builder，签名确认该区块头。此时Proposer只看到区块头和出价，不需要执行任何交易——这是ePBS与传统流程的关键区别。

步骤五：Attester投票确认区块头。 Attester对已签名的区块头进行投票。注意，此时区块体尚未揭示，Attester的投票仅确认"这个slot的区块头已被Proposer签名确认"。这相当于一个"承诺"——Builder已经承诺了一个区块体，但尚未公开。

步骤六：Builder揭示区块体。 投票确认后，Builder必须在规定时间内揭示完整的区块体。如果Builder未能按时揭示，将受到协议级惩罚——其质押的ETH将被部分罚没。

步骤七：Prover生成证明。 区块体揭示后，Prover获取区块数据和Execution Witness，开始生成zkEVM证明。ePBS的设计将区块头确认与区块体揭示之间的时间间隔拉长，为Prover创造了6-9秒的证明窗口。这个窗口虽然仍然不足以让当前的Prover实时完成证明生成，但已经将"不可能"缩小为"非常困难"——这是工程进步的基础。

步骤八：Prover提交证明。 证明生成完毕后，Prover将证明提交至共识层。

步骤九：Attester验证证明。 Attester调用证明验证算法，确认证明的有效性。验证耗时在毫秒级，不会成为瓶颈。

5.3 Glamsterdam升级与ePBS的协议级保障

Glamsterdam（以太坊的下一个重大升级，预计2026上半年上线）是ePBS的关键载体。ePBS的协议级保障体现在以下几个方面：

Builder成为协议级参与者：在当前的MEV-Boost中，Builder是链下中继网络中的角色，协议层并不感知Builder的存在。ePBS将Builder引入协议层——Builder需要在信标链上注册身份、质押保证金、签名出价。这意味着Builder的行为受到协议层约束，违规将受到罚没。
Builder问责机制：如果Builder提交了区块头但未按时揭示区块体，其质押的保证金将被罚没。这消除了当前MEV-Boost中"中继审查"和"Builder withholding"的信任问题——协议层的罚没机制替代了对中继运营者的信任依赖。
证明窗口的协议级保障：ePBS通过将区块头确认和区块体揭示分离，在协议层创造了一个固定的时间窗口用于证明生成。这个窗口的长度不是由Prover的性能决定的，而是由协议参数确定的——即使Prover速度慢，窗口也不会被压缩。

六、EIP-7928（BALs）与ZK验证的协同效应

Block-Level Access Lists（BALs，EIP-7928）是另一个与L1-zkEVM高度协同的协议改进。BALs的核心功能是：在区块级别声明该区块内所有交易所访问的状态——包括账户和存储槽的读写集合。

6.1 BALs对ZK验证的意义

在当前的无状态验证模型中，Execution Witness隐含地包含了状态访问信息——因为Witness中记录了所有被读取和写入的状态值。但Witness的构造方式是从执行结果中提取的，而非预先声明的。这意味着：

Witness的生成必须依赖完整的状态数据库——EL客户端必须先执行区块，才能知道哪些状态被访问了。
Witness的完整性校验困难——如何确认Witness没有遗漏任何状态访问？

BALs的引入改变了这一局面。如果区块在构建时就声明了完整的访问列表，那么：

证明盲区消除：BALs预先声明了区块的所有状态访问，Prover可以将BALs与Execution Witness进行交叉验证，确保没有遗漏任何状态依赖。这消除了"证明覆盖不完整"的风险。
并行执行基础：BALs声明了每个交易的读写集合，使得多个交易的并行执行成为可能——只要两个交易的写集合不相交，就可以安全地并行执行。并行执行又可以反过来加速证明生成（将区块内的交易分组，分别生成子证明，再聚合为完整证明）。
Gas重新定价依据：BALs提供了精确的状态访问统计，为Gas重新定价提供了数据基础。EIP-7904/8037/8038等提案正在重新调整操作码的Gas定价以反映实际计算和状态访问开销，这些调整客观上也将使Gas价格更接近ZK-friendliness的方向——即证明开销较高的操作码（如需要大量多项式承诺的操作）将承担更高的Gas成本。

6.2 BALs + ePBS的协同

BALs与ePBS的组合为L1-zkEVM创造了更有利的运行环境。在ePBS的框架下，Builder在构建区块时就可以生成BALs，并将其作为区块头的一部分提交给Proposer。这样，当区块体被揭示后，Prover可以立即获取BALs和区块体，开始证明生成——不需要等待EL客户端从状态数据库中提取Execution Witness。

这种"预先声明+事后验证"的模式，将证明生成的启动时间从"区块揭示+Witness提取"提前到"区块揭示"，进一步压缩了证明生成的前置开销。

七、性能权衡与挑战分析

L1-zkEVM的架构跃迁并非没有代价。在从重新执行向证明验证迁移的过程中，多个维度的权衡需要审慎考量。

7.1 证明生成延迟 vs 验证效率

这是最根本的权衡。zk-SNARKs的"简洁性"（Succinctness）意味着验证是高效的，但证明生成是计算密集的。在L1-zkEVM的语境下，这意味着：

验证者的硬件门槛大幅降低：验证一个zk-SNARK证明的计算量仅为毫秒级，远低于重新执行的数百毫秒到秒级。这对轻客户端和移动端验证者是重大利好。
Prover的硬件门槛极高：实时证明生成需要高性能GPU集群，运营成本远超普通全节点。这可能导致证明生成集中在少数专业机构手中，形成新的中心化风险。

缓解这一风险的方向包括：Prover实现的完全开源、证明生成的去中心化网络（允许多个独立Prover竞争生成证明）、以及专用ASIC的开发。但这些方案各自也有工程和经济层面的挑战。

7.2 多客户端zk证明的安全增益 vs 协调复杂度

以太坊的多客户端哲学——运行多个独立实现的客户端以降低单点故障风险——在zkEVM证明领域同样适用。如果多个独立的Prover（基于不同的zkVM实现）为同一个区块生成证明，且所有证明都通过验证，那么安全性将显著高于单一Prover——因为多个独立实现同时存在相同漏洞的概率极低。

但多Prover的协调是复杂的：

证明格式标准化：不同Prover生成的证明格式可能不同，CL客户端需要支持多种证明格式的验证。
证明提交时序：如果多个Prover的证明生成时间不一致，CL客户端需要定义"何时可以确认"的规则——是否需要等待所有Prover的证明？还是只要一个证明通过即可？
矛盾处理：如果两个Prover对同一个区块生成了不同的证明（一个通过验证，一个不通过），共识层应如何裁定？

当前的路线图倾向于"渐进式引入"：先部署单一Prover的证明验证，验证其稳定性和安全性后，再逐步引入多Prover验证。

7.3 Gas重新定价对DApp开发的影响

ZK-friendliness驱动的Gas重新定价可能显著改变DApp开发的成本结构。当前，EVM操作码的Gas定价基于"计算复杂度+状态访问开销"的模型，但未考虑"证明生成开销"。例如，MLOAD操作在传统执行中开销很低，但在zkVM中可能需要额外的多项式承诺来验证内存读取的正确性，导致证明开销远高于执行开销。

如果Gas价格按照ZK-friendliness重新调整：

存储密集型DApp的Gas成本可能上升：频繁读写存储槽的合约（如DEX的流动性池）可能面临更高的Gas费用，因为存储操作的证明开销较高。
计算密集型DApp的Gas成本可能下降：纯计算操作（如哈希运算、签名验证）的证明开销相对较低，Gas价格可能下调。

这种重新定价对DApp开发者意味着：合约的Gas优化策略需要从"减少状态访问"扩展为"兼顾状态访问和证明开销"。长期来看，这可能催生新一代"ZK-native"的合约设计模式——从架构层面就考虑证明效率，而非仅仅优化传统执行路径。

八、案例深挖：Builder惩罚机制与证明可靠性

8.1 Builder未按时揭示的协议级惩罚

在ePBS框架下，Builder提交区块头后必须在规定时间内揭示区块体。如果Builder未能按时揭示，协议级惩罚机制将启动：

保证金罚没：Builder在注册时质押的保证金将被部分罚没。罚没金额的设计需要平衡"威慑力"和"参与意愿"——罚没过轻无法有效威慑恶意行为，罚没过重则可能抑制Builder的参与积极性。
声誉记录：Builder的未揭示行为将被记录在链上，作为其声誉数据的一部分。其他Proposer在选择Builder时可以参考这些数据。
紧急区块构建：当Builder未按时揭示时，Proposer需要有能力构建一个"紧急区块"——通常是一个只包含标准交易（无MEV提取）的区块——以确保slot不被浪费。

这个惩罚机制是ePBS与当前MEV-Boost的关键区别之一。在MEV-Boost中，如果Builder提交了区块头但未揭示区块体，中继运营者只能将Builder列入黑名单，但无法罚没其质押物。ePBS将这一惩罚机制纳入协议层，消除了对中继运营者信任的依赖。

8.2 证明可靠性问题

Prover生成的证明并非100%可靠。可能出现的问题包括：

证明生成失败：Prover在生成证明的过程中遇到内部错误（如内存溢出、计算超时），导致无法生成证明。这种情况下，该区块的证明将缺失，zkAttester无法通过证明验证确认区块有效性，需要回退到传统验证。
证明验证失败但实际有效：由于证明系统实现中的缺陷（如算术化中的边界条件处理错误），可能产生"实际上正确但无法通过验证"的证明。这类问题的调试极为困难，因为证明系统的内部状态是高度压缩的，无法像传统执行那样逐步回溯。
恶意Prover提交伪造证明：如果zk-SNARK系统的安全假设被打破（例如信任设置的毒性废料被泄露），恶意Prover可能伪造能通过验证的证明。这是最严重的安全威胁，也是形式化验证需要重点防范的场景。

路线图中的应对策略包括：建立证明生成成功率监控面板、制定证明缺失时的降级方案（回退到传统验证）、以及推进形式化验证以排除证明系统实现中的缺陷。

九、路线图展望与开发者行动指南

9.1 2026下半年至2027年的里程碑预测

基于当前路线图的进展和工程复杂度，可以做出以下审慎预测：

2026年Q3-Q4：Execution Witness标准化完成，debug_executionWitness RPC端点在主流EL客户端中稳定可用。Guest Program的第一个稳定版本发布，支持以太坊主网区块的无状态验证。Prover基准测试数据公开，展示标准区块的证明生成时间。
2026年Q4-2027年Q1：Glamsterdam升级上线，ePBS在主网激活。证明窗口扩展至6-9秒，为实时证明创造条件。zkAttester客户端的测试网部署。
2027年Q2-Q3：L1-zkEVM的混合验证模式在主网上线——传统Attester和zkAttester并行运行，验证证明系统的稳定性。如果一切顺利，zkAttester的权重将逐步提升。

这些预测基于"一切顺利"的假设。实际的工程进展可能受到多种因素影响：形式化验证中发现关键缺陷、ePBS在测试网上暴露出意料之外的问题、Prover性能提升速度不及预期等。任何一个环节的延迟都可能影响后续里程碑的时间线。

9.2 开发者如何参与

对于希望参与L1-zkEVM建设的开发者，以下是几个切入方向：

关注eth-act规划仓库：以太坊基金会的活动协调仓库（eth-act）追踪了L1-zkEVM的各项工作流和待办事项，是了解当前进展和贡献机会的最佳入口。
加入Discord频道：以太坊R&D Discord中的#l1-zkevm频道是核心开发者讨论技术细节的主要场所。非核心开发者可以通过阅读讨论和提出问题来熟悉技术上下文。
运行Prover基准测试：在本地搭建Prover环境，对以太坊主网历史区块生成证明，提交基准测试数据。这有助于社区了解不同硬件配置下的证明性能，识别瓶颈。
参与Guest Program的测试和审计：Guest Program的正确性是安全根基，社区审计可以发现核心团队遗漏的边界条件。

9.3 对L2 ZK-Rollup生态的溢出效应

L1-zkEVM的进展不仅影响以太坊L1本身，还将对L2 ZK-Rollup生态产生溢出效应：

证明基础设施的共享：L1-zkEVM推动的Prover基础设施（GPU实现、证明协调框架）同样适用于L2 ZK-Rollup的证明生成。L1的规模效应可以降低L2的证明成本。
标准化溢出：L1-zkEVM的标准化工作（Guest API、Witness格式、证明格式）可能被L2 ZK-Rollup采纳或适配，减少L2之间的碎片化。
Gas定价联动：如果L1的Gas定价向ZK-friendliness方向调整，L2的费用结构也可能随之变化——因为L2的数据发布成本与L1的Gas价格直接相关。

十、结语

L1-zkEVM不是一次简单的技术升级，而是以太坊验证模型的根本性重构。从重新执行到证明验证的跃迁，涉及数据标准化、证明系统设计、共识层改造、性能优化、安全保障等多个维度的深度工程，每个维度都有不可忽视的技术挑战和权衡。

路线图的发布是一个清晰的信号：以太坊核心开发团队对这一方向有坚定的共识和系统的规划。但从规划到落地的距离，往往比乐观估计的要远。证明生成的实时性、形式化验证的完备性、多客户端协调的复杂度——这些问题的解决需要持续的技术突破和工程迭代。

对于关注以太坊长期发展的人来说，L1-zkEVM是继The Merge之后以太坊最重要的架构变革方向之一。它的影响不仅限于验证效率的提升，更在于重新定义了"在以太坊上验证意味着什么"——从"我自己算一遍"到"我检验你的证明"，这一范式转换的深远影响，可能要到数年后才能被完整理解。

本文基于以太坊基金会L1-zkEVM路线图公开文档、EIP-8025/7732/7928/7870等提案、以及Ethproofs项目的公开数据撰写。文中技术判断为作者独立分析，不构成任何投资建议。