摘要：Rollup之间的选择就是在解决争端所需的链上成本和时间之间作出权衡。

作者 Ed Felten  翻译 & 校对  闵敏 & 阿剑

Rollup 是近年来在智能合约可扩展性方面最火爆的想法之一。这个想法已经提出有一段时间了，但是直到最近才有几个团队，其中也包括我们 Offchain Labs 团队，才开始大力推进。接下来让我们花个几分钟时间，来谈谈什么是 rollup ，以及不同的方案之间有什么相关性。

Rollup 是一种可以对开放式合约（即，所有人都能看见并与之交互的合约）进行扩容的通用方法。在 Rollup 上，对合约的调用及其 argument（实际参数）都是作为调用数据（calldata）写在链上的，但是合约的实际计算和存储都是在链下完成的。有人会在链上发布一个 assertion（断言），断言合约将要执行的一系列操作（例如要完成的支付）以及执行完成之后合约状态的哈希值。可以认为，这个发布上链的断言将所有的调用和结果都 “卷起来”（“rolling up”）成为单笔发送上链的交易。

不同的 Rollup 系统有所区别的地方在于确保 assertion 正确性的方式。这里有三种基本方法：非交互型 rollup（如，ZK-Rollup）、一轮交互型 rollup（如， “optimistic rollup” 提案）和多轮交互型 rollup （如，我们团队的 Arbitrum Rollup ）。

非交互型 Rollup（如，ZK-Rollup）

非交互型 rollup 依赖于简洁的有效性证明。每个 assertion 都会附有一个易于验证的证明（如，SNARK），以此表明 assertion 里的计算和结果都是正确的。例如，ZK-Rollup 系统使用的是 ZK-SNARKs ，即，一种易于验证的零知识证明系统 。这对于矿工和其他观察者来说很友好，因为验证证明的成本较低，可以立即核实 assertion 的正确性。但是，零知识证明系统也有一个很大的缺点：除非要断言的交易非常简单，否则创建证明的成本会高得离谱。因此，ZK-Rollup 非常适用于支付交易，但是对于复杂一点的智能合约执行来说，效果就没那么好了。

用于智能合约的 Rollup

对于复杂的智能合约来说，我们必须采用一种交互式方法。也就是说，如果要将 assertion 发布到链上，asserter（断言者）必须缴纳保证金，并且会开放一个时间窗口，如果验证者认为该 assertion 不正确，可以在窗口期内挑战它。有时这被称为 “错误性证明”。如果 asserter 发布了错误的 assertion ，就会失去自己的保证金。

一轮交互型 rollup 又称为“optimistic rollup”，不过这么说有点用词不当，因为所有交互型 rollup 都是乐观主义的设计。在一轮交互型 rollup 中，assertion 包含每次调用的结果，挑战者会指出 assertion 中对哪个调用给出的结果是错的。链上合约会模拟执行被挑战的调用，并验证 asserter 关于这个调用的声明是否有误。如果真的有误，则取消整个 assertion ，并罚没 asserter 的保证金。如果一个 assertion 到挑战期结束为止还没有被挑战成功的话，就会被接受并得到最终确定。

在多轮交互型 rollup（例如，我们团队的 Arbitrum Rollup 产品）中，也设有挑战窗口期，挑战者可以在此期间缴纳保证金，并声明该 assertion 是错误的。接下来就会触发 asserter 和挑战者之间的往复交互型协议，并由一个链上合约来充当该协议的仲裁方（referee）。最后由仲裁方来决定哪一方有误，并罚没其保证金。这种设计是为了将解决争议所需的链上工作量降至最低，即，在链上仲裁方据实评估合约行为之前，先通过交互型协议尽可能缩小双方之间的争议范围。

一轮交互型 Rollup vs. 多轮交互型 Rollup

归根结底，一轮交互型 Rollup（例如，“optimistic rollup”）和多轮交互型 Rollup（例如，Arbitrum Rollup）之间的选择就是在解决争端所需的链上成本和时间之间作出权衡。一轮交互型 Rollup 需要在链上模拟一次完整的调用，成本可能会非常高——因此，合约所执行的调用会受到以太坊的全局 gas limit 的限制。多轮交互型 Rollup 则不受此限制，它会进一步缩小争议范围，直到可以以较低成本在链上解决该争议为止。通常情况下，多轮交互型 Rollup 还可以在链上编写较少的数据。

写到链上的内容

一轮交互型 Rollup 和多轮交互型 Rollup 都需要编写所有对合约的调用及其数据到链上，这些就是调用数据。但是，二者之间的区别在于，需要放到链上作为 assertion 的数据不同。通常来说，assertion 包含对多个对合约的调用。一轮交互型 Rollup 需要把每一步哈希值添加到 assertion 内。如此才能使得每一次调用都可以被单独挑战。相比之下，多轮交互型 Rollup 只需要在 assertion 的最后添加整个合约状态的哈希值即可。（中间状态哈希值将会按需生成，但仅在极少数存在争议的情况下。）这样一来，多轮交互型 Rollup 的链上数据成本会略低一些。

一轮交互型 Rollup 中的挑战期和最终确定性

在任意类型的交互型 Rollup 中，系统都必须具备抵御审查攻击的能力。令人担忧的是，攻击者可能会提交一个错误的声明，然后发起审查攻击来阻止所有针对这个声明的挑战被公布到链上，直到挑战期结束，错误的声明被接受为止。对此的解决方案是，确保挑战期比审查攻击的持续时间更长。（也可以采用防御措施，例如，对发布错误声明的一方予以更高额的罚款，并鼓励潜在的挑战者使用复制和其他系统方法来抵御审查攻击。）

鉴于上文对审查攻击的设想（我会在之后的文章中阐述），挑战期可能需要很长一段时间。例如，有些系统将挑战期设为一周时间。也就是说，交易被提交之后，需要等待整整一周时间才能得到 Rollup 协议的确定——直到那时，通过交易完成的付款才算已经发生在链上。

这会造成很大的问题吗？可能比你想象的要少。要想了解原因的话，我们先假设一个有效的 assertion 已经被发布到了链上，并且正在等待确认。你或是其他任何人都可以核实这个 assertion 的正确性。而且你知道 Rollup 协议最后会对有效的 assertion 进行确认。因此，即使 Rollup 协议还没有确认某个 assertion ，但是每个关注它的人都知道这个 assertion 将会被确认，可以把它当作“已确认过”。他们都知道被确认是迟早的事，因此可以继续推进下去。

举例来说，如果你将会通过这类交易收到一笔付款，且每个人都能够确定这笔付款肯定会发生，因此可以签署这笔付款并将其转让给其他人，被转让人也能确定自己将来肯定会收到这笔付款。这几乎就跟现金一样，唯一的差别是，因为是延迟确认，其价值会等于面值减去一小笔利息（译者注：可以想象成票据贴现）。

关键在于，即使在被确认之前，一个有效的交易也可以获得 “免信任确定性（trustlessly final）”。也就是说，任何人都能够确定这个交易会得到确认。

多轮交互型 Rollup 中的挑战期和最终确定性

在多轮交互型 Rollup 中也是如此：该协议在设计上可以让有效的 assertion 具备免信任确定性，因此任何人都可以确定这个 assertion 一定会得到确认。区别在于，为了确保交易得到确认，你必须准备好参与到该协议中来保护 assertion ——只要你愿意这样做，你一个人就可以让有效的 assertion 得到最终确认。

（专门给我们的 Arbitrum Rollup 产品的一个边注：尽管 Arbitrum 技术的早期版本并没有提供这种免信任确定性，但是最新的版本是有的。在旧版本的协议中，为了安全起见，每个被挑战的 assertion 都会被取消，以防该挑战的相关方串通起来将错误的挑战结果上链。在新版本的协议中，凡是诚实的相关方都可以强制让正确的结果通过挑战期，因此有效的 assertion 一定会通过挑战并得到确认。）

（这里还需要纠正一个误区，即，只要有争议存在，多轮交互型 Rollup 协议就必须“暂停整个网路”，也就是说，如果有恶意参与方愿意损失押金，就可以一直阻止网络进程。在最新版本的协议中并非如此。各方可以继续发布新的 assertion ，无论争议是否继续，新的 assertion 可以获得免信任确定性。只是协议的正式确认被拖慢了而已——这需要攻击者付出巨大代价。)

在多轮交互型 Rollup 协议中，确认一个 assertion 需要多久？在通常情况下，如果一个有效的 assertion 发布之后没人挑战的话，在确认之前就只会经历一个挑战期，就像一轮交互型 Rollup 那样。

如果出现了特殊情况，即 assertion 有效但依然遭到了挑战，最终确认会在多轮争议协议的影响下被推迟。挑战者注定会输，并失去保证金，但是会将最终确认的时间推后。这不会影响 assertion 的免信任确定性，因为所有人一开始就可以判断出该 assertion 是有效的，还可以在必要之时强制确认有效的 assertion 。整个网络会继续像往常那样安全运行下去，所有人都知道这种恶意挑战最终会输。

哪种 Rollup 更适合你？

那么，你应该采用那种 Rollup 系统呢？如果仅仅用于支付，或是很简单的智能合约，像 ZK-Rollup 这样的非交互型系统比较合适。

如果你想运行比较复杂的智能合约，就需要从一轮交互型（例如， “optimistic rollup”）和多轮交互型（例如，Arbitrum Rollup） Rollup 系统中进行选择。在通常情况下， 这两种系统都需要等待较长一段时间才能对 assertion 进行最终确认，而且会为有效的 assertion 提供即时的免信任确定性。一轮 Rollup 系统的优点是可以抵御 “推迟确认” 攻击，作恶者无法通过放弃保证金的方式推迟 assertion 的最终确认（在任何情况下，assertion 都具有免信任确定性）。多轮 Rollup 系统的优点是（1）通常情况下占用的链上空间较小，并且（2）可以处理计算量和存储量较大的合约，不受以太坊 gas limit 的限制。

我们 Offchain Labs 团队认为大多数人都会喜欢链上成本较低且适用性较广的多轮 Rollup 系统，如 Arbitrum Rollup ，而且多轮 Rollup 系统的劣势也可以通过增加挑战所需的保证金来补足，以此抵御推迟确认攻击。

我们还认为，多轮 Rollup 系统很容易正确实施。这就是为什么我们希望接下来的几个月（甚至更早）在测试网上提供 Arbitrum Rollup 的功能版本。

（完）

（文内提供了许多超链接，请点击阅读原文到 EthFans 网站上获取）

原文链接:

https://medium.com/offchainlabs/whats-up-with-rollup-db8cd93b314e