BYOR——动手制作并理解区块链中的 Rollup 技术

最近正在研究 Rollup 的实现。看到一个开源项目 byor 号称 Build Your Own Rollup. 我发现这个项目还挺不错，使用了非常少的代码实现了 Rollup 的 MVP，对刚接触 Rollup 的开发者而言，理解一遍这个项目可以在头脑里构建起一个基本可用的框架。 w 

具体行级别的源码分析就不做了。我站在一个设计者的角度来介绍一下此项目的原理。

我读代码喜欢顺着数据流动的方向。因此让我们从 ApiServer 组件开始。架构图我已经画好了，让我们结合图来说明。

ApiServer 是一个 tRPC 接口。tRPC 读者就暂且当成是一种前端调后端的方式就行。这个接口主要提供的方法是 submit，参数是 input。input 是一个被签名的交易批次，由若干个被签名的交易构成。submit 的 handler 会将交易放到 MemPool 中。

MemPool 是一个交易缓冲池，BatchPoster 会定期地按照一定的优先级取出交易来执行。具体来说就是将交易数据作为 CallData 发送到 L1 的 Input 合约。

Input 合约的实现非常简单，它会触发一个 BatchAppended 事件。

与此同时，StateUpdater 也在定期执行 update，在 update 时会调用 BatchDownloader 提供的 getNewBatches 获取存放在 L1 的BatchAppended 事件关联的交易数据，然后以这些交易作为状态机的输入执行 apply。

StateUpdaer 的 apply 负责从原始的 calldata 通过 deserializeBatch 提取多个批次，并逐个进行状态转移（accountState = executeBatch(accountState, batch!, state!.poster)）和数据库写入（向 transactionRepository，对于每个批次，写入此批次的所有交易）

至此，一批 L2 的交易完成，并且在 L1 保留了所有可以证明这些交易有效性的数据。

---

不过，这种 Rollup 并不会在真实世界中使用，真实世界中我们可能需要考虑：

1. 如何在 L1 上尽可能少地存储信息，但依然能证明。（Merkle Tree 方法）

2. 如何对交易内容保密，但仍然能证明。（ZK 技术）