我们务实的去中心化之路

呜哦：每个 L2 都有升级密钥 😱

在讨论 Layer 2 (L2) 协议时，有一个难以接受的真相常常被忽视：每个主要的 L2 项目都有一个可信的方可以执行协议升级。目前，这几乎是所有人，包括我们，中心化的主要点。如果升级密钥受到威胁，所有存入 L2 协议的资产都将面临风险。

具有桥接资产的其他 L1 项目也容易受到类似的破坏性攻击。依靠 L1 的安全保证去避免这种情况是 L2 愿景的关键部分。但我们还没有达到那一步——在某种程度上，人人仍在销售一个梦想。

让我们谈谈导致 L2 项目保持升级密钥的危险，Ethereum 自身是如何避免这些陷阱的，以及我们该如何效仿。

Layer 2 中心化的现状

你的安全性只如你的弱点。最好的加密技术在密码是 passwordpasswordpassword 的时候也无法拯救你。那么，L2 空间中最薄弱的环节是什么？

你猜对了：升级密钥。每个主要的 L2 在其 L1 合约上都有某种形式的即时可升级性。这很好，因为它允许项目推出改进和修复漏洞，但这最终也意味着一个可信的第三方对 L2 余额拥有单方面的发言权。

这引出了一个问题：如果最后这种安全性可以通过升级简单地被覆盖，那还有什么意义呢？

无论多么坚固地建造，建立在薄弱基础上的城堡仍然可能倒塌。

我们并不是要贬低 L2 团队在推动去中心化可扩展技术方面所做的非凡工作。我们正在取得重大进展——看看我们最近推出的首个 下一代故障证明的漏洞赏金 吧！相反，这只是一个提醒：今天没有主要的 L2 拥有可投入生产的故障/有效性证明。

拥有这个中间阶段是必要的——将这些复杂协议投入生产是非常不简单的——但我们也需要谈谈放弃密钥和实现真正去中心化 L2 愿景的现实路径。

为什么 L2 不是去中心化的

一种必要的邪恶

在跳入解决方案之前，让我们首先明确问题：所有 L2 拥有升级密钥的原因是因为 编写复杂且无漏洞的代码极其困难. 每一行新的代码编写都是引入漏洞的新机会。

在加密领域，单个关键漏洞可以使项目陷入瘫痪，因此我们必须非常谨慎。这意味着 简洁、简单的代码。代码减少是 Optimism 哲学的核心，也是我们进行 EVM 等效性升级的主要动机。（即便如此，漏洞仍然可能 滑过缝隙。）

事实是，去中心化 L2 中的任何关键漏洞都将是灾难性的：按设计 , 智能合约将以 L1 的全部“安全性”来强制执行。如果没有升级密钥作为最后的补救措施，将根本没有回旋余地。这设定了一个极高的标准。

看看 Ethereum

Ethereum 本身是去中心化安全的一个优秀案例，我们可以用它来判断编写无漏洞的 L2 的难度。在其历史上，Ethereum 遭遇了 大量漏洞，这些漏洞被引入、发现、修复，有时还会引发意外的硬分叉（相信我们，这可不好玩）。

尽管出现了多次关键性漏洞，Ethereum 在其生命周期中仍然保持了高度可用。仅在发布 2 年后，Ethereum 在 上海 DoS 攻击 中最接近于真正的停机。鉴于区块链停机如此常见，能够做到这一点是一个令人印象深刻的成果。

此时，我们可以非常自信地认为 Ethereum L1 不会停机或被破坏。我们需要在 L2 达到同样的信心水平，才能放弃升级密钥。那么，Ethereum 的秘密是什么？在我们努力安全 L2 的过程中，我们能否沿其足迹而行？

下次剧透请看...开玩笑，我们已经告诉你了，继续往下读👇

去中心化的实用路径

Ethereum 在最小化安全风险和最大化正常运行时间方面的成功并非偶然——这归功于 Ethereum 战略性地创建了一个多客户端生态系统，具有多个不同的实现能够互相操作。

这种安全性的方法依赖于实现之间的漏洞是无关的。换句话说：如果一个实现有特定的漏洞，另一个实现可能就不会遭受同样的漏洞。

这样，即使出现失败，你也可以剔除出现故障的客户端，而选择正常运行的客户端。这种冗余是 Ethereum 高可用性保证的关键。

我们可以效仿 Ethereum 的足迹，在 Layer 2 中使用这种相同的方法。我们可以创建一个 L2 的多客户端生态系统，就像我们在 L1 中所做的那样，而不是实现一个客户端、一个故障证明或一个 ZK 证明。这样可以确保关键漏洞不会导致整个网络崩溃，即使它存在于一些乐观客户端中。

用多客户端架构去中心化 Optimism

我们设计 Optimism 以坚持 Ethereum 的哲学，不仅从 社会影响 的角度，而且从技术角度出发。自第一天起 编写我们的 Optimism: Bedrock designs，我们已经将其构建为使用 ETH2 合并 API，这使得与多个客户端的集成变得简单。

实际上，我们目标是使标准的 Ethereum 客户端转换为 Optimism 客户端所需的行数 少于 1,000。通过 EVM 等效性，我们还将故障证明和汇总客户端的实现模块化为单独的软件组件。这些方法结合在一起将使我们能够混合和匹配证明与客户端，最大限度地提高冗余性！

ZK Rollups：额外的安全层

我们常被问到“你们会采用零知识证明技术吗”？答案是这有可能，但不是你想的那样。还有很长的路要走，但如果 ZK 技术足够强大以支持 EVM 等效性，完全有可能作为这一多客户端生态系统中的另一个客户端加入。 这并不意味着我们偏离目前的架构或核心功能，但它确实意味着增加了一层安全性。

所以——虽然 ZK 技术让人兴奋，但我们不需要等待就能获得低成本、高安全性的 EVM 等效 L2。这以如今的 Optimism 形式存在，一旦 ZK 成熟，它就可以很自然地融入我们的架构。

推出计划

目前，我们正深藏于 Bedrock 的开发核心中。这将产生一个详细的 规范，用于我们的 EVM 等效汇总，以及首个 汇总客户端 和 MIPS 故障证明 Cannon。到那时，多客户端的旅程就开始了。

我们的目标是与外部团队合作并激励他们创建其他客户端。这将不是一个快速的过程，但 Bedrock（😉）将已经建立，代码优化才是关键。要将这些整合为一个多客户端证明系统，需要遵循 Hydra 框架。到那时，我们将获得消除升级密钥所需的信心。

总结：

1. 形成乐观者的伙伴关系。
2. 发布 Bedrock，启用多客户端架构。
3. 激励/支持创建替代 Optimism 客户端。
4. 递交多客户端证明合约。
5. 将我们的升级密钥丢入魔山。

我们现在去中心化了

恭喜！你已阅读完这篇文章，意味着 L2 已完全去中心化，我们实现了完整的 L2 愿景。你现在生活在加密的涅槃中。

小心——希望，我们没让你上当！编写生产软件需要时间——所以保持警惕并保持怀疑。平衡你无拘无束的乐观和健康的怀疑论。尽管我们还没有达到加密的涅槃，但我们终将实现。

L2 将将去中心化计算带到全球规模。我们还没有达到那里，但请耐心——我们尚未达到旅程的终点，这意味着我们的机会！

这意味着你可以参与并重新塑造现实！

我们在招聘 ！ 加入 我们的社区! 享受生活！不要过于担忧！刷牙！吃苹果！吃培根！研究公共关系的起源！回馈社区！发你不一定相信的推文！用你的图书馆卡下载免费音乐！不要下载汽车！除了父母之外不要听任何人的话，即便如此，也要持保留态度！

最后，我们非常感谢 Yoav Weiss 帮助我们找到了去中心化故障证明的实用路径！

• 原文链接： medium.com/ethereum-opti...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～