Rollup 各方案异同简介

[Whisker17]

Rollup 各方案异同简介

Contents

• 简介

• 非交互式 Rollup

• 交互式 Rollup

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

[Whisker17]

一轮交互型 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 得到最终确认。

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

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

[Whisker17]

非交互式 Rollup

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

[Whisker17]

交互式 Rollup

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

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

一轮交互型 Rollup 需要在链上模拟一次完整的调用，成本可能会非常高——因此，合约所执行的调用会受到以太坊的全局 gas limit 的限制。

[Whisker17]

简介

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

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

Back to top