每个区块链都提供了一种独特的方法来解决并行化挑战，并有一套自己的利弊权衡。

撰文：Ali Sheikh，加密分析师

翻译：金色财经 xiaozou

本文将概述区块链的并行设计架构，借用三个相关例子：Solana、Sei 和 Monad。本文强调乐观并行和确定性并行之间的区别，并了解这些链上的状态和内存访问的细微差别。

1、前言

1837 年，计算机科学家和数学家 Charles Babbage（查尔斯·巴贝奇）设计了「Analytical Engine（分析机）」，为并行计算奠定了理论基础。如今，并行化是加密世界的一个关键主题，区块链正试图扩展处理、效率和吞吐量的边界。

并行计算使许多计算或进程能够同时执行，而不是必须按顺序或一个接一个地执行计算。并行计算指的是将较大的问题分解成多个较小的独立部分，这些部分可以由多个通过共享内存进行通信的处理器来执行。并行系统具有许多优点，例如提高效率和速度、可扩展性、改进可靠性和容错性、优化资源利用率以及处理超大数据集的能力。

然而，认识到并行化的效力取决于底层体系结构和实现的细节是至关重要的。区块链的两个核心瓶颈是加密功能（哈希函数、签名、椭圆曲线等）和内存 / 状态访问。对于区块链来说，设计高效并行系统的关键组件之一在于状态访问的细微差别。状态访问是指交易读取和写入区块链状态的能力，包括存储、智能合约和账户余额。为了使并行区块链有效且具有高性能，必须优化状态访问。

目前在优化并行化区块链的状态访问方面有两个思想流派：确定性并行和乐观并行。确定性并行要求代码明确地预先声明区块链状态的哪些部分将被访问和修改。这让系统可以事先确定哪些交易是可以并行处理的，而不会发生冲突。确定性并行支持可预测性和高效率（特别是在大部分独立交易的情况下）。然而，它确实给开发人员带来了更多的复杂性。

乐观并行不需要代码预先声明其状态访问就可并行处理交易，就好像不会发生冲突一样。如果出现冲突，乐观并行将重新运行、重新处理或串行运行冲突交易。虽然乐观并行化为开发人员提供了更大的灵活性，但冲突需要重新执行，因此当事务不冲突时，这种方法是最有效的。至于哪一种方法更好，还没有正确答案。它们只是实现并行化的两种不同的可行方法。

下面我们先来探索非加密并行系统相关的一些基础知识，然后再来看区块链并行执行的设计空间，我们将重点关注三个核心领域：加密并行系统概述、内存和状态访问方法以及并行设计机会。

2、非加密并行系统

通过我们刚刚了解到的关于并行计算的功能和并行系统的优势，现在就很容易理解为什么并行计算的采用在最近几年开始流行起来。而且在过去的几十年里，并行计算就已呈现日益流行之势并实现了许多突破。

医学影像：并行处理从根本上改变了医学影像，带来各种影像模式（如 MRI、CT、X 射线和光学断层扫描）的速度和分辨率的显著提高。英伟达处在这些进步的最前沿，通过其并行处理工具包为放射科医生提供更加强大的人工智能功能，使影像系统能够更有效地处理更多的数据和计算负载。

天文学：一些新的天文现象，比如对黑洞的理解，只有使用并行超级计算机才能实现。

Unity 游戏引擎：Unity 引擎使用 GPU 能力（专为大规模图形工作负载构建）以帮助提高性能和速度。该引擎配备了多线程和并行处理功能，带来无缝的游戏体验，能够创建复杂逼真的游戏环境。

让我们来看看三个已部署并行执行环境的区块链。首先，我们来看 Solana，然后是两个基于 EVM 的链——Monad 和 Sei。

3、并行设计概述

（1）Solana

从高层来看，Solan 的设计理念是区块链创新应随硬件进步而发展。随着时间的推移，硬件根据摩尔定律不断改进，Solana 的设计将受益于性能和可扩展性的提高。Solana 联合创始人 Anatoly Yakovenko 在五年多以前就设计了 Solana 的最初并行架构，今天，并行性作为区块链设计原则正迅速传播开来。

Solana 使用确定性并行方式，这来自于 Anatoly 过去处理嵌入式系统的经验，在嵌入式系统中，通常会预先声明所有状态。这使 CPU 能够知道所有的依赖关系，从而使它能够预先载入内存的必要部分。结果就是优化了系统执行，但是再一次，它要求开发人员预先做好额外的工作。在 Solana 上，程序的所有内存依赖都是必需的，并在构建的交易（即访问列表）中进行声明，从而使运行时（runtime）能够高效地调度及并行执行多个交易。

Solana 架构的下一个主要组件是 Sealevel VM，它是 Solana 的并行智能合约运行时。Sealevel 原生支持基于验证者的内核数量并行处理多个合约和交易。区块链中的验证者是负责验证交易、提议新区块以及维护区块链完整性和安全性的网络参与者。由于交易预先声明哪些帐户需要读写锁定，因此 Solana 调度器能够确定哪些交易可以并行执行。正因如此，当涉及到验证时，「区块生产者」或 Leader 就能够对数千个待处理交易进行排序，并且并行调度非重叠交易。

Solana 的最后一个设计元素是「pipelining」。当需要以一系列步骤处理数据，并且每个步骤由不同的硬件负责时，就会触发 pipelining。这里的关键想法是获取需要串行运行的数据，并使用 pipelining 将其并行化。这些 pipelines 可以并行运行，并且每个 pipeline 阶段可以处理不同的交易包。

这些优化允许 Sealevel 同时组织和执行独立的交易，利用硬件的能力，一次使用一个程序处理多个数据点。Sealevel 按 programID 对指令进行排序，并在所有相关帐户上并行执行相同指令。

通过这些创新，我们可以看到 Solana 被有意设计为支持并行化。

（2）Sei

Sei 是一个通用的、开源 L1 区块链，专用于数字资产交易。Sei V2 采用乐观并行方法，因此，它对开发人员来说更加友好。在乐观并行模式下，智能合约可以更加无缝地并行执行，不需要开发人员预先声明它们的资源。这意味着链乐观地并行运行所有交易。尽管如此，当发生冲突时（即多个交易访问相同的状态），区块链将跟踪每个冲突交易所影响的特定存储组件。

Sei 区块链使用「乐观并发控制（OCC）」机制来执行交易。并发交易处理发生在有多个交易同时在系统中活动时。这种交易方式有两个阶段：执行和验证。

在执行阶段，交易被乐观地处理，将所有读 / 写临时存储在特定交易存储中。此后，每个交易都将进入验证阶段，在验证阶段，临时存储操作中的信息将根据先前交易所做的状态更改进行检查。如果交易是独立的，则交易将并行运行。如果一个交易读取的数据被另一个交易修改过，将产生冲突。Sei 的并行系统将通过比较交易的读取数据集与多版本存储中的最新状态变化（这些变化是按交易顺序索引的）来识别每个冲突。Sei 将在出现冲突的位置重新执行并重新验证实例。这是一个迭代过程，涉及到执行、验证和重新运行，才能修复冲突。下图说明了当出现冲突时 Sei 是如何处理交易的。

Sei 的实现为 EVM 开发人员提供了更低的 gas 费和更广阔的设计空间。一直以来，EVM 环境被限制为小于 50 TPS，这迫使开发人员创建遵循反模式的应用程序。Sei V2 让开发人员能够接近通常要求高性能和低费用的领域，如 DeFi、DePIN 和游戏。

（3）Monad

Monad 正在建设一个具有完全字节码兼容性的并行 EVM L1。Monad 的独特之处不仅在于它的并行引擎，还在于他们在底层构建的优化引擎。Monad 采用了一种独特的整体设计方法，结合了几个关键特性，如 pipelining、异步 I/O、共识执行分离，以及 MonadDB。

Monad 设计的一个关键创新是带有轻微偏移量的 pipelining。偏移量允许通过同时运行多个实例来并行化更多进程。因此，pipelining 被用来优化许多功能，如状态访问 pipeling、交易执行 pipelining、共识和执行内部 pipelining 以及共识机制自身内的 pipelining。

接下来，我们将具体来看 Monad 的并行化部分。在 Monad 中，交易在区块内是线性排序的，但目标是通过利用并行执行更快地达到最终状态。Monad 的执行引擎设计采用了乐观并行算法。Monad 的引擎同时处理交易，然后执行分析，以确保如果交易被一个接一个地执行，也将取得相同的结果。如果存在任何冲突，则需要重新执行。这里的并行执行是一个相对简单的算法，但将它与 Monad 的其他关键创新结合起来，就让这种方法变得新颖了。这里需要注意的一点是，即使发生重新执行，通常也很便宜，因为无效交易所需的输入几乎一直保留在缓存中，所以这将是一个简单的缓存查找。重新执行被确保一定会成功，因为你已经执行了区块中之前的交易。

Monad 还通过分离执行和共识（类似于 Solana 和 Sei）以及延迟执行来提高性能。其中的想法是，如果你放宽执行条件，以便在达成共识之前完成执行，则可以并行运行执行和共识，从而为两者增加额外的时间。当然，Monad 使用一种确定性算法来处理这种情况，以确保其中的一个不会跑得太远而失控。

4、状态访问和内存的独特方法

正如我在本文开头提到的，状态访问是区块链的典型性能瓶颈之一。状态访问和内存的设计选择最终可以决定并行系统的特定实现是否会在实践中提高性能。下面我们来具体了解并比较 Solana、Sei 和 Monad 采用的不同方法。

（1）Solana 状态访问：AccountsDB / Cloudbreak

Solana 利用水平扩展来跨多个 SSD 设备分发和管理状态数据。如今，许多区块链使用通用数据库（即 LevelDB），这在处理大量并发读写状态数据方面存在限制。为了避免这种情况，Solana 利用 Cloudbreak 构建了自己的自定义帐户数据库。

Cloudbreak 是为跨 I/O 操作的并行访问而设计的，而非单纯依赖于 RAM，这本身就很快。I/O 操作（输入 / 输出）是指从外部源（如磁盘、网络或外围设备）读取数据或向其写入数据的操作。最初，Cloudbreak 使用 RAM 内部索引将公钥映射到持有余额和数据的帐户。然而，在撰写本文时，V1.9 索引已经从 RAM 移到了 SSD 上。这种转变允许 Cloudbreak 在其队列中同时处理 32 个（I/O）操作，从而增强了跨多个 SSD 的吞吐量。因此，可以高效地访问区块链数据，例如帐户和交易，就像在使用内存映射文件的 RAM 中一样。下图表明了内存结构。虽然 RAM 更快，但它的容量比 SSD 小，而且通常更昂贵：

通过横向扩展和跨多个设备分发状态数据，Cloudbreak 降低了延迟，提高了 Solana 生态系统的效率、去中心化程度和网络弹性。

（2）Sei 状态访问：SeiDB

Sei 重新设计了它的存储——SeiDB——以解决以下几个问题：写入放大（维护数据结构需要多少元数据，越小越好）、状态膨胀、操作缓慢以及性能随着时间的推移而下降。新的再设计现分为两个组件：状态存储和状态承诺。记录和验证对数据的任何更改由状态承诺处理，而在任何时候记录所有数据的数据库由状态存储（SS）处理。

在 Sei V2 中，状态承诺使用内存映射 IAVL 树架构（MemIAVL）。内存映射 IAVL 树存储较少元数据，这减少了状态存储和状态同步时间，并使运行完整节点变得更加容易。内存映射 IAVL 树表示为磁盘上的三个文件（kv 文件、branch 文件和 leaf 文件）；因此，需要跟踪的元数据更少，这有助于将状态存储减少 50% 以上。新的 MemIAVL 结构有助于减少写入放大因子，因为它减少了维护数据结构所需的元数据。

更新后的 SeiDB 允许对状态存储层提供灵活的数据库后端支持。Sei 认为，不同的节点运营商的需求和存储需求不同。因此，SS 设计是为了适应不同的后端需求，为运营商提供自由度和灵活性，如 PebbleDB、RocksDB、SQLite 等。

（3）Monad 状态访问：MonadDB

Monad 的状态访问有一些重要的细微差别。首先，大多数以太坊客户端利用两种类型的数据库：B-Tree 数据库（即 LMDB）或日志结构合并树（LSM）数据库（即 RocksDB、LevelDB）。这两种都是通用的数据结构，不是为区块链专门设计的。此外，这些数据库没有利用 Linux 技术的最新进展，特别是在异步操作和 I/O 优化方面。最后，以太坊本身使用 MPT 树管理状态，MPT 树专用于加密，验证和证明。主要的问题是，客户端必须将这个特定的 MPT 树集成到更通用的数据库（即 B-Tree / LSM）中，这会带来严重的性能缺陷，例如过多的磁盘访问。

所有这些都有助于为 Monad 决定创建自定义 MonadDB 数据库奠定基础，MonadDB 数据库专用于更高效地处理区块链数据和状态访问。MonadDB 的一些关键特性包括并行访问数据库、针对 Merkle Trie 数据优化的自定义数据库、优于标准 RAM 使用的高效状态访问、去中心化特性和可扩展性。

MonadDB 专为区块链设计，使其比使用通用数据库的性能更高。自定义 MonadDB 专用于高效管理 Merkle Trie 类型数据，支持同时并行访问多个 Trie 节点。虽然 MonadDB 与上述一些通用数据库的单次读取成本是相同的，但 MonadDB 的关键特性是它可以并行运行多个读取，从而带来巨大提速。

MonadDB 支持对并行访问数据库的同步状态访问。因为 Monad 是从头开始构建这个数据库的，所以它能够利用最新的 Linux 内核技术和 SSD 的全部功能来实现异步 I/O。使用异步 I/O，如果一个交易需要从磁盘读取状态，这不应该为待完成操作带来阻力。相反，它应该立刻开始读取并同时继续处理其他交易。这就是异步 I/O 显著加快 MonadDB 处理速度的做法。Monad 能够通过优化 SSD 使用以及减少对过多 RAM 的依赖，收获更好的硬件性能。这具有与去中心化和可扩展性对齐的额外好处。

5、结论

总之，通过 Solana、Sei 和 Monad 的视角探索区块链中的并行化发展，可以全面了解不同架构和方法是如何提高性能和可扩展性的。Solana 的确定性并行注重预先声明状态访问，提供了可预测性和效率，使其成为高吞吐量需求的应用程序的有力选择。另一方面，Sei 的乐观并行方法优先考虑了开发人员的灵活性，非常适合交易冲突不频繁的环境。凭借其独特的乐观并行方式和自定义 MonadDB，Monad 提供了一个创新解决方案，利用最新的技术进步来优化状态访问和性能。

每个区块链都提供了一种独特的方法来解决并行化挑战，并有一套自己的利弊权衡。Solana 的设计旨在最大限度提高硬件利用率和吞吐量，而 Sei 则专注于简化开发过程，Monad 则把重心放在了为区块链数据提供量身定制的数据库解决方案。这些差异凸显了区块链生态系统的多样性，以及根据应用程序的特定需求选择合适平台的重要性。

随着区块链领域的不断发展，Solana、Monad 和 Sei 所展现出的并行化技术的进步无疑将激发进一步的创新。迈向更高效、更可扩展且对开发人员更加友好的区块链的旅程正在进行中，从这些平台中吸取的经验将对塑造区块链技术的未来发挥至关重要的作用。