V神带你读懂以太坊扩展性解决方案Rollup

译者注：本文为译文，可能存在与原文表达意思偏差的地方。原文请参见Vitalik Blog。

背景：什么是 Layer-1 和 Layer-2 扩容？

在区块链生态系统中，一般存在两种扩容方式 。

• Layer-1： 使区块链本身拥有更高的交易能力 – 把区块变得更大（每个区块包含更多交易）。但这种方案的挑战是：更大的区块更难验证，而且可能会加剧中心化程度。为了避免这种风险，开发人员可以提高（区块链）客户端软件的效率，或者使用 分片 等技术，允许将验证交易的工作“分割”后分配给不同的节点； 这就是ETH2.0正在做的事情 。
• Layer-2： 改变用户与区块链的交互方式 。用户不是直接将 所有 交易活动放在区块链进行（链上），而是在“Layer-2”协议中执行大部分活动（链下）。（这种方式要求）链上存在一个智能合约，执行两个关键任务：处理资产的流入（Deposits）和流出（Withdrawals）合约，以及验证链下发生的一切交易活动都符合提前设定的规则。验证链下交易的方式有很多，但它们都有一个共同的特性：链下验证相较于链上验证要“便宜”很多。

状态通道（State Channels）vs Plasma vs Rollups

实现 Layer-2 扩容的方式主要有三种：State Channles，Plasma 以及 Rollups。它们属于三种不同的范式，分别具有不同的优势和劣势，目前来看，所有的 Layer-2 扩容方案基本都能够归到这三个类别（尽管存在一些在命名上的争议情况，例如：“ Validium ”）。

State Channels 的工作原理

另见： https://www.jeffcoleman.ca/state-channels和statechannels. org

试想一种情况：Alice 向 Bob 提供网络带宽服务，而 Bob 则需要以 $0.001/MB 的价格给 Alice 付钱。每一次数据服务若 Alice 和 Bob 都结算一次，则可以理解为 Layer-1 的方式，若两者采用 Layer-2 的方式结算，则如下：

首先，Bob 将1美元（或一些 ETH 或稳定币等资产）存入智能合约。为了向 Alice 支付第一笔款项，Bob 可以签署一张“票”（一条链下信息），上面写着“0.001美元”，并将其发送给 Alice。当出现第二笔交易时，Bob 可以在另一张写着“0.002美元”的票上签名，并把它发送给 Alice。以此类推，根据 Bob 实际使用的服务签署相应金额的“票”，并发送给 Alice。当 Alice 和 Bob 完成交易后，Alice 可以选择在金额最高的那张“票”上签上自己的名字，然后发送给链上智能合约。智能合约验证 Alice 和 Bob 的签名，向 Alice 支付 Bob 票上的金额，并将其余部分返还给 Bob。如果 Alice 不愿意关闭这个状态通道（这种支付方式）（由于想使坏或技术问题），Bob 可以发起一个提款期（例如7天）；如果 Alice 在这段时间内没有提供任何“票”，那么 Bob 可以收回他所有的钱。

这个技术方案的强大之处在于：它可以处理双向支付、智能合约（的逻辑）关系（如处理 Alice 和 Bob 在状态通道内部制定的规则）和延展（如果 Alice 和 Bob 搭建了一个通道，Bob 和 Charlie 也是如此，那么 Alice 就可以放心地与 Charlie 进行互动，Charlie也是一样）。 但这种方案的能力也有一定局限性：

• 没有参与通道的人无法参与这些交互；
• 缺乏明确清晰所有权逻辑的情况无法使用状态通道（如 Uniswap）；
• 此外，在处理复杂的情况时，状态通道一般需要参与者提前锁定大量资产。

Plasma 的工作原理

另见：原 Plasma白皮书 和 Plasma Cash 。

Plasma 也是一种链下的 Layer-2 扩容方案，任何人都可以创建自己独有的 Plasma 子链来支持自己的业务需求。子链是多种多样的，可以是去中心化交易所，也可以是中心化的社交网络或者私人的区块链。每条子链通过定期与主链（如以太坊）互动实现链下交易提交至链上。具体过程如下：

首先，在以太坊上（主链），用户将资产发送到管理 Plasma 子链的智能合约，以太坊将这些资产锁定，转移至 Plasma 子链上，完成存款。存入后，Plasma 子链会为该资产创建一个独有ID “X”（类似游戏币），不同的 Plasma 子链都有一个操作员（操作员代表这拥有这条 Plasma 子链的主体，可能是游戏公司，中心化的节点，多签节点，甚至是执行PoS或者DPoS等较为复杂共识的去中心化网络）。每隔（15s至1小时）一段时间，操作员都会生成一个交易集合“batch”，这个 batch 包含了 Plasma 在链下收集到的所有交易。然后他们会生成一个“默克尔树” Merkle Tree，在默克尔树中的每一片写有用户 ID “X” 的“叶子”，都对应一笔 ID 为 “X” 的资产交易，否则该叶的值为0。然后，操作员们会将默克尔根（Merkle root）发布到以太坊上。同时，他们也会给相应资产持有者发送每个 ID 为 “X” 的默克尔枝干（Merkle branch）。如果用户想要提取资产，也就是将 Plasma 子链的资产提至以太坊上（也被称为 Exit ），需要先向以太坊主链发布一个 Merkle branch（最近的一个branch）取款请求，然后子链智能合约会开始一个“争议期（Challenge period）”，在此期间，任何其他节点都可以使用其他 branch 来阻止该用户提取资产，只需证明

• 发送者在发送资产时不拥有资产，或；
• 他们在稍后的某个时间点将资产发送给其他人。

如果在该期间内（如7天内），没有人证明出该笔提款是不良或欺诈作恶行为，用户即可完成提款，资产成功回到主链。

Plasma的特点是，其比状态通道更为灵活： 用户可以将资产发送给系统外的参与者，并且对投资成本要求要低得多。 但也也不是没有缺点，状态通道在“正常操作”期间不需要任何数据上链，而 Plasma 要求每个链定期发布一个哈希值。此外， Plasma资产转移缺乏即时性：用户必须等待生成 batch 的间隔结束，或者区块产出后，才能完成资产转移 。

Plasma 和状态通道有一个共同的关键弱点：支撑其安全性的博弈论理论依赖于同一个逻辑，就是这 两个系统的所掌管的资产背后需要有它们名义上的“拥有者”，如果这些拥有者并不关心他们的资产，就可能导致很多“无用功”的结果 。这虽然在很多应用中无关紧要，但对于如 Uniswap 这样的去中心化交易平台，这样的反逻辑或者非理性的存在就可能破坏整套体系。甚至一些不需要所有者同意就可以改变资产情况的系统也不能很好的和 Plasma 兼容（像是一些基于账户的系统，在没有持有者同意的情况下就可以增加他们的余额）。这就意味着， 想要实现 Plasma 或者状态通道的部署，需要大量的“特定应用场景推理”，针对不同场景设计不同方案 ，因此根本不可能做出一个 Plasma 或者状态通道完全模拟以太坊环境的虚拟机。为解决这些问题，我们将目光投向……Rollups。

Rollups

另见： Ethereum on optimistic rollups 和 ZK rollups 。

Plasma 和状态通道是 完全的 Layer-2 扩容方案，因为它们将 数据和计算 都放在链下进行。然而，围绕数据可用性的 基本博弈论 问题意味着，让所有应用都安全地使用这两种方案是不可能的。Plasma 和状态通道非常依赖于对明确的资产和所有者的对应关系。这一点限制了其得到更广泛的应用。相比之下，Rollups则是一种“混合”的 Layer-2 方案。

Rollups 将计算（和状态存储）放在链下，但在链上保留了每笔交易的部分数据 。为了提高效率，Rollups 使用了一系列“花哨的压缩技巧”，尽可能 用计算代替数据 。这样做的结果是，区块链系统底层的可扩展性仍然受到带宽的限制，但已经有了明显的提升：以太坊 ERC20 资产转账成本约为45,000 gas，而利用 Rollups 进行的 ERC20 资产转账则仅仅占用了16字节的链上空间，消耗的 gas 低于300。

这里的关键是存在链上的数据（注意：将数据“存储到IPFS上” 不起作用 ，因为IPFS不能就任何给定的数据 是否可用达成共识 ； 数据必须上链 ）。将数据放在链上并对这一事实达成共识，允许任何人对数据进行操作，允许用户检测欺诈、发起提款等操作。对缺乏数据可用性问题的解决，意味着恶意或离线操作员能造成的损失减少（例如，他们不能造成一周的延迟），为有权打包交易发起确认的人提供了更多的设计空间以及更容易推演的设计逻辑。更重要的是，数据可用性问题缓解意味着，之前介绍的两种方案所极度依赖的资产到拥有者之间的明确映射关系变得不再需要。这 Rollups 让以太坊社区更加兴奋的关键原因： Rollups 完全通用，连 EVM （以太坊虚拟机）都可以在其中运行，允许现有的以太坊应用程序迁移到Rollups，并且几乎不需要编写任何新代码。

Rollup 具体如何工作？

Rollup 设计中，链上存在一个智能合约，作用是维护一个 状态根 ：Rollup 状态的默克尔根（Merkle Root，意包含账户余额、合同代码等信息）。

Rollup 链上合约与默克尔树（默克尔树并不存储数据，但是能够通过链上数据计算得出），来源：vitalik.ca

任何人都可以通过高度压缩的形式，将新打包一批交易的状态根（理解为摘要）和之前的状态根结合，形成一个batch，然后向链上发布。维护状态根的智能合约将通过检查旧的状态根和新的状态根是否符合计算逻辑；如果符合，智能合约则将旧的状态根替换为新的状态根。

新打包的交易集合与旧的状态根“融合”生产新的状态根，通过智能合约维护，来源：vitalik.ca

为了支持存款和提款，还需要为这个压缩状态增加与状态根之外的交互能力，即增加“输入”和“输出”。如果打包的新交易中有来自外部转入的资产，则这些资产也需要转入 Rollup 智能合约中；同理如果一个打包的新交易中有转移至外部的资产，那么在处理时，智能合约会启动这些提款。

就是这样！除了一个细节： 如何知道包含打包新交易后的状态根是正确的？ 如果没有办法验证，则用户可以提交任意交易，甚至可以将 Rollup（智能合约）里面的所有资产都转移到自己的地址中。这个问题十分关键，并且目前有两类非常不同的解决方案，这两类解决方案也指向两种不同类型的 Rollups 方式。

Optimistic Rollups 和 ZK Rollups

两者的区别在于：

• Optimistic Rollups，使用欺诈证明（Fraud Proofs） ：Rollup 合约追踪状态根的所有历史和每批打包交易的哈希摘要。如果任何人发现了某一批打包的交易中存在问题，并且导致了错误的状态根，那么用户就可以通过向链上提交证明的方式将其揭露出来。Rollup 合约将验证证明，如果确定则会回滚该批次的交易以及该批次之后的所有交易。（事后验证，如果出错则回滚修改）
• ZK Rollups ， 使用有效性证明（Validity Proofs） ：每个批处理的交易都包含一个称为ZK-SNARK的加密证明（如，使用 PLONK协议 生产），用于证明状态根是执行新打包交易的正确结果。无论计算量有多大，这种方式都可以非常快速地在链上验证。（事前验证，保证记录的信息都是对的）

在两种风格的 Rollups 之间有复杂的权衡：

属性	Optimistic Rollups	ZK Rollups
每批次交易消耗的固定 Gas 费用	~40,000 （一笔仅改变状态根的轻交易（指数据））	~500,000（ZK-SNARK的验证本身就比较消耗计算能力）
提款周期	~1 周（从 Rollup 合约中提款，需要给予用户对状态根中的交易进行欺诈验证的时间窗口）	非常快（只需要等待下一个批次的交易打包即可）
技术复杂度	低	高（ZK-SNARKs 是一系列相对较为新颖并且数学上较为复杂的技术）
可实现性	简单（Rollups 中通用目的的EVM已经部署主网）	难 （ZK-SNARK 的方式证明通用目的的EVM在执行上要比简单的计算难很多）
每笔链上交易的 Gas 消耗	高	低（如果一笔交易中的数据仅仅是用于验证，那么利用 ZK Rollups 则可以将数据放在链下；但使用 Optimistic Rollups 在欺诈验证中则需要将数据发送到链上）
链下计算成本	低（尽管许多全节点需要重新计算）	高（ZK-SNARK 证明在通用目的的计算中可能非常昂贵，相较于直接计算其成本可能是上千倍）

总的来说，我自己的观点认为，短期内 Optimistic Rollups 可能会在通用EVM计算中胜出，ZK Rollups 则更适合于简单的支付、交易和其他特定应用中（计算相对固定、简单）。但在中长期内，随着ZK-SNARK技术的改进，ZK Rollups 可能会全面胜出。

对欺诈证明的剖析

Optimistic 的安全性依赖于这样一种想法：即如果有人将包含无效交易的打包交易发布到 Rollup 中，任何保持链上数据最新状态的用户，都可以检测到这样的欺诈并且可以提交欺诈证明 — 向 Rollup 合约证明该批次的交易无效，应该撤销。

发现欺诈行为，提供绿色块中的正确数据重新计算状态根，来源：vitalik.ca

如上图所示，证明一个批次中的交易存在无效交易的证明应该包含图中绿色的数据：该笔交易（或多笔交易本身以及明确所有 Merkle Tree 中相关交易中需要涉及到的数据。（交易本身可以通过链上存储的哈希摘要确定，Merkle Tree 则需要两两验证）。图中黄色部分可以通过绿色的数据计算得到，因而不需要提供。通过提供图中绿色的数据，便可以计算得到一个新的状态根。如果计算出来的状态根和原来提供的状态根不一致，则说明该批次中打包的交易存在欺诈行为。

通过这样的方式可以保证，如果某一个批次的交易打包存在问题，并且所有在此之前的打包交易都是正确的，那么构建并且提供一个欺诈证明来验证该批交易存在问题是可行的。但是需要注意的是，如果出现超过一个批次的交易打包出现问题，那么最好的解决方案是找到最早的一批交易。此外，这也同样意味着：如果每一个批次交易的打包都正确，那么构建这样一个欺诈的证明也当然是不可能的。

Rollups 中交易数据是如何得到压缩的？

一个简单的以太坊交易（发送 ETH）需要约110字节。然而，Rollup 中的 ETH 传输只需要大约12个字节：

Parameters	Ethereum	Rollup
Nonce	~3	0
Gas Price	~8	0-0.5
Gas	3	0-0.5
To	21	4
Value	~9	~3
Signiture	~68 (2 + 33 + 33)	~0.5
From	0 (Received from signiture)	4
Total	~112	~12

部分功劳归于更高级的代码编译：对于每个值的长度上，以太坊的递归长度前缀编码（Recursive Length Prefix, RLP)仅会使用1字节/值。但同样也有些更为精巧的压缩技巧：

• Nonce：设置此参数的目的是防止交易重复进行。如果帐户的当前 Nonce 为5，则该帐户的下一个交易必须也是 Nonce 为5，并且一旦该交易被结算，帐户中的 Nonce 将增加到6，因此不能再次进行该交易。在Rollup中，我们可以忽略 Nonce，因为他只是我们从预状态（Pre-State）中得来的；如果有人想用更早的 Nonce 重新进行某交易，签名将无法通过验证，因为签名中会根据更新更高 的Nonce验证交易。
• Gas Price：用户可以支付固定范围的 Gas 费用 。 或者，我们可以在每个批次（batch）中收取一个固定的 Gas 费用，甚至可以将 Gas费的支付完全移出 Rollup 协议，让交易者使用通道向 batch 创建者支付相应费用。
• Gas ： 同样可以将总 Gas 设定为2的多次幂形式。或者，我们也将 Gas 限制在 batch 的水平。
• To：可以用代号（index）来替换占据20字节的地址（例如，如果一个地址是添加 到 默克尔 树中的第4527个地址，我们只需使用 index 4527 来表示即可。然后只需向状态添加一个“子树（subtree）”来存储index和地址本身的映射关系信息）。
• Value：我们可以用科学记数法储存值。在大多数情况下，一笔交易只需要1-3个有效数字即可。
• Signiture ： 我们可以使用 BLS聚合签名 ，将许多签名聚合成一个约为32-96字节（取决于协议）的签名集合。该集合可以一次性地检查整批消息和发件人组。表中的 “~0.5” 说明一个签名集合中可以包含地签名个数是有限制的，因为这个签名集合需要能在一个欺诈证明中进行验证。

ZK Rollups特有的一个重要压缩技巧是，如果交易的一部分信息仅用于验证，并且与计算状态的更新无关，那么该部分信息可以移至链下。这种技巧并不能在 Optimistic Rollup 中完成，因为该数据仍然需要保留在链上，以防以后需要在欺诈证明中检查的不时之需。而在ZK Rollup 中，SNARK对 batch 的正确性证实，已经证明了验证所需的所有数据都已经提供齐全。 Rollups 中的隐私保护功能（Privacy-Proserving Rollup）是一个很显著的例子：在 Optimistic Rollup 中，每笔交易中用于隐私的ZK-SNARK加密证明需要链上，这需要占据大约500字节；而在 ZK Rollup 中，覆盖整个 batch 的 ZK-SNARK 已经毫无疑问地表明“内部” ZK-SNARK 是有效的，不需要浪费额外的500字节在链上。

这些压缩技巧是 Rollups 可拓展性的关键。没有它们，Rollups 可能只会比基础链的可拓展性提高大约10倍，而使用这些压缩技巧后，几乎所有应用的可拓展性能都可以比之前实现超过100倍的提升。

谁可以打包交易并提交？

业界对于Optimistic Rollups 和 ZK Rollups 中交易的打包权有多种看法。一般来说，任何想要打包交易并且提交的用户，必须要锁定大量资产。如果用户提交了包含欺诈/无效交易的交易批次，那么该用户变会受到惩罚：提前锁定的部分资产将被没收，并且作为奖励转移至发现问题并提出的用户。但是除此之外，我们也可以考虑其他可能性：

• 完全“ 无政府状态” ：任何人都可以在任何时候打包并提交交易。这是最简单的方式（比特币和以太坊的PoW挖矿就是如此）。缺点是多个参与者同时尝试打包交易但最终只有一个人能够成功，这意味着其他用户的打包交易和提交的过程消耗的 Gas 都被浪费。
• 中心化节点进行：中心化节点处理交易，打包并提交。这是“最高效”的方式，但是严重依赖于一个中心化的角色。（提款交易例外：一般来说用户若想要提款，则一般会发起申请，若中心化节点没有在下一个批次处理该提款交易，则用户可以自己打包自己的交易并提交）。
• 拍卖：通过定期举行拍卖 的形式来确定谁有权成为第二周期（可以是第二天，第二周等）的处理节点。这种技术的优点是它可以筹集资金，这些资金可以通过例如由汇总控制的DAO来分配（见： MEV拍卖）
• PoS随机选择 ：任何人都可以将ETH（或者是其他资产）存入 Rollup 合约，然后通过随机抽签的形式确定每一个交易批次的打包权利（获得权利的比例与抵押的资产比例成正比）。
• DPoS投票 ：通过拍卖确定拥有权利的人，其他人后补。如果有权利的节点出现问题则选择一个新的节点替代（EOS的共识机制）。

打包交易和状态根处理分离

目前正在开发的一些 Rollup 项目使用分离处理的方式，即将交易分批次打包，和打包任意批次交易获得的状态根提交到主链的过程分离。这么做的优势在于：

• 允许多个交易打包节点同时进行，用于提高去中心化程度和抗审查能力（Censorship Resistance）。并且减少部分打包的交易集合由于其他交易集合受到记录后无效的情况；
• 如果一个状态根（一批交易）中出现欺诈/无效的交易，此时不需要回滚一整个批次，只需要修改链上的状态根，然后等待用户提供相同交易批次的新的状态根即可。这意味着对用户的交易受到确认来说也是更好的用户体验。

总之，不同的方案在效率、简单、抗审查、中心化程度以及其他方面都有着权衡。现在来判断什么样的方案在未来能够成功还是太早。就让时间来证明一切吧！

Rollups 能够带来多少交易处理性能的提升？

在现有的以太坊链上，Gass的限制是1,250万，交易中的每字节数据花费16 Gas。这意味着，如果一个块只包含一个批次（我们这里使用ZK Rollup的方案，验证证明需要消耗50万 Gas），则该批次可以具有（1,200万/16）=750,000字节的数据。如上面的表所示，Rollup 来发送 ETH 交易只需要12个字节，这意味着批处理最多可以包含62,500（ 750,000/12）笔交易。在区块间隔时间为 13秒 的情况下，这相当于约4,807的TPS（相比之下，以太坊本身直接交易的ETH的效率为：1,250万/21,000/13~=45 TPS）。

下面是其他一些示例用例的图表：

应用情况	Rollup 中字节大小	Layer-1 消耗 Gas	最高的效率提升
ETH 转账	12	21,000	105x
ERC20 转账	16（4个字节用户明确 Token 是哪个）	~50,000	187x
Uniswap 交易	~14（发送方4个字节，接受方4个字节，数量3个字节，最高价1个字节，misc1个字节	~100,000	428x
隐私保护提款 Privacy-preserving withdrawal (Optimistic rollup)	296 (4 bytes index of root + 32 bytes nullifier + 4 bytes recipient + 256 bytes ZK-SNARK proof)	~380,000	77x
隐私保护提款 Privacy-preserving withdrawal (ZK rollup)	40 (4 bytes index of root + 32 bytes nullifier + 4 bytes recipient)	~380,000	570x

最大性能提升的计算方式为：（Layer-1 Gas 消耗）/（Rollup 中的字节大小16）* 1,200万/1,250万。

需要注意的是，上面的计算得出的结果有些过分乐观。主要原因包含：

• 最重要的原因，一个区块一般情况下不太可能只包含一个批次的交易集合。即使是那样（一个区块中也可能包含多个 Rollups（一个 Rollup 里就包含至少一个批次的交易集合）；
• （流入 Rollup 合约的）存款和（流出 Rollup 合约的）提款持续存在；
• 短期内的应用不够广泛，因而固定的 Gas 成本还是占据大头。

但是即使是将这些因素都考虑进去，Rollups 也至少能够提升100倍的性能。

如果我们想要超越 1,000-4,000 的 TPS（取决于特定的应用情况）该怎么办？这时候就需要 ETH2.0 的分片 表现了。分片的方案每隔12秒开放一个能够存储至多 16M 任何数据的空间，并且系统能够对这些数据的可用性达成共识。这些数据空间都将可以被 Rollups 方案使用，这意味着每秒能够处理大约1398kB的数据，这对于现在以太坊每秒处理大约60kB的数据来说是约23倍的提升。此外，长期来看，数据容量有望进一步得到增长。因而 Rollups 方案使用ETH2分片数据最多能够实现大约十万的TPS，不排除未来更大的可能性。

在 Rollups 中有哪些尚未完全解决的挑战？

在 Rollup 的基本概念已经理解的差不多之后，我们很确信的是， Rollup 从根本上是可行的并且是安全的。同时，已经有多条 Rollups 被部署到主网上了。但目前， Rollup 设计的很多方面还没有被完全的挖掘。在以太坊生态系统大面积引入 Rollup ，以增强可拓展性的诸多方面，我们仍面临着诸多挑战，其中一些关键的挑战包括：

• 用户和生态系统 的使用度 – 没有多少应用使用 Rollup，Rollup 对用户来说是陌生的，很少有钱包已经开始融合 Rollup 。商家和慈善机构还不支持使用 Rollup 付款。
• Cross-Rollup 交易 – 有效地将资产和数据（例如 oracle）从一个 Rollup 移动到另一个 Rollup ，而不会产生由于跨越基础层（Basic Layer）的成本。
• 审计 激励 – 如何最大限度地提高至少一个诚实节点完全验证 Optimistic Rollup 的机率，以便在出现问题时发布欺诈证明？对于小规模的 Rollup（至多几百 TPS ），这不是最重要的问题，用户可以简单地依赖利他主义实现，但对于大规模的 Rollup ，更为明晰的机制设计就变得至关重要。
• 探索 Plasma 和 Rollup 间的设计空间 – 是否有技术能将部分而不是全部，与状态更新相关的数据放在链上？
• 最大限度地提高 确认前 的安全性 – 许多 Rollup 为更快的UX提供了“预确认”的概念，在这种情况下，序列发生器（Sequencer）立即承诺交易将打包于下一批次中，如果序列发生器违背诺言，其存款将被销毁。但是这个方案的安全性是受限的，因为有可能出现一个 Sequencer 同时向许多参与者做出许多承诺的情况。这个机制是否可以改善呢？
• 提高对 掉线 的 Sequencer 的响应速度 – 如果 Rollup 的 Sequencer 突然掉线，那么从这种情况中快速、低成本地恢复上线将会变得十分有价值。要么迅速且低成本地大规模转移到其他 Rollup ，要么更换新的 Sequencer 。
• 高效的ZK 虚拟机 – 生成ZK-SNARK证明通用EVM代码（或现有智能合约可以编译到的某些不同虚拟机）已经可以正确地执行并具有一定成果。

结论

Rollups 是一个强大的新型的 Layer-2 扩容方案，并有望在短期和中期（也可能是长期）成为以太坊扩容的基石。另社区尤为兴奋的一点原因在于，Rollups 与之前出现的 Layer-2 扩容方案不同， Rollups 能够支持通用的 EVM 代码，允许现有 DApp 轻松迁移 。而这一点的实现通过一个关键的妥协来实现：不把所有的数据计算都放到链下进行，而是把每笔交易的一小部分关键数据保留在链上。 关于 Rollups 的方案有很多，而且这些方案也都可以选择、权衡不同的特点。Optimistic Rollup 使用欺诈证明，ZK Rollup 使用有效性证明（也叫 ZK-SNARKs）。将打包的（多个）交易批次放入 Rollup 内随后发布到链上的阶段选择也可以多样化：中心化节点、完全去中心化的节点，或者采用折中的方案。总的来说 Rollups 还属于早期但发展迅速的技术，很多采用这个方案的项目（Loopring，ZKSync以及DeversiFi）已经运行几个月。（我）很期待未来几年能够在 Rollup 领域看到更多令人兴奋的突破。

文章翻译自： https://vitalik.ca/general/2021/01/05/rollup.html