Rollup与解耦SVM：深入分析

引言

随着区块链技术的广泛应用，链上扩展性问题变得日益突出，尤其是在以太坊等公共链生态系统中。如何在确保去中心化和安全性的同时，实现高吞吐量和低交易成本已成为一项重大挑战。Rollup 作为 Layer 2 (L2) 解决方案，受到广泛关注。其中，Optimistic Rollup 是一种被广泛应用的代表方案，Optimism 是其旗舰项目。

本文将首先以 Optimism 为例，从 Optimistic Rollup 的工作机制出发，深度分析其安全保障机制。旨在帮助读者深入理解区块衍生与解构的基本原理，然后探索 SOON 的解构 SVM 的具体设计和架构优势。这将使读者深入了解解构 SVM 的概念和原理。

为了为后续讨论奠定坚实基础，我们将首先分析 Rollup 的基本概念，以理解 Optimistic Rollup 的基本安全性是如何保证的。Rollup 是一种主流的扩展解决方案，它降低了用户与区块链交互的成本。然而，鲜有对 Rollup 背后的技术原理和安全问题进行细致探讨，从整体角度进行全面分析的文章更是稀缺。今天，我们将深刻探讨其原理及更深层次的问题。

Optimistic Rollup 的架构 — 以 Optimism 为例

Optimistic Rollup 架构的关键组成部分

L2 面临一个非常重要的问题：如何从 L1 衍生区块？

区块衍生之所以如此重要，是因为 L2 本质上是 L1 的扩展。 L2 不能在没有 L1 的情况下独立保持一个账本，而 L2 的账本的合法性也需要以一种 L1 的去中心化共识可以确认的方式记录在 L1 上。

在深入了解衍生的具体细节之前，我们首先来看 L1 与 L2 之间的关系。L2 和 L1 是如何通信的，数据之间的关系是什么？

L2 提交给 L1 存储的关键数据包括：

• DA 承诺：此项表示 L2 的交易数据已经发布，确保后续的验证者能够访问和验证这些数据。
• 状态根：这反映了 L2 执行后的链上状态；
• Blob（通常放置在单独的 DA 层）：这是 L2 提交的 blob 数据，作为数据可用性证明。

这些存储的数据保证 L2 交易的最终性，并为未来的验证和挑战提供基础数据。

L2 系统需要监听来自 L1 的关键交易数据，以确保与 L1 的同步和一致性。L2 监听的主要数据包括：

• 存款和取款交易：L2 必须不断监测在 L1 上的存款和取款交易，因为这些交易在 L1 上的确认直接影响 L2 上用户账户的状态。L2 必须实时同步这些交易，以确保 L1 和 L2 之间资金流动的安全性和一致性。
• L2 提交的交易批次数据：这是 L2 提交给 L1 的批量数据，包含交易详细信息。这允许 L1 或独立验证者重放这些交易并进行状态验证。

为什么这样设计？

我们可以将 L2 提交给 L1 的数据分为两大类以便理解：

第一类是交易批次信息。 这批信息特别重要，因为它支持独立验证者重放 L2 的交易。验证者可以使用这些批次信息重新计算一个独立的状态根，并检查其是否与 L2 提交给 L1 的状态根相匹配。这是确保 L2 不会随意“恶意行为”的关键。如果 L2 提交的数据是非法或欺诈的，独立验证者在重放并衍生出不同的状态根后，可以提交故障证明并发起挑战，要求区块回滚。

第二类是状态根。 状态根反映了 L2 交易执行后的链上状态，包括账户余额、合约状态等。这些数据被提交给 L1 进行数据验证。如果独立验证者计算出不同的结果，他们可以发起挑战。因此，L2 必须确保提交给 L1 的数据完全正确；否则，可能面临来自验证者的挑战和处罚。

L2 监听来自 L1 的核心数据是存款和取款交易。L1 上的存款和取款必须反映在 L2 上的账户状态内。这确保了跨链资金操作的安全性和一致性。L2 还需要监听交易批次数据。

有人可能会问，由于 L2 自身提交这些数据，为什么还需要监听这些数据？

尽管 L2 的交易是打包并首先提交给 L1，但 L2 必须通过确认数据确实被成功提交并且可用来确保一致性。尽管数据最初是由 L2 打包并提交给 L1 的，但 L2 仍须从 L1 再次监听这些批次详情，以确认其已被正确记录。这个过程本质上是一种安全保障。如果提交的数据未在 L1 记录，L2 就无法确保系统的安全。

此时，可能会出现另一个问题：为什么 L2 不需要等待 L1 确认提交的数据后再继续区块生产？这就是 Optimistic Rollup 中“乐观假设”的核心：乐观执行。L2 不需要在每一步都等待 L1 的确认，而是继续独立生成区块和处理交易，假设所有交易都是合法有效的。 这通过避免与验证过程相关的长时间延迟，大大提高了系统效率。每个 L2 区块都假设交易是有效的，并定期将交易数据批量提交给 L1，直到有验证者发现问题，提交故障证明并发起挑战。

现在我们可以理解 L2 是如何从 L1 衍生出来的。

工程实现 — 以 Optimism 为例

目前，Optimism 的主要组成部分包括：op-node、op-geth、op-batcher 和 op-proposer。

• op-node：这是系统中的协调节点。它与 L1（以太坊主网）通信，从 L1 接收区块头和交易信息，同时管理 L2 网络内的状态转更新逻辑。op-node 充当 L1 和 L2 之间的桥梁，帮助将区块数据从 L1 转移到 L2 网络。此外，它还协调不同组件的核心节点。
• op-geth：这是在 Optimism 上实现以太坊虚拟机 (EVM) 的节点。它负责在 L2 上执行智能合约和交易。实际上，所有在 L2 上运行的智能合约和执行环境均由 op-geth 处理，后者充当核心执行引擎。
• op-batcher：此组件负责将 L2 打包的交易提交给 L1。它收集用户的交易，将其打包成一个批次，并通过 L1-RPC 将批次提交给以太坊 L1。此批数据并不会立即执行，而是存储在 L1 上，L2 的状态更新依赖于这些批次。
• op-proposer：此组件负责向 L1 提交 L2 的状态根。每当 L2 网络发生状态变化（比如执行交易）时，op-proposer 会定期将这些状态变化提交给 L1。

op-node 和 op-geth 一起形成通常所称的 Sequencer，而 op-batcher 和 op-proposer 主要负责确保我们之前提到的交易数据是可验证的，专注于设计的安全性。

此时，可能会出现另一个问题：为什么 op-batcher 和 op-proposer 两者都是必要的，即便它们都将数据提交给 L1？我们之前提到，op-batcher 仅提交“原料”（交易批次），而最终的“产品”（状态根）由 L2 上的执行引擎（op-geth）生成，并最终由 op-proposer 提交给 L1。

因此，尽管 op-batcher 提交的数据很重要，但它并不直接控制 L2 到 L1 的状态通信。相反，它只是提供独立验证者可以重放的交易数据。在乐观执行的假设下，Sequencer（op-node + op-geth）独立生成区块并定期提供交易数据和结果给 op-batcher 和 op-proposer。

总的来说：

• op-node：协调 L1 和 L2 之间的数据同步。
• op-geth：在 L2 上执行交易和合约。
• op-batcher：提交 L2 交易批次以确保数据可验证性。
• op-proposer：定期向 L1 提交 L2 的状态根以确保状态更新和数据一致性。

通过之前的讨论，我们现在可以理解如何保证 L2 的安全。尽管我们并没有具体讨论故障证明，但这些核心条件已经在 L2 架构中得到隐含反映。L2 系统的安全性依赖于独立验证者重放 L2 提交的交易数据，以验证其正确性，如果有必要则提出挑战。

在 Optimistic Rollup 框架中，从 L2 到 L1 提交的交易数据和状态根被假设为正确，并且系统不会立即进行完全验证。这一乐观假设使 L2 能够继续高效地处理交易和生成区块，而不必等待每个交易被单独验证。通过提高吞吐量和降低交易成本，系统效率大大提升。

在挑战过程中，如果确认状态根存在问题，L1 将触发回滚机制，撤回错误的区块，同时对 L2 实体处以处罚。提交故障证明的验证者将根据系统设计获得奖励，从而激励更多验证者积极参与系统的安全监控。

这标志着 Rollups 与主权区块链之间的显著差异。Optimistic Rollups 专注于数据可验证性，假设数据是正确的，然后等待独立验证者提出挑战。相比之下，主权区块链则专注于构建去中心化节点和共识机制。

将执行层与共识层解耦

接下来，我们将更深入地探讨解耦的概念。以 Optimism 为例，通过我们之前的分析，我们可以看到，通过 Optimism 的设计，结果是将 L2 的区块生产与 L1 的共识机制分离，同时保持验证机制以确保安全。这本质上是解耦。解耦的核心思想是将执行层与共识层分开，使它们能够独立运作。在传统区块链架构中，执行与共识紧密结合，意味着交易必须在节点的共识下得到确认，才能进行处理。

衍生管道的关键角色

尽管在解耦执行层和共识层的过程中，L2 可以独立产生区块，但系统的安全仍依赖于 L1 的衍生管道。

衍生管道解决了 L2 独立区块生产期间可能出现的安全和一致性问题。具体而言，衍生管道为 L2 的区块生成提供了一个可信的基础。即使 L2 不等待 L1 的实时确认，它仍然可以通过衍生数据确保交易的合法性和安全性。当独立验证者重放交易并发现 L2 数据与提交给 L1 的数据之间存在差异时，衍生管道提供了足够的数据支持，允许提起故障证明并触发回滚机制。如果没有这个衍生过程，L2 无法保证其数据的可验证性，故障证明将变得毫无意义。因此，衍生管道不仅是 L2 扩展能力的技术支持，也是确保系统安全的重要组成部分。

解构 SVM — SOON 的核心执行层

在此时，我们应当对解耦有了相对深刻的理解。我们上面使用的例子是以太坊生态系统中的 Optimism。实际上，在以太坊内，大多数 Rollup 解决方案已实现了执行层与共识层的解耦。然而，在 SVM 中，一切只是刚刚开始。SOON 采用了一种类似于 Optimism 的解决方案，这也是我们最初使用 Optimism 作为示例的原因。然而，SOON 将 SVM（Solana 虚拟机）与 Solana 共识层解耦。这里还有更多复杂和深入的问题需探讨。虽然核心思想相同，但具体的工程实现和挑战却有所不同，因此我们需要继续探索 SOON 如何将 SVM 核心执行层与 Solana 解耦。

在 Solana 中，SVM 与 Solana 的共识层紧密结合。SVM 负责智能合约和交易的执行，而共识层通过 Tower BFT 和 PoH（历史证明）机制达成共识。SOON 的挑战在于将 SVM 从这种紧密集成的架构中解耦，使其能够独立运行并与其他共识机制或 Layer 1 接口交互。这涉及到拆解现有的 Solana 验证者节点架构，移除共识相关的组件，同时保留执行层的核心功能，并重新设计处理区块衍生、数据提交和验证的机制。

要进一步分析这个问题，我们必须首先深入理解 Solana 验证者的结构。

Solana 验证者的结构

验证者在 Solana 的架构中扮演着重要角色，它们是实现共识、验证交易和维护网络状态的核心组件。验证者通过运行多个模块来确保交易的有效性和共识。Solana 的验证者结构相对复杂，集成了执行环境（SVM）和共识机制（Tower BFT 和 PoH）。我们将逐一分析验证者的关键模块。

• Json RPC 服务：客户端（如钱包或 dApp）通过此服务向 Solana 验证者发送请求。该服务充当 Solana 系统的外部接口，处理提交交易、查询账户状态和检索区块信息等请求。
• TPU（交易处理单元）：这是负责接收和执行交易的核心模块。它集成了 SVM，排序交易，并处理其执行逻辑。在 TPU 中，交易首先被排序和打包，然后在 SVM 环境中执行。交易结果生成状态变化，这些状态变化以状态根的形式提交给共识模块，最终反映在整个网络的状态中。
• Bank Forks：该模块处理网络发生状态分歧时的链状态分叉（例如，当多个验证者同时生产区块时）。
• Gossip 服务：该协议管理 Solana 网络中节点间的通信，传播网络最新的状态、交易和区块信息。验证者节点通过该服务从其他节点接收区块和交易，确保网络的状态一致。
• 其他与共识相关的过程或模块：重放阶段重新验证打包在区块中的交易，通过重放交易确保数据的一致性。验证者持续获取交易信息，进行执行、验证，并接受来自其他节点的信息，最终在 Tower BFT 和 PoH 共识下达成一致并生成区块。

在 Solana 的架构中，执行层（SVM）与共识层紧密耦合。然而，对于 Optimistic Rollups 而言，许多这些模块是不必要的。在 Optimistic Rollup 中，接收到交易后，Rollup 节点可以立即执行、打包并生成区块，而不需要共识。唯一的要求是定期将可验证的交易批量数据和状态根信息提交给 DA 层或 L1，同时确保访问来自 L1 或 DA 层的存款和取款交易、交易批量数据和状态根信息。结合故障证明机制，这已经足够保证安全。

因此，为了将 Solana 的核心执行环境（SVM）与 Solana 解耦，第一步是从 Solana 验证者中移除共识相关模块并重新组装其余部分。下一步是建立 L2 从 L1 衍生信息的机制，这就是前面详细介绍的衍生过程。最后，需要构建故障证明机制。具备这些元素后，SOON 可以实现一个极为灵活且安全的 Optimistic Rollup。这是 SOON 所承担的工作。

现在，SOON 栈就清晰可见。如果提交可验证数据的目标被替换为专用 DA 层，那么 SOON 可以使用任何 DA 层进行独立验证和确认。如果用不同的 L1 替代验证块、存储状态根信息以及处理存取款的地方，那么 SOON 可以将任何 L1 用作结算层。在 SOON 栈的基础上，任何实体都可以构建选择任何 L1 和任何 DA 层的 Rollup。

接下来，我们将从工程角度详细说明解构 SVM 是如何实现的。

执行层重建

在 SOON 的架构中，传统 Solana 验证者的共识相关模块已被显著简化或完全移除，重点放在交易执行、状态更新和数据提交。共识层不再直接处理交易验证和排序，从而释放了大量计算资源，使系统更高效。

SOON 保留了交易处理、打包和交易传输的核心模块。以下是一些关键模块的重构和优化：

TPU（交易处理单元）

TPU 是 SOON 执行层的核心组件，负责接收、排序、执行交易并生成状态更新。在重构后的验证者中，TPU 继续作为主要执行引擎。SOON 中，TPU 处理传入的交易，调用 Anza SVM APIs 来执行智能合约和状态变化。TPU 处理以下功能：

• 接收和排序交易：TPU 接收并排序网络中的交易请求，将其打包成批次，并确保交易按预定顺序执行。
• 调用 SVM APIs：每笔交易提交给 SVM 执行。
• 生成状态根：在执行交易后，TPU 生成状态根，作为系统状态快照。这些状态根通过衍生机制提交给共识层或外部存储层。

TPU 中详细的交易处理流程如下：

• SigVerifyStage：此阶段验证每笔交易的签名，确保交易的签名有效后，才能进入执行流程。
• BankingStage：经过签名验证后，交易进入 BankingStage，该阶段根据交易内容管理账户和状态更新。尽管这一阶段处理交易逻辑，但并不实际执行交易，而是计算相关的状态变化。
• SVM 执行者：此阶段负责实际执行交易中的智能合约或指令。SVM 根据先前的账户状态和交易内容执行合约调用与执行。
• 入口组件：此最终阶段处理交易的入口。它打包导致状态变化的执行交易，并将其写入区块链，将交易和状态变化记录在区块链上。

衍生层和衍生管道

SOON 在工程上重新构建了区块衍生层，并设计了完整的接口系统以支持衍生、打包和故障证明等关键流程。本节将详细解释 SOON 的衍生层如何从 Layer 1 (L1) 获取和处理数据，并将其整合到 Layer 2 (L2) 的区块生产流程中，从而确保系统一致性和安全性。

衍生层的架构和接口设计

在 SOON 的区块衍生过程中，L2 的区块生产依赖于从 L1 衍生的关键信息。这些信息包括 L1 区块头、存款交易、数据可用性批次信息等。这些数据被解析并打包到 L2 区块中以完成最终的区块生成。具体过程如下：

衍生

衍生的第一步是获取 L1 的最新区块头，并提取衍生所需的关键信息。这些信息包括：

• 区块头：区块的元数据，用于确认区块的时间戳和基础信息。
• 存款交易：发生在 L1 上的跨链存款交易需要反映在 L2 的账户中。
• 数据可用性批次信息：确保 L2 上的数据能够被验证者正确访问和验证的关键数据。

通过实现 PayloadAttribute 特征，这些关键信息被解析并存储在一个结构中，为后续的区块打包做好准备。

打包

在解析并获取 L1 的衍生信息后，L2 需要将这些信息与 L2 客户端提交的常规交易（即用户在 L2 上发起的交易）进行打包。此打包过程通过 BlockPayload 特征实现，将所有交易和区块头信息集成到一个统一的数据结构中。在此打包过程中，系统处理来自多个来源的交易，包括：

• L1 衍生的数据：如区块头、存款交易等。
• L2 本地交易：用户在 L2 上提交的常规交易，通过 L2 的 TransactionStream 进入打包过程。

最后，这些交易被组合成一个标准化的块有效载荷，准备就绪以供执行和处理。

传输和生产

打包好的 BlockPayload 被发送到 SOON 的核心模块—— Engine，这是一个实现了 EngineAPI 接口的内核模块。Engine 模块负责在 SVM（Solana 虚拟机）上执行打包后的交易，并生成最终的区块。在此过程中，系统处理交易执行、重组（Reorg）和最终区块确认。

交易执行

在 Engine 中，BlockPayload 被传递给 SVM 进行执行。

通过 EngineAPI 接口中的 new_block 函数，系统可以基于接收到的 BlockPayload 生成一个新区块，并将其添加到 L2 区块链。在此过程中，SVM 确保交易执行的正确性并验证状态更新。

区块重组

在某些情况下，系统可能需要重组 L2 区块链，通常发生在 L1 发生重组时，需要 L2 与 L1 的状态同步。reorg 函数在 EngineAPI 接口中触发重组操作，将 L2 的链重置为匹配 L1 的状态。这个机制确保 L2 的链状态与 L1 保持一致，防止由于 L1 的重组导致的不一致。

区块最终确定

区块生产的最终步骤是区块确认和最终确定。使用 EngineAPI 接口中的 finalize 函数，系统可以将生成的区块标记为最终确定，并将其记录在 L2 区块链上。此过程确保区块不会进一步修改，保证交易的最终性。

故障证明和挑战机制

SOON 的衍生层不仅支持区块的生产和重组，还通过故障证明机制确保系统的安全性。独立的验证者可以基于状态根和通过衍生层提交的交易批次重放 L2 的交易，以验证数据的正确性。如果发现 L2 提交的数据与实际执行结果之间存在差异，验证者可以通过提交故障证明发起挑战。

故障证明流程：

1. 验证者重放交易：使用从 L1 衍生的交易数据，验证者可以重放 L2 交易，计算状态根，并与提交的结果进行比较。
2. 提交故障证明：如果发现差异，验证者可以通过 L1 提交故障证明，请求系统回滚。
3. 区块回滚和重组：一旦故障证明得到验证，系统将触发区块回滚机制，撤销错误的区块，并使用衍生机制确保数据的一致性。

SOON 设计了一个完整的接口，以实现区块衍生、交易打包、执行和故障证明机制。结合前面执行层的重构，解构 SVM 已完全实现，成功将核心执行层与共识层解耦。

结论与展望

在对解构 SVM的技术架构进行了深刻分析后，我们可以清楚地看到，解耦带来的好处在多个层面显著提升系统的安全性、性能和灵活性。通过将 SVM 同共识层解耦，SOON 不仅释放了 SVM 的执行能力，实现了高吞吐量 (TPS)，还为未来的扩展和跨链操作奠定了坚实基础。

解构 SVM 的一个核心优势是提高了安全性。通过分离执行层和共识层，验证者能够独立重放 L2 交易并验证结果，确保数据可验证性。衍生机制还确保用户无需担心资产的存取款问题，因为 L1 的存款交易被包含在此过程之中。

从性能角度来看，解构 SVM 显著提升了系统的并行处理能力。由于 SVM 不再依赖于共识层的实时确认，能够独立快速处理和执行交易，生成区块。这种分离大大减轻了共识层的负担，并释放了 SVM 的性能潜力，使其能够专注于执行并行交易，实现超高的吞吐量。这种高效的处理机制对于 L2 系统尤其关键，在高并发的区块链应用中，解构 SVM 能够显著提升系统响应速度和整体处理能力。

在架构上，解构 SVM 显示出卓越的灵活性。解耦后，可以选择任何 DA 层（数据可用性）和 L1 结算层，甚至可以将 DA 层与 L1 合并以实现 SOON Stack。通过这一设计，SVM 能够无缝与各种 Layer 1 网络（例如，TON、BTC 或其他公共链）及数据可用性解决方案集成。这不仅增强了系统的扩展性，还为未来部署不同的 Layer 2 扩展解决方案提供了巨大的灵活性。

通过本文的详细分析，我们旨在展示解构 SVM 的技术优势，特别是在安全性、性能和灵活性方面的卓越表现。

展望未来，基于解构 SVM 的 SOON Stack 将在跨链、Layer 2 扩展和数据可用性解决方案中发挥关键作用。解耦架构不仅适用于现有的区块链生态系统，还为新兴跨链协议和多链应用提供了理想的基础设施。SVM 可以作为各种 Layer 2 和跨链应用的核心虚拟机，灵活适应不同的共识机制和 Layer 1 网络，以满足不同行业的需求。结合即将推出的互操作性产品，SVM 生态系统的潜力将进一步扩大。

关于 SOON

SOON 栈是最有效的 Solana 虚拟机 (SVM) Rollup，通过任何 L1 生态系统提供高性能。执行层使用的是解构的 Solana 虚拟机 (SVM)，而不是大多数 SVM 项目使用的分叉 SVM 框架。衍生管道和争议游戏的实现符合 OP Stack 规范。SOON 的使命是创建使用 SVM 的最高吞吐量的 Rollup 栈，通过降低成本 10 倍，推动 SVM 使用，并解锁跨生态系统的用例。

SOON 还将在以太坊之上推出 SOON 主网。SOON 主网通过 SOON Stack，利用解构 SVM，与其他使用分叉 SVM 的 SVM 项目有所区别。解构 SVM 使故障证明成为可能，这带来了更高的安全性和更少的 DA blobspace 浪费。作为激励和执行层，SOON 主网将在将开发者引入和留在 SVM 生态系统方面发挥关键作用。

SOON 与来自 Solana Labs 的分拆开发工作室 Anza 保持一致。Anza 的 Agave 仓库中的 SVM 规范作为 SOON 的实施参考。团队在加密领域拥有丰富的经验，能够高效执行。联合创始人兼首席执行官 Joanna Zeng 自 2017 年以来就一直活跃于 Crypto，并曾在 Coinbase、Optimism 和 Aleo 领导业务发展与合作。技术联合创始人 Andrew Zhou 在开发智能合约和 L1 方面备受尊重，拥有 5 年 Rust 和 6 年 Golang 的开发经验。

SOON 得到了行业内最受尊敬的天使投资者的支持，包括 Toly，Anatoly “Toly” Yakovenko（Solana Labs 的联合创始人）；Lily Liu，Solana Foundation 的总裁及 Anagram Ventures 的创始人；Jonathan King，Coinbase Ventures 的首席顾问；Mustafa Al-Bassam，Celestia Labs 的联合创始人；Amrit Kumar，AltLayer 的联合创始人；Prabal Banerjee，Avail 的联合创始人，以及其他知名建设者。

• 原文链接： medium.com/@soon_SVM/rol...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～