【英文长推】从误解到实现：Based Rollups 扩展性逻辑解读

Chainfeeds 导读：

Based Sequencing 主要影响的是可扩展性的两个维度：延迟和数据吞吐量。基于链排序的区块构建流程可以通过性能优化手段，将区块构建与交易排序的重负载任务进行分散处理。而如基于预确认（Based Preconfs）、排序器选举机制以及其他实现细节，也会直接影响 Based Rollup 的扩展能力及用户体验。

文章来源：

mteam

观点：

mteam：当前关于 Based Rollups 的许多批评，例如它们无法扩展或它们受限于 L1 的吞吐，往往源于对其架构和原理的误解。简单来说，Based Rollup 是指复用其结算层（例如以太坊）的排序与共识机制的 Rollup。它不是一个完全独立的执行环境，而是主动导入底层区块链的区块生产体系。根据 Spire 的定义，Based Sequencing 包含两个关键属性：其一是协调机制 —— 底层链的出块者在排序权利上占据优先地位（这可以是完全优先，或通过预留拍卖结构实现）；其二是共享结算 —— 基于原子区块提案，Rollup 与其结算层共同经历重组与达成最终性。因此，Based Rollup 的交易顺序由结算层中嵌套的交易决定。这种机制常被误解为意味着必须由 L1 的同一个实体处理所有事务，或必须采用 Gateway 模型的基于预确认的路径，实则不然。事实上，Based Rollup 是否高效，关键取决于其他系统设计，比如排序过程如何实现、预确认系统是否存在、执行与数据可用性层的耦合方式等。 文章进一步通过两个基于以太坊的 Based Rollup 架构，分析它们在可扩展性上的实际表现。第一种是完全无权限的 Based ZK Rollup，其中任何人都可提交区块，L1 区块构建者在构建 L1 区块时顺带打包 L2 区块，其状态通过零知识证明在以太坊验证。这种架构下，延迟完全受限于 L1 的出块速度，但执行吞吐取决于自身的证明与验证架构，而非 L1。本质上，扩展瓶颈来自 L1 区块构建者的带宽与算力。第二种是具备预设排序者选举的 Based Rollup，排序权限定于某一 L1 出块 slot 的特定节点，该节点可能将排序权委托给支持预确认的网关系统。在此架构中，通过信任执行环境（TEE）等机制，Rollup 延迟可能低于 L1，执行性能媲美中心化排序器。两种模型都表明：延迟和吞吐并非单一取决于是否 Based，而是源于排序架构、DA 层设计、状态依赖管理等多个交互系统的协同效果。许多流行误解，如 Based Rollup 无法高频交易或必须与 L1 出块时间绑定，在这些架构里并不成立。 从宏观视角看，Based Rollup 的可扩展性不仅取决于自身设计，还深受 L1 发展路径影响。以太坊若推进更快的 Slot 时间、更强的预确认机制（如 TOOL 提案），将极大提升 Based Rollups 在延迟与吞吐维度的表现空间。尤其值得强调的是，具备同步可组合性的 Based Rollup，能更高效地扩展以太坊的区块空间，相较其他 Rollup 模型具备更优的网络效应外溢能力。然而，该模型也可能对 L1 造成反向压力，例如在区块构建带宽、资源调度或激励机制上与传统路径冲突。文章指出，未来基于 L1 的多个 Based Rollup 并行运行时，主要瓶颈将出现在区块构建与排序资源的竞争阶段。Spire 提出的 Sidecar 模型，即 L1 排序器旁运行的轻量排序系统，是一种尝试分离资源、降低干扰的解法。综上，Based Rollups 不仅不是扩展性的障碍，反而可能成为提升区块链系统整体可组合性与同步性的关键工具，其最终性能仍需在更大范围的系统设计权衡中考察。