扩容未来：multi-Rollup 系统设计构想

注：原文为以太坊社区成员Andreas Tzionis发布于论坛帖子，旨在分享其对解决当下Rollup所面临的问题提出的解决思路。

长期以来，我一直有这样一个想法，即通过多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 hub和子Rollup。Rollup hub是一个Rollup，包含所有子Rollup的所有智能合约注册表，并决定哪个Rollup负责哪个智能合约。此外，Rollup hub包含另一个子Rollup的所有排序器的注册表。子链负责执行Rollup hub在智能合约注册表中分配给它们的智能合约的交易。排序器注册表包含每个排序器系统有两个主要组件：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的扩容能力。

如果你认为哪里有缺陷或者设计有问题，请随时告诉我.