大银行正在竞购陷入困境
Rollup Layer2的模块化演进之路
2023.05.01
本文尝试从演化角度讨论 Rollup Layer 2 的发展以及演进，主要解答以下几个问题：
Rollup 是如何工作的
Rollup 的模块化演进
模块化带来的可能性
模块化应用的技术趋势
总结
Rollup 是如何工作的
区块链的“三难问题”一直是困扰业界的一个难题，如果我们认为 Layer 1 区块链应该首先保证“去中心化”和“安全”，那将“扩展性”方案从 Layer 1 迁移出来就是自然的选择了，于是有了 Layer 2 。那新的难题就是如何通过 Layer 1 来保证 Layer 2 的安全。
最初有一种想法是定时将 Layer 2 应用的状态树根写到 Layer 1 ，这样可以通过状态证明来校验应用的状态，类似于交易所储备金证明。但这种方式第三方无法通过公开的方式验证两次状态转换是正确的。
为了更深入的探讨这个问题，我们抽象一下，任何程序的状态都可以通过一个状态转换公式表达：
σt+ 1 ≡ Υ(σt, T)
这个公式来自于 Ethereum 黄皮书，但它可以代表任意的程序。在这里 Υ 代表程序，σ 代表状态。状态 σt+ 1 由程序 Y 通过状态 σt 和交易 T 计算得出。交易 T 代表程序的输入。任意时候，如果 σt 是确定的，程序 Y 是确定的，T 是确定的，那 σt+ 1 就是确定的。
所以要提供公开的可验证性，关键是 Y 要公开可用，历史上所有的 T 要公开可用并且顺序确定，中间的状态可通过 Y 和 T 重新计算得到。而程序的公开可用我们可以通过开源来实现，关键是 T 公开可用如何保证，这就引入了数据可用性（DA）的概念。
数据可用性需要有个公开的不可篡改的账本来记录应用的交易。自然想到，区块链账本就是这样一个系统，于是将 Layer 2 的交易写回 Layer 1 ，保证数据可用性，这也就是 Rollup 名称的来源。
所以 Layer 2 系统中需要有个角色收集用户的交易，进行排序并写入到 DA，这个角色叫 定序器（Sequencer）。这里的交易序列叫 Canonical Transaction Chain。
保证了数据的可用性，每个人都可以通过自己运行程序执行交易来得到最终的状态。但这里并没有达成共识，因为每个人不确定自己得到的结果是否和其他人的结果一致，毕竟软件或者硬件故障也可能导致数据不一致。所以需要另外一个角色将交易执行后的状态树根定时公布出来，供大家校验自己的状态，这个角色叫 提案者（Proposer）。这里每次提交的状态也构成了一个状态序列，和交易序列对应，叫 State Commitment Chain。
到这里，我们达到了应用的可验证性。如果某个人运行的结果和 Proposer 提交的状态不一致，并确定不是自己的问题，那就是 Proposer 作弊或者出错了，那怎么让别人也知道呢？这就需要引入**仲裁者（Arbitrator）**的角色。仲裁者需要是一个可信第三方，链上合约正好可以承担这个角色。
仲裁有两个方案：
Proposer 每次提交状态的时候，同时提供与前一次状态之间的状态转换有效证明（Validity Proof），链上的仲裁合约进行校验。有效证明一般通过 Zero knowledge 技术生成，这种叫 ZK Rollup。
先假定 Proposer 的结果是对的，但如果发现不一致，则提交欺诈证明（Fraud Proof），由仲裁合约进行判定。如果仲裁合约判定 Proposer 作弊，则对 Proposer 进行惩罚，并将 State Commitment Chain 回滚到欺诈交易之前的状态。当然，为了保证安全，一般会设置一个比较长的挑战周期来达到链上交易结算的最终确定性。这种叫 Optimistic Rollup。
我们还需要实现 Layer 1 和 Layer 2 之间的资产互通。于是构建一个 Layer 1 到 Layer 2 之间的桥，通过状态证明来进行资产结算。而 Layer 2 在 Layer 1 的状态根由 Layer 1 的仲裁合约保证，我们可以认为这个桥的安全也受仲裁合约保证。
至此，我们得到了一个由 Layer 1 保证安全，并且可以和 Layer 1 进行资产互通的 Rollup Layer 2 方案。
当然，Rollup 方案也做了一些妥协：
