zkSync Atlas 与 Airbender 是什么？RISC-V 虚拟机怎么给 ZK Stack 重做证明系统

一次换引擎级别的升级

按 ZKsync 官方协议升级页面的记录，2025 年 10 月的 Atlas 升级”为 ZK Stack 引入 ZKsync OS 和作为其新证明系统的 Airbender”。这与给某条链加一个功能不是一回事：执行引擎、共识测试器（CTM）和证明栈一起换血。官方页面上列举了升级方给出的吞吐与证明成本目标，这类数字属于厂商标称，验证要看自己接的链，本文不引用其性能承诺，只讲机制。

双编译：一份代码，两种命运

Airbender 架构的核心决定很优雅：ZKsync OS 的状态转换函数是一个 Rust 程序，编译两次——x86 版本给排序器日常出块用，RISC-V 版本供证明器的模拟器回放用。证明器不信任执行现场的任何中间结果，而是把 RISC-V 字节码当作唯一真相源，从初始状态出发一步步重新执行整条状态转换，同时把每一步的约束喂给证明后端。官方概览文档把执行切成约四百万个周期一块的片段，各片段并行证明，再递归折叠成一份总量证明。这样做的收益是执行与证明解耦：出块路径不必为可证明性做苛刻的结构妥协，证明路径也不必理解业务语义——它只回放指令。

约束层的选择：AIR 与 M31

证明后端走的是 STARK 路线：在梅森尼数 31（即二的三十一次方减一这个素数域）上做 FRI 承诺，约束采用 AIR（代数中间表示）形式、约束次数限制在二以内，哈希与 256 位大整数运算通过预编译委托给特化电路。选择 M31 域的动机是算术单元利用率和 GPU 亲和——官方文档明确 Airbender 面向消费级 GPU 运行。最后一站是包装：STARK 证明经多层递归后套上 FLONK SNARK 包装，让以太坊 L1 上的验证合约能以可接受的 gas 验收入场。同一套虚拟机还有不同机器配置变体（完整内核、应用、递归模式），字节码烧在 ROM 里，触发无法表达约束的陷入即判不可证明。

与上一代证明系统的分野

Atlas 之前，ZK 链普遍为每个交易类型写专用约束电路，链逻辑与电路逻辑双线维护、相互拖速。Airbender 把这条链拆成”程序即状态机”：链的合法性等于一段确定性程序的执行轨迹可满足性，升级链逻辑从改电路变成改字节码。代价同样明确：通用虚拟机的每条指令都要过约束层，工程重心从电路设计转向模拟器效率、片段切分与递归成本。官方概览文档给出的规模感是：单个程序执行可覆盖到非常高的周期总量，按片段并行展开后靠递归层压缩回一份可上链的证明——片段大小、递归深度这些数字在不同文档页之间仍有出入，接入前应当以具体版本的官方深度文档为准逐条核对，而不是从宣传口径反推。

升级怎么被记录和核查

一个值得借鉴的核验姿势：Atlas 相关组件的演进在官方协议仓库的变更日志里逐条留痕——例如二零二六年七月一条记录为预编译增加 Airbender 委托支持，同类条目持续给出”哪个月动了哪个组件”的版本事实，而不是笼统的已全面上线。评估一条基于 ZK Stack 的链，可靠路径是查它锁定的协议版本、对照升级日志确认证明栈是 Atlas 前还是 Atlas 后，再看桥合约实际验证的是哪一种证明包装。截至本文写作，升级日志显示 Airbender 相关组件仍在持续小版本迭代，接入方应以官方文档与版本日志为准判断自己链上的实际证明栈。

适合谁、不适合谁

对应用方，Atlas 意味着选择 ZK Stack 时更该关注证明延迟与桥退出参数，而非”有没有电路”这种旧问题；对研究者，M31 加 AIR 加消费级 GPU 的组合是一条区别于大域数路线的工程赌注。本文内容为技术机制介绍，不构成任何投资建议。