前言
在 Solana 应用的实际生产环境中，getTransaction 是最频繁被调用的 RPC 方法之一。无论是钱包展示用户交易历史、Explorer 与分析平台显示交易详情、indexing 系统进行 backfill 与对账，还是 backend API 进行错误调查与状态确认，getTransaction 的响应速度与稳定性都直接决定了应用整体的用户体验与运维效率。本文将从技术角度解析最近一次以 getTransaction 为核心的历史交易检索性能优化，重点关注最近 30 个 epoch 的数据获取能力。
一、为什么 getTransaction 是 Solana RPC 性能的关键路径
Solana 应用的工作流程通常包含实时数据接收、交易发送、结果确认、历史显示、分析与监控等多个阶段。getTransaction 在这其中扮演了"事后核对"的核心角色：
- 钱包：当用户打开钱包查看交易历史时，钱包客户端通常会针对每一笔签名调用 getTransaction，以呈现金额、对手方、状态与时间戳。
- Explorer / 分析基础设施：每一笔交易的详细字段（指令、账户列表、log、错误码）都需要通过 getTransaction 反序列化展示。
- Indexing pipeline：流式接收事件后，系统需要按需 re-fetch 完整交易内容以进行内容验证与内部数据库对账。
- Backend API / 监控：故障调查、用户支持、内部对账等都依赖 getTransaction 的响应延迟与稳定性。
因此，仅仅"实时层"快不足以支撑 Solana 应用的整体性能，接收之后的验证、补全、记录、展示、分析这条下游链路同样关键。getTransaction 的响应速度直接决定了下游链路的整体吞吐与延迟。
二、本次优化的核心：以 getTransaction 为中心的历史交易检索
ERPC 对 Solana RPC 的历史交易检索路径进行了系统性优化。在我们的内部对比环境中，getTransaction 相比更新前最高可实现约 6 倍提速。该改进已应用于所有区域以及所有 ERPC Solana RPC 方案，无需用户进行额外配置。
技术上，本次优化重点放在以下几方面：
- 数据存取层：针对最近 30 个 epoch 的数据建立更紧凑的索引结构，使按签名定位交易的常见路径在 IO 层面更接近"单跳"。
- 响应路径：缩短从 RPC 节点到数据存储之间的跳数，减少跨服务调用的累计延迟。
- 资源分配：在网络部署、服务器配置与数据分发上为 Solana 工作负载持续做面向场景的运维调优。
- 连续改进：本次更新不是一次性的功能添加，而是对既有方案与核心方法持续改善的一部分，目标是让同一套方案在真实生产负载中越来越实用。
三、为什么聚焦"最近 30 个 epoch"
Solana 的 epoch 长度会随网络状况变化，作为大致参考，最近 30 个 epoch 大约相当于近两个月的历史数据。从工程视角看，这一时间窗口正是大量生产应用最频繁触达的范围：
- 钱包展示的"近期交易"主要落在这个窗口内；
- Explorer 与分析服务最常被点开的"详情页"集中在最近几天到几周；
- Indexing 系统的 gap check、re-fetch、backfill、verification 等流程最频繁回扫的也是这一段；
- Backend API 与监控系统在故障调查、用户支持、内部对账时，绝大多数请求集中在最近几个 epoch。
因此，对最近 30 个 epoch 的检索性能进行强化，能以最小的工程成本覆盖最大比例的真实请求，避免把资源浪费在极少被查询的远古归档数据上。
四、对应用的实际影响
getTransaction 提速对多种 Solana 应用都有直接收益：
- Explorer 与钱包：用户想要查看的交易详情可以更快显示，UI 卡顿与等待时间降低。
- NFT、DeFi、游戏、支付、交易、DePIN、AI x Crypto 等领域的应用：需要确认链上实际发生的处理，并将结果反映到用户界面或内部状态中，getTransaction 的响应速度直接决定了"交易已成功"到"界面更新"的时延。
- Indexing 与分析基础设施：除实时收集事件外，还需要在必要时 re-fetch 交易详情、验证内容、与内部数据库对账。getTransaction 检索速度提高后，这类 backfill 与复查流程可以更高效地推进。
- 监控系统与 backend API：为了理解某个具体 signature 发生了什么、执行了哪些 instruction、涉及哪些 account、是否发生错误、处理是否符合预期，getTransaction 的响应速度与稳定性都是生产运营中的重要因素。
在 Solana 生产环境中，数据获取缓慢会直接形成运营摩擦：交易已经完成但详情获取仍然耗时、UI 反映延迟、内部流程等待确认、历史 backfill 花费过长时间等问题，会同时影响用户体验与运维效率。本次优化正是为了减少历史交易检索环节中的这类摩擦。
五、方法覆盖范围的持续扩展（包含 DAS 相关方法）
除了 getTransaction 性能改进之外，对应方法的支持范围也在持续扩展，包括 DAS（Digital Asset Standard）相关方法。Solana 应用的需求差异显著：标准的 Solana RPC 方法适用于一部分项目，而另一些项目则需要 NFT、压缩 NFT、资产信息、metadata、history、account state、token information 与各类 indexer 风格 API 的组合。对应方法支持的持续扩展，使更多类型的应用能够在同一基础设施上落地。
六、ERPC Solana 专用基础设施总览
ERPC 在同一平台上提供 Solana RPC、WebSocket、Solana Geyser gRPC、Solana Shredstream、VPS 与裸金属服务器。本次 getTransaction 提速是面向 Solana 的网络部署、服务器配置、数据分发与运维调优持续改进的一部分。后续会继续围绕方法覆盖、检索速度、到达稳定性、区域扩展与运维易用性进行迭代，让开发者能够更专注于 Solana 应用的开发与生产运营。
总结
- ERPC 对 Solana RPC getTransaction 为核心的历史交易检索路径进行了系统性优化，最高约 6 倍提速；
- 改进已应用于所有区域和所有 ERPC Solana RPC 方案，无需额外配置；
- 重点强化最近 30 个 epoch（约相当于两个月）的数据获取，覆盖钱包、Explorer、indexing、监控、backend API 中最频繁的请求范围；
- 对应方法覆盖范围继续扩展，包含 DAS 相关方法，覆盖 NFT、压缩 NFT、资产信息等更多场景；
- 整体目标是减少 Solana 生产环境中历史交易检索带来的运营摩擦，提升应用整体体验与运维效率。