ETH Research：详解Rollup的Snap Sync设想及机制

原文标题：《 RFC: Deep dive into snap sync for rollups 》

原文作者：George Spasov，LimeChain 区块链架构师兼联合创始人

原文编译：Sharon，BlockBeats

编者按：随着 Rollup 不断增多，问题也随之显现。将 Rollup 进行 Snap Sync（快照同步），可以使节点能够从系统的其他参与者获取预处理信息来进行同步，同时自身也可以适当地验证它。这也是一种「减轻基础设施提供商的中心化向量」的方式。

概述

以下的各种想法和概念的探索，与对改善 Rollup 节点时间来最初将其状态同步到汇总的最新 Rollup 的时间有关。在下文中，这个改进的过程可以被称为 Rollup 的「Snap Sync」，这是从类似命名 L1 的过程中汲取的灵感。本文档概述了 Snap Sync 如何用于 Rollup 的总体思路，并深入探讨了各种 Rollup 参与者的角色和需求。

Rollup 节点的 Snap Sync 是一个重要的概念，因为 rollup 有望实现比 L1 高出几个数量级的吞吐量。

虽然 Rollup 承诺任何观察数据可用性层的人，都将拥有所有数据来重新执行和同步 Rollup，但实际上这将很快变得十分缓慢。这种缓慢的情况可能会导致通过将数据整合到少数专门持续同步 L1 的实体中来实现集中化。

Snap Sync 的目的是使节点能够通过从系统的其他参与者获取预处理信息来进行同步，但自己适当地验证它。

概念化的观点

下面是一个概念性的想法，包含 4 个步骤，可用于 Rollup 的 Snap Sync。它概述了新的 Rollup 节点如何同步到 Rollup 的尖端。

1. 同步节点记录来自 Rollup 的 L1 智能合约的最近（理想情况下不是最后一个）最终确定的块及其块哈希/状态根。

2. 该节点连接到一个或多个对等点并下载指定的最终区块的状态。

3. 节点根据步骤 1 中 L1 记录的区块哈希/状态根验证区块哈希/状态根。

4. 节点继续从 L1 同步后续的最终确定（如果适用）和虚拟状态。

深度阐述

上面的概念看似简单，但和往常一样，细节决定成败。当您开始考虑 Rollup 系统中各个参与者的目标和动机时，Snap Sync 的 Rollup 特定特性就开始出现。以下是 Snap Sync 设计的几个重要考虑因素，它们提供了更多输入，以便提出更完整的概念解决方案。

跟随者节点的作用

rollup 中的主要参与者是排序器和证明者（Optimistic Rollup 可以将其验证者视为证明者）。

排序器的工作是（以某种方式）获取用户事务并将其排序到 L1 中。他们通过发布 Rollup（理想情况下有效）序列的服务获得报酬。证明者获取数据并生成给定序列有效性的证明。证明者因在 L1 中提交有效证明而获得报酬。

最终，这两个参与者都将因其具体行为而获得奖励。定序器通过对 L2 状态修改事务进行排序而获得报酬。

为了让排序器完成其工作，它们只需要最近的虚拟状态和某个版本的内存池（私有化或公共化）。他们根本不需要关心（读取存储）过去已验证或未验证的状态。

证明者因提供证明而获得报酬。他们只需要来自 L1 DA 层的序列信息。他们也不需要关心（阅读存储）过去的状态。

这给最终用户留下了相当大的真空——没有参与者的工作是为读取当前或历史状态的 RPC 请求提供服务。虽然 Rollup 设计者通常将跟随者节点视为排序器的「简化」版本，但实际上，现在人们可以争辩说，它们是一个完全独立的参与者，具有单独的目标——为网络用户提供服务。

从 L1 节点推理，您应该请求状态读取的是您自己的「完整节点」。人们可以推断，「你自己的完整节点」相当于「你自己的跟随者节点」。跟随者节点需要保存 Rollup 的部分或全部历史状态，以便能够为（您的）历史数据的 RPC 请求提供服务。

一些非常非常常见的历史操作是——「给我从合约 X 发出的事件」，「给我我的交易哈希的交易收据」。目前没有其他演员需要服务其中任何一个。

跟随者节点的类型和 sync 类型

Sync 跟随者节点的简单方法是从 L1 DA 层下载 L2 序列并重新执行它们，直到赶上提示。如前所述，作为唯一的 Sync 模式，这很快就会变得不切实际地慢。

因此，这是一个可能但不充分的跟随者节点版本。在下文中，我们将完全从 L1 DA 同步并存储完整状态的节点称为归档跟随节点。

可以推断，多个用例需要节点的同步速度比归档跟随者节点能够提供的速度要快得多。这些都是实际需求，可以从 Rollup 的正常运行、其加密经济学中触发，或者纯粹是为了快速抓住（MEV？）机会。此类节点可以连接到档案跟随者节点，并使用上面概述的「概念化观点」来同步到 Rollup 的提示。

更深入地说，如果跟随者节点仅从存档跟随者下载最新的验证状态并同步到前向（通过重新执行虚拟状态），那么它在很大程度上无法满足我们要求跟随者节点满足的要求。他们将无法回答有关最后一个最终确定检查点之前任何区块的历史状态（最近或不是）的查询。这概述了跟随者节点需要从最后确定状态之前的状态进行同步。

从跟随者节点运营商的角度来看，可以做出两个单独的决策。这些决策有点类似于 L1 节点用于链同步的模式。

首先，跟随者节点可能会选择一个固定的历史验证序列（检查点）作为起点并从那里向前同步。就像快照同步模式下的 Geth 仅存储最后 128 个块一样，Snap 跟随者节点可以从最后 X（例如 32）个验证序列开始同步。

此外，它可以选择在任何时候仅保留已验证提示的最后一个 X（例如 32）的状态。Snap 跟随者节点将能够为汇总的最新状态和块提供查询服务。X 参数需要仔细选择，以确保大多数用户的历史数据需求和 Snap 跟随者节点的存储需求之间的适当平衡。

其次，跟随者节点可能会选择以与捕捉跟随者节点类似的方式进行捕捉同步，但也保留多个/所有其他已验证序列的状态——检查点。我们可以将该节点称为完整跟随者节点。需要注意的是，完整跟随者节点不需要重新执行旧历史检查点之间的交易，而只为它们保存状态。

这种机制允许完整的跟随者节点为更旧的 Rollup 状态的请求提供服务。全 跟随者节点可以看到请求的区块信息，计算之前同步和验证的检查点，并且只重新执行下一个序列的交易，直到所需的区块。

这种方法不像归档节点那样占用存储空间，但由于需要下载和重新执行数据，因此对查询的响应也不那么高效和快速。

所有三种类型的跟随者节点都有自己特定的权衡集，并且对于用户的各种用例都是最佳的。

排序器和证明器也需要跟随者节点

如上所述，定序器和证明器有自己的状态数据需求。与用户类似，他们需要以某种方式同步到 Rollup 中所需的点。从本质上讲，这意味着排序器和证明器需要一种机制来快速同步到最新的最终状态并从那里继续。讽刺的是，这实际上意味着他们需要某种形式的跟随者节点才能快速同步。（现在是谁被简化了排序器？）

想要进行 Snap Sync 并开始排序的定序器和证明器都可以连接到跟随者节点，下载最新的最终状态，对其进行验证并继续同步虚拟状态。

进一步的研究途径

深入研究 Snap Sync 机制，会出现一些实际问题。这些都需要考虑并需要进一步的研究和构思。

序列化状态机制

在上面的文本中，我们将检查点数据传输的复杂性隐藏在「连接和下载状态」后面。然而，在幕后，这意味着需要有一个定义的协议，用于在任何给定检查点对 Rollup 状态进行序列化、分区和传输。

下载状态的机制

虽然任何寻求 Snap Sync 的节点都可以连接到「一个」跟随者，但这会带来活性和可用性问题。以类似「torrent」的方式从多个关注者并行同步可以通过并行化加速 Snap Sync 过程，并能够进一步验证和验证下载的数据。

结论

Snap Sync 对于减轻基础设施提供商的中心化向量至关重要。虽然从表面上看，snap sync 的过程有些简单，但当考虑到网络中不同参与者的各种激励、角色和需求时，就会出现一些有趣的细微差别。

同步过程展示了跟随者节点（通常被误解的）角色对于 Rollup 生态系统来说是特殊且重要的，并且需要仔细设计。深入研究跟随者节点，根据操作者的需求，出现了各种跟随者节点的同步模式。

最后但并非最不重要的一点是，上面的分析展示了跟随者节点对于 rollup 的其他参与者（排序者和证明者）的重要性。这使得跟随者节点对于整个系统的稳健性非常重要。

欢迎对以上分析提出任何意见。欢迎对「进一步研究途径」提出任何想法、建议和/或贡献。

原文链接