getTransactionsForAddress 与速度提升高达 10 倍的归档数据

在 Solana 上查询历史数据的挑战

Solana 的账本保存着链上发送过的每笔交易。这些历史数据包括自创世以来发生的每次铸造、转账、兑换和程序交互。

截至目前，Solana 已生成超过 3.75 亿个区块，从创世区块至今未经裁剪的完整交易历史规模达到数百 TB。 

对于如今几乎所有在 Solana 上构建产品的团队来说，快速可靠地访问这些数据都至关重要。Solana 的归档方法为各种功能提供支持，从你常用钱包的交易历史选项卡，到你常用的区块浏览器和投资组合仪表板。 

此前，开发者查询归档数据只有两种选择，而且都很麻烦： 

1. getBlock
2. getSignaturesForAddress 加 getTransaction

使用 getBlock 速度太慢

首先，开发者可能会尝试查询 getBlock 来回填数据。虽然可行，但这种方法耗时过长、成本高昂，还会占用大量资源：

1. 调用 getBlocks，查找 slot 范围内已确认的区块
2. 对每个区块调用 getBlock，获取完整的交易详情、签名或账户
3. 从区块中解析所有相关数据并将其存入数据库
4. 重复以上步骤，直至处理完所有区块

虽然 getBlock 方法很适合繁忙的程序（例如为 USDC 等热门代币或 Pump.fun 等 Solana 程序建立索引），但用它处理小型特定数据集并不实用。

循环调用 getSignaturesForAddress 和 getTransaction

结合使用 getSignaturesForAddress (gSFA) 和 getTransaction 是另一种常见的数据回填方式。

这种“N+1 循环”方法会反复获取交易签名，通常每次获取 1,000 个，然后发起批量 RPC 调用来获取每笔交易的详情。 

由于 RPC 请求数量巨大，开发者需要实现指数退避和重试逻辑，以免触发速率限制和遗漏数据。 

虽然使用 gSFA 和 getTransaction 比 getBlock 更灵活，但在大规模应用中仍然成本高昂、复杂且容易出错。

getTransactionForAddress 的优势

新的 getTransactionsForAddress RPC 方法将 getSignaturesForAddress 和 getTransaction 合并为一次调用，并提供强大功能，让索引构建和历史数据查询更轻松、更快速。

以下是主要功能：

1. 反向搜索

gSFA 等现有归档 RPC 方法要求开发者从最新交易开始，逐步向前回溯。

借助 getTransactionForAddress，开发者现在可以选择升序（即按时间顺序，最早的优先）或降序（即最新的优先）排列。 

结合基于时间的筛选条件，开发者可以使用 getTransactionForAddress，从任意时间点开始，以任意顺序查询 Solana 历史记录的任何部分。

例如，我们的新 Solana 区块浏览器 Orb 使用 getTransactionsForAddress RPC 方法实现“最早的优先”筛选功能：

如果要使用 getSignaturesForAddress 和 getTransaction 查询相同的数据，你需要：

1. 找出与第一笔交易对应的准确时间戳
2. 找出与你的起始日期对应的交易签名
3. 使用 before: lastSignature 从该签名开始向前循环回溯 
4. 继续循环，直到返回签名的 blockTime 到达结束日期
5. 编写退避和重试逻辑，以免触发速率限制和遗漏数据

这个过程不仅查询速度慢，而且配置繁琐，容易出错。

2. 高级筛选

借助新的 getTransactionsForAddress 方法，开发者可以按时间范围（即 Unix 时间戳）、slot 和状态（例如成功或失败）进行筛选。这些筛选条件让你能够更精准、细致地控制查询，只获取所需数据。

例如，这个基于时间的筛选条件使用 Unix 时间戳，获取从 2025 年 1 月 1 日凌晨 12:00 (GMT) 到 2025 年 10 月 1 日凌晨 12:00 (GMT) 之间发生的所有成功交易。

// Time range with successful transactions only
"filters": {
  "blockTime": {
    "gte": 1767225600,
    "lte": 1759363200
  },
  "status": "succeeded"
}

3. 基于游标的分页

当你需要查询的交易数量超过 gTFA 的默认限制（1,000 个签名或 100 条包含完整交易详情的记录）时，可以使用响应中的 paginationToken 来获取下一页。paginationToken 是一个格式为 "slot:position" 的简单字符串，用于告知 API 从何处继续。

例如，此查询使用 paginationToken（游标），以每批 100 条记录的方式扫描地址历史。

// First request
let paginationToken = null;
let allTransactions = [];

const getNextPage = async (paginationToken = null) => {
  const params = [
    'ADDRESS',
    {
      transactionDetails: 'signatures',
      limit: 100,
      ...(paginationToken && { paginationToken })
    }
  ];

  const response = await fetch(rpcUrl, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'getTransactionsForAddress',
      params
    })
  });

const data = await response.json();
  return data.result;
};

// Paginate through all results
do {
  const result = await getNextPage(paginationToken);
  allTransactions.push(...result.data);
  paginationToken = result.paginationToken;

  console.log(`Fetched ${result.data.length} transactions, total: ${allTransactions.length}`);
} while (paginationToken);

新的 Solana 归档系统

除了新的 getTransactionsForAddress 方法外，我们还发布了一套从零重建的全新归档系统，优化了归档路由器和存储路径。

新系统已为所有 Solana 归档 RPC 方法启用（例如 getTransaction、getBlock、getInflationReward），所有免费和付费计划的用户均可使用。

这意味着，所有计划中的每种归档方法现在都快了 2–10 倍——延迟更低、性能更强，而且无需更改代码。

开始使用

从今天起，所有付费计划均可公开使用 getTransactionsForAddress RPC 方法，并且可以直接配合你现有的 Helius RPC URL 使用。gTFA 方法每次调用消耗 100 个额度，并计入你的 RPC 速率限制组。

要了解该方法的工作原理并开始使用，请阅读 API 参考文档，并按照我们的 getTransactionsForAddress 快速入门指南操作。