跳转到主要内容区块链端到端性能的主要瓶颈之一是 磁盘 I/O（Disk I/O）。尤其是在区块执行后提交和存储状态数据的操作，是性能的关键瓶颈。Stable 通过架构创新，使用如 MemDB、VersionDB 以及文件内存映射存储（mmap），显著提升系统吞吐量。
为什么磁盘 I/O 是性能瓶颈
状态转换与持久化
每当执行一批交易并产出区块时，区块链系统都会从一个状态转变为下一个状态。这个过程分为两个基本阶段：
- 状态提交（State Commitment）：在交易执行完成后，提交新的状态。
- 状态存储（State Storage）：已提交的状态被持久化到磁盘，用于长期访问和历史验证。
在传统架构中，状态存储与状态提交是紧密耦合的，这意味着：
- 节点在继续执行下一个区块之前，必须等待新状态完全写入磁盘。
- 状态数据被写入磁盘中随机的位置，这导致在后续交易执行中读取状态时出现高延迟。
即使共识层和执行层做了大量优化，这种对低效的串行磁盘操作的依赖仍然限制了整个系统的性能上限。
针对高吞吐量的数据库优化
为了解决这些限制，Stable 提出了两项核心架构优化：解耦状态操作 和 引入内存映射数据库优化（mmap）。
1. 拆解状态提交与存储
第一步是将状态提交与其存储过程拆解：
- 在提交新状态后，节点可以立即执行下一个区块。
- 状态的持久化操作在后台异步进行。
这种分离让执行可以得到立即的处理，绕过磁盘写入带来的延迟，从而消除阻塞依赖，大幅提升端到端性能。
2. 基于 mmap 的 MemDB 和 VersionDB
进一步通过 mmap（内存映射文件）实现双数据库模型：
- MemDB（内存数据库）：
- 存储近期频繁访问的活跃状态。
- 使用固定地址映射（通过
mmap），支持快速的数据查找。
- 适用于大多数以近期状态为目标的交易场景。
- VersionDB（历史数据库）：
- 存储更早期的历史状态。
- 优化用于归档和长周期查询，针对低频访问设计。
这种设计确保热点数据通过内存驻留结构快速响应，而冷数据则由较慢的持久化存储承担。通过结合 mmap 访问与状态智能分层，Stable 能够显著降低区块执行过程中的数据库读写延迟。
预期收益与已有实践
这种架构优化并非理论设想，已有 Sei 和 Cronos 等高性能区块链采用类似的解耦式内存映射数据库架构，实测可带来 ** 高达 2 倍的整体 TPS 性能提升**。
Stable 也预期将获得类似的性能提升，因为该架构不再受限于存储层瓶颈，系统的共识与执行性能可以按需扩展，而不会被磁盘操作拖慢。
延伸阅读
如需深入了解相关技术与实现细节，请参阅：
