探索并行区块链的设计空间

作者：Ali Sheikh，加密分析师；翻译：金色财经xiaozou

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

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

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

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

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

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

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

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

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

从高层来看，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被有意设计为支持并行化。

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

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

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

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

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使用一种确定性算法来处理这种情况，以确保其中的一个不会跑得太远而失控。

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

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生态系统的效率、去中心化程度和网络弹性。

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

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

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

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的依赖，收获更好的硬件性能。这具有与去中心化和可扩展性对齐的额外好处。

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

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

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