Solana RPC 主要用于获取当前状态和近期信息。然而在应用开发与分析基础设施的实际运营中，仅靠当前状态往往不够。开发者经常需要在事后获取已经发生的 transactions、地址级历史、token transfers、特定 program 的执行情况、各 slot 的 transaction 数、epoch 级活动量等。

启动新应用时，仅依赖「从现在开始能获取的数据」并不够，还需要「到目前为止已经发生的数据」。对钱包、Explorer、交易应用、分析基础设施、监控系统、bots 与 AI agents 而言，无法获取历史数据将无法掌握过去的使用情况、交易历史、token 流动以及作为异常检测前提的比较数据。

以往这种 backfilling 负担较重：要快速获取较旧的 archive 数据并整理为应用易用的形式，往往需要专用 indexer、archive node、独立数据库以及长时间的重新获取处理。本文介绍通过 self-hosted index 在 Solana RPC 层面提供历史数据获取与分析方法的实践。

通过 Jetstreamer 实现的 self-hosted index 集成

将 self-hosted index 集成到 Solana RPC 基础设施中之后，开发者不仅可以使用从现在开始的数据，还可以利用 indexes 中保留的历史数据进行 backfilling、重新获取、恢复与分析。可通过同一个 API key 与文档流程，处理历史 transactions、token transfers、program 统计、slot 统计、TPS 趋势与 epoch summary。

以下逐一介绍主要方法。

getTransactionsForAddress — 地址级历史 transactions 获取

getTransactionsForAddress 是用于获取与特定地址相关 transactions 的 Indexed RPC 方法。通过指定目标地址，并组合 slot、blockTime、signature、status 等条件，可以获取地址级的历史数据。

该方法支持两种获取模式：signatures 模式返回 signature、slot、transactionIndex、err、memo、blockTime、confirmationStatus 等 index row；full 模式在执行相同 index lookup 的基础上，对每个 transaction 组合详细信息获取，同时返回 transaction、meta 和 version。

response 中包含 paginationToken 用于获取下一页，还包含 windowStart 用于确认当前 index 中保留的最旧 slot。客户端可以在判断 endpoint 可获取范围的同时，设计历史数据获取流程。

应用场景：钱包、Explorer、监控系统、用户支持、交易历史确认、内部核对，以及新产品需要展示历史记录、补充现有 indexer、故障后重建特定地址历史等。

getTransfersByAddress — SPL Token v1 转账历史

getTransfersByAddress 是用于获取与特定 owner address 相关的 SPL Token v1 转账数据的 Indexed RPC 方法。通过组合 inbound、outbound、any 方向指定，以及 counterparty address、mint、amount、blockTime、slot 等条件，可以获取所需的 token transfers 历史。

每个 row 包含 signature、slot、blockTime、type、fromUserAccount、toUserAccount、fromTokenAccount、toTokenAccount、mint、amount、decimals、uiAmount、feeAmount、feeUiAmount、transactionIdx、instructionIdx、innerInstructionIdx 等字段。如果一个 transaction 包含多个 Token program call，每个 call 将作为独立的 row 处理。

solMode 可在 merged 模式与 separate 模式之间切换：merged 模式将 wSOL 与 native SOL 同等处理，适合钱包与资产组合展示；separate 模式将 wSOL mint 分离处理，适合分析用途中区分 SOL 与 wSOL 的流向。

应用场景：钱包、资产组合、交易历史、会计、监控、alerts、资金流动分析、bot 验证与用户支持。希望事后重建某段时期资产流动、补充 indexer 缺失期间的场景同样有效。

jetTopPrograms — program 调用排行

jetTopPrograms 以排行榜形式获取指定时间范围内调用次数较多的 programs。通过指定 since、until、includeVotes、limit，可以获取每个 program 的 invocations、errors 与 total_cus。

仅看 transaction 数无法得知哪些 programs 实际被频繁调用、消耗了多少 compute units、发生了多少 errors。通过 jetTopPrograms 可以高粒度地确认特定时期内 Solana 上的 program activity，可用于研究新的应用领域、发现备受关注的 programs、识别负载较大的 programs、与过去期间进行比较，以及把握整个网络的活动趋势。

jetProgramStats — program 级时序分析

jetProgramStats 是针对特定 program ID 按时间 bucket 获取 invocations、errors 与 total_cus 的方法。通过指定 programIdBase58、since、until、bucketSec，可以按时序确认目标 program 的使用情况。

适用于确认特定 program 的使用量增加、错误增加、compute units 消耗变化、事件发生前后的活动量、发布后的使用情况、异常调用激增等用途。以时序方式查看 program 级 activity，可以掌握仅靠单次汇总无法看到的变化。

适合交易应用、DeFi、游戏、DePIN、AI x Crypto、监控系统与分析 dashboards。

jetSlotStats — slot 级处理情况

jetSlotStats 针对单个 slot 或 slot range 获取 transaction_count、vote_transaction_count、non_vote_transaction_count、block_time。支持通过指定 slot 进行单 slot 获取，或通过 fromSlot 与 toSlot 进行范围获取。

在 Solana 分析中，重要的是按 slot 级确认处理了多少 transactions，其中包含多少 vote 与 non-vote。仅看 transaction 总数，无法区分源自应用的 activity 与 consensus 相关的 vote activity。

应用场景：故障调查、性能分析、各 slot 的 activity 分析、backfill 范围确认、数据缺失验证、监控系统的基础数据获取。

jetTpsTimeseries — TPS 趋势

jetTpsTimeseries 针对指定时间范围按 bucket 获取 total_tps 与 non_vote_tps。通过指定 from、to、bucketSec，可以按时序确认 Solana 的 transaction throughput。

TPS 仅以单一数值呈现时容易产生误导：它会随时段、网络负载、应用 activity、vote transaction 比例与拥堵情况而大幅波动。jetTpsTimeseries 可分别获取 total TPS 与 non-vote TPS，因此更容易现实地把握源自应用的 activity。

适合分析 dashboards、网络监控、研究用途、基础设施负载分析、应用 activity 比较、特定时期的流量验证。

jetEpochSummary — epoch 级汇总

jetEpochSummary 针对指定 epoch 获取 slots、non_vote_txs、vote_txs、total_txs、first_block_time、last_block_time、distinct_programs、program_invocations 等汇总信息。

epoch 级汇总对于以较大时间单位掌握 Solana 网络的活动量非常有效。可确认某个 epoch 在 index 中存在多少 slot、处理了多少 vote 与 non-vote transaction、调用了多少 programs。

适合研究、报告、网络分析、长期使用趋势确认、应用 activity 的时序比较、基础设施负载预测。jetEpochSummary 让大尺度分析可以在无需大量获取个别 transactions 的情况下开始。

index 保留范围与 windowStart

各 endpoint 能处理的历史数据范围取决于当前 index 中保留的范围。getTransactionsForAddress 与 getTransfersByAddress 会返回 windowStart，可确认当前 index 中保留的最旧 slot。

通过 windowStart 判断 endpoint 可获取的范围。在设计历史数据的 backfilling、重新获取、恢复处理时，重要的是组合目标时期、paginationToken、sortOrder、limit、filters 与 windowStart，按阶段获取所需范围。

实时数据与历史数据的组合

Solana 应用仅靠实时订阅是不够的。还需要 getTransaction 来事后确认实时检测到的事件、Indexed RPC 来补充历史期间、用于面向用户屏幕的历史数据、作为监控基准的 slot stats 与 TPS timeseries，以及 program activity 的分析。

在应用侧，根据用途组合 standard RPC、getTransaction、Indexed RPC、WebSocket、Geyser gRPC、Shredstream 进行设计非常重要。

总结

将 self-hosted index 集成到 Solana RPC 层之后，开发者可以通过同一个 API key 与文档流程，处理历史 transactions、token transfers、program 统计、slot 统计、TPS 趋势与 epoch summary。这降低了搭建专用 indexer 与 archive node 的初期负担，让 backfilling、故障恢复与分析基础设施搭建更加直接。