高性能 RPC

在追求高性能区块链的过程中，仅仅优化共识或区块生产是不够的。RPC 层是端到端用户体验的关键组成部分，因为它是区块链与其用户之间的接口。Stable 提出了一种新的 RPC 专用架构，以克服传统 RPC 设计的局限性。

为什么高性能 RPC 很重要

用户通向区块链的网关

远程过程调用 (RPC) 接口是用户与区块链交互的主要方式：

• 钱包使用 RPC 广播交易。
• dApp 通过 RPC 查询状态，以使用链上数据渲染 UI、准备和模拟交易、获取日志和事件等。
• 浏览器、索引器和机器人全部依赖 RPC 获取实时数据。

即使区块链能够以闪电般的速度处理交易并快速生成区块，如果用户由于 RPC 速度慢而遇到延迟和卡顿，这一切都将毫无意义。实际上，RPC 往往是整体用户体验中的瓶颈。

Stable 的高性能链路线图明确将 RPC 优化 作为一个首要任务。

传统 RPC 架构的问题

单体设计和资源争用

传统上，RPC 节点只是一个经过改造的全节点，暴露了额外的 RPC 端点。这意味着：

• 链同步和处理 RPC 请求发生在同一个实例上。
• 为了扩展 RPC，团队必须启动全新的全节点，从而触发耗费资源的操作，例如状态同步和共识设置。
• 共识、执行和 RPC 都共享相同的 CPU、内存和磁盘。在交易负载较高期间，繁忙的组件会饿死其他组件，从而降低 RPC 性能。

此外，传统 RPC 架构对读密集型和写密集型操作的处理方式相同。尽管读查询（例如 eth_getBalance）在数量上远远超过写事务，但它们在处理方式上没有区别。这种设计本质上是低效且不可扩展的。

Stable RPC 架构

Stable 引入了一种分路 RPC 架构，将读写操作分离并独立优化。

核心原则

• 根据功能将 RPC 分离为高效的轻量级 RPC 节点。
• 使用轻量级 RPC 作为边缘节点，以增强可扩展性。
• 优化特定功能 RPC 的数据路径，以减少延迟，提供更直接的访问或通过更高效的数据结构进行管理。

性能提升

新读 RPC 路径的内部基准测试表明：

• 在相同环境下，支持超过 10,000 RPS 的吞吐量，端到端延迟低于 100 毫秒。
• 边缘节点线性可扩展，无需全状态同步或共识开销。

Stable 的新 RPC 架构即使在高流量事件期间也能带来显着更流畅、更快的用户体验。

未来工作

优化 EVM 视图调用

一项令人兴奋的持续研究领域是专门支持 EVM 视图操作 (eth_call)：

• 这些操作不需要事务提交或状态更新。
• 执行可以在轻量级无状态环境中进行，仅使用当前状态快照。
• 可以专门为这些操作设计一个专门的 RPC 节点，从而提供更快的响应时间并减轻主全节点的负载。

将索引器直接集成到节点中

通过将索引器直接集成到节点中，可以向 dApp 提供最快的数据。

• 典型架构：节点 → RPC → 索引器（例如 The Graph）→ 存储 → dApp
• 建议架构：带有索引器的节点 → 数据库 → dApp
• 这种架构可以实现更快的数据传输，因为索引器原生集成到节点中，从而消除了网络通信步骤。

下一步建议

• JSON-RPC API：使用 Stable 暴露的 eth_* 方法进行合约读取、事务提交和日志过滤。
• 执行：了解执行如何向 RPC 层提供状态。
• 存储 (StableDB)：查看 RPC 读取查询的存储层。