ZK-Rollup 详解：zkSync、StarkNet、Scroll
ZK-Rollup 在链外批量执行交易，再把状态数据与有效性证明提交到以太坊。ZKsync、Starknet 和 Scroll 都采用该思路，但执行环境、证明系统和 EVM 兼容路线不同。
项目当前写法通常为 ZKsync 和 Starknet，旧资料常写作 zkSync 与 StarkNet。名称变化不影响基本分类，但阅读技术文档时应确认资料日期和所描述的协议版本。
ZK-Rollup 如何证明交易有效？
ZK-Rollup 的证明器把一批交易的执行过程转换为密码学证明。以太坊上的验证合约不必重新执行批次中的每一笔交易，只需验证证明和公开输入，即可判断新状态是否由协议允许的状态转换产生。
典型流程包括：
- 排序器接收交易并形成 L2 区块或批次。
- 执行环境计算账户、合约存储和消息的状态变化。
- 证明器根据执行轨迹生成证明，多个区块的证明还可以聚合。
- 批次数据或状态差异发布到以太坊，以便其他节点恢复 L2 状态。
- L1 验证合约检查证明，接受通过验证的新状态承诺。
证明生成可能晚于用户看到的 L2 确认。应用显示“成功”通常表示交易已被排序和执行，不一定表示证明已在以太坊验证。
有效性证明与数据可用性为什么要分开看？
有效性证明回答“状态计算是否符合规则”，数据可用性回答“其他人能否取得足够数据重建状态”。两者解决的是不同问题。
Rollup 把恢复状态所需的数据发布到以太坊。Validium 也可以使用有效性证明，却把数据放到外部网络或委员会。后者能进一步降低 L1 数据费用，但当外部数据不可用时，用户可能难以重建状态或完成退出。
因此，“使用 ZK 证明”不能单独证明一条链拥有 Rollup 的完整安全属性。还要查看该具体网络的数据发布模式、升级权限和退出机制。
ZKsync、Starknet 和 Scroll 有什么区别？
三者都让以太坊验证批量状态，但选择了不同的执行与开发路线。
| 比较项 | ZKsync | Starknet | Scroll |
|---|---|---|---|
| 核心定位 | 以 ZK Stack 构建 Rollup 与可配置链网络 | 使用 STARK 证明和 Cairo 执行环境的有效性 Rollup | 面向以太坊兼容应用的 zkEVM Rollup |
| 执行环境 | Era 路线包含为证明优化的 EraVM，当前协议文档也描述面向 EVM 的执行环境演进 | 原生使用 Cairo 与账户合约模型，不是直接复制 EVM | 重点证明 EVM 状态转换，开发体验接近以太坊 |
| L1 数据 | Rollup 模式把压缩状态差异等数据发布到以太坊 | 把压缩状态差异发布到以太坊，可使用 Blob | 排序层向以太坊发布批次数据，结算层验证证明 |
| 证明特点 | 证明器验证批次状态转换，协议正在向新的 ZKsync OS 架构演进 | 使用 STARK 系证明，并通过聚合降低 L1 验证负担 | 证明电路约束 EVM 执行结果，由以太坊合约验证 |
| 开发迁移 | Solidity 工具可用，但特殊 VM、系统合约和编译路径仍需测试 | 通常需要 Cairo、Starknet 账户与工具链知识 | Solidity 应用迁移阻力较低，仍需测试预编译和系统差异 |
这里的“兼容”不能只写成是或否。钱包 RPC、Solidity 编译、字节码、操作码、Gas 计量和调试工具分别属于不同层次。即使合约能部署，依赖底层区块字段、预编译或精确 Gas 行为的应用仍要重新验证。
ZK-Rollup 是否一定比 Optimistic Rollup 更快？
要先说明比较的是哪种速度。ZK-Rollup 在证明被 L1 验证后，不需要再等待故障挑战期来确认同一状态，这通常有利于协议原生退出。可是证明生成、聚合和提交本身也需要时间。
用户看到的交互速度主要由排序器出块和应用确认策略决定。两条不同路线都可能提供快速 L2 确认。若比较最终结算，应查看批次发布频率、证明延迟和以太坊确认，而不是只看钱包动画。
ZK-Rollup 的主要限制是什么？
| 限制 | 实际影响 |
|---|---|
| 证明复杂度 | 证明器需要专门硬件和软件，故障可能延迟证明但不一定回滚已排序交易 |
| 电路覆盖 | 只有被电路或可证明执行环境约束的逻辑才获得有效性保证 |
| 升级权限 | 管理者可能更新验证合约、桥或系统配置，改变原有假设 |
| 排序集中 | 单一排序器仍可能延迟或审查交易，证明不能自动解决交易排序问题 |
| 生态差异 | 钱包、预言机、桥和应用深度可能与以太坊主网不同 |
此外，ZK-Rollup 的“零知识”常被误读为隐私。扩容型有效性证明可以在不隐藏地址、金额和合约调用的情况下工作，公开区块浏览器仍可能展示完整交易活动。
使用三条网络前怎样核对？
先从应用支持的具体网络出发，而不是先选证明名词。确认官方 RPC、链 ID、浏览器、Gas 资产和标准桥，再检查目标代币是原生发行还是桥接版本。
对于合约应用，还应在目标执行环境实测部署、调用、事件索引和预言机。对于资产用户，则要核对 L2 内确认、证明状态和退出到 L1 的不同等待阶段。
若要比较另一类验证方式，可阅读Optimistic Rollup：Arbitrum 与 Optimism；完整分类见Layer2 扩容方案全景解读。ZK 证明在身份、隐私和跨链等方向的应用，可延伸查看Web3 前沿赛道与趋势。
常见问题
ZK-Rollup 会隐藏转账金额和地址吗？
不会自动隐藏。有效性证明可以只用于证明公开交易的计算正确。是否具有隐私，要看协议是否专门设计隐藏状态、加密数据和查看权限。
有效性证明能保证某个 DeFi 应用没有漏洞吗？
不能。证明保证的是 L2 按既定执行规则处理交易。应用合约若本身存在权限、预言机或经济设计问题，仍会按错误逻辑正确执行。
所有 ZK-Rollup 都需要可信设置吗？
不一定。不同 SNARK、STARK 和递归证明系统的参数生成方式不同，有些需要多方仪式，有些强调透明设置。应查看具体证明系统，不能从“ZK”三个字推断。
为什么 L2 浏览器显示成功，以太坊上还找不到对应证明？
排序器可以先执行并确认交易，证明器随后才把多个区块聚合成证明提交 L1。两个浏览器观察的是不同阶段，延迟不一定表示交易失败。
推荐阅读
查看更多
