原标题：探讨以太坊Layer2 Optimism的多客户端架构，透过务实的去中心化路径解决Layer2中心化问题
在讨论第二层扩展协议（Layer2 protocols）的时候，有个残酷的事实往往没有实现：每个主要的Layer2项目都需要一个的可信方负责执行协议升级。
目前，这几乎是所有Layer2的主要中心化问题，包括我们。
如果升级密钥（Upgrade Keys）出现问题，那么Layer2协议中所有存入的资产都将面临风险。
拥有以太坊跨链资产的替代性底层公链（Layer1）也容易受到类似的破坏性攻击，依靠Layer1的安全保障来避免这种情况是Layer2愿景的一个关键点。
但我们还没有完全达到目的，在某种意义上，每个人都还在卖梦想。
让我们来谈谈导致Layer2项目在“升级密钥”方面的风险，以太坊本身是如何避免这些陷阱的，以及我们能够如何效仿。
Layer2的中心化情形
你的安全性强度仅取决于最薄弱的那一环。
如果你的密码是“pass word pass word pass word”，再好的加密技术也救不了你。
那么，Layer2领域当中最薄弱的那一环是什么？
你猜对了，是“升级密钥”。
每一个主要的Layer2在他们的Layer1合约上都有某种形式的即时升级能力，这是好的，因为它允许项目的改进和漏洞修复，但它最终也意味着一个受信任的第三方对Layer2馀额有单方面的发言权。
但这就衍生了一个问题：如果到头来，升级的重要性可以简单地凌驾于安全性之上，那么拥有容错证明（fault proof）或有效性证明（validity proof）的意义何在？
探讨以太坊Layer2 Optimism的多客户端架构，透过务实的去中心化路径解决Layer2中心化问题无论建造得多麽坚固，基础薄弱的城堡仍然可能倒塌。
我们并不是说要无视Layer2团队为推动去中心化可扩展性技术的发展所做的努力，我们已经取得了巨大的进步，只要看看我们最近所推出有史以来第一个用于下一代容错证明的漏洞赏金就知道了。
相反地，这是一个提醒，当今没有一个主要Layer2产品有完备的容错/有效性证明。
这种过渡阶段是需要的，生产这些複杂的协议是不容易的，但我们也需要讨论放弃密钥和实现真正去中心化的Layer2愿景的务实路径。
为什么Layer2不是去中心化的？
一个必要之恶
开始探讨解决方案之前，让我们先确定问题：所有Layer2都有升级密钥的原因是，编写复杂、无漏洞的代码是非常困难的，每写一行新的代码就多一次出现漏洞的机会。
在密码学领域，一个关键的漏洞就可以让一个专案瘫痪，我们必须非常小心。
这意味着简洁、简单的代码需求，减少代码是Optimism理念的核心，也是我们升级EVM（以太坊虚拟机）的主要动力。（即使如此，漏洞还是会被遗漏）。
事实是，去中心化Layer2中的任何关键漏洞都是灾难性的：根据设计，智能合约将基于Layer1的所有“安全性”来执行，如果没有升级密钥作为最终办法，一般来说将没有追索权，其设计了一种难以置信的高标准。
研究以太坊
以太坊本身就是研究去中心化安全性的一个很好的案例，我们可以用它来判断编写一个没有漏洞的Layer2的难度。
纵观历史，以太坊有很多漏洞，这些漏洞被写入、找到和修复，有时还会不小心引起硬分叉。
尽管有多个关键漏洞，但以太坊在其整个生命周期中一直保持高度可用性。
在上海DoS攻击期间，当时仅运行两年的以太坊是最接近真正停止运作的一次。
鉴于区块链中断在当今仍很常见，这是一个令人印象深刻的壮举。
在这一点上，我们可以非常有信心，以太坊Layer1不会瘫痪或被破坏。
我们需要对Layer2达到同样的信心水准，以便能够放弃升级密钥。
那么以太坊的秘密是什么？当我们努力确保Layer2的安全时，我们能跟随它的脚步吗？
去中心化的务实路径
以太坊在最小化安全性和最大化正常运行时间方面的成功并不只是运气好，这归功于以太坊策略性地创建了一个多客户端生态系统，并拥有多种不同的互操作性实现方式。
达成这种安全性的方法建立在漏洞与实作之间是不相关的情况下，换句话说：如果一个实作出现一种特定的漏洞，另一个实作可能不会遭受完全相同的漏洞。
这样一来，即使出现执行失败，你也可以剔除有漏洞的客户端，而选择正常运行的客户端，这种冗馀（Redundancy）是以太坊高度可用性保证的关键。
我们可以跟随以太坊的脚步，在Layer2使用非常类似的方法。
我们可以为Layer2创建一个多客户端的生态系统，就像我们在Layer1中一样，而不是单一实作客户端、一个容错证明或一个零知识证明（Zero-knowledge proof）。
这确保了关键的漏洞不会导致整个网路瘫痪。
采用多客户端架构的去中心化Optimism
设计Optimism是为了坚持以太坊的理念，不仅从社会影响层面，还包含技术层面。
从编写Optimism：
Bedrock版本的第一天开始，就为以太坊2.0合并API的使用来构建它，这使得我们能够轻松地与多个客户端整合。
事实上，我们的目标是将一个标准的以太坊客户端转变为Optimism客户端所需的代码降至低于1000行，透过EVM等效性（EVM equivalence，与以太坊虚拟机规范完全符合）。
我们还将容错证明和Rollup客户端的实作模组化为独立的软体片段，综合这些方法，让我们能够混合和匹配证明和客户端，最大化地增加冗馀！
ZK Rollups：额外的安全层
我们经常被问及一个问题：“你们会采用零知识证明技术吗？”
答案是可能的，但不是你想像的那样。
前面的路还很长，但如果ZK技术变得足够强大，能够支援EVM等效性，那么就有可能在多客户端生态系统当中将其作为另一个客户端添加，这并不意味著放弃我们目前的架构或核心功能，但它确实意味著另一个安全层。
因此，虽然ZK技术令人振奋，但我们不需要等待获得一个低成本、高安全性、EVM等效的Layer2。
现在已经以Optimism的形式运作，一旦ZK技术成熟，它可以直接融入我们的架构当中。
推出
目前，我们正在深入Bedrock的开发核心，这将使我们的EVM等效性Rollup的详细规格产生，以及第一个Rollup客户端和MIPS容错证明“Cannon”。
届时，多客户端旅程就开始了。
我们的目标是与外部团队合作，并激励他们创建其他客户端，这不会是一个快速的过程，但Redrock已经被建立起来，代码最小化是最重要的部分。
要把这些整合到一个多客户端证明系统中，需要遵循Hydra框架。届时，我们将获得移除升级密钥的必要信心。
链金研究员总结
1.形成一个Optimists委员会。
2.发布Bedrock，实现多客户端架构。
3.激励/支援替代性Optimism客户端。
4.发送多客户端证明合约。
5.完全放弃升级密钥这种方式。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。