原文作者：jolestar（X：@jolestar）
看到几位朋友在聊 Based Rollup，大多是从安全角度来聊，我从 L1 与 L2 的关系，以及应用的构建角度，聊聊对 Based Booster Rollup 的看法。
Based Rollup 的思路其实很简单，就是用户直接把 L2 的交易提交到 L1，由 L1 排序打包，但 L1 不校验交易的有效性，只保证交易的顺序以及可用性，而 L2 是个纯粹的执行器，执行打包在 L1 上的 L2 交易。看到这里大家是不是觉得很眼熟？这不就是铭文 (Inscription) 模式么。是的，铭文的 Indexer 就可以理解成这里的 L2。这个我观点我在《铭文是个 bug 还是 feature》 一文里说过。
Booster Rollup 则从另外一个角度出发，如何在 L2 上通过合约直接读取到 L1 的状态？思路其实也不复杂，既然 Based Rollup 已经在执行 L1 上的 L2 交易了，那要不顺便把 L1 的交易也执行一下？这样 L1 和 L2 的状态就在一个大的状态树里，L2 的合约就可以直接读取 L1 的状态了。
于是也有项目把 Based Rollup 和 Booster Rollup 合在一起，叫做 Based Booster Rollup(BBR)，比如 taiko。
BBR 的背景
BBR 从提出，到现在受到市场关注，主要的大背景是当前 Ethereum 主流的 L2 方案带来的割裂问题，L1 与 L2 的割裂，以及 L2 之间的割裂。现在的 L2 方案，提供的功能，无论从开发者角度，还是用户角度，和一个 Alt-L1 并没有太大的差异，读取 L1 数据还依赖 Oracle，资产还是要桥，钱包也得切换网络。而这种割裂也带来了另外一个问题，L1 和 L2 的绑定并没有那么紧密，L2 随时可以增加一套共识机制变成一条 Alt-L1，「自立为王」，并且可以让开发者和用户基本无感。当前主要的绑定关系来自于 EF 对正统性的约束： L2 必须将 L1 作为 DA，但明显这个约束并不牢靠。
那如果把现在的 L2 方案都换成 Based Rollup 方案问题是不是就解决了呢？估计 Optimism 和 Arbitrum 要跳出来说了，换 Based Rollup 不很容易么？现在主要的 L2 方案都有 Force Inclusion 机制，L2 直接把 Sequencer 给去掉， 让用户都通过 Force Inclusion 向 L1 发交易不就实现了 Based Rollup？
但这样能解决割裂问题吗？不能。虽然 Arb 和 Op 都实时把交易提交到 L1，由 L1 打包排序了，但它们还是割裂的，因为各自只认自己的交易。到这里大家应该明白 Based Rollup 要想解决割裂问题的关键是要有可以在 L2 之间共享的交易或者数据，而这种数据格式要求：
它必须是和平台和实现无关的，在 L1 上定义的格式。不同的 L2 的账户，虚拟机有差异，各自的交易肯定没法直接共享。
它需要在 L2 之间达成共识，多个 L2 都支持。
所以它必须是协议先行，先设计公开的协议和数据格式，链上只保存协议必须的数据，执行和校验在链下，不同的 L2 各自实现支持方案。但要做到这两点其实挺难，首先 Ethereum 生态的开发者一般通过智能合约设计协议，并没有直接基于数据格式设计协议的习惯。这个方向主要的尝试还是上次铭文热的时候的 Ethscriptions。而第二点就更难了，需要实践和时间来验证。
从 BBR 到 BBSR，Stackable L2
说完了数据共享的问题，再说说用户体验的问题。明显如果所有交易都由用户直接发给 L1，体验就和使用 L1 差不多，无论是 Gas 还是确认时间。于是开始有人设计 Based Rollup 的预确认协议了，但如果预确认协议能真正工作，需要所有的交易都先通过预确认协议，那不就是 Sequencer 了么？这部白折腾聊一圈么？
之所以产生这种矛盾是因为大家混淆了几种交易类型：
用户直接提交到 L1 并由 L1 执行和验证的交易，也就是 L1 交易。
用户直接提交到 L1，但 L1 并不直接验证和执行，L2 之间共享协议的数据交易，可以叫 L1.5 交易。
用户直接提交给 L2 Sequencer，由 Sequencer 预确认并执行的交易，某个 L2 的专用交易。
而 Based Rollup 只和 1 ， 2 有关系， 3 是现在的 Sequencer Rollup 的工作方式，二者完全可以结合起来。
假如有这样一个 Rollup 方案：
Sequencer 自动同步所有的 L1（包括 L1.5） 交易，并按照 L1 的给定的顺序执行。
Sequencer 同时接收 L2 交易，和 L1 交易混在一起排序并执行。
通过 1 ， 它实现了 Based 和 Booster，通过 2 它实现了 L2 交易的快速确认，也不损失用户体验。如果按照前面的命名方案，这种应该叫做 BBSR(Based Booster Sequencer Rollup)，但有点长，不容易理解，所以我把它叫做 Stackable L2，堆叠式 L2，顾名思义就是在 L1 上堆叠了 L2，L2 包含了 L1 的所有交易和状态。这就是 @RoochNetwork 的解决方案。
如何保证 L2 的交易的 DA？ Rollup or Rollout?
如果采用上面的方案，L2 再次把自己的交易打包提交到 L1 就会有点奇怪，因为 L2 会再次把打包自己交易的 L1 交易也读取下来重新执行，有点像自己的输出同时也成了自己的输入。所以 Rooch 的方案是 Rollout 而不是 Rollup。因为长远来看 L1 的区块空间非常珍贵，多个 L2 的交易抢占 L1 的空间是一种「内卷」模式，L1 的空间应该留给 L1 和 L1.5 交易，L2 应用级别的交易应该寻求更低廉的区块空间，通过「外卷」拓展新的区块空间，这样也有利于整个行业生态的发展。
Bitcoin 生态的 BBSR/Stackable L2 实践
前面的描述都是从 Ethereum 角度来描述，而 Rooch 作为 Bitcoin 的首个 BBSR 或者 Stackable L2 实践，这里聊聊 Bitcoin 生态上的差异。
Bitcoin L2 上没有图灵完备的智能合约，Based Rollup 模式下反倒成为一种优势。因为 Based Rollup 本来就不需要 L1 执行和验证交易，只要保证 Permission Less 以及 DA。这同时也逼迫 Bitcoin 生态的项目从很早以前就开始设计基于数据结构的协议，无论是染色币，还是后来的 RGB，Taproot Assets，Ordinals Inscription，Atomicals，Runs 等，都是这个范畴下的尝试，可以包含在广义的 CSV（Client-side Validation）协议概念下，它们的交易都是典型的 L1.5 交易。如果 Ethereum 生态的项目想实践 Based L2，设计出多个 L2 之间共享的协议，大体上会和上面的协议差不多。
下面以 Rooch 为例，说明一下 Bitcoin 上的 BBSR 的工作模式：
用户会直接提交 L1 以及 L1.5 交易给 Bitcoin，因为协议是公开的，所以入口可以是任何应用。
Rooch 会同步所有的 L1 交易，处理其中的 UTXO，同时会发现是否携带了额外的协议信息，然后用对应的 Move 模块去处理。比如被识别为 Inscription 的交易会由 ord 模块处理，而 Babylon Staking 的交易会由 bbn 模块处理。
用户直接将 L2 交易提交给 Rooch 的 Sequencer 节点处理。上面三种交易的执行结果会生成一个完整的状态树，应用合约可以充分利用到 L1 以及 L1.5 交易生成的状态。
这种模式下的应用可以设计两种交易，一种是公共协议交易（Based 部分，在 L1 上），一种是应用交易，（由 Sequencer 排序），二者可以通过 Booster 模式互相配合，保证 Permission Less 的同时，也能保证用户体验。
正如前面提到的，公共协议的设计需要时间和实践来验证以及达成共识，而 Rooch 能提供的是这样一个方便的试验环境：如果想设计一个新的 Bitcoin 上的应用或者资产协议，只需要定义好协议格式，然后部署一个对应的 Move 合约模块去处理，就可以通过构造应用场景去试验。
当然，Bitcoin 生态在这个路线也上存在一些挑战：
Bitcoin 设计之初并没有给这种 DA 场景留下足够的扩展空间，所以通过什么形式将数据写到 Bitcoin 上，是前面各种协议尝试探索的方向之一，比如 OP_RETURN 嵌入数据，通过 Witness，甚至通过签名，当前还缺少标准化的解决方案。
Bitcoin 生态对链上嵌入数据的价值并没有达成广泛的共识，这也是从上次铭文热一来，我一直持续呼吁的方向，Bitcoin 生态应该重视 Bitcoin 作为一个全球的公共数据总线（Data Bus）的价值。
L1 作为全球公共数据总线的价值
从 DeFi summer 之后,整个 Crypto 领域一直在探索 DeFi 之外的新型应用。无论是 Bitcoin 的铭文热潮，还是最近的 Based Rollup 热议，都可以理解为对 L1 作为数据总线价值的重新发现。从分布式系统的角度来看，通过数据总线可以实现系统之间的解耦，而系统之间的解耦是实现 Permission less 的关键前提之一。例如，Crypto 生态中的去中心化交易所，就充分利用了区块链这个 Data Bus 实现了「去中心化」的对接，这在传统金融系统中是很难直接实现的。如果要支持更复杂的应用，只需要将简单的转账交易升级为应用协议交易，就可以实现应用层面的 Permission less，而这种方式对现有应用的侵入性最小。
本文主要从生态和应用角度探讨 BBR，关于 BBR 模式的安全，以及 BBR 模式下的 L1，L1.5 ，L2 状态的互操作性的问题，留在后面的文章中再详细探讨。后面附加上一些相关链接，有我的历史文章，也有推友从不同角度对 Based Rollup 的阐述。
相关链接：
1. Stackable L2 — 一种新的区块链扩容方案 https://rooch.network/zh-CN/blog/stackable-l2
2. Bitcoin 的 Layer 2 应该怎么做？https://x.com/jolestar/status/1717358817992995120 我从 L2 如何利用 Bitcoin L1 上的状态和数据设计的最初方案，评论中有朋友提到了 Booster 的方案，最后实践中采用了 Booster 的方案。
3. 铭文是个 Bug 还是 Feature？ https://x.com/jolestar/status/1732711942563959185从 L2 的构建方式角度阐述铭文的价值，包括 L1 和 L2 的激励相容难题。
4. 减法理论出发探讨 Based Rollup @kerne l1 983 https://web3 caff.com/zh/archives/108241
5. @jason_chen 998 关于 Based Rollup 的文章 https://x.com/jason_chen998/status/1799692331635048697
6. Based Rollup 赛道研究报告 https://research.web3 caff.com/zh/archives/22719
