> ## 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.
# 高性能 RPC
> 读写分离的 Stable RPC 架构，实现高吞吐量与低延迟的链上数据访问。
在构建高性能区块链的过程中，仅仅优化共识机制或出块速度是不够的。**RPC 层** 是区块链与用户之间的接口，是实现端到端用户体验的关键组成部分。Stable 提出一种高性能 RPC 架构，旨在突破传统 RPC 的性能瓶颈。
## 为什么高性能 RPC 至关重要
### 用户连接区块链的入口
**RPC** 是用户与区块链交互的主要方式：
* 钱包通过 RPC 广播交易；
* DApps 借助 RPC 查询链上状态来渲染界面、准备交易、进行模拟、获取事件和日志等；
* 区块浏览器、索引服务和交易机器人程序都依赖 RPC 实时获取数据。
即使底层区块链处理交易的速度极快、出块迅速，如果 RPC 响应缓慢、延迟高，用户的整体体验仍将受到影响。事实上，在现实使用中，RPC 常常成为链上体验的性能瓶颈。
因此，Stable 的高性能区块链路线图中将 **优化RPC架构** 明确作为优先任务。
## 传统 RPC 架构的弊端
### 单一的架构设计与资源争用
传统上，RPC 节点通常是功能扩展的全节点，它们同时负责：
* 在同一时间处理区块链的同步与RPC请求；
* 若要扩展 RPC 能力，只能新增完整节点，导致必须重复执行状态同步、共识配置等繁重流程；
* 共识、执行与 RPC 服务共用同一 CPU、内存与磁盘资源。一旦某一部分高负载，**将会拖慢其他模块的性能**，例如在交易高峰期，RPC 延迟大幅上升。
此外，传统架构通常并不区分读取与写入请求的处理方式。即使读取请求（如 `eth_getBalance`）在调用量上远超写入交易，两者仍在同一逻辑结构中混合处理，造成系统整体效率低下、可扩展性差。
## Stable 的 RPC 架构
Stable 提出了 **路径分离（Split-Path）RPC 架构**，将读取与写入操作分离，并分别进行独立优化。
### 核心原则
* 将 RPC 按功能拆分为多个轻量高效的节点；
* 使用轻量级 RPC 边缘节点进行扩展，以提升系统可扩展性；
* 根据不同功能优化路径，通过更高效的数据结构来减少请求延迟，实现更直接的链上数据访问或管理。
### 性能提升
在读取路径下，Stable 的内部测试结果显示：
* 单节点吞吐量超 **10,000 次/秒（RPS）**；
* 同一环境下，端到端延迟 **低于 100ms**；
* 边缘节点支持线性扩展，**无需状态同步或共识负担**。
Stable 的新型 RPC 架构在高流量场景下仍可维持流畅、迅捷的用户交互体验。
## 未来工作方向
### 优化 EVM View 查询
一个备受关注的研究方向是：**为 `eth_call` 等 EVM 只读操作提供专有支持**：
* 此类调用不涉及状态更新或交易确认；
* 可在轻量、无状态的运行环境中执行，只需当前状态快照；
* 未来可设计专门针对 `eth_call` 的 RPC 节点，进一步降低响应时间，同时减轻主节点负担。
### 全节点原生集成 Indexer
通过将索引器（Indexer）原生集成至全节点，可以显著加快向 DApps 提供数据的速度：
* 当前架构：Node → RPC → Indexer（如 The Graph）→ 存储 → DApp；
* 提议架构：集成 Indexer 的 Node → 数据库 → DApp；
* 由于省略了额外的网络通信步骤，索引数据可被原生调用，大幅提升查询效率与实时性。