资讯正文

全球区块链监管查询APP

扫一扫下载APP

    首页  >  Layer2  >  正文

    简析以太坊二层扩容方案 zkSync 安全机制

    区块天眼   |   06-06 23:01

    分享到:

    微信分享 ×
    微信扫描上方二维码

    摘要: 为了降低可能存在的技术漏洞和可升级状态对安全性的影响,zkSync 提出了三重安全性方案。…以太坊,安全,智能合约,治理,Layer 2,ZK Rollup,Layer 1,Rollup,zkSync

      为了降低可能存在的技术漏洞和可升级状态对安全性的影响,zkSync 提出了三重安全性方案。

      原文标题:《科普 | zkSync 的三重安全性方案》

      撰文:Matter Labs

      翻译和校对:闵敏和阿剑

      唯有偏执狂才能生存下来。

      —— Intel 的 CEO Andy Grove

      在为 NFTs、swaps 和 zkEVM 上线做准备的过程中,我们注意到 zkSync 的用户和资金量迎来了指数级增长。然而,处于早期开发阶段的新协议往往存在一些风险和信任假设,我们认为有必要提醒新老用户注意这点。

      风险一方面来自应用于 Layer 2 的创新技术,另一方面来自这些解决方案的潜在中心化趋势。就像大多数务实的团队那样,zkSync 踏上了渐进式去中心化道路,并积极开拓创新,增强以太坊生态的安全性和可扩展性。

      这里需要注意的几点是:

    •   我们无法保证项目没有漏洞。但是,我们会参照业内最新最好的安全实践,并联合顶级审计公司对项目的合约、电路和底层密码学技术进行审计,将出现漏洞的可能性降至最低。所有基于以太坊构建的新项目都存在这一风险。我们的项目更是如此,因为零知识证明技术增加了项目的创新性和复杂性。

    •   在功能范围稳定之前,zkSync 将保持可升级状态。但是,升级与否将由协议治理机制控制,而且需要经历为期 4 周的锁定期(详见下文)。

    •   zkSync 目前依赖于可信设置。我们使用的是超过 200 位参与者(包括 Vitalik Buterin、以太坊基金会、Consensys、Argent 和 Matter Labs 等)通过多方计算仪式得出的结果。只要有一位参与者是诚实的,我们的系统就是安全的。虽然这个信任假设目前看来还不是什么大问题,但是我们依然打算将来切换至 RedShift,这样就不再需要任何可信设置了。

    •   为了降低 (1)和 (2) 的影响,我们现采取多层安全策略。

      zkSync 的三重安全方案
      •   通过隔离和冗余实现的安全性

      •   信任最小化的可升级性

      •   zkSync 安全委员会

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

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

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

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

        •   隔离:只有得到授权的定序器提交的区块才能向 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)

            •   Stefan George (Gnosis)

            •   Baek Kim (Hashed)

            •   Chris Burniske (Placeholder)

            •   Nick Grossman (USV)

            •   Will Harborne (ZK Validator)

            •   Sergej Kunz (1inch)

            •   Lasse Clausen (1kx)

            •   如果出现无法通过正常升级流程解决的问题,安理会将发挥作用。安理会的权力仅限于缩短 4 周的锁定期,但它不属于 zkSync 治理的一部分,无法绕过治理机制发起升级

                在 Gnosis Safe 多签机制的帮助下,zkSync 安理会将遵守以下规则:

              •   8/15 签名可以将锁定期缩短至 2 周。

              •   10/15 签名可以将锁定期缩短至 1 周。

              •   12/15 签名可以将锁定期缩短至 3 天。

                为了防止最坏的情况发生,任何升级都有一个最低锁定期。安理会只是为了让人们相信零知识证明安全性的临时措施。等到我们切换至纯选择性升级机制后,就不再需要安理会了。

              结语

                我们始终将用户资金的安全性放在首位。当 Matter Labs 于 3 年前成立时,我们就选择只聚焦于 zkRollup —— 唯一具备与 Layer 1 相同安全属性的 Layer 2 可扩展性技术。我们希望通过用户教育、信息透明和三重安全方案,让用户可以放心与 zkSync 交互。

                来源链接:medium.com

    相关阅读