Based Booster Rollup是什么?BBR背景、未来价值解读
Based Booster Rollup是什么?看到几位朋友在聊 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。
那么Based Booster Rollup是什么?Based Booster Rollup有什么价值值得大家关注?下面就和脚本之家小编一起详细了解下吧!
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 的阐述。
拓展知识
Based Rollup的历史背景与设计
图源:@drakefjustin
Rollup概念最早由以太坊创始人Vitalik Buterin提出,其最初设想是实现一个完全无约束的“Total Anarchy(无政府)”状态,以允许任何人无限制的交易扩展。结合上述当前排序器存在的问题,在2023年Ethereum Researcher :Justin Drake,提出了将排序器由以太坊L1自身管理的解决方案Based Rollups,其内容如下(出处见扩展链接1):
定义:
“当汇总的排序由基础层(L1)驱动时,我们称其为基于L1或由L1排序的汇总。具体地说,基于L1的汇总是指下一个L1提议者可以与L1搜索者和构建者合作,无需许可地将下一个Rollup区块包含在下一个L1区块中。”
优点:
活性(liveness): Based Rollup 享有与 L1 相同的活性保证。请注意,带有逃生舱(Escape Hatches)的非 Based Rollup 的活性会降低(逃生舱是 Rollup 中的一种安全机制,允许用户在 Rollup 系统出现问题时,将资产从 L2 安全地提取回 L1 主链。它类似于一个应急出口);
较弱的结算保证:在结算得到保证前,逃生舱的交易必须等待一段超时时间;
基于审查的 MEV:带有逃生舱的 Rollups 在超时期间,容易受到短期内排序器审查带来的不利 MEV 影响 ;
网络效应面临风险:由排序器活性故障触发的大规模退出(例如对去中心化 PoS 排序机制的 51% 攻击)将破坏 Rollup 的网络效应。请注意,与 L1 不同,Rollup 不能使用社会共识从排序器活性故障中优雅地恢复。在所有已知的非 Based Rollup 设计中,大规模退出是达摩克利斯之剑;
Gas 惩罚:通过逃生舱结算的交易通常会为其用户带来 Gas 惩罚(例如由于交易非批量打包的次优数据压缩)。
去中心化(decentralization) : Based Rollup 继承了 L1 的去中心化,自然复用了 L1 搜寻者 - 构建者 - 提议者的基础设施。L1 搜寻者和构建者受到激励,在他们的 L1 区块中包含 rollup 区块来提取 rollup 的 MEV。然后这又会激励 L1 区块提议者在 L1 上打包 rollup 区块。
简洁性(simplicity):Based Rollup 排序是最简单的,甚至比中心化排序要简单得多。Based Rollup 不需要验证排序器签名,不需要逃生舱,也不需要外部 PoS 共识。
历史注释:2021 年 1 月,Vitalik 将基于 L1 排序的方案称为「完全无政府状态」,这有同时提交多个 rollup 区块的风险,导致 Gas 和工作量的浪费。现在的区块提议者 — 构建者分离方案(Proposer-Builder Separation, PBS)可以严格控制的 L1 排序,每个 L1 区块最多有一个 rollup 区块,并且没有 Gas 浪费。当 rollup 的 n+1 区块(或对于 k >= 1,n+k)包含区块 n 的 SNARK 证明时,可以避免浪费 ZK-rollup 的证明工作。
成本:Based Rollup 的 Gas 开销为零 —— 甚至不需要验证来自去中心化或中心化排序器的签名。Based Rollup 的简洁性降低了开发成本,缩短了发布时间,并减小了代码漏洞的暴露面积。Based Rollup 的排序也是无需代币的,避免了基于代币的排序器的监管负担。
与 L1 经济一致(L1 economic alignment):源自 Based Rollup 的 MEV 自然流向了其基于的 L1。这种流向加强了 L1 经济安全,并且在 MEV 销毁的情况下,提高了 L1 原生代币的经济稀缺性。这种与 L1 在经济上的紧密结合可能有助于构建 Based Rollup 的合法性。重要的是,尽管牺牲了 MEV 收入,Based Rollup 保留了从 L2 拥塞费(例如 EIP-1559 形式的 L2 基础费用)中获得收入的选项。
主 权性(sovereignty):尽管将排序委托给了 L1,但 Based Rollup 保留了主 权性。Based Rollup 可以有一个治理代币,收取基本费用,并且可以在合适的时候使用这些基本费用的收益(例如 Optimism 为公共产品提供资金)。
缺点:
无 MEV 收入:Based Rollup 将 MEV 放手给了 L1,使其收入限制为基本费用。反直觉的是,这可能会增加 Based Rollup 的总收入。原因是 rollup 的格局似乎是赢家通吃,获胜的 rollup 可能会利用 Based Rollup 的安全性、去中心化、简洁性和一致性来实现主导地位并最终实现收入最大化。
受约束的排序:将排序委托给 L1 会降低排序灵活性。这使得某些排序服务变得更加困难,甚至可能是无法实现的:
预确认:快速预确认对于中心化排序不是问题,并且可以通过外部 PoS 共识来实现。使用 L1 排序进行快速预确认是一个开放性问题,有着许多有前景的研究方向,包括 EigenL、打包交易列表 (Inclusion Lists) 和构建者债券 (Builder Bonds)。
先到先得 (FCFS):Arbitrum 式的 FCFS 排序不确定能否在 Based Rollup 上实现。EigenL 可能给 L1 排序的 Based Rollup 提供 FCFS 的覆盖层。
命名:
「Based Rollup」 这个名称源于与基础链 (Base L1) 的亲近性。这与 Coinbase 最近宣布的 Base 链有所冲突,是一个奇妙的巧合。事实上,Coinbase 在他们的 Base 公告中分享了两个设计目标:
无代币 (tokenlessness):「我们没有发行新网络代币的计划。」
去中心化 (decentralisation):「 我们 [...] 计划随着时间的推移逐步去中心化区块链。」
Base 可以通过成为 Based Rollup 来实现无代币的去中心化。
图源:@jchaskin22
综上理论,Based Rollup可让任何人都可扩展到Rollup区块,把排序后的交易状态变化发布到L1即可从L2中提取MEV,让所有的排序和安全性均由以太坊L1提供。这样可以规避外部权益证明共识和特定的Rollup的Token需求,同时相比于其他Rollup为保住资产安全必不可少的”紧急逃生舱“功能相比,在Based Rollup的愿景中可以去除,其过程只需在保住以太坊安全运行的前提下,在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
以上就是脚本之家小编给大家分享的Based Booster Rollup是什么?以及BBR背景、未来价值解读了,希望大家喜欢!
本站提醒:投资有风险,入市须谨慎,本内容不作为投资理财建议。