乐观Rollup的“为什么”

为什么乐观 Rollup 具有什么特性，它为何安全和去中心化，以及为什么它是今天扩展以太坊的最有前景的途径？

如果你在阅读这个帖子，你肯定听说过乐观 Rollup，这是一种新兴的扩展技术，今年在 DevCon 上备受关注。已有几篇文章解释了这种技术是如何工作的，但没有人解释为什么它能奏效。这导致许多团队试图以他们自己的方式实现乐观 Rollup，通常会损害整个系统的加密经济安全性。

这篇文章旨在第一次聚焦于这一主题：解释乐观 Rollup 如何在保持去中心化的同时可持续、安全地扩展。

什么是乐观 Rollup？

我在六月份写了第一份最小可行规范，现在被称为乐观 Rollup。该规范为我早期论文构建可扩展的去中心化支付系统（与[Mikerah](https://medium.com/u/45aa03e426be?source=post_page---user_mention--7c6a22cbb61a---------------------------------------）共同撰写）中提出的更一般概念提供了具体的参数化高层规范。目标是首次在区块链历史上实现一个无权限、最小信任、可扩展的侧链。

而不是这个。（来源）

乐观 Rollup 的工作原理如下：任何人都可以无权限地提交侧链块，将整个块作为 calldata 发布在链上，以便进行身份验证（即 Merkleized）和抵押。新的侧链块只能延伸侧链的尖端，链上合约跟踪尖端（简单来说，合约充当轻客户端，存储侧链块头哈希）。侧链块在经过一段较长的延迟后完成（这是一个系统参数，应该相当长，例如一两周），届时返回抵押金。提现在侧链上发起，可以通过针对已完成的侧链块进行非交互式的包含证明完成。如果一个侧链块无效且未完成，它及其所有后续块可以通过提交非交互式欺诈证明被孤立，以回滚链的尖端，并烧毁一半的抵押金，将另一半奖励给欺诈证明人。所有这一切使得资金在最小信任的情况下双向桥接成为可能。

没错，事情就是这么简单。那么为什么之前没有实现这一点呢？

我再进一步：为什么这样乐观 Rollup？

事实证明，乐观 Rollup 和之前的扩展提议之间存在一些微妙的差异，使前者成为最有前景的短期到中期扩展解决方案，而后者大多被 relegated到历史书中。本节涵盖了这些关键差异背后的直觉。

合并共识

乐观 Rollup 的一个关键特征是合并共识，一种可在链上验证的共识协议（实际块验证通过欺诈证明隐式完成）。但是，什么是去中心化的共识协议？

去中心化共识协议包含几个独特的特征：

• 一个分叉选择规则（如何在两个有效链之间选择）
• 一个块有效性函数（状态转换函数）
• 一个领导者选择算法（谁被允许通过新增块来推动链的进展）
• 一个 Sybil 抵抗机制（工作量证明、权益证明等）

这些特征一起为区块链提供了经济安全性：操控历史的成本。（注意，为了简洁起见，我在这里忽略了一些内容，例如一些去中心化共识协议是无领导者的）。

在乐观 Rollup 中，侧链在构建上是无分叉的，因此不需要复杂的分叉选择规则。块有效性在链下执行，并可以通过欺诈证明在链上证明不正确。这使得我们只需关注领导者选择和 Sybil 抵抗。

该规范提出了“先到先得”的方案，接受第一个扩展侧链的交易。领导者选择是隐含的，并且事后决定，而 Sybil 抵抗由主链本身提供（即交易费用和区块大小/油价限制）。为什么这种简单的领导者选择能奏效？因为以太坊链本身已经提供了安全性。孤立的唯一方式是如果它无效或构建在无效块之上，或者如果以太坊链发生重组。因此，有效块具有与以太坊相同的终局性和安全保证！因此，我们不需要复杂的领导者选拔算法或昂贵的 Sybil 抵抗机制来提供安全性；安全性是免费的，以便我们可以将系统参数化得尽可能简单。

好的，但如果我们想预先知道领导者呢？一个建议是可以在链上运行 PoS + RANDAO 来进行领导者选择。不需要分离的代币，实际上对这个过程是有害的。根据比特币设计论文：

如果一个贪婪的攻击者能够组装比所有诚实节点更多的 CPU 能力，他将不得不在利用这项能力去欺骗他人窃取支付与用于产生新币之间做选择。他应该发现遵循规则更有利可图，这些规则使他获得比其他人更多的新币，而不是通过破坏系统和自己财富的有效性来获利。

中本聪所描述的原生货币/代币的整个意义在于激励诚实的多数来保护这个系统。乐观 Rollup 中没有“诚实的大多数”，也不存在分离的安全概念，因此原生代币完全没必要，而且只会增加比仅使用以太币更多的摩擦。

注意，实际上可以使用任何完全在链上运行的领导者选择方案，而不仅仅是我在这里建议的方案。例如，可以使用燃烧证明拍卖。

这个合并共识的想法是乐观 Rollup 和一些相似提案之间的关键区别，例如延迟状态执行或阴影链。乐观 Rollup 的共识协议完全在链上运行于智能合约中；因此，它不影响或需要主链共识规则的支持。相反，延迟状态执行和阴影链自动在链上应用状态转换，这需要主链共识规则的明确支持以及协议内的激励和惩罚。

可持续扩展

现在我们知道乐观 Rollup 如何通过合并共识而无权限，那么它为什么能够在可持续的情况下扩展呢？

未压缩的以太坊状态（用户余额和合约存储）在当前写作时的大小约为~45GB。与历史（交易和块）不同，完整节点无法修剪状态——必须完整保留状态以验证（即，执行）新交易。更糟糕的是，为了验证交易，必须执行许多随机访问状态，这就要求状态必须保留在 RAM 中——大多数消费硬件无法做到——或者在快速的 NVMe SSD 上。状态增长是以太坊的单一最大扩展瓶颈。

虽然确实可以设置状态大小的硬限制，从而不必担心状态增长，不失其真正解决方案是某种形式的状态租金，对使用状态收取持续费用。然而，将这种变化引入以太坊的复杂程度超乎想象，并且已无限期推迟。

一种适当的解决方案是使用区块链作为数据可用性层，在某种程度上缓解了状态增长的问题。最早由zk rollup普及，这些方案将侧链交易数据作为 calldata 发布在主链上，然后使用有效性证明或欺诈证明确保正确性。事实证明，历史比状态便宜得多（也就是说，价格量级便宜得多）。因此，主链可以负责确保数据可用性，跟踪 Rollup 链的块头，处理存款和提取，并检查有效性/欺诈证明，而这些都不会特别重利用状态。通过避免状态，以这种方式扩展在长期内是可持续的。Buterin 在这里提供了利用链上数据可用性进行 zk rollup 和乐观 Rollup 的优秀总结。

需要注意的是，尽管有人建议阴影链与乐观 Rollup 完全相同，但那显然是不真实的。

现在的想法是创建一个完整的“阴影链”，计算在链外进行，但在 100 个块后将状态转换提交回主链。预言机可以将新区块添加到链的“尾部”，其中块由交易列表和由这些交易引起的状态转换的[[k1, v1], [k2, v2] ... ]列表组成。如果一个块在 100 个块内没有遭到挑战，则状态转换将自动应用到主链。

除了被描述的不够充分之外，阴影链的想法是在链上自动应用状态转换，这对状态增长没有任何帮助。乐观 Rollup 只有在用户明确支付的情况下才应用任何状态转换（即，提取）。

非交互性芳恩的胜利

乐观 Rollup 大大强调非交互式欺诈证明。为什么呢？

这种偏执 实际上源自于希望避免Plasma Cash 的一个缺陷，即对无效历史进行交互式退出挑战。这种交互式的多步骤挑战使 Plasma Cash 特别易受链拥堵攻击，攻击者向主链发起大量退出，试图窃取所有来自 Plasma 合约的资金（尽管它在这些攻击中比无尽的 Plasma MVP 更有抗干扰性）。仅需一个非交互式欺诈证明即可孤立任何数量的无效乐观 Rollup 块（按侧链），使系统能够抵抗链拥堵。需注意的是：由于乐观 Rollup 使用欺诈证明，如果主链不具有抗审查能力，资金仍有可能被盗。

在乐观 Rollup 中，提现也以非交互方式进行，在侧链上发起并通过针对主链上已完成块的非交互式包含证明完成。这要求侧链必须是无权限的，因此需要合并共识，而不是像 Plasma 一样的单一操作员。

使用非交互式欺诈证明也比交互式验证游戏具有优势。交互式验证游戏需要长时间进行。鉴于乐观 Rollup 是无分叉的，攻击者可以通过产生一个无效块并在验证游戏的持续期间中止侧链来进行拒绝服务攻击。通过非交互式欺诈证明，可以立即证明欺诈（尽管有一个需要注意的前提，即通过欺诈证明所能证明的内容在潜在上要少于通过交互式验证游戏所能证明的内容——这种限制在区块链应用中是否真正有意义则有待辩论）。

解密交易延迟声明

乐观 Rollup 不减少交易延迟。每个侧链块都需要提交到主链，因此区块时间不会低于主链。除非使用充分抵押的通道，否则没有已知的安全和无信任的方法可以减少这种延迟。

然而，你不必等到侧链块完成才能接受其交易。由于乐观 Rollup 是无分叉的，所有在链上接受的有效块最终都会完成，并且所有数据都是可用的（因为所有有效块都在链上发布），用户可以进行客户端验证以立即接受交易。

提现延迟乍一看似乎是另一个问题，但实际上并非如此。在通常情况下，用户不必等到他们的提款完成。实际上，该功能在很大程度上主要存在于加密经济安全中，正常情况下不应使用。立即提取资金的简单方法是与流动性提供者（或希望存入 Rollup 链的其他用户）进行原子交换 [见章节快速提款：流动性提供者]。

乐观 Rollup 为你提供即时、无Gas费用的交易！

关于数据可用性挑战

原始论文隐式和显式地建议了三种解决数据可用性问题的方法：

1. 始终将所有数据发布在链上
2. 使用数据可用性挑战在需要时仅发布该数据
3. 使用数据可用性证明

第二种情况，数据可用性挑战，似乎是一个不错的简单解决方案。不幸的是，如果防御者为挑战付费，他们可能会遭到恶意攻击。如果攻击者为挑战付费，该系统就会简化为始终在链上发布所有数据。因此，在设计规范时，选择持续发布所有数据，而专注于让此过程更便宜和更高效。后来，使用数据可用性证明来优化乐观 Rollup变得可行。

进一步改进

我针对原始最小规范撰写了一些性能改进，概述如下。注意，重点主要是基于 UTXO 的支付和谓词，而不是一般智能合约执行。

以太坊 1 的多线程数据可用性——身份验证（即 Merkle 化）数据和其他预处理步骤是纯函数，因为它们不接触任何状态。因此，它们可以并行化。以这种方式利用以太坊将大大减少状态使用和增长，如果针对 4 核电脑，数据可用性吞吐量将增加 4 倍。为实现这一目标，计划中的几个 EIP 的第一个是EIP-2242：交易后数据。

无中介状态序列化的 UTXO 链紧凑欺诈证明——用于以太坊风格智能合约的通用欺诈证明是昂贵的。在 UTXO 数据模型中，UTXO 最多被创建一次且最多被消费一次，每个交易完全描述其状态转换。区块生产者可以在每个输入上附加元数据，声称特定的输出生成了它。如果声明不正确，可以通过非交互式方式证明这一点。独立重新发现的欺诈证明方案在 BIP-141 中得到了描述。

基于 Merkle 归纳法的链上无状态交易验证的实用性（无状态客户端）——状态查找是昂贵的。无状态客户端通过消除状态来消除这些成本。简而言之：只需消除状态查找。见证的有效期不再是立即的，但可以在几个块内有效。它们必须与最近块的状态转换进行比较，这可以在 UTXO 数据模型中无状态计算。

链上非交互式数据可用性证明——始终在链上发布所有数据是昂贵的，并且限制乐观 Rollup 为线性扩展（与诸如 Plasma，此类完全链外技术没有相对的渐近问题，因为Plasma Cash 检查点也是线性的）。我们可以将共识节点进行数据可用性检查的能力暴露为FFI功能（例如，通过预编译），这赋予我们二次扩展而不需要分片。这是像Celestia这样的系统的核心思想，承诺显著提高数据可用性吞吐量且成本低。然而，与 Celestia 不同，在以太坊上实现这一点并不会提供前者的扩展属性。

通过中止建立的无信任双向桥与侧链——侧链的永远在线要求，与使用欺诈证明的双向桥可能对用户来说是繁琐的。不像 Plasma Cash，其不适用于监视塔，可以为乐观 Rollup 使用监视塔。然而，我们可以做得更好：在预定的时间后完全和永久地暂停侧链，然后为用户提供一个巨大的窗口（几个月）来提交欺诈证明以确定有效的链头，用户必须在线的窗口是1）已知的，2）有限的。只有在此期间过期后才能提款；希望提前提取资金的用户可以通过与流动性提供者进行原子交换而实现。

正在建立乐观 Rollup 的团队

自从几个月前撰写第一份乐观 Rollup 最小规范以来，我很高兴地发现许多开发团队已开始构建乐观 Rollup 的实现，具有各种不同的花样和修改。以下是我们迄今为止公共看到的非详尽清单（顺序、包含或不包含不应被视为认可或批评）。

Fuel——以 UTXO 数据模型为重心，侧重于稳定币支付。可以进行任意 ERC-20 代币和以太币的转账及原子交换，未来将实现谓词脚本。接近长期使用的公共测试网发布。

Plasma Group——在OVM背景下的通用 EVM 风格智能合约。在 DevCon 5 上与 Uniswap 合作演示了Unipig。

Arbitrum——交互式验证游戏而非非交互式欺诈证明，通用智能合约。除此之外，新的Arbitrum Rollup 设计与乐观 Rollup 在很大程度上是相同的。

Interstate Network——通用 EVM 风格智能合约，带有欺诈证明。

SKALE——配备BLS 签名聚合的乐观 Rollup。

NutBerry——交互式验证游戏而非非交互式欺诈证明，通用 EVM 风格智能合约。

IDEX——针对其交易所的“优化乐观 Rollup”。

结论

即将到来的一年将是以太坊的游戏改变者，因为实现乐观 Rollup 的项目上线，将大幅提高以太坊的吞吐量，并在可扩展的、可持续的数据可用性领域推动进一步创新。

如果你对与 zk rollup（一个最初由 Barry Whitehat 作为roll_up开发的想法，后来由 Buterin 改进为zk rollup）的比较感到好奇，我在这里没有覆盖，查看这一篇出色的文章，由Alex Gluchowski撰写。

感谢Mikerah Quintyne-Collins、James Prestwich、Robert Drost和Joseph Chow的审阅。

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