为了在零知识证明技术部分增加额外的保护层来抵御漏洞攻击，我们采用了双保险措施：

• 　　隔离：只有得到授权的定序器提交的区块才能向 zkSync Layer 1 智能合约提交状态转换。我们很快就会转向由多名验证者的 PoS 共识保护的集体定序器。

• 　　冗余：在被打包进区块之前，提交至定序器的每笔交易都将通过简单的执行进行验证。

　　因此，即使零知识证明电路或底层密码学技术存在漏洞，以至于做恶者可以为无效交易生成零知识证明，也不容易利用这个漏洞。

　　若想将无效区块提交至 Rollup，攻击者必须同时攻破密码学和定序器 /PoS 共识。

　　为了尽早发现潜在漏洞，我们将为白帽黑客推出低安全阈值的漏洞赏金计划。

信任最小化的可升级性

　　在 zkSync 协议的早期阶段，可升级性有助于我们创新、快速迭代，更快修复漏洞。如果每次升级（就像 Uniswap V2 升级到 V3 那样）都需要用户迁移资产，用户体验会很差。但是，可升级性是一把双刃剑：它会引入额外的信任假设和风险。

　　我们坚信用户不应该只依赖于开发者团队或治理来保障安全性。因此，我们的 zkRollup 采用优先队列 / 紧急出口机制来保护用户免受验证者的审查：无论验证者的协作情况如何，你都能自由退出 zkSync。但是，如果存在未被发现的可升级性后门，就凉凉了。

　　为了帮助 zkSync 2.0 实现良好的平衡：

• 　　初期，升级可以通过 zkSync 治理机制发起，在部署之前需要经历 4 周的锁定期。即使治理机制遭到极大程度上的破坏，锁定期也可以让用户有足够的时间通过优先队列 / 紧急出口机制退出。

• 　　协议经过充分检验后就会固定下来（再也无法升级），并要求用户选择新的版本。

zkSync 安理会

　　我们最后还要考虑的一种情况是，从理论上来说，某些交易可能会导致 zkEVM 内部出现故障。如果这类交易被提交至优先队列，且无法得到处理，系统就会停止运行并进入紧急模式。即使我们通过升级来修复这个问题，至少也要等到 4 周的锁定期结束。也就是说，zkSync 内的所有资金都要被冻结 4 周乃至以上。

　　为了避免这种情况，以太坊社区内 15 位备受尊敬的成员将在紧急情况发生时介入。zkSync 安理会由以下成员组成：

• 　　Aave

• 　　Itamar Lesuisse (Argent)

• 　　Mike McDonald (Balancer)

• 　　James Prestwich (cLabs)

• 　　Michael Egorov (Curve)

• 　　Jack Baumruk (Dekrypt)

• 　　Haseeb Qureshi (Dragonfly)

• 　　Justin Drake (Ethereum Foundation)

  (责任编辑：admin)