Optimism 的未来:Bedrock 升级 Rollup 去中心化以及融合 ZK 方案
注:原文作者是 Optimism 核心开发者 Kelvin Fichter(smartcontracts)。
以下是关于 Optimism 未来的帖子,包括即将到来的 Bedrock 升级,Rollup 的去中心化以及关于 ZK 的部分。 Bedrock 是一个 Rollup 客户端,而不是一个 Optimistic Rollup 客户端。
我最近发表了一次题为《何时?》的探索 Optimism 未来的主题演讲,由于 Optimism 做的所有东西都是开放的,因此这次演讲里面有很多 alpha 信息。
我想谈谈我在那次演讲中提出的一些最重要的观点,因为它们对于理解“为什么 Optimism 会以这种方式做事”是至关重要的。让我们来谈谈 Bedrock、去中心化以及 ZK 的未来。
Bedrock 架构
Optimism 即将推出的 Bedrock 设计是有史以来最先进的 rollup 架构。这不是什么比赛,Bedrock 在各个方面都接近理论上的最优值,包括最优的交易费用、最优网络以及最优区块生产。
Bedrock 之所以如此先进,是因为它非常模块化并且是极简的,它的设计理念是把 以太坊 现有的代码变成 Rollup 代码,并且我们成功了。我们的客户端差异是 500 行代码。
Bedrock 有一个新的 L2 派生管道,使其成为了一个独一无二的 rollup 架构,在将 tx 数据发布到以太坊时挤出每一点节省的 gas。Bedrock 也是当前唯一使用以太坊引擎 API 实现共识/执行客户端分离的 rollup 设计。
那这些为什么很重要呢?
因为 Bedrock 是使得 Optimism 成为第一个真正去中心化的 EVM Rollup 的基石。
为了使一个 rollup 真正安全与去中心化,它需要有一种证明机制(故障证明或有时是“欺诈证明”),而无需任何类型的升级密钥,可以在不长时间延迟的情况下更新证明。
这就是 rollup 肮脏的真相,如果你有快速升级,即使你有故障证明,你的区块链安全性仍然取决于你的升级密钥。而在解决该问题之前,你根本无法获得真正的 rollup 级安全性。
目前,只有一种方法可以一劳永逸地解决这个问题 :客户端多样性以及证明多样性。
就像以太坊需要客户端多样性(Geth、Erigon、OE、Nethermind 等)一样,rollup 也需要客户端多样性。有了客户端的多样性,一个漏洞就变成了一次链分裂,并且可以得到解决。而如果没有客户端多样性,一个漏洞就有可能成为关键的安全事件。
Bedrock 的 500 行代码差异以及共识/执行分裂并非是偶然。这是一个深思熟虑的决定,旨在使 rollup 客户端多样化成为可能。我们已经有了 Optimistic Geth,那你知道还会有 Optimistic Erigon 吗?
我们最终还将通过故障证明的多种实现来证明多样性。最终结果是,我们可以使用多个客户端运行多个证明,这意味着我们可以通过查看任何证明结果是否不一致来检测关键的漏洞。
客户端和证明的多样性是未来,它将使我们能够安全地删除快速升级密钥。
但 Bedrock 也是其他东西的基础……
Bedrock 非常灵活和模块化,我们的 L2 派生管道和我们的故障证明架构,意味着 Bedrock 可以轻松插入新的数据可用性层。这就是为什么 OP Labs 正在努力帮助交付 EIP-4844 ("proto-danksharding")。
一旦以太坊交付 EIP-4844,Optimism 就可以无缝迁移到「data blobs」交易类型,用户将能够节省大量的 gas 费用。
并且,Bedrock 是非常灵活的,它是一个 Rollup 客户端,而不是一个 Optimistic Rollup 客户端。
Optimistic 和 ZK 系统的无缝过渡
与其他设计不同,Bedrock 与所使用的 Rollup 证明类型完全无关,它甚至不知道证明。现在,我们正在构建一个 Optimistic 证明……
但是 Bedrock 也可以使用一个 ZK 证明系统,我们认为 Optimistic Rollup 目前相比 ZK 同类产品具有优势,而 Bedrock 旨在使 Optimistic 和 ZK 之间的无缝过渡成为可能。
Optimism 是为未来做准备的,而 Bedrock 就是未来的基础。这并不是关于构建最好的 Optimistic Rollup 或最好的 ZK Rollup,而是关于构建最好的 Rollup。我们不只是这么说,我们是从头开始这么设计的。
如果你想了解更多信息,我强烈建议你看看《Wen?》这期演讲视频,它大约有 1 个小时的时间,并且要比这篇文章中提到的要更详细得多。
而关于这个帖子,以太坊联合创始人 Vitalik Buterin 也发表了他的看法:
“混合思路:optimistic + ZK,治理只用于判决两者之间的漏洞。
1、发布区块;
2、等待 24 小时时长的欺诈挑战期;
3(a)如果没有挑战,则发布 ZK SNARK,最终确认;
3(b)如果出现了挑战,根据(挑战游戏、ZK SNARK 以及治理)的 3 个选项中的 2 个做出决定;