# 我们的去中心化务实之路 哦哦：每个 L2 都有升级密钥😱 By [0xJack](https://paragraph.com/@0xjack) · 2022-05-27 --- ![](https://storage.googleapis.com/papyrus_images/4a2d6e466ae2a3a59f74485aced2885c08fbc7851b36f6ef65207782612c0624.png) 在大家讨论L2协议时，通常不会讨论一个棘手的事实：**每一个主要的L2项目都有一个可以执行协议升级的受信任方**。目前，对于包括我们在内的几乎所有人来说，这是集中化的主要点。如果升级密钥被泄露，所有存在在L2协议内的资产都将面临风险。 在ETH链上具有桥接资产功能的L2都容易受到类似的破坏性攻击。依靠L1的安全保证来避免这种情况时L2愿景的关键部分。但目前而言我们还没有完全做到——从某种意义上，每个人都在兜售梦想。 让我们谈谈导致L2项目维护升级密钥的危险，以太坊本身如何避免这些陷阱，以及我们如何跟进。 **L2中心化的状态** 你的安全性取决于你最薄弱的环节。如果你的密码是passwordpasswordpassword，最好的加密技术也无法拯救你。那么L2协议中最薄弱的环节是什么？ 你猜对了：升级密钥。每个主要的L2都在其L1合约上具有某种形式的即时升级能力。这很棒，因为它允许项目发布改进和修复错误，但它最终也意味着受信任的第三方对L2余额有单方面的发言权。 这就引出了一个问题：如果在一天结束时可以简单通过通过升级来覆盖安全性，那么故障或有效性证明的意义何在？ ![再坚固的城堡，如果地基薄弱，都有可能会倒塌](https://storage.googleapis.com/papyrus_images/677888642271167b78df31f413c08769d7571413ebf8987e67f131b1b4677113.png) 再坚固的城堡，如果地基薄弱，都有可能会倒塌 但是我们并不是要放弃L2，团队为推动去中心化可扩展性技术的发展做出了令人难以置信的新成果。我们已经取得了长足的进步——看看我们最近推出的第一个用于下一代故障证明的漏洞赏金！相反，这是一个提醒，今天没有任何L2具有生产就绪的故障/有效性证明。 我们需要这个中间阶段——研发这些复杂的协议并非易事——但我们还需要讨论放弃密钥和实现真正去中心化L2愿景的实现路径。 **为什么L2不是去中心化的** **必要的邪恶** 在了解解决方案之前，让我们首先明确一个问题：所有L2都有升级密钥的原因时因为编写复杂，无错误的代码非常困难。编写的每一行新的代码都有引入错误的机会。 在加密行业中，一个关键漏洞可能会破坏项目，我们必须非常谨慎。这意味着我们需要简洁简单的代码。代码减少是Optimism理念的核心，也是我们升级EVM等效性的主要动力（即便如此，也很难完全避免错误）。 事实是，去中心化L2中的任何严重错误都将是灾难性的：根据设计，智能合约将以L1的绝对“安全性”来执行它。如果没有升级密钥作为最后的手段，根本就没有追索权。这提出了很高的标准。 **以ETH为参考** ETH本身就是完全去中心化的很好案例，我们可以用它来判断编写一个没有bugL2的难度。纵观其历史，ETH有很多被引入、捕获、修复的错误，有时候会触发无意的硬分叉（相信我们，这并不好玩）。 尽管存在多个严重错误，但以太坊在其整个生命周期内始终保持高度可用。在接近2周年的时候，ETH在上海的DoS攻击中几乎中断。鉴于今天区块链中断仍然司空见惯，这是一个令人印象深刻的壮举。 在这一点上，我们可以非常有信心：ETH不会出现故障或受到损害！我们需要对L2达到同样的信心水平才能放弃升级密钥。那么以太坊的秘密是什么？在外面努力保护L2的过程中，我们能否追随它的脚步？ 下次再Dragonba上查找。。。。。我们找到了你，请继续阅读_👇_ **去中心化的务实路径** ETH再最小化安全性和最大化正常运行时间方面取得的成功并不是运气好——这是因为以太坊战略性地创建了一个多客户端生态系统，该生态系统可以实现多个互操作。这种安全方法依赖于各个实现之间的错误隔离。换句话说：如果一个实现有一个特定的错误，另一个实现可能不会产生完全相同的错误。 因此即使出现问题，你也可以淘汰有问题的客户端，转而使用功能正常的客户端。这个设计是ETH保持高可用性的关键。 ![](https://storage.googleapis.com/papyrus_images/f9d50f5c6c6a0b3f656043b220b191a1752741f1ada171bf76e572a0130d2634.png) 我们可以追随ETH的脚步，在L2使用同样的方法。我们可以像在ETH中那样为L2创建一个多客户端生态系统，而不是一个客户端\*\*\*，\*\*\*一个故障证明或一个ZK证明。这个措施确保了关键漏洞不会破坏整个网络，即使存在于一些Optimism客户端中也是如此。 **多客户端架构的去中心化Optimism** 无论从社会影响的角度，还是从技术角度来看，我们设计的Optimism是忠于ETH的哲学。从写我们的Optimism：Bedrock设计的第一天起，我们就将其构建为使用ETH 2.0合并API，它可以轻松地与多客户端集成。 事实上，我们的目标是将标准ETH客户端转变为Optimism客户端最多需要1000行代码。借助EVM等效性，我们还将故障证明和汇总客户端实现模块化为单独的软件片段。总之，这些方法将使我们能够混合和匹配故障证明和客户端，最大限度地增加冗余！ ![](https://storage.googleapis.com/papyrus_images/c0c6fe647f424ced48a103b0ebd9140a06f12210a8465039e8cfba4974a31608.png) **ZK Rollups: 额外的安全层** 我们经常被问到”你会采用零只是证明技术吗“？答案是可能，但不是你想的那样。前面还有很长的路要走，但如果ZK技术变得足够强大以支持EVM等效性，那么就有可能将其添加为这个多客户端生态系统中的另一个客户端。这并不意味着放弃我们目前的架构或核心功能，但它确实意味着另一层安全性。 所以虽然ZK技术令人兴奋，但我们不需要等待获得低成本，高度安全，EVM等效的L2。现在以Optimism的形式出现，一旦ZK成熟，它就可以直接融入我们的架构。 **推出** 目前，我们深入基岩的发展核心。这将导致我们的EVM等效汇总的详细规范，以及第一个汇总客户端和MIPS故障证明Cannon。届时，多客户端之旅就开始了。 我们的目标是与外部团队合作并激励他们创建其他客户。这不会是一个快速的过程，但基岩已经建立，代码最小化是游戏的名称。要将这些集成到多客户端证明系统中，需要遵循Hydra框架。至此，我们将获得删除升级密钥的必要信心。 **总之：** 形成一个乐观主义者的团契； 发布Bedrock，启用多客户端架构； 激励/支持创建代替Optimism客户； 发送多客户证明合约； 将我们的升级密钥放入末日山！ ![末日山](https://storage.googleapis.com/papyrus_images/4c73593bd2c9b7be74a8da91f878d76d94409f609ad48f4301c2bc738823c759.png) 末日山 **我们现在是去中心化的** 恭喜！您完成了这篇文章，这意味着 L2 是完全去中心化的，我们已经实现了完整的 L2 愿景。您现在生活在加密的必杀技中。 小心——希望我们没有愚弄你！编写生产软件需要时间——所以要保持警惕并保持怀疑。平衡你肆无忌惮的乐观与健康的怀疑态度。虽然我们还没有进入加密领域，但我们都会成功。 L2 将去中心化计算带到全球范围。我们还没有到达那里，但请耐心等待——我们还没有走到旅程的尽头，这是一个机会！ 这意味着您可以参与其中并重塑现实！ 我们正在招聘！加入我们的社区！玩得开心！享受生活！不要太担心！刷牙！吃苹果！吃培根！研究公共关系的起源！回馈您的社区！在推特上发布您实际上并不相信的事情！使用您的借书证下载免费音乐！不要下载汽车！除了你的父母，不要听任何人的话，即使那样，也要半信半疑！ 最后——我们要特别感谢 Yoav Weiss 帮助我们提出了这种去中心化故障证明的务实路径！ 原文链接： [https://medium.com/ethereum-optimism/our-pragmatic-path-to-decentralization-cb5805ca43c1](https://medium.com/ethereum-optimism/our-pragmatic-path-to-decentralization-cb5805ca43c1) 译者：0xJack#1034 --- *Originally published on [0xJack](https://paragraph.com/@0xjack/l2)*