Sei DB：数据库优化为何对区块链可扩展性至关重要

主要内容

• “并行执行”已成为过去一年区块链行业中的关键流行语之一。然而，要正确实施并行执行，需要在各个领域进行创新，其中最关键的是改进区块链数据库。

• 作为 EVM 并行处理的先驱之一，Sei 已经意识到这种必要性，并且自去年以来一直在考虑数据库优化。这些努力的结果就是 Sei DB。

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

2023 年和 2024 年，有很多关键词炒热了区块链市场周期。模因币、Farcaster 和 restaking 就是其中之一。然而，我发现技术上最有趣的关键词是“交易并行执行”。虽然市场对 EVM 并行处理很熟悉，但我认为通过并行化交易从根本上提高区块链性能比 EVM 本身更重要。

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

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

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

今天，我想谈谈 Sei 区块链是如何优化其数据库的。请注意，数据库优化不仅仅是支持并行处理的区块链的问题；所有需要处理大量交易的高性能区块链都面临着这一挑战。通过本文，我希望读者能更深入地了解 Sei V2，并且那些设计高性能区块链的人能够获得有价值的见解，从而为高性能区块链设计数据库。

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

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

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

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

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

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

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

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

区块链中状态变得太大的问题称为状态膨胀。如果在没有改进数据库的情况下实现交易并行执行，状态将会进一步膨胀，从而导致上述的各种问题。这些问题最终会阻止从交易并行执行中寻求的益处得以实现。Sei 从一开始就认识到了这个问题，而这种认识的结果就是 Sei DB。那么，Sei DB 在其设计中关注了什么，并且它在多大程度上改进了数据库？

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

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

为什么要将数据库分为两层？因为状态本身被分为历史状态和活跃状态。为了更好地理解 Sei DB，定义这两种类型的状态至关重要：

1. 历史状态

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

2. 活跃状态

活跃状态是指与最新区块高度相关的信息。简而言之，它包括区块链上记录的最新信息，例如用户的当前余额。

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

Sei DB 分为 1) 状态承诺层 (SC Layer) 和 2) 状态存储层 (SS Layer)。让我们来研究一下这些层的作用以及它们是如何交互的。

2.1 状态承诺层 (SC Layer)

状态承诺层管理 Sei 区块链的活跃状态。SC 层的最关键组件是 Memory-Mapped 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 Layer)

虽然状态提交层管理着最关键的活跃状态，但状态存储层处理着活跃状态之前的所有记录，也被称为历史状态。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 团队本身。这些共同努力将使我们能够构建卓越的区块链，最终使区块链技术更容易被更广泛的受众所接受。

感谢Kate为本文设计图形。

• 原文链接： 4pillars.io/en/articles/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～