Rollup最近在Ethereum社区风靡一时，有望在未来成为Ethereum的主要扩容解决方案。但这项技术到底是什么样的呢？它可以给我们带来什么变化？我们如何使用这项技术？这篇文章将试图回答其中的一些关键问题。
背景：什么是Layer1和Layer2扩容？
目前主要有两种区块链扩容方式。
首先，你可以直接提高区块链交易吞吐量，但这类技术主要挑战为「当区块容量越大时，区块链将更难以验证，而且很可能逐渐变得更中心化」。为了避免这样的风险，开发者可以提高客户端软件的效率，或者使用Sharding技术让构建和验证工作分散到许多节点上，目前Ethereum准备借助Eth2升级引入Sharding技术。
其次，你也可以改变使用区块链的方式。用户不必将所有交易放在区块链上，而是可以通过Layer2协议在链下执行大部分交易。即链上的智能合约只需执行两个任务：处理存取款和验证链下交易的有效性。由此减轻链上负担，提高交易处理效率。
Statechannelsvsplasmavsrollups
目前主要有三种Layer2扩容方案：Statechannels、Plasma和Rollups，这三种各有优劣。
译者注：译文中省略Statechannels和Plasma科普内容，主要讲述Rollups部分。
术语说明
Batch：批处理交易，指将Layer2交易批量打包并提交到Layer1的Rollup合约。
Sequencer：排序者，指在Layer2上打包排序交易的角色，类似Layer1的矿工。
Stateroot：状态根，指Layer2上所有状态通过MerkleTree生成的哈希值。
Rollups
参考：Optimisticrollups和ZKrollups。
Plasma和StateChannels是「完全」的Layer2方案，因为它们试图将数据和计算都转移至链下。然而，由于存在「数据可用性的博弈问题」，意味着这两种方案不可能安全地满足所有应用场景。
Plasma和StateChannels通过依赖所属权的owner来解决该问题，但这使它们无法完全通用化。
另一方面，Rollups是一种「混合」的Layer2方案。Rollups将计算转移至链下，但同时将每笔交易的部分数据保留在链上。
为了提高效率，他们使用了不少fancy的压缩技巧，尽可能地使用「计算」代替「数据」。其结果是系统的扩容仍然受限于底层区块链的数据带宽，但效率是可观的：EthereumERC20代币转账成本约为45,000gas，而Rollup中的ERC20代币转账仅使用16字节的链上空间，成本低于300gas。
事实上，数据上链是关键。将数据放在链上并获得共识，如果任何人愿意，他们可以在本地处理rollup中的所有操作，从而允许他们监测欺诈交易，请求提款，或亲自生成transactionbatches。
因为没有数据可用性问题，所以恶意或离线运营者所造成的损失会更少，从而为谁有权发布batches打开了更大的设计空间，并简化rollups系统。最重要的是，没有数据可用性问题也意味着不再需要将资产映射到owners。
这是Ethereum社区对rollups比以往的Layer2扩容方案更兴奋的关键原因：Rollups是完全通用的，我们甚至可以在rollup内运行一个EVM，使得现有的Ethereum应用不必编写过多新的代码就可以迁移到rollups上。
那么Rollup到底是如何工作的呢？
链上会有一个智能合约维护着stateroot：rollup状态的Merkleroot。
任何人都可以发布一笔batch交易，这是一个高度压缩的交易集合，包含旧的stateroot和新的stateroot。合约会检查batch中的旧stateroot是否匹配当前的stateroot，如果匹配，则将stateroot更新到新的stateroot。
为了支持存款和提款，我们增加了交易的能力，其输入或输出是「外部」的rollup状态。如果一个batch来自外部的输入，那么提交该batch的交易也需要将这些资产转移到rollup合约中。如果一个batch有对外的输出，那么在处理该batch时，智能合约将会执行「提现」操作。
这一切就这么简单!除了一个主要的细节：如何知道batch中的post-stateroots是正确的呢?如果有人可以用任意post-stateroot提交一个batch而没有任何惩罚，他们就可以直接将rollup内的全部资产转给自己。这个问题有两种截然不同的解决思路，从而衍生出两种「口味」的rollup方案。
OptimisticrollupsVSZKrollups
以下是这两种「口味」的rollups方案描述：
Optimisticrollups，采用欺诈性证明：rollup合约会跟踪历史的stateroots和每一个batch的哈希值。如果有人发现某个batch的post-stateroot不正确，那么他们可以向合约提交证明，证明该batch计算错误。合约验证该证明有效后，会对该batch和之后的所有batch进行回滚。
ZKrollups，采用有效性证明：每一个batch都包含一个称为ZK-SNARK的密码学证明，它可以证明post-stateroot是执行该batch的正确结果。无论计算量有多大，合约都可以迅速地在链上验证证明。
但两种「口味」的rollup之间有着复杂的权衡：
方案权衡
总的来说，我的观点是：
短期内，Optimisticrollups很可能在通用的EVM计算中胜出，而ZKrollups则可能在简单的支付、交易和其他特定应用场景中胜出，但最终从中长期来看，随着ZK-SNARK技术的改进，ZKrollups将在所有场景中胜出。
欺诈性证明剖析
Optimisticrollup的安全性主要取决于：如果有人将一个无效batch发布到rollup合约中，那么保持跟踪链上信息并发现欺诈的任何人都可以发布欺诈性证明，向合约证明该batch无效并回滚。
如图所示，声称某batch无效的欺诈性证明将会包含这些绿色数据：该batch本身和Merkletree的部分内容，从而证明该batch读取或修改特定账户。
而该树中的黄色节点可以从绿色的节点重建，所以不必提供。这些数据足以执行该batch并计算post-stateroot。如果计算出的post-stateroot和该batch中提供的post-stateroot不一样，那么说明该batch具有欺诈性。
如果一个batch存在错误，但之前所有的batches都是正确的，那么就可以创建一个欺诈性证明以表示该batch是错误的。
请注意对旧的batches声称无效的处理：如果存在多笔无效batches提交到rollup中，那么最好尽量证明最早无效的batch。当然，如果一个batch是正确的，那么永远不可能创建一个欺诈性证明以表示其无效。
Bitcoin.com将对FTX、BlockFi、Celsius、Voyager受害者进行补偿:金色财经报道，据 financefeeds 消息，Bitcoin.com 已经启动一项名为“The CEX Education Program”的计划，旨投入 Verse 总供应量的 5% 来筹集资金（Verse 是 Bitcoin.com 生态系统的一种奖励和实用 Token），旨在对 FTX、BlockFi、Celsius、Voyager 受害者进行补偿。Bitcoin.com 表示，这些平台和其他受到损失的中心化实体的受害者有资格通过在 getverse.com 上注册来获得补偿激励。[2022/11/22 7:54:50]
Rollups是如何压缩数据的？
一笔简单的Ethereum交易通常消耗约110字节。然而，在Rollup上发送ETH仅仅消耗约12字节。
字节消耗对比
为了达到这样的压缩效果，一方面是采用了更简单高级编码，而目前Ethereum的RLP在每个值的长度上都浪费了1字节。另一方面，还有一些巧妙的压缩技巧：
Nonce：该参数的目的是为了防止「重放」。如果账户的当前nonce是5，那么该账户的下一笔交易必须使用nonce5，但一旦交易被处理，那么该账户中的nonce就会被递增到6，这样采用nonce5的交易就不会被执行。在rollup中，我们可以完全省略nonce，因为我们只是从pre-state中恢复nonce。同时由于签名会采用最新的nonce进行检查，如果有人试图使用旧的nonce重放交易，那么签名将无法通过验证。
Gasprice：我们可以允许用户使用固定范围的gasprices进行支付，例如2的16次幂。或者，我们也可以在每笔batch中收取固定费用，甚至可以将gas支付完全移到rollup协议之外，让交易者通过特定渠道向batch创建者支付费用。
Gas：我们同样也可以将gas设置为2的多次幂。另外，我们也可以在batch层面设置gas限制。
To：我们可以使用「索引」来代替20字节的地址。
Value：我们可以用科学计数法存储value。在大多数情况下，转账仅需1～3有效位。
Signature：我们可以使用BLS聚合签名，它允许许多签名聚合成一个约32-96字节的签名。然后，这个签名可以一次性对整个消息集和发送者进行batch检查。表中的~0.5表示一个区块中可验证的聚合签名的数量是有限制的，因为它需要在一次欺诈证明中验证签名。
ZKrollups特有的一个重要压缩技巧：如果交易的一部分仅用于验证，并与计算状态更新无关，那么这部分可以省略。这在Optimisticrollup中是做不到的，因为该数据仍然需要包含在链上，以防将来欺诈性证明检查所需，而在ZKrollup中，证明数据正确性的SNARK已经提供了任何验证所需的数据。
一个重要的例子是隐私保护rollups：在Optimisticrollup中，每笔交易中～500字节用于隐私的ZK-SNARK需要上链，而在ZKrollup中，覆盖整个batch的ZK-SNARK已经足以表明「内部」的所有ZK-SNARKs是有效的。
这些压缩技巧是rollup扩容的关键，如果没有这些技巧，rollup或许只能在基础链的扩容上有大约10倍的提升，但有了这些压缩技巧，几乎所有应用的扩容系数都可以超过100倍。
谁可以提交batch？
关于哪些人可以在Optimisticrollup或ZKrollup中提交batch的问题存在许多流派。一般来说，大家都认为提交batch的用户必须先交纳一大笔押金，如果该用户提交欺诈性的batch，那么这笔押金的一部分将被烧掉，另一部分作为奖励给到提交欺诈性证明的用户。但除此之外，还存在许多可能性：
Totalanarchy：任何人都可以在任何时候提交batch。这是最简单的方法，但它有一些严重的缺点，比如存在这样的问题：多个参与者同时生成并试图提交batch，而其中仅有一个batch可以成功被收录。这将导致大量的浪费，比如没有意义的生成batch证明或者提交batch到链上。
中心化的Sequencer：通过Sequencer这样的角色提交batch。这是最「高效」的，但它依赖于一个中心化的角色。
Sequencer拍卖：通过拍卖来决定谁有权利成为第二天的Sequencer。这种方案的优点是可以筹集资金，而这些资金可以通过rollup的DAO来分配。
从PoS集合中随机选择：任何人都可以将ETH存入rollup合约中，每一个batch的sequencer都会从其中一个存款人中随机选择，被选中的概率与存款金额成正比。这种方案的主要缺点是大量资产被锁定，导致资金效率低。
DPoS投票：Sequencer通过拍卖选中，但如果他们表现不佳，那么代币持有者可以投票将其踢出，并举行新的拍卖来替代他们。
改进提交batch和stateroot的方式
目前一些正在开发的rollup方案采用的是“splitbatch”模式，即提交Layer2batch的动作和提交一个stateroot的动作分开执行，这会有一些关键优势：
你可以允许许多sequencers并行发布batch，以提高抗审查能力，而不用担心一些batch会因为其他batch已经被打包而无效。
如果一个stateroot存在欺诈，你不需要回滚所有batch，仅恢复该stateroot即可，并等待有人为该batch提供新的stateroot。这样可以更好地保障交易发送者的交易不会被回滚。
总的来说，这是一个相当复杂的技术组合，它们试图在涉及效率、简单性、抗审查和其他目标的复杂权衡中获得平衡。但现在谈哪种组合最有效还为时过早，而时间会证明一切。
Rollups将会带来多大的扩容？
目前Ethereum的gaslimit是1,250万，交易中每个字节的数据需要消耗16gas。那么如果一个区块仅包含一个batch，那么该batch会有=75万字节。如上图所示，每一位用户转账ETH仅消耗12字节，那么也就是说，该batch最多可以包含62,500笔交易。
在平均区块时间为13秒的情况下，这相当于达到约4,807TPS。
部分用例扩容提升规模
那么扩容上限可以这么计算：
(L1gascost)/(bytesinrollup*16)*12million/12.5million
现在值得注意的是这些数字还是过于乐观，原因有几个：
首先，最重要的是一个区块几乎永远不会仅包含一个batch，因为将可能会存在多个rollup方案同时运作。第二，存款和提款将持续存在。第三，短期内使用量会很低，所以固定成本成为主要消耗。但即使将这些因素考虑在内，预计扩容规模也会超过100倍。
现在，如果我们想要超过~1,000-4,000TPS，该怎么办呢？这就是ETH数据分片的意义所在，sharding建议每12秒开辟一个16MB的空间，这个空间可以被任何数据填满，系统保证对这些数据的可用性达成共识，而这些数据空间可以被rollup使用。
这个约1,398kB/s的数据量比当前Ethereum60kB/s提高了23倍，从长远来看，数据容量有望进一步增长。因此，使用Eth2分片数据的rollup可以处理高达约100kTPS，未来甚至会更多。
Rollup还有哪些尚未解决的挑战？
虽然现在Rollup的基本概念已经被大家所熟知，我们也很确认它们从根本上是可行的、安全的，以及已有多个rollup方案被部署到主网上，但rollup的设计仍然存在许多地方没有被很好地探索，将Ethereum生态系统的大部分内容完全迁移到rollup上以利用其扩容能力也存在不少挑战：
Userandecosystemonboarding-使用rollups的应用不多，用户对rollups也不熟悉，目前很少有钱包开始整合rollups，而商家和慈善机构还不接受它们用于支付。
Cross-rolluptransactions-有效地将资产和数据(例如oracle输出)从一个rollup转移到另一个rollup中，而不会产生经过Layer1的费用。
Auditingincentives-如何最大限度地提高至少一个诚实节点会真正全面验证一个Optimisticrollup的概率，以便出错时他们会发布欺诈性证明。对于小规模的rollup来说，这不是一个重要的问题，可以简单地借助利他主义，但对于更大规模的rollup来说，需要更严谨地推理这个问题。
Exploringthedesignspaceinbetweenplasmaandrollups-是否存在一些方法可以将状态更新的相关数据放在链上，而不是所有的数据。
Maximizingsecurityofpre-confirmations-许多rollup为了更快的用户体验，提供了一个「预确认」的概念，即sequencer立即给予一个承诺，交易将被包含在下一个batch中，如果他们食言，sequencer的押金将被销毁。但这种方案的经济安全性是有限的，因为可能同时向许多用户做出承诺，这种机制能否获得改进？
Improvingspeedofresponsetoabsentsequencers-如果一个rollup的sequencer突然下线，那么快速和经济地从这种情况中恢复过来将是非常有价值的：要么快速且经济地大规模退出到另一个rollup，要么更换sequencer。
EfficientZK-VM-生成通用EVM代码的ZK-SNARK证明可以被正确执行，并且有一个明确结果。
结论
Rollups是一种强大的Layer2扩容范式，预计将成为Ethereum短期和中期扩容的基石。我们已经看到了Ethereum社区对此感到大大的兴奋，因为这与之前的Layer2扩容方案不同，它们可以支持通用的EVM代码，允许现有的智能合约轻松迁移。
这是通过一个关键的妥协来实现的：放弃将数据和计算完全放在链下，而是将每笔交易的少量数据留在链上。
Rollups方案有很多种，在设计空间上会有很多选择：可以采用欺诈性证明的Optimisticrollup，或者采用有效性证明的ZKrollup。Sequencer可以是一个中心化的角色，也可以是一个去中心化的角色，或者是介于两者之间的其他选择。
总的来说，Rollup仍然是一项早期阶段的技术，一切仍在迅速发展，特别是Loopring，ZKSync和DeversiFi已经运作了几个月。
期待在未来的几年内，Rollup领域会出现更多令人兴奋的工作成果。
原文：AnIncompleteGuidetoRollups
作者：Vitalik
译者：阿树
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。