> ## Documentation Index
> Fetch the complete documentation index at: https://stablelabs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# StableDB
> 通过解耦状态提交、MemDB 和 mmap 消除磁盘 I/O 瓶颈的 StableDB 架构。
区块链端到端性能的主要瓶颈之一是 **磁盘 I/O（Disk I/O）**。尤其是在区块执行后提交和存储状态数据的操作，是性能的关键瓶颈。Stable 通过架构创新，使用如 `MemDB`、`VersionDB` 以及文件内存映射存储（`mmap`），显著提升系统吞吐量。
## 为什么磁盘 I/O 是性能瓶颈
### 状态转换与持久化
每当执行一批交易并产出区块时，区块链系统都会从一个状态转变为下一个状态。这个过程分为两个基本阶段：
1. **状态提交（State Commitment）**：在交易执行完成后，提交新的状态。
2. **状态存储（State Storage）**：已提交的状态被持久化到磁盘，用于长期访问和历史验证。
在传统架构中，状态存储与状态提交是**紧密耦合**的，这意味着：
* 节点在继续执行下一个区块之前，必须等待新状态完全写入磁盘。
* 状态数据被写入磁盘中随机的位置，这导致在后续交易执行中读取状态时出现高延迟。
即使共识层和执行层做了大量优化，这种对低效的串行磁盘操作的依赖仍然限制了整个系统的性能上限。
## 针对高吞吐量的数据库优化
为了解决这些限制，Stable 提出了两项核心架构优化：**解耦状态操作** 和 **引入内存映射数据库优化（mmap）**。
### 1. 拆解状态提交与存储
第一步是将状态提交与其存储过程拆解：
* 在提交新状态后，节点可以立即执行下一个区块。
* 状态的持久化操作在后台异步进行。
这种分离让执行可以得到立即的处理，绕过磁盘写入带来的延迟，从而消除阻塞依赖，大幅提升端到端性能。
### 2. 基于 `mmap` 的 `MemDB` 和 `VersionDB`
进一步通过 `mmap`（内存映射文件）实现双数据库模型：
* **MemDB（内存数据库）**：
* 存储近期频繁访问的活跃状态。
* 使用固定地址映射（通过 `mmap`），支持快速的数据查找。
* 适用于大多数以近期状态为目标的交易场景。
* **VersionDB（历史数据库）**：
* 存储更早期的历史状态。
* 优化用于归档和长周期查询，针对低频访问设计。
这种设计确保**热点数据通过内存驻留结构快速响应**，而冷数据则由较慢的持久化存储承担。通过结合 `mmap` 访问与状态智能分层，Stable 能够显著降低区块执行过程中的数据库读写延迟。
## 预期收益与已有实践
这种架构优化并非理论设想，已有 Sei 和 Cronos 等高性能区块链采用类似的解耦式内存映射数据库架构，实测可带来 \*\* 高达 2 倍的整体 TPS 性能提升\*\*。
Stable 也预期将获得类似的性能提升，因为该架构不再受限于存储层瓶颈，系统的共识与执行性能可以按需扩展，而不会被磁盘操作拖慢。
## 延伸阅读
如需深入了解相关技术与实现细节，请参阅：
* [ADR-065：Cosmos Store V2 架构](https://docs.cosmos.network/main/build/architecture/adr-065-store-v2)
* [MemIAVL：实用指南](https://hackmd.io/@yihuang/rkeCvy5xh)
* [Cronos MemIAVL 节点配置](https://docs.cronos.org/for-node-hosts/running-nodes/memiavl)
* [Sei 的数据库设计方案](https://4pillars.io/ko/articles/sei-db)