作者：Steve 来源：4pillars 翻译：善欧巴，金色财经

要点

• “并行执行”是过去一年区块链行业的关键词之一。然而，要真正实现并行执行，还需要各个领域的创新，其中最关键的是区块链数据库的完善。

• EVM并行处理的先驱之一Sei已经意识到了这种必要性，并从去年开始就不断考虑数据库优化。这些努力的成果就是 Sei DB。

• Sei DB将传统的单一数据库结构转变为分为两层的模块化结构。它消除了不必要的元数据并优化了状态访问，从而消除了数据库级别的低效率并提高了区块链的整体性能。Sei 的方法不仅对于追求事务并行性的区块链来说是一个很好的例子，而且对于旨在提高整体区块链效率的构建者来说也是如此。

2023年和2024年区块链市场周期升温的关键词不少，Meme币、Farcaster、restake等都在其中。然而，我发现技术上最有趣的关键词是“事务并行执行”。虽然市场对 EVM 并行处理很熟悉，但我认为通过并行化交易从根本上提高区块链性能比 EVM 本身更重要。

说到“交易并行执行”，你可能会想到各种链，但我第一个想到的就是Sei区块链。他们并不是第一个引入事务并行处理概念的人，但他们在市场上普及这个关键词方面发挥了重要作用。截至撰写本文时，Sei Network 已成为第一个能够进行 EVM 并行处理的 Layer 1 区块链。这是因为他们已经通过了一项支持 EVM 并行处理的治理提案。

Sei V2治理提案的通过意义重大，因为它表明以前被认为难以实施的事务并行处理已经达到了实用阶段。为什么事务并行处理的应用如此困难？我的调查揭示了几个原因。首先，影响同一状态的交易之间很可能发生冲突（例如更改相同帐户余额的交易）。确定交易顺序时，复杂性也会增加。最重要的是，即使事务在执行层并行化，如果没有数据库级别的优化，也很难实现可扩展性的显着提升。这些问题使得事务并行处理的实施变得尤为困难。

Sei的联合创始人兼CTO Jayendra一直通过各种媒体渠道指出这个问题（数据库级优化）。如果 EVM 并行处理或一般的事务并行处理仅被视为区块链“执行”级别的优化，则无法实现显着的可扩展性改进。因此，要讨论通过并行处理提高性能，必须解决如何实现数据库级优化。

今天我想谈谈Sei区块链是如何优化其数据库的。请注意，数据库优化不仅仅是支持并行处理的区块链的问题；对于支持并行处理的区块链来说，数据库优化也是一个问题。这是所有需要处理大量交易的高性能区块链所面临的挑战。通过这篇文章，我希望读者能够更深入地了解 Sei V2，也希望那些设计高性能区块链的人能够获得在高性能区块链中设计数据库的宝贵见解。

1. 区块链存储的问题：状态膨胀

1.1 区块链中的状态是什么？

在讨论存储问题之前，我们需要先定义一下状态的含义。区块链背景下的状态是什么？状态是指区块链内所有账户的信息，包括账户本身、账户余额和合约代码的详细信息。因此，当区块链上发生交易时，它不可避免地会影响特定的状态。例如，如果A将Sei代币转移给B，则A和B的余额都需要更新。这就是国家改变的意义。当状态发生变化时，会产生什么影响？通常，我们不认为状态只是通过改变而增加，但即使是仅仅改变状态的交易也会在区块链的历史中留下交易记录（这种类型的数据称为历史状态））。因此，可以说即使是状态改变的交易也会稍微增加状态大小。换句话说，所有链上交易都有助于国家的增长。

1.2 快速区块链中的状态增长问题

正如我之前解释的，链上交易有助于状态增长。对于像 Sei 这样的快速区块链来说，它在给定时间内处理更多交易，与其他区块链相比，状态的增长速度会更快。如果我们进一步添加对事务并行执行的支持，状态将会增长得更快，从而导致几个问题：

1. 增加节点运行成本：全节点必须存储整个区块链状态，这增加了存储成本并使该区块链上的节点操作变得困难。这可能会导致中心化，因为运行全节点的进入门槛变得更高。

2. 区块链性能下降：较大的状态意味着节点需要更多的时间来处理和验证交易。每当发生改变区块链状态的事务时，节点都需要读取并更新相关的状态值。随着状态的增长，有更多的数据需要访问，更多的状态值需要更改。这最终会导致区块链性能变慢。

3. 节点同步问题：区块链从根本上涉及多个节点共享账本并不断相互同步有效账本。如果状态变得太大，新节点的加入就会变得非常困难。新节点必须下载链的整个账本才能参与主网。链在特定点拍摄整个记录的“快照”，新节点使用这些快照进行同步。但是，如果链太大，则拍摄快照需要很长时间，并且在此期间，区块链不断添加新的交易和数据。这种差异可能会使新节点的同步变得困难。同步落后的节点还将面临大量的时间和成本来追赶，从而导致性能问题并使新节点更难加入，从而可能导致中心化问题。

区块链中状态变得太大的问题称为状态膨胀。如果在没有数据库改进的情况下实现事务并行执行，状态将进一步膨胀，导致上述各种问题。这些问题最终阻碍了事务并行执行所带来的好处的实现。Sei 从一开始就意识到了这个问题，这种认识的结果就是 Sei DB。那么，Sei DB在设计上注重了什么，对数据库的改进有多大呢？

2. 介绍Sei DB，最快的区块链最快的数据库

Sei V1 采用了基于不可变 Adelson-Velsky 和 Landis (IAVL) 树数据结构的普通数据库结构，Cosmos SDK 使用该结构来存储状态。在以太坊中，类似的概念是 Merkle Patricia Trie (MPT)。然而，这种结构在几个方面被证明是低效的：1) 它需要在每个节点上存储大量的元数据，2) 维持树内的平衡需要多次磁盘访问，减慢内存访问，3) 它通常会导致存储更多的元数据。数据超出预期。为了解决这些低效率问题，Sei 推出了 Sei DB，这是一种模块化数据库架构，将存储分为两层。

为什么要把数据库分成两层？因为国家本身分为历史状态和活跃状态。为了更好地理解 Sei DB，有必要定义这两种类型的状态：

1. 历史状态

历史状态是指区块链最新区块高度之前记录的所有状态。换句话说，它包含了区块链的所有过去记录，不包括当前处理的块。例如，用户过去的所有余额记录都属于历史状态。

1. 活动状态

活动状态涉及与最新区块高度相关的信息。简单来说，它包括区块链上记录的最新信息，例如用户当前的余额。

即使从这些定义来看，很明显历史状态和活动状态包含明显不同的信息，历史状态比活动状态重得多。Sei 旨在通过不同地处理这两种类型的状态来优化数据库。

Sei DB 分为 1）状态承诺层（SC 层）和 2）状态存储层（SS 层）。让我们研究一下这些层的角色以及它们如何交互。

2.1 状态承诺层（SC层）

状态承诺层管理 Sei 区块链的活动状态。SC 层最关键的组件是内存映射 IAVL 树 (MemIAVL)，它是 Cosmos SDK 中使用的 IAVL 树的修改版本。由于前面提到的效率低下而进行的修改优化了状态访问。但为什么 MemIAVL 对于状态访问如此有效？为了理解这一点，我们需要深入研究 Sei 使用的内存映射的概念。

通常，在处理文件时，使用文件描述符或文件结构指针来访问它们，这需要通过缓冲区进行输入和输出操作。内存映射（mmap()）通过将文件映射到进程的虚拟地址空间来解决这个问题，允许在不使用读取或写入函数的情况下读取或写入数据。

据 Sei 介绍，MemIAVL 可以在数百纳秒内实现状态访问，与传统树结构相比，写入速度快 10~287 倍，读取速度快 10 倍。

（上图重点关注状态写入（提交）而不是状态读取。这一结果表明，通过 SeiDB 和异步提交的结合实现了显着的性能改进。）

为了便于理解，我们概述一下使用 MemIAVL 实现记录在区块链上的交易的整个生命周期：

1. 事务发生，从 MemIAVL 读取状态，事务执行将导致状态更改（也称为更改集）

2. 变更集首先应用于 MemIAVL 树，然后可以重新计算新的根哈希。

3. 新计算的状态根值包含在块头中，标记交易已成功记录在区块链上。

4. 在不同的goroutine中，这些变更集会异步持久化到一个WAL文件中，可以用于恢复（如果需要恢复某个节点，则可以使用最近的快照以及WAL中存储的信息进行恢复） .)。

这些变化从根本上减少了 CPU 和内存的使用，使 Sei 能够构建异常快速的区块链，而无需高硬件规格。

2.2 状态存储层（SS层）

状态提交层管理最关键的活动状态，而状态存储层处理活动状态之前的所有记录，也称为历史状态。Sei V2 的状态存储层由三个关键组件组成，我们将详细研究它们：

2.2.1 原始键值存储

任何熟悉区块链的人都会遇到键值对的概念。该数据存储结构使用键作为唯一标识符，使用值作为关联数据。例如，在区块链的背景下，账户余额或合约状态由键表示，而相应的数据（例如账户中的代币数量）是值。

虽然键值存储结构在其他区块链和数据库中很常见，但 Sei 通过最小化元数据存储来优化这一点，从而减少存储的数据量。此外，由于键直接映射到值，不需要额外的抽象层，因此数据访问速度更快，从而提高了区块链的整体效率。

2.2.2 灵活的数据库后端

数据库结构的效率与其对各种存储后端的支持同样重要。要求节点运营商使用单个存储后端可能会受到限制，因为这会阻止他们优化后端以满足其特定需求。Sei V2 支持 PebbleDB、RocksDB 和 SQLite，允许节点选择最适合其需求的数据库。下表比较了这三个数据库的特点：

Sei V2 支持的数据库的特征与 Sei 对性能的关注一致。这些数据库中的每一个都经过优化，可以有效地处理大规模数据，同时最大限度地减少写入放大（即降低数据写入磁盘的频率）。

Sei 表示，PebbleDB 在受支持的数据库中表现出最佳性能。然而，值得注意的是，这些数据库都有自己的优点和缺点。详细的优缺点对比可以参考Sei团队提供的对比图。

2.2.3 异步剪枝

最后要讨论的组件是异步修剪。在区块链的背景下，修剪是指从区块链中删除不必要或过时的数据的过程。传统上，修剪操作会对网络性能产生负面影响。然而，Sei 异步执行修剪操作，这意味着这些任务在后台执行，不会影响主要的区块链操作。这种方法允许 Sei 优化历史状态数据并减少节点的存储需求，而不会影响区块链的性能。

综上所述，Sei V2 的创新数据库管理方法，包括原始键值存储、灵活的数据库后端支持和异步剪枝，确保有效处理活动和历史状态数据，从而提高区块链的整体性能和可扩展性。

3. Sei DB的实施结果

我们现在已经探索了 SeiDB 的两层（状态提交层和状态存储层），并研究了每一层的角色和功能。通过这个解释，我们了解到SeiDB理论上是通过数据库改进来增强Sei区块链的性能并对其进行优化。然而，最关键的还是实际结果。Sei团队在测试网环境中实现SeiDB时，获得了以下数据：

1.减少活动状态大小

测量了内存中存储的活动状态的大小，结果显示活动状态大小减少了60% 。

2.历史数据增长率减少

对历史状态大小的增长速度进行了评估，发现与之前的数据库相比慢了90%以上。

3.状态同步时间减少

测量了节点同步状态所需的时间，结果显示速度提高了约1,200% 。

4.块同步时间减少

测量了从快照点同步块到最新块高度所需的时间，显示速度比之前的数据库提高了2 倍。

5.块提交时间减少

测量了将块提交到区块链所需的时间，结果表明与之前的数据库相比，速度提高了287 倍。

6.TPS（每秒事务数）

测量了处理事务所需的时间，结果显示与之前的数据库相比，速度提高了2 倍以上。

基于这些指标，预计 Sei v2 通过 SeiDB 的实施将表现出显着的性能改进。尽管被 EVM 兼容性的主要叙述所掩盖，但 Sei 的长期重大改进很可能在于数据库级别发生的变化。

4. 展望未来：超越叙述，做出实际贡献

Sei v2 时代已经到来。在叙事至关重要的市场中，提到 Sei v2 通常会让人想起“EVM 并行处理”。然而，仔细研究 v2 升级带来的变化就会发现，技术密集型转变远远超出了 EVM 支持和并行处理改进的范围。虽然我之前提到的性能指标只是 v2 主网发布之前的测试结果，但实际影响仍有待观察。尽管如此，这些努力值得持续关注，因为 Sei v2 的实际性能可以激励其他 Layer 1 区块链对自己的数据库进行基准测试和增强，从而为“区块链性能改进”这一更广泛的目标做出重大贡献。

从一开始，Sei 就一直追求成为“快速区块链”的单一目标，并进行广泛的研究来实现这一目标。作为一名研究人员，我赞扬他们对实施快速区块链的不懈奉献。此外，我希望他们的研究能够继续发展，带来更好的数据库创新，这些创新可能来自 Sei 团队本身。这些努力共同将使我们能够构建卓越的区块链，最终使区块链技术更容易被更广泛的受众所使用。