概述
ERPC 是面向 Solana 应用的 RPC 基础设施，最近在 Solana RPC 端点中集成了与 Pyth Hermes 兼容的 Price API。本文从架构角度解析该集成的实现方式，以及在 Solana 应用开发中如何把链上数据与市场价格数据整合到同一个数据获取路径上。
集成后，开发者可以通过同一个 ERPC API key、同一套使用量计量、同一个仪表板，访问 JSON-RPC、DAS、WebSocket 以及价格数据接口。价格数据涵盖加密资产、股票、外汇、金属、利率、大宗商品等多种资产类别。
为什么把价格数据放进 RPC 层
在 Solana 应用中，仅依赖链上状态往往无法满足真实的产品需求。交易界面需要展示价格、钱包需要计算持仓估值、DeFi 协议需要价格来评估抵押和清算条件、分析平台需要把链上事件和市场价格关联起来。AI agent 和机器人则需要同时处理链上状态与外部市场状态。
传统做法是把价格数据当作独立的外部依赖，单独申请 API key、单独管理计费、单独配置监控。这种拆分在工程上是可行的，但增加了运行时的协调成本：两个不同的数据源各自有自己的可用性、限流、版本演进。
将价格数据放在与 RPC 同一层级，意味着应用在开发期就可以用统一的认证、统一的请求语义来获取链上状态与市场价格，减少在生产中协调多套基础设施的负担。
架构：Pythnet、Wormhole Network 与 Hermes
Pyth 是一个由数据提供方共同推送报价的市场数据网络。Pythnet 负责聚合数据提供方提交的报价，Wormhole Network 作为消息传递通道，把 Pythnet 上生成的价格更新带到其他链或应用环境。
Hermes 是 Pyth 给开发者提供的接入层：它持续从 Pythnet 和 Wormhole Network 拉取价格更新，并以 REST API 或 server-side streaming 的方式对外暴露。对于希望以 Web API 形式获取价格的应用来说，Hermes 是最自然的接入点。
ERPC 的 Price API 与 Pyth Hermes 兼容，意味着请求格式可以复用 Hermes 体系下已有的工具与示例。在实现上，ERPC 内部组合了三类组件来支撑这条路径：
- Pythnet node：直接接入 Pythnet 网络，获取最新的价格聚合状态。
- Hermes client：负责把 Pythnet 状态转换为 Hermes 风格的查询接口。
- Wormhole Spy：观察 Wormhole Guardian Network 上的消息流，daemon 化地把 Wormhole 网络上的更新带进可观察的本地路径。
这三类组件协同工作，使 Pyth 体系的价格数据可以在 ERPC 的 Solana RPC 平台中以稳定形式被访问。
数据范围：3,059+ Price Feeds
Pyth 官方公开的 price feeds 已经覆盖 3,059+ 条，涵盖以下资产类别：
- 加密资产（crypto）
- 股票（equities）
- 外汇（FX）
- 金属（metals）
- 利率（rates）
- 大宗商品与期货（commodities / futures）
对于 Solana 应用而言，这意味着可访问的数据范围不再局限于加密资产价格。把外汇、股票、金属、利率纳入同一套接入路径，可以支撑更广泛的金融类应用，例如多资产投资组合视图、合成资产、跨资产风险评估等场景。
价格数据使用中的关键字段
直接读取 price 数值是不够的。Pyth 的 price update 同时提供以下字段，应用层需要在设计阶段处理它们：
- price：当前价格
- confidence：置信区间，反映市场流动性、波动率、交易时段、数据状态
- expo：价格的指数缩放，需要与 price 配合还原为实际数值
- publish time：价格更新的时间戳，用于判断数据新鲜度
confidence 在交易、清算、抵押评估、报警等场景下尤其重要。市场流动性差或波动剧烈时，confidence 会扩大，应用应当在自己的风险策略中定义可接受的范围。
publish time 与资产类别强相关：加密资产 7×24 小时交易，价格更新可以保持较高频率；股票、金属、利率、大宗商品、外汇分别有自己的市场时段、节假日和维护窗口。直接套用同一份 staleness 阈值会忽略这些差异，因此应用应当按资产类别配置不同的新鲜度策略。
与 Solana RPC、DAS、WebSocket 在同一条路径上
ERPC 在 Solana 端提供的能力不仅是单一 JSON-RPC：
- Solana RPC：HTTP JSON-RPC 接口
- WebSocket：实时订阅
- DAS（Digital Asset Standard）：资产元数据查询
- Geyser gRPC / Shredstream：低延迟事件流
- VPS、裸金属服务器：靠近网络拓扑的部署形态
把 Price API 放在同一条接入路径上，应用可以在同一个 API key 与计费体系下，组合「链上事件 + 实时订阅 + 价格更新」三类数据。常见的组合方式包括：
- 钱包与投资组合：用 RPC 读取持仓、用 DAS 拉取资产元数据、用 Price API 计算估值。
- DeFi 与交易应用：链上状态决定可执行的合约调用，价格数据决定风险与清算阈值。
- 分析与监控：链上事件需要与市场上下文关联，价格更新可以作为事件的解释维度。
- AI agent / 自动化系统：链上状态与市场状态需要同时纳入决策上下文。
在 Dashboard 中验证调用
ERPC Dashboard 提供 Price API 的调用入口，可以从同一个开发流程中验证 price feed 查询与最新价格获取。这种「同一界面下能完成 RPC 与价格数据调试」的设计，缩短了 Solana 应用开发中的环境切换成本。
对于已经在使用 ERPC Solana RPC 的开发者，这意味着不需要新增独立的市场数据服务即可开始 Price API 的接入测试。
实现层面的若干设计要点
从应用工程角度，建议在接入 Price API 时关注以下设计点：
- price + expo 的还原必须放在最早的解析层，避免把未还原的整数当作真实价格传给业务逻辑。
- confidence 阈值应当与资产类别、业务场景绑定，而不是统一硬编码。
- publish time 检查需要在业务层执行，结合本地时间源与市场时段，定义资产级别的 staleness。
- 价格读取的失败处理应分两类：网络/接口失败 vs. 数据本身过期或 confidence 过宽，二者的恢复策略不同。
- 对实时性敏感的场景（清算、做市、套利），建议结合 Geyser gRPC / Shredstream 与 Price API，把链上事件与价格更新作为同一时序的数据来处理。
总结
ERPC 在 Solana RPC 端集成 Pyth Hermes 兼容的 Price API，本质上是把价格数据从「独立外部依赖」变成「与 RPC 同层级的数据通道」。对开发者而言，这种集成把链上数据与市场数据放在同一套接入语义下，使得钱包、DeFi、分析平台、AI agent 等应用可以在更短的开发路径上把市场上下文纳入产品逻辑。
在使用 Price API 时，建议按资产类别处理 confidence 与 publish time，把 price/expo 的还原放在解析层最早完成，并结合 Solana 的实时数据通道（WebSocket、Geyser gRPC）构建对实时性敏感的应用逻辑。