在讨论第二层扩展协议（Layer 2 protocols）的时候，有个残酷的事实往往没有实现：每个主要的Layer 2 项目都需要一个的可信方负责执行协议升级。目前，这几乎是所有Layer 2 的主要中心化问题，包括我们。如果升级密钥（Upgrade Keys）出现问题，那么Layer 2 协议中所有存入的资产都将面临风险。

拥有以太坊跨链资产的替代性底层公链（Layer 1）也容易受到类似的破坏性攻击，依靠Layer 1 的安全保障来避免这种情况是Layer 2 愿景的一个关键点。但我们还没有完全达到目的，在某种意义上，每个人都还在卖梦想。

让我们来谈谈导致Layer 2 项目在「升级密钥」方面的风险，以太坊本身是如何避免这些陷阱的，以及我们能够如何效仿。

Layer 2 的中心化情形

你的安全性强度仅取决于最薄弱的那一环。如果你的密码是「passwordpasswordpassword」，再好的加密技术也救不了你。那么，Layer 2 领域当中最薄弱的那一环是什么？

你猜对了，是「升级密钥」。每一个主要的Layer 2 在他们的Layer 1 合约上都有某种形式的即时升级能力，这是好的，因为它允许项目的改进和漏洞修复，但它最终也意味着一个受信任的第三方对Layer 2 余额有单方面的发言权。

但这就衍生了一个问题：如果到头来，升级的重要性可以简单地凌驾于安全性之上，那么拥有容错证明（fault proof）或有效性证明（validity proof）的意义何在？

我们并不是说要无视Layer 2 团队为推动去中心化可扩展性技术的发展所做的努力，我们已经取得了巨大的进步，只要看看我们最近所推出有史以来第一个用于下一代容错证明的漏洞赏金就知道了。相反地，这是一个提醒，当今没有一个主要Layer 2 产品有完备的容错/有效性证明。

这种过渡阶段是需要的，生产这些复杂的协议是不容易的，但我们也需要讨论放弃密钥和实现真正去中心化的Layer 2 愿景的务实路径。

为什么Layer 2 不是去中心化的？

一个必要之恶

开始探讨解决方案之前，让我们先确定问题：所有Layer 2 都有升级密钥的原因是，编写复杂、无漏洞的代码是非常困难的，每写一行新的代码就多一次出现漏洞的机会。

在密码学领域，一个关键的漏洞就可以让一个项目瘫痪，我们必须非常小心。这意味着简洁、简单的代码需求，减少代码是Optimism 理念的核心，也是我们升级EVM（以太坊虚拟机）的主要动力。（即使如此，漏洞还是会被遗漏）。

事实是，去中心化Layer 2 中的任何关键漏洞都是灾难性的：根据设计，智能合约将基于Layer 1 的所有「安全性」来执行，如果没有升级密钥作为最终办法，一般来说将没有追索权，其设计了一种难以置信的高标准。

研究以太坊

以太坊本身就是研究去中心化安全性的一个很好的案例，我们可以用它来判断编写一个没有漏洞的Layer 2 的难度。纵观历史，以太坊有很多漏洞，这些漏洞被写入、找到和修复，有时还会不小心引起硬分叉（相信我们，这不好玩）。

尽管有多个关键漏洞，但以太坊在其整个生命周期中一直保持高度可用性。在上海DoS 攻击期间，当时仅运行两年的以太坊是最接近真正停止运作的一次。鉴于区块链中断在当今仍很常见，这是一个令人印象深刻的壮举。

在这一点上，我们可以非常有信心，以太坊Layer 1 不会瘫痪或被破坏。我们需要对Layer 2 达到同样的信心水准，以便能够放弃升级密钥。那么以太坊的秘密是什么？当我们努力确保Layer 2 的安全时，我们能跟随它的脚步吗？

去中心化的务实路径

以太坊在最小化安全性和最大化正常运行时间方面的成功并不只是运气好，这归功于以太坊策略性地创建了一个多客户端生态系统，并拥有多种不同的互操作性实现方式。

达成这种安全性的方法建立在漏洞与实作之间是不相关的情况下，换句话说：如果一个实作出现一种特定的漏洞，另一个实作可能不会遭受完全相同的漏洞。这样一来，即使出现执行失败，你也可以剔除有漏洞的客户端，而选择正常运行的客户端，这种冗余（Redundancy）是以太坊高度可用性保证的关键。

单一客户端可能执行失败，但以太坊网络仍维持正常状态

我们可以跟随以太坊的脚步，在Layer 2 使用非常类似的方法。我们可以为Layer 2 创建一个多客户端的生态系统，就像我们在Layer 1 中一样，而不是单一实作客户端、一个容错证明或一个零知识证明（Zero-knowledge proof）。这确保了关键的漏洞不会导致整个网络瘫痪。

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

我们设计Optimism 是为了坚持以太坊的理念，不仅从社会影响层面，还包含技术层面。从我们编写Optimism：Bedrock 版本的第一天开始，我们就为以太坊2.0 合并API 的使用来构建它，这使得我们能够轻松地与多个客户端整合。

事实上，我们的目标是将一个标准的以太坊客户端转变为Optimism 客户端所需的代码降至低于1000 行，透过EVM 等效性（EVM equivalence，与以太坊虚拟机规范完全符合），我们还将容错证明和Rollup 客户端的实作模组化为独立的软体片段，综合这些方法，让我们能够混合和匹配证明和客户端，最大化地增加冗余！

ZK Rollups：额外的安全层

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

因此，虽然ZK 技术令人振奋，但我们不需要等待获得一个低成本、高安全性、EVM 等效的Layer 2。现在已经以Optimism 的形式运作，一旦ZK 技术成熟，它可以直接融入我们的架构当中。

推出

目前，我们正在深入Bedrock 的开发核心，这将使我们的EVM 等效性Rollup 的详细规格产生，以及第一个Rollup 客户端和MIPS 容错证明「Cannon」。届时，多客户端旅程就开始了。

我们的目标是与外部团队合作，并激励他们创建其他客户端，这不会是一个快速的过程，但Redrock 已经被建立起来，代码最小化是最重要的部分。要把这些整合到一个多客户端证明系统中，需要遵循Hydra框架。届时，我们将获得移除升级密钥的必要信心。

总结

1. 形成一个Optimists 委员会。
2. 发布Bedrock，实现多客户端架构。
3. 激励/支持替代性Optimism 客户端。
4. 发送多客户端证明合约。
5. 把我们的升级密钥扔进末日火山。

本文链接地址：https://www.wwsww.cn/jishu/11537.html
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。