Optimism的去中心化路线：使用多客户端架构实现去中心化

在讨论第 2 层 (L2) 协议时，有一个难题通常不被提及：每个大型的L2 项目都有一个用于执行协议升级的受信任方。目前，对于包括我们（Optimism）在内的几乎所有人来说，这是中心化的主要点。如果协议升级密钥被泄露，所有存放在 L2 协议中的资产都将面临风险。

在以太坊上具有桥接资产的替代 L1 容易受到类似的破坏性攻击。依靠 L1 的安全保证来避免这种情况是 L2 愿景的关键部分。但我们还没有完全做到——从某种意义上说，每个人都在兜售梦想。

让我们谈谈导致 L2 项目维护升级密钥的危险，以太坊本身如何避免这些陷阱，以及我们如何跟进。

Layer2中心化现状

您的安全性取决于您最薄弱的环节。如果您的密码是passwordpasswordpassword，那么即使是最好的加密技术也无法拯救您。那么 L2 空间中最薄弱的环节是什么？

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

这就引出了一个问题：如果在一天内可以简单地通过升级来覆盖安全性，那么拥有故障或有效性证明的意义何在？

无论再坚固，地基薄弱的城堡也有可能倒塌。

我们并不是要放弃L2团队为推动去中心化可扩展性技术的最新发展而做出的令人难以置信的工作。我们已经取得了长足的进步——看看我们最近推出的第一个用于下一代故障证明的漏洞赏金！相反，这是一个提醒，今天没有主要的 L2 具有生产就绪的故障/有效性证明。

需要有这个中间阶段——生产这些复杂的协议并非易事——但我们还需要讨论放弃密钥和实现真正去中心化的 L2 愿景的现实路径。

为什么 L2 不是去中心化的

一种必要的邪恶

在进入解决方案之前，让我们首先确定问题：所有 L2 都有升级密钥的原因是因为编写复杂、无bug的代码非常困难。编写的每一行新代码都是引入bug的新机会。

在加密货币中，一个关键漏洞可能会破坏项目的运行，我们必须非常小心。这意味着我们需要简洁、简单的代码。代码减少是 Optimism 理念的核心，也是我们升级 EVM 等效性的主要动力。（即便如此，某个bug仍然可以从裂缝中溜走。）

事实是，去中心化 L2 中的任何严重bug都将是灾难性的：根据设计，智能合约将以 L1 的完全“安全性”来执行它。如果没有升级密钥作为最后的手段，就根本没有追索权。这设定了一个令人难以置信的高标准。

看向以太坊

以太坊本身就是去中心化安全的一个很好的案例研究，我们可以用它来判断编写一个没有 bug 的 L2 的难度。纵观其历史，以太坊有很多被引入、捕获、修复的错误，有时会触发无意的硬分叉（相信我们，这并不好玩）。

尽管存在多个严重错误，但以太坊在其整个生命周期内始终保持高度可用。在 2 岁的时候，以太坊在上海 DoS 攻击中最接近真正的中断。鉴于今天区块链中断仍然司空见惯，这是一个令人印象深刻的壮举。

在这一点上，我们可以非常有信心以太坊 L1 不会出现故障或受到损害。我们需要对 L2 达到同样的信心水平才能放弃升级密钥。那么以太坊的秘密是什么？在我们努力正确保护 L2 的过程中，我们能否追随它的脚步？

去中心化的务实路径

以太坊在最小化安全性和最大化正常运行时间方面取得的成功是不费功夫的好运气——这是因为以太坊战略性地创建了一个多客户端生态系统，该生态系统具有多个互操作的不同实现。

这种安全方法依赖于实现之间的bug不相关性的事实。换句话说：如果一个实现有一个特定的bug，另一个实现可能不会遭受完全相同的bug。

这样，即使出现故障，您也可以淘汰有问题的客户端，转而使用功能正常的客户端。这种冗余是以太坊高可用性保证的关键。

我们可以追随以太坊的脚步，在L2使用同样的方法。我们可以像在 L1 中那样为 L2 创建一个多客户端生态系统，而不是实现一个客户端、一个故障证明或一个 ZK 证明。这确保了关键漏洞不会破坏整个网络，即使存在于一些Optimistic客户端中也是如此。

使用多客户端架构实现Optimistic去中心化

我们设计 Optimism 以忠于以太坊的哲学，不仅从社会影响的角度来看，而且从技术角度来看。从编写我们的 Optimism: Bedrock 设计的第一天起，我们就将其构建为使用 ETH2 合并 API，它可以轻松与多个客户端集成。

事实上，我们的目标是减少将标准以太坊客户端转变为 Optimism 客户端所需的 1,000 行代码。借助 EVM 等效性，我们还将故障证明和Rollup客户端实现模块化为单独的软件片段。总之，这些方法将使我们能够混合和匹配证明和客户端，最大限度地增加冗余！

ZK Rollups：额外的安全层

我们经常被问到“你们会采用零知识证明技术吗”？答案是有可能，但不是你想的那样。前面还有很长的路要走，但如果 ZK 技术变得足够强大并且支持 EVM等效性，那么我们就有可能将其添加为这个多客户端生态系统中的另一个客户端。这并不意味着放弃我们当前的架构或核心功能，但它确实意味着另一层安全性。

所以——虽然 ZK 技术令人兴奋，但我们不需要等待获得低成本、高度安全、EVM 等效的 L2。现在已经以 Optimism 的形式出现，一旦 ZK 成熟，它就可以直接融入我们的架构。

推出

目前，我们深入Redrock的发展核心。这将为我们的 EVM 等效Rollup生成详细规范，以及第一个Rollup客户端和 MIPS 故障证明 Cannon。届时，多客户端之旅就开始了。

我们的目标是与外部团队合作并激励他们创建其他客户。这不会是一个快速的过程，但Redrock已经建立，代码最小化就是这场游戏的口号。要将这些集成到多客户端证明系统中，需要遵循 Hydra 框架。至此，我们将获得删除升级密钥的必要信心。