当下的 Rollup 有一些方法可以互操作，但将多个异构系统连接起来是一个相当大的挑战，作者的思路是提供一个设计构想为所有 Rollup 提供统一的体验。本文作者是以太坊社区成员 Andreas Tzionis，MarsBit 全文编译如下：
长期以来，我一直有这样一个想法，即通过多 Rollup（multi-Rollup）设计来解决当前 Rollup 所面临的一些问题。在大约一年半的时间里，我认为有人会构建它，但从未真正深入研究或考虑过这样一个系统的细节。
现在已经过去一段时间了，似乎没有一个设计可以解决我在本篇文章中描述的问题，所以，我将尽可能地填充这个系统的细节，希望有人能从中获得灵感，甚至从现有的 Rollup 中借用一些想法。
介绍
今天，Rollup 面临的问题之一是用户体验。在许多设计中，Rollup 是具有不同特征的独立生态系统。有一些方法可以互操作，但将多个异构系统连接起来是一个相当大的挑战。此外，吸引用户注册所有这些 Rollup 是困难的。他们必须分别了解每个 Rollup，评估相关的智能合约，将他们的钱包连接到新的 RPC 端点，将资产桥接到链上等。
如果有一种 Rollup 设计可以为所有 Rollup 提供统一的体验，那会怎么样？它会是什么样子？
我一直在问自己这个问题，并得到了以下五个观点：
- 它应该提供一个统一的 RPC ，以查询和调用不同跨 Rollup 的智能合约。智能合约应该有一个唯一的地址，不依赖于它们所属的 Rollup。
- 它应该允许根据需求扩大和缩小规模。更多的交易应该意味着更多的 Rollup 来处理它们，并且应该平衡 Rollup 之间的不均匀负载。
- 它应该激励不同 Rollup 中的排序器保持在线。系统应该鼓励其他排序器取代离线排序器。
- 它应该支持即时的跨链转账。交易应该结算得足够快，这样跨链操作才有意义。
- 它应该在多个合并中保持轻客户端和区块浏览器的功能。区块浏览器应该提供一个统一的区块链视图，轻量级客户端应该允许低成本地验证。
考虑到所有这些，我提出了一个设计，包括一个 Rollup hub 和一个可变数量的子 Rollup。Rollup hub 既是所有子 Rollup 的注册中心又是负载均衡器，但不做任何智能合约处理。智能合约在子 Rollup 中处理。
在接下来的部分中，我将通过一个草稿设计来解释我上面提到的 5 个考虑因素。
设计概述
每个排序器系统有两个主要组件：Rollup hub 和子 Rollup。Rollup hub 是一个 Rollup，包含所有子 Rollup 的所有智能合约注册表，并决定哪个 Rollup 负责哪个智能合约。此外，Rollup hub 包含另一个子 Rollup 的所有排序器的注册表。子链负责执行 Rollup hub 在智能合约注册表中分配给它们的智能合约的交易。排序器注册表包含每个排序器 RPC 端点和 DA 地址。
排序器注册表（Sequencers registry）
排序器注册表充当全局智能合约地址到智能合约地址的映射。这用于将 RPC 调用路由到与查询或更新的智能合约相对应的特定排序器 RPC。
智能合约注册表
智能合约注册表充当了从全局智能合约地址到智能合约地址的映射。
Rollup 链
子链通常有一个状态根，此状态路由可以通过直接调用智能合约来更新，也可以在 Rollup hub 将智能合约分配给另一个 Rollup 时更新，在这种情况下，应该删除该智能合约，并将其添加到其他智能合约中。
统一 RPC
目标：不必为每个 Rollup 连接到一个新的链，并对用户透明地进行跨 Rollup 交易。
统一的 RPC 在多 Rollup 网络中恢复了单个链的用户体验，用户不必连接到不同的网络来使用不同的 Rollup。
系统使用来自 Rollup hub 的 Rollup 排序器的注册表来查找与特定智能合约对应的排序器的 RPC 端点。然后将请求直接提交给该排序器。通过向不同的 Rollup 提交请求，可以完成多个交易。查看以下部分以获取更多细节。
如何工作
Rollup hub 为所有子链保存一个排序器的注册表。
当用户想要提交一个新的交易时，用户钱包会查询智能合约注册中心来获取该智能合约的 RollupID，并查询排序器注册中心来获取同一 Rollup 中的排序器的 RPC 端点。
然后将交易提交到排序器的 RPC 端点。
负载均衡
目标：平衡所有 Rollup 的费用
负载均衡允许在 Rollup 中平衡负载。当系统堵塞时，可以生成新的 Rollup 来处理负载。当没有太多使用时，可以删除 Rollup 来节省资源。此外，系统可以通过将交易中需求高的智能合约移动到具有更多可用容量的 Rollup 来避免费用飙升。
如何工作
每个 epoch，Rollup hub 都会评估系统中所有 Rollup 的负载。epoch 应该持续几个小时 ( 可能为 6 到 24 小时 )，以避免大规模的智能合约重新分配。
Rollup hub 可以决定重新分配哪些智能合约，以及何时生成或删除 Rollup，可以使用治理或使用不同智能合约的 Gas 消耗历史来自主决定。
Rollup hub 检查是否有任何 Rollup 的交易负载高于平均值 ( 即费用很高 ) 或低于平均值 ( 即费用很低 )。
如果一个 Rollup 的负载高于平均值，Rollup hub 会评估哪些智能合约消耗了最多的 gas，并将其重新分配到一个能够承担额外负载的不同的 Rollup。然后，智能合约将从其初始主机 Rollup 状态中删除。
如果所有 Rollup 的平均负载高于平均值，Rollup hub 将创建一个新的 Rollup，并向新 Rollup 分配一些智能合约。 类似地，如果所有 Rollup 的平均负载低于平均值，Rollup hub 将删除一个 Rollup，并将其智能合约重新分配给其他 Rollup。
Rollup 链应该在每个时期查看 Rollup hub，下载任何分配给它们的新智能合约的存储，并删除任何不再由它们负责的智能合约。
注意：下载一些智能合约的存储可能不是一件小事。首先，状态在 DA 层不可用，并且大小相当大。这限制了最小的 epoch 时间，需要一个宽限期来准备智能合约存储。
排序激励
目标：使用原生代币中的部分奖励激励备用排序器。
今天大多数 Rollup 都是建立在单链上，只有一个或很少几个排序器来管理，目标是最大化 Rollup 的正常运行时间。相比之下，在多 Rollup 系统中，有多个独立的子 Rollup，每个都必须在线才能在整个系统中保持活性。
排序器自然会受到激励加入 Rollup 以收集 MEV，但最好为这些排序器提供适当的奖励，因为它们更一致，不会像 MEV 那样错位激励。这些奖励应该来自 Rollup hub 货币政策。
此外，最好有几个排序器处于待命状态，并准备进入，这些排序器可以在交易需求增加时加入系统，并在没有计算资源时离开系统。
备用排序器将留在排序器队列中，并获得少量的可用性承诺奖励。当它们在 Rollup 中被交换时，它们将获得全部奖励。奖励将来自 Rollup hub 的费用燃烧机制。
如何使用
排序器可以通过提交一个财务债券 ( 类似于当前的 Rollup 系统 ) 加入 Rollup hub 的排序器队列。
队列中的排序器需要提供 DA 证明，表明它们具有 Rollup 集线器状态，并且可以随时读取以加入 Rollup。
当他们提交证据时，他们将获得部分奖励，即系统本地代币。该代币是 Rollup 枢纽上的句柄。
如果 Rollup hub 决定需要一个新的 Rollup，他们将被分配并获得全部奖励。该奖励由系统中消耗的总费用数量决定。
跨 Rollup 交易
目标：对用户来说，Rollup 交易应该是即时和透明的。
在 Rollup A 和 Rollup B 之间的跨 Rollup 交易需要有 2 个部分：1)Rollup A 上的交易 2)Rollup B 上的交易，只有当 Rollup A 上的交易成功且是 final 时才会发生。
为快速确认，用户钱包可以检查交易是否提交到底层的 DA 层，并使用 ZK 证明是有效的。如果交易被包含并且有效，那么排序器必须对该特定交易得出相同的结论。
这一想法归功于 Mustafa Al-Bassam 和 Sovereign Labs。
如何使用
一个用户提交了一个包含三个 Rollup 的交易，比如 RollupA、B 和 C。
让我们思考一个具体的例子，Rollup A 有一个稳定币智能合约，Rollup B 有一个 DEX，Rollup C 有一个借贷协议，在这个例子中，用户想将其稳定币兑换为不同的代币，并其存入借贷协议。
用户必须首先提交 Rollup A 交易，将稳定币转移到 Rollup B 上的 DEX。
随后，他们可以提交 Rollup B DEX 交易，该交易将稳定币兑换为 Rollup B 上所需的代币。
继而，该代币应该被转移到 RollupC，因此用户提交了第三个交易，正是这样做的。
最后，用户提交第 4 个也是最后一个交易，将代币存入借贷协议。
轻节点和区块浏览器
目标：轻节点应该能够跨 Rollup 验证智能合约，区块浏览器应该提供链的统一视图。
区块链系统应该允许任何人运行节点并验证链本身。在这种多 Rollup 设计中，智能合约不断被重新分配到不同的子 Rollup，应该有一种方法来跟踪这些特定的智能合约。这是从验证一个或多个链到验证一个或多个智能合约的思维转变。轻节点可以利用 ZK 证明来低成本地验证所有子 Rollup。
如何工作 ( 轻客户端）
Rollup 节点应该支持一个验证模式，沿着排序器模式。
验证模式验证单个智能合约的状态，不像排序器模式那样向 DA 层提交交易批次。
如果智能合约更改了子集群，验证节点只需更新他们监听的子集群，因为他们已经拥有了智能合约存储，直到重新分配之前。
智能合约应该一次在一个 Rollup 中处理。由于它们被限制在一个 Rollup 中，具有相同规格的验证节点应该能够跟踪和验证它们。
轻节点可以用 ZK 证明低成本地验证链的状态。
区块浏览器是区块链系统不可或缺的一部分。它们促进原生资产的余额查询、智能合约查询，并维护从第一个区块到当前区块的交易历史。在这个多 Rollup 系统中，区块浏览器应该提供所有子 Rollup 的统一视图。
如何工作（区块浏览器）
区块浏览器应该支持查询 Rollup hub 的余额 ( 针对原生资产 ) 和所有子 Rollup 的交易历史。
与单一 Rollup 系统类似，区块浏览器使用索引来实现这一点。多 Rollup 系统必须对所有 Rollup 进行索引，以便为系统中的任何智能合约提供查询服务。
如果 Rollup hub 决定扩大子 Rollup 的数量，区块探索器应该准备好处理它。它们应该提供更多的子 Rollup 容量，或者有一个容器编排系统 ( 例如 Kubernetes) 来自动扩大子 Rollup。
它们应该使用来自 DA 层的区块号，以便在所有 Rollup 之间保持一致性。
结论
目前上述设计只是一个想法，我可能永远不会进一步实现它，但是我希望该设想使你感兴趣。如果设计通过，我期待它可以用于 Rollup 项目，并接近 EIP-4844、Celestia 或 Avail 的扩容能力。
如果你认为哪里有缺陷或者设计有问题，请随时告诉我。
（声明：请读者严格遵守所在地法律法规，本文不代表任何投资建议）
