全新

通过即将推出的 IQ.wiki API,将专家精选的加密货币和区块链知识集成到您的应用中。

0% read

zkEVM

zkEVM

zkEVM(零知识 虚拟机)是一种虚拟机,它能够以与 虚拟机 (EVM) 兼容的方式执行智能合约,并利用零知识技术生成这些执行过程的加密证明。它被设计为 的扩展解决方案,旨在通过利用 主网来提高交易吞吐量并降低成本,同时保持高度的安全性。通过捆绑大量交易、在链下执行这些交易,然后向主区块链提交简洁的有效性证明,zkEVM 允许在不需要每个网络节点重新执行计算的情况下验证计算结果。[1] [2]

概述

zkEVM 开发的主要动力是解决 网络的扩展性瓶颈。在 的标准模型中,每个验证者节点都必须重新执行区块内的每笔交易以验证其有效性,这一过程被称为“N-of-N 执行”。这种冗余计算限制了网络的容量,也是高需求期间 Gas 费用居高不下的原因之一。[3]

zkEVM 提出了一种“1-of-N”模型,其中一个被称为“证明者”的单一专业实体执行一批交易,并生成一个简洁的密码学证明(零知识证明,即 ZK-proof)来确认执行的正确性。网络验证者随后只需验证这个计算成本极低的证明,而无需重新运行整个区块。这种范式转变极大地减轻了网络的计算负荷,从而实现了更高的吞吐量和更实惠的费用。[4]

虽然早期的 提供了扩展性优势,但它们往往以牺牲 EVM 兼容性为代价,将其用途限制在特定应用中,并要求开发人员学习新的语言或工具。zkEVM 是一个重大的演进,因为它们旨在与 EVM 兼容或等效,允许开发人员将现有的 智能合约和 部署到更具扩展性的层级上,且只需进行极少甚至无需进行代码修改。这种方法允许项目利用 广泛的开发者、工具和基础设施生态系统。[1] [5]

该技术主要应用于两个场景:作为运行在 之上的 Rollups,以及一个更具雄心的提案,即直接将 zkEVM 集成到 的一层网络 (Layer 1) 协议中,以扩展主网本身。[6]

zkEVM 的工作原理

zkEVM 架构从根本上由三个核心组件组成,这些组件促进了具有链上验证功能的链外计算。 [2]

核心组件

  • 执行环境:该组件复制了虚拟机,提供了一个可以执行由 等语言编写的智能合约的空间。它获取当前的区块链状态,处理用户提供的一批交易,并计算出更新后的新状态。它与 EVM 的兼容性使得现有的 dApp 能够无缝迁移。[2]
  • 证明电路:这是 zkEVM 的密码学引擎。它观察交易的执行过程并生成零知识证明,通常是 zk-SNARK 或 zk-STARK。该证明在密码学上证明了从初始状态到新状态的状态转换是有效的,并且所有计算都是根据 EVM 规则正确执行的。证明的生成过程不会泄露底层交易数据本身。[5] [2]
  • 验证者合约:这是一个部署在底层第 1 层区块链(例如)上的智能合约。zkEVM Rollup 将生成的有效性证明和更新后的状态数据提交给该合约。验证者合约的唯一功能是检查密码学证明。如果证明有效,新状态将被接受并在第 1 层链上最终确定。这种验证过程非常高效,避免了每个第 1 层节点重新执行交易的需要。[2]

证明过程

在zkEVM系统中,证明者以“无状态”方式执行区块,这意味着它不需要维护整个区块链状态的完整副本。相反,正在处理的交易所必需的状态数据作为输入提供,通常被称为“见证数据”(witness)。该输入附带默克尔证明(Merkle proofs),用于根据父区块的已知状态根验证其完整性。[4]

值得注意的是,在扩容的语境下,“zk”(零知识)这一术语在某种程度上可能具有误导性。虽然该技术可用于隐私保护,但zkEVM主要利用了SNARKs等零知识证明系统的“简洁性”(证明体量小)和“完整性”(证明在计算上是可靠的)特性。它们证明了计算执行的正确性,而不一定隐藏交易细节,因为隐私保护会增加额外的复杂性和证明成本。[6]

zkEVM 的类型

联合创始人 提出了一个 zkEVM 分类系统,根据它们与 的兼容程度将其分为不同类型。该系统强调了一个核心权衡:较高的兼容性(编号较低的类型)使得使用现有基础设施更加容易,但证明速度较慢且成本更高;而较低的兼容性(编号较高的类型)通过打破 标准实现了更快的证明时间。[2]

第1型(完全等同于以太坊)

第1型zkEVM旨在与完全且毫不妥协地等同。它们不对系统进行任何更改,包括哈希函数(如Keccak)、状态树或其他共识逻辑。

  • 优点:与所有去中心化应用(dApps)和基础设施完美兼容。区块浏览器和执行客户端等工具无需修改即可重复使用。
  • 缺点:证明生成速度极慢,因为协议的某些部分对零知识证明(ZK)并不友好。
  • 示例:这是用于第1层集成的zkEVM项目的既定目标。[2] [3]

第 2 类(完全等效于 EVM)

从开发者的角度来看,第 2 类 zkEVM 是完全等效的,但它们对底层的 架构进行了细微修改,例如使用不同的状态树结构,以加速证明生成。

  • 优点:与大多数现有应用程序兼容,提供比第 1 类更快的证明时间。
  • 缺点:对于某些用例,证明时间仍可能成为瓶颈。
  • 示例 zkEVM 和 是致力于实现这一等效水平的项目。[5] [2]

Type 2.5(除 Gas 成本外与 EVM 等效)

这是 Type 2 的一种变体,它增加了在 ZK 电路中特别难以证明的特定操作的 Gas 成本。这种修改改善了最坏情况下的证明时间,但可能会破坏依赖精确 Gas 成本计算的开发工具和智能合约。[2]

第3类 (几乎等同于EVM)

第3类zkEVM牺牲了完美的EVM兼容性,以进一步简化开发并提高证明器性能。它们可能会省略在ZK电路中特别难以实现的特性,例如某些预编译合约。

  • 优点:比第2类更容易构建,且提供更快的证明生成速度。
  • 缺点:某些应用程序可能需要修改代码才能部署。 zkEVM 和 的当前实现通常被认为更接近这种类型。[2]

第 4 类(高级语言等效)

第 4 类系统不追求 EVM 字节码层面的直接兼容性。相反,它们将使用 或 Vyper 等高级语言编写的智能合约源代码直接编译为 ZK 友好型语言或指令集。

  • 优点:可以显著缩短证明生成时间。
  • 缺点:字节码层面的不兼容可能会导致调试工具、合约地址以及使用手写 EVM 字节码的应用程序出现问题。
  • 示例:zkSync Era 是第 4 类 zkEVM 的一个突出代表。 [5] [2]

优势与挑战

优势

  • 安全的可扩展性:zkEVM 在链下执行交易以提高速度,但通过提交有效性证明在第 1 层(Layer 1)进行结算。这使得它们在以更高吞吐量运行的同时,能够继承母链的安全性和去中心化特性,有可能将交易处理能力从 的每秒约 30 笔交易 (TPS) 提升至 2,000 TPS 以上。 [2] [1]
  • 低成本:通过批量处理数千笔交易并将单次链上证明的成本分摊到这些交易中,zkEVM 可以大幅降低 Gas 费用。每笔交易的成本可以从近一美元降低到不到一美分。 [7] [1]
  • 快速最终性:一旦有效性证明被 上的验证者合约接受,zkEVM 上的交易即被视为最终确认。这避免了 Optimistic Rollups 所需的一到两周的挑战期,提高了资金效率和用户体验,尤其是在提现方面。 [2]
  • 开发者体验:EVM 兼容性或等效性是一项重大优势,允许开发者以极少的改动迁移现有的 dApp,并利用成熟的 开发者生态系统和工具。这利用了巨大的网络效应,并降低了构建者的学习曲线。 [7]

开发挑战

  • 证明成本与复杂性:生成零知识证明是一个计算密集型过程,通常需要专门且强大的硬件,这可能成为瓶颈和成本中心。 [5]
  • 架构不匹配:EVM 在设计之初并未考虑 ZK 证明。其基于栈的架构、复杂的指令集(如 CALL)以及使用对 ZK 不友好的哈希函数(如 Keccak),在为其执行过程创建证明时带来了显著的技术挑战和开销。 [2]
  • 兼容性与性能的权衡:正如 zkEVM 类型中所详述的,在实现完全的 兼容性与设计能够高效生成证明的系统之间存在内在的矛盾。 [5]
  • 去中心化担忧:证明生成对昂贵专业硬件的依赖引发了对潜在中心化的担忧,因为可能只有少数资源充足的实体能够作为证明者或排序器参与其中。 [5]

安全考量

将 zkEVM 集成到 生态系统中(无论是 还是 ),都会引入新的安全考量和潜在的攻击向量。 的研究已经确定了许多值得关注的领域。[6]

系统多样性

一个主要关注点是单点故障的风险。如果生态系统仅依赖一两个执行层(EL)客户端进行证明,或者依赖单一的底层 zkVM 实现,那么该主导软件中的漏洞可能会导致整个网络停滞或受损。一种提议的缓解措施是“多重证明策略”,即一个区块只有在收到来自多个不同 zkEVM 系统的证明后才被视为有效。 [6]

客户程序与编译

使执行层(EL)客户端变得“可证明”的过程存在重大风险。EL 客户端是为具有缓存和系统调用等特性的复杂 CPU 设计的,而这些特性在 zkVM 的受限环境中并不存在。这种环境之间的不匹配是一个高层面的担忧。此外,在修改客户端时可能会引入漏洞,且针对 zkVM 所使用的 RV32IM 等小众指令集架构(ISA)的编译器,其经过实战检验的程度不如主流编译器。用于加速 Keccak 哈希等 ZK 不友好操作的自定义“zkVM 预编译”也增加了复杂性,并引入了其自身的攻击面。[6]

证明者与电路的正确性

zkEVM 最关键的组成部分是定义虚拟机规则的算术电路以及底层的加密协议。其中任何一个环节出现漏洞都可能是灾难性的,可能允许恶意证明者为无效的状态转换创建看似有效的证明,从而导致资金被盗。此类缺陷可能源于原始研究论文、规范中的歧义或实现过程中的错误。其他实现风险包括错误的“见证”(witness)生成、程序格式之间的转译错误,或偏离协议已证明的安全保证的不安全“优化”。[6]

缓解策略

为了应对这些风险,该生态系统依赖于多种策略,包括形式验证(利用数学证明代码的正确性)、针对标准化测试套件(如 执行规范测试)的广泛测试、独立的安全性审计、旨在激励白帽黑客攻击的漏洞赏金计划,以及多重证明策略等架构设计。 [6]

形式化验证倡议

为了增强安全性,发起了 zkEVM 形式化验证项目。这是一项全生态系统的努力,旨在将形式化验证方法应用于整个 zkEVM 栈,目标是创建“无漏洞的 zkEVM”。该项目预计将持续到 2026 年底,旨在开发工具、标准和流程,以确保 zkEVM 的正确性和安全性。[8]

该倡议分为三个主要关注领域或“赛道”:[8]

  • RISC-V zkVM 赛道:专注于验证基于 RISC-V 的 zkVM 的多项式约束是否正确实现了官方 RISC-V 指令语义。
  • EVM 赛道:旨在证明在 RISC-V 架构上运行的 EVM 实现是官方 EVM 规范的正确实现。
  • 密码学赛道:验证底层密码学证明系统和原语的规范、安全性证明及实现。

该项目通过资助计划运作,支持多个团队应对这些挑战。受支持的工作包括:ArkLib(Lean 证明助手中的形式化密码学证明库)、cLean(用于在 Lean 中编写电路的领域特定语言 DSL)以及 LLZK(零知识语言的统一中间表示)。这些努力突显了社区驱动、开放且方法多样化的方式,旨在保障下一代 扩容方案的安全。[8]

历史与著名项目

虽然早期的 (如 )展示了零知识证明(ZK)技术在扩展性方面的强大能力,但它们缺乏通用的 EVM 兼容性。zkEVM 的开发代表了将 ZK 证明与 EVM 可编程性相结合的一次重大推进。[1]

早期开发与主网发布

第一批公共zkEVM主网于2023年3月上线,标志着扩展进程中的一个重要里程碑。

  • zkSync Era:由开发,zkSync Era于2023年3月24日发布了其公共主网。作为一种Type 4 zkEVM,它将和Vyper代码编译成ZK友好格式,以实现更快的证明生成时间。[1] [5]
  • Polygon zkEVM于2023年3月27日启动了其zkEVM Beta版。该项目以开源著称,其第一笔交易由联合创始人发送。它通常被归类为Type 2或Type 3 zkEVM。zkSync和团队在发布时都承认该技术仍处于早期阶段。[1]

Polygon zkEVM 的演进

在整个 2024 年, zkEVM Beta 版进行了多次升级,包括 “Etrog”、“Elderberry” 和 “Eggfruit” 更新,这些更新引入了 cdk-erigon 排序器等功能。然而,作为战略转型的一部分, Labs 在 2026 年 1 月宣布计划弃用 zkEVM Beta 版。该项目的技术和经验正被整合到其他生态系统产品中,例如 链开发套件 (CDK),它允许开发人员启动自己的零知识证明 (ZK) 驱动链。[7]

其他项目

  • Scroll:一个zkEVM项目,被归类为Type 2,是与基金会的隐私与扩展探索(PSE)小组合作开发的。[5]
  • Linea:由Consensys开发的zkEVM,Consensys是生态系统中领先的软件公司之一。[1]
  • Taiko:另一个开发zkEVM解决方案以扩展的项目。[1]

以太坊基金会的 L1 计划

正在研究将 Type 1 zkEVM 直接集成到基础层中。其目标是实现“实时证明”(RTP),即在 12 秒的插槽时间内为整个区块生成 ZK 证明。这将使整个网络从 ZK 扩展中受益,而无需用户迁移到单独的 Layer 2。该项目的指导原则是“完全、不妥协的 EVM 等效性”。[3]

“我们的目标是完全、不妥协的 EVM 等效性。” [3]

截至 2026 年初,该计划包括对 OpenVM 和 RISC0 等 zkVM 实现进行持续的基准测试,并致力于准备 Reth 和 等以太坊客户端,以便未来可能与基于证明的验证机制进行集成。[3]

发现错误了吗?

参考文献 (8 来源)

首页分类维基MC事件词汇表