在构建高性能区块链的过程中，仅仅优化共识机制或出块速度是不够的。RPC 层 是区块链与用户之间的接口，是实现端到端用户体验的关键组成部分。Stable 提出一种高性能 RPC 架构，旨在突破传统 RPC 的性能瓶颈。

​
为什么高性能 RPC 至关重要

​
用户连接区块链的入口

RPC 是用户与区块链交互的主要方式：
  • 钱包通过 RPC 广播交易；
  • DApps 借助 RPC 查询链上状态来渲染界面、准备交易、进行模拟、获取事件和日志等；
  • 区块浏览器、索引服务和交易机器人程序都依赖 RPC 实时获取数据。
即使底层区块链处理交易的速度极快、出块迅速，如果 RPC 响应缓慢、延迟高，用户的整体体验仍将受到影响。事实上，在现实使用中，RPC 常常成为链上体验的性能瓶颈。 因此，Stable 的高性能区块链路线图中将 优化RPC架构 明确作为优先任务。

​
传统 RPC 架构的弊端

​
单一的架构设计与资源争用

Traditional RPC Architecture 传统上，RPC 节点通常是功能扩展的全节点，它们同时负责：
  • 在同一时间处理区块链的同步与RPC请求；
  • 若要扩展 RPC 能力，只能新增完整节点，导致必须重复执行状态同步、共识配置等繁重流程；
  • 共识、执行与 RPC 服务共用同一 CPU、内存与磁盘资源。一旦某一部分高负载，将会拖慢其他模块的性能，例如在交易高峰期，RPC 延迟大幅上升。
此外，传统架构通常并不区分读取与写入请求的处理方式。即使读取请求（如 eth_getBalance）在调用量上远超写入交易，两者仍在同一逻辑结构中混合处理，造成系统整体效率低下、可扩展性差。

​
Stable 的 RPC 架构

Stable 提出了 路径分离（Split-Path）RPC 架构，将读取与写入操作分离，并分别进行独立优化。 Stable RPC Architecture

​
核心原则

  • 将 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；
  • 由于省略了额外的网络通信步骤，索引数据可被原生调用，大幅提升查询效率与实时性。