> ## 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.

# 技术路线图

> 涵盖数据库、执行、共识及 USDT 专项性能优化的 Stable 分阶段技术路线图。

## Stable 针对稳定币的全栈优化路径

从用户提交交易到最终结果确认，交易生命周期要经历多个阶段：交易首先通过 RPC 广播，然后进入内存池（mempool），然后被打包进区块，经过共识验证、执行，最终将结果状态写入数据库。只有完成这些步骤，用户才能获得最终的交易结果。

这个过程中任何一个环节存在瓶颈，都会影响整体系统性能。Stable 致力于优化交易路径中的每一步，以最大化提升性能并减少延迟。

Stable 的核心技术将分阶段推出，每一阶段都旨在提升每秒交易数（TPS），同时不牺牲交易的终局性。计划中的优化包括状态数据库处理、执行层、共识机制以及 USDT 特定流程的优化。

下文将概述当前区块链架构中的常见性能瓶颈，以及 Stable 的优化方案。

<img className="block" src="https://mintcdn.com/stablelabs/J4B7HU7gv5jVOi-7/images/roadmap.png?fit=max&auto=format&n=J4B7HU7gv5jVOi-7&q=85&s=615880cb0f40ea26fb25cf1c38df5663" alt="技术路线图" width="1600" height="774" data-path="images/roadmap.png" />

## 第 1 阶段

### StableBFT

Stable 区块链最初将采用 StableBFT，这是一种基于 CometBFT 的定制化 PoS 协议，提供高吞吐、低延迟与强可靠性。该协议具备终局性，能容忍三分之一的节点故障。未来，Stable 将升级为基于 DAG 的共识机制，实现 5 倍的共识速度提升。

### USDT 作为原生 Gas

在 Stable 上，USDT0 作为其原生 Gas 代币。USDT0 同时作为用于支付 Gas 和进行价值转移的原生资产，并作为支持 `approve`、`transfer`、`transferFrom` 和 `permit` 的 ERC20 代币。

### Stable Pay与 Stable Name

Stable Pay使用直观设计和社交登录等功能，而已有用户则可直接连接现有钱包，无需迁移。Stable 钱包将提供网页版钱包和原生的手机钱包，保障用户在任何设备上都能安全访问数字资产。

与钱包配套的是 Stable Name：这是一套友好的别名系统，用于替代繁琐且容易出错的 EVM 地址格式，采用唯一且可读性强的标识符。用户只需通过 Stable Name 即可完成收发代币，免去管理十六进制字符串的烦恼。该系统大大减少了交易出错的几率，提升了与加密资产交互的整体体验，使 Stable 成为进入区块链生态的便捷入口。

## 第 2 阶段

### **并行执行**

60–80% 的交易之间并不冲突，可以安全地并行执行。但大多数区块链系统仍采用顺序执行，造成不必要的延迟。

Stable 将采用Optimistic并行执行模型以提高吞吐量。交易在假设无冲突的前提下并行执行，若检测到冲突，则将相关交易回滚并按顺序重新执行。此模型在确保正确性的同时带来显著的性能提升。

### **状态数据库优化**

区块链性能的主要瓶颈之一是磁盘 I/O 慢。在执行完区块后，状态需被提交（commit）和存储。传统模式中，验证节点需等待状态完全存储完毕后才能继续执行下一区块。

Stable 通过拆解状态提交与状态存储来优化该流程。验证节点可在内存中提交最新状态，从而继续下一轮区块执行，同时允许历史状态延迟写入磁盘。这显著降低了执行延迟。

此外，Stable 计划采用 `mmap`（内存映射文件）机制，将文件放置到内存中，加速存储性能。在内存中实时提交状态，同时将归档状态写入磁盘，大幅减少磁盘 I/O 延迟，并提升读写吞吐量。

### **USDT 转账聚合器**

为支持大规模 USDT0 转账，Stable 将实现转账聚合机制。USDT0 的转账交易将被批量打包处理，从而降低每笔交易的系统开销，提高整体吞吐量。

### **企业专用区块空间**

企业在使用区块链基础设施时，通常需要可预测的交易延迟，而在网络拥堵时，这种可预测性可能下降。

Stable 通过专用区块空间模型解决该问题，为企业客户保证固定比例的区块容量。该保障机制包括：

* 验证节点级定制：验证节点为企业客户预留空间。
* 专属 RPC 节点：企业交易通过独立的内存池和 API 接口优先处理。

该模式确保关键企业在不同网络条件下也能保持稳定性能。

## 第 3 阶段

### **基于 Autobahn 的高级共识（StableBFT）**

第一代基于 DAG 的 BFT 引擎（如 Narwhal 和 Tusk）表明，通过将数据传播与共识排序解耦拆解，可消除单个 proposer 的瓶颈。然而，直接将这类系统引入 CometBFT 环境会与高度依赖区块高度的开发习惯及传统内存池设计发生冲突。

Autobahn 提供了一种 PBFT-on-DAG 架构，更自然地与 Stable 的共识层集成。基于 Autobahn 构建的 StableBFT 将实现：

* 消除单领导者限制，支持并行交易处理；
* 通过分离数据传播与最终排序，加快交易确认速度；
* 通过强健的 BFT 机制提升对网络攻击的抵抗性。

根据内部测试结果，该共识协议已在可控环境下实现超过 200,000 TPS（仅共识层）的处理能力。

### **StableVM++**

StableVM++ 是高性能执行引擎，将用 C++ 实现替代当前基于 Go 的 EVM。此更替预计将带来最高 6 倍的执行速度提升，极大增强链上处理能力。

### **高性能 RPC**

高吞吐量的去中心化应用依赖于快速准确的 RPC 与索引服务。Stable 的高性能 RPC 架构将包括：

* **节点级优化**：实时链状态处理，提升 RPC 响应速度；
* **集成式索引器**：低延迟索引服务，在保证一致性的情况下提升应用层 API 效率 ；
* **强健的 Pub/Sub 系统**：可扩展的 WebSocket 架构，提供可靠的推送和事件通知机制；
* **混合负载均衡器**：基于操作类型智能分配流量，最大化利用资源并减少瓶颈。

这些优化将使 Stable 能为 dApp 和企业用户提供稳定且可扩展的访问接口。
