科普 | zkSync 的三重安全性方案

正文

请到「今天看啥」查看全文

zkSync 安全委员会

1. 通过隔离和冗余实现的安全性

由于我们的 Layer 1 智能合约在设计上非常轻量级（只有几百行代码），我们预期这部分不会出现严重问题。但是，零知识证明技术部分不仅代码更多，而且复杂性更强，因此风险会更高。

实际上，密码学部分也不太可能出现问题。如果我们将智能合约漏洞比作突然爆发的海啸，那么密码学漏洞就就像是由连天暴雨引发的洪灾：地面很快就会被淹没，但是人们实际上都集中在摩天大楼楼顶，有足够的时间疏散。通常情况下，新发现的漏洞只有在安全性较低的环境下才有利用价值，因为实际生产环境的安全阈值要高得多，从而导致攻击成本倍增。以著名的 RSA 破解挑战赛为例，破解 100 位密码仅花了一个月，但是破解 250 位密码花了近 30 年。然而，在现实世界中，系统使用的都是 2048 位及以上的密码。

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

1. 隔离 ：只有得到授权的定序器提交的区块才能向 zkSync Layer 1 智能合约提交状态转换。我们很快就会转向由多名验证者的 PoS 共识保护的集体定序器。
2. 冗余 ：在被打包进区块之前，提交至定序器的每笔交易都将通过简单的执行进行验证。

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

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

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

2. 信任最小化的可升级性

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

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

请到「今天看啥」查看全文