ZK Rollup 的安全性叙事很吸引人：密码学证明保证状态正确，不需要信任任何人。
但这是理想状态下的描述。实际部署的 zkEVM 与这个理想之间存在差距。这些差距就是风险所在。
风险一：升级权限的中心化
这是所有 L2 中最被低估的风险。
zkSync 的智能合约（包括 L1 上的验证者合约、状态转换合约）是可升级的。谁能升级？通常是治理机制或多签。
这个权限意味着什么？ 意味着持有这个权限的人可以改变协议规则——包括修改验证逻辑、改变状态转换规则、甚至绕过证明机制。
这直接影响安全性：如果证明系统可以被升级绕过，那么"密码学保证"就变成了"多签保证"。用户需要信任的是多签持有者，而不是数学。
要问的问题：
- 升级权限由谁控制？多签的构成是什么？需要几个签名？
- 升级是否有时间锁（Timelock）？给了用户多久的退出窗口？
- 紧急升级（Emergency Upgrade）的机制是什么？谁能单方面触发？
这是评估任何 L2 时都应该首先查清的问题。
风险二：证明系统的实际运行状态
"用的是 ZK 证明"这句话可能掩盖很多细节：
证明是否真的在生成？ 有些 L2 在早期宣称是 ZK Rollup，但实际上运行的是中心化节点，证明系统并未完全启用。
证明是否是真的验证？ 如果 L1 合约接受证明的方式有漏洞（比如验证不充分、或者有"管理员可以跳过验证"的路径），那么证明的意义就被削弱。
是否有实际的证明被拒绝过？ 历史上有没有因为证明错误而导致状态回滚的案例？这个信息反映了系统是否真的在"用"证明。
要问的问题：
- 证明是每个批次都生成并提交，还是有例外？
- 有没有"暂时关闭证明"的机制？
- 谁有权限调整证明参数？
风险三：排序器的中心化与 MEV
与所有 L2 一样，zkSync 的排序器目前是中心化的。
具体风险：
- 审查：排序器可以不打包特定交易
- MEV 提取：排序器能看到待处理交易，可以调整顺序获利
- 单点故障：排序器宕机则交易停滞
- 延迟提交：排序器决定何时把批次提交到 L1，可以延迟
"强制交易"机制（把交易直接发到 L1 合约，绕过排序器）是缓解方案，但它通常有延迟和额外成本，不是无缝的。
风险四：zkEVM 实现的安全边界
zkEVM 的核心挑战是精确复现 EVM 的行为。
风险在哪：
- EVM 有大量边界情况（溢出、异常处理、Gas 计算的细节）
- 每个操作码的约束实现都需要正确
- 约束的实现错误可能导致证明通过但状态错误（最坏情况）或者合法交易无法被证明（可用性问题）
- 已有多个 zkEVM 项目发现过这类 bug
这类风险的特殊性在于：它很难被普通审计发现（需要密码学和 EVM 双重专业），且一旦出现影响是系统性的。
风险五：跨链桥的信任假设
资金从以太坊到 zkSync 需要跨链。跨链的机制决定了信任假设：
官方桥。 依赖 L1 合约和 L2 状态。安全性较高，但速度慢（需要等证明）。
第三方桥。 通常更快，但引入额外的信任假设（流动性提供方、桥的托管机制）。历史上跨链桥是区块链领域被盗资金最多的环节。
风险：用户可能以为自己在"用 zkSync"，实际上信任的是某个第三方桥的机制。
风险六：生态应用的质量
ZK 的技术安全性不能保护应用层面的安全。
zkSync 的生态相对年轻，应用的审计资源有限。有大量新项目、新合约未经充分检验。
风险点：
- 部署在 L2 上的合约可能有漏洞（与 L2 的安全性无关）
- 开发者可能不熟悉 zkEVM 的细节差异（比如某些 Gas 行为、预编译合约的差异）
- 生态内的组合协议可能有跨协议风险
用户需要区分"链的安全性"和"应用的安全性"。zkSync 的证明保证了链上状态转换的正确性，但不保证你调用的那个合约没有逻辑漏洞。
风险七：Gas 模型的差异带来的隐性成本
zkSync 的 Gas 模型与以太坊不完全一致（这是为了效率做的妥协）。
可能的影响：
- 某些在以太坊上廉价的操在 zkSync 上可能更贵（反之亦然）
- 依赖精确 Gas 计算的合约可能行为异常
- 依赖 Gas 的合约（比如基于 Gas 消耗的逻辑）可能有不同的执行路径
这是一个容易被忽视的兼容性风险。开发者如果假设 Gas 模型完全一致，可能遇到意外。
怎么系统性评估
把这七个风险整理成一个检查清单：
| 风险点 | 要查什么 |
|---|---|
| 升级权限 | 多签构成、时间锁、紧急升级机制 |
| 证明状态 | 是否真的每批生成、是否有跳过路径 |
| 排序器 | 中心化程度、强制交易机制、宕机历史 |
| zkEVM 实现 | 审计报告、历史 bug、形式化验证 |
| 跨链桥 | 用的是哪个桥、信任假设、历史安全记录 |
| 生态应用 | 合约是否审计、开发者成熟度 |
| Gas 差异 | 是否有兼容性文档、已知差异列表 |
一个更根本的思考
评估 L2 时，人们容易被"ZK"这个技术标签吸引，认为它意味着更高等级的安全。但安全性不是由技术标签决定的，而是由最薄弱的环节决定的。
如果升级权限在多签手里，那么安全等级就是多签的安全等级；如果排序器中心化，那么抗审查性就是中心化的抗审查性；如果用户通过第三方桥进入，那么安全等级就有桥的成分。
"密码学保证"是这套体系中很强的一环，但它不是唯一的一环。真正的安全评估需要看完整链条，而不只是看最亮眼的那一环。
这个原则适用于所有 L2——包括 Optimistic Rollup 和所有其他方案。技术路线的选择会影响风险的分布，但不会消除风险。
常见问题
ZK Rollup 的最大风险是什么？
常被忽视的是升级权限的中心化。L1 合约可升级意味着持有权限者能改变协议规则甚至绕过证明，此时"密码学保证"实际变成了"多签保证"，用户信任的是人而非数学。
跨链桥和 L2 的安全等级如何区分？
链本身的安全性由证明与共识机制决定，但用户进入 L2 往往通过跨链桥，桥有独立的信任假设。历史上跨链桥是区块链领域被盗资金最多的环节，用户可能信任的是桥而非链。
zkEVM 的实现风险为什么难以发现？
需要同时具备密码学和 EVM 的专业知识才能审计。约束实现错误可能导致证明通过但状态错误，或合法交易无法被证明。这类错误影响是系统性的，且已有多个 zkEVM 项目发现过类似 bug。
评估 L2 应该查哪些信息？
升级权限与时间锁、证明是否真的每批生成、排序器中心化程度、zkEVM 审计报告与历史 bug、跨链桥的信任假设、生态合约的审计情况、以及 Gas 模型差异清单。