一文探讨Rollup扩容方案的演进思路和设计缘由

原文作者：ORFEO

原文来源：The SeeDAO

L2 项目再次成为万众焦点。

作为 L2 中 Rollup 扩容路线的代表，前脚 Arbitrum 空投完，后脚 zkSync Era 就上线了。层出不穷的新设计、路线图背后，Rollup 到底有一条什么主线，演进的思路是怎样的，今天就来理一理。

本文要点：

写给三年级看的 L1 的扩容思路

从零设计一个 Rollup 方案

如何用零知识证明让 Rollup 再进化

从一个类比说起

对比特币、以太坊而言，自诞生起，来自普通用户的最大诟病有二：

慢：本来就车道窄，车稍微一多就堵得水泄不通。

贵：平峰过路费就不便宜，要遇到高峰期想快点过，更是要使用「钞能力」，加钱让矿工开直升机来捞你。

这俩诟病之处，分别源于区块链设计上的 2 个因素：

区块容量：类比车道，区块容量越大，能容纳的车就越多，就越不容易堵。

激励机制：再大的车道，都有堵的可能，这种时候让谁先过呢，看谁有急事，但不能光听人嘴上说，得看掏钱意愿，比如叫救护车一趟就要好几百。

要是区块链真可以类似车道，那么治本之策自然是奔着拓宽车道去，同时配合价格手段来在出门时间上进行疏导，不急的就先别出门了。

然而，拓宽车道，提升区块容量，虽然是个诱人的通行效率解决方案，但在区块链设计上，却是舍本逐末了。因为区块容量越大，对矿工的硬件要求就越高，能达到要求的矿工就越少；按这种思路，要想做到像 Visa 那样每秒处理成千上万条交易，最终只会做出另一个中心化的 Visa，与区块链去信任的核心目的南辕北辙。

那还有其他解法吗？有的，除了在时间上疏导，我们在空间上也可以优化，包括但不限于：

开辟不同车道，大货车走一条，小轿车走一条，公交车走一条，互不干扰 — — 基于这个思路，我们可以来些各有所长的主链、侧链或 Plasma。

优化路线设计，适当分流，别进城干点啥都要走这条主干道，都要过这里的检查站了 — — 基于这个思路，我们可以分片（Sharding）。

干嘛一定要出门呢？远程开会，达成一致了，线下签协议再出门也不迟 — — 基于这个思路，我们可以有状态通道（State Channel）。

大家出门不一定都得自己开车，也可以拼车，或乘坐公共交通工具 — — 基于这个思路，我们就有了本文的主角，Rollup。

作为区块链上的公交车，Rollup 的关键其实就是省空间和省汽油（Gas，pun intended）：

省空间，从而不容易堵，而且每人分摊的过路费相比自己开车，也要少很多；

省汽油，从而票价亲民，大家都坐得起。

这样一来，「慢」和「贵」这两个槽点就被 Rollup 解决了。

下面我们回到区块链上，看看 Rollup 的具体方案。

从零设计一个 Rollup 方案

与其偷看看标准答案（何况没有），不如来点悬念，想象自己接到为以太坊设计 Rollup 的任务，会怎么做。

我们不妨从减少计算成本（省汽油）和减少存储成本（省空间） 2 个角度出发，先提一个比较激进的方案，叫 Rollup 1.0 。

Rollup 1.0 

Rollup 1.0 包含 3 个要点：

有一个服务商（Operator），专门收集大家的「拼车」交易（Transaction），拼满了，或者没满但约定时间到了就「派单」，兼顾价格和时效；

大家提交的交易中涉及的所有计算都由这个服务商在链下进行，因为链下计算比链上快，而且计算往往是链上成本中的大头，这样可以省不少钱；

计算完后，得到更新后的状态（比如大家账户里的最新余额），上链存储，这样一来存储成本低了很多。

简单来说，就是定时定量收集大家的交易请求，链下计算后，只把计算结果固化到链上。

这个方案完美地解决了「慢」和「贵」这 2 大痛点，但又似乎衍生了新的问题：

动机问题（Incentive）：谁来提供「拼车」服务，有什么好处。

审查问题（Censorship）：服务商故意不处理我的单（或者挂了、不干了），我该怎么办；

欺诈问题（Fraud）：如果服务商使诈，篡改计算结果，导致我给别人转账，钱被他私吞了该怎么办。

针对这 3 个新问题，我们可以迭代一版方案。

Rollup 2.0 

动机问题最好解决，能用钱解决的问题都不是问题。服务商可以平摊「拼车」成本，再额外收一点「小费」，即便如此和「拼车」人之间仍然是双赢。