getTransactionsForAddress и архивные данные до 10 раз быстрее

Сложности запросов исторических данных Solana

Реестр Solana содержит каждую транзакцию, когда-либо отправленную ончейн. Эти исторические данные включают все выпуски токенов, переводы, свопы и взаимодействия с программами с момента создания genesis-блока.

К настоящему моменту Solana сформировала более 375 миллионов блоков, а полный, не подвергавшийся обрезке архив транзакций от genesis-блока до сегодняшнего дня занимает сотни терабайт.

Быстрый и надежный доступ к этим данным необходим практически каждой команде, которая сегодня разрабатывает на Solana. Архивные методы Solana обеспечивают работу всего — от вкладки с историей транзакций в вашем любимом кошельке до предпочитаемого вами обозревателя блоков и панели управления портфелем.

До сих пор у разработчиков было только два неудобных варианта запросов архивных данных:

1. getBlock
2. getSignaturesForAddress вместе с getTransaction

getBlock работает слишком медленно

Сначала разработчики могут попробовать запрашивать getBlock, чтобы заполнить исторические данные. Это возможно, но такой метод требует неоправданно много времени, средств и ресурсов:

1. Вызвать getBlocks, чтобы найти подтвержденные блоки в нужном диапазоне слотов
2. Вызвать getBlock для каждого блока, чтобы получить полные данные транзакций, подписи или аккаунты
3. Извлечь из блока все необходимые данные и сохранить их в базе данных
4. Повторять, пока не будут обработаны все блоки

Метод getBlock хорошо подходит для программ с высокой активностью — например, для индексации популярных токенов вроде USDC или программ Solana вроде Pump.fun. Но для небольших специализированных наборов данных он непрактичен.

Циклические вызовы getSignaturesForAddress и getTransaction

Еще один распространенный способ заполнить исторические данные — использовать getSignaturesForAddress (gSFA) вместе с getTransaction.

При таком подходе с «циклом N+1» подписи транзакций многократно загружаются, обычно по 1 000 за раз, после чего выполняются пакетные RPC-вызовы для получения данных каждой транзакции.

Из-за огромного количества RPC-запросов разработчикам приходится реализовывать экспоненциальную задержку и логику повторных попыток, чтобы не превышать лимиты запросов и не терять данные.

Хотя использование gSFA и getTransaction дает больше гибкости, чем getBlock, в большом масштабе этот подход остается дорогим, сложным и подверженным ошибкам.

Преимущества getTransactionForAddress

Новый RPC-метод getTransactionsForAddress объединяет getSignaturesForAddress и getTransaction в одном вызове. Его мощные функции упрощают и ускоряют создание индексов и запросы исторических данных.

Основные возможности:

1. Обратный поиск

Существующие архивные RPC-методы, такие как gSFA, требовали начинать с самой новой транзакции и двигаться назад.

С getTransactionForAddress разработчики могут выбирать восходящий (то есть хронологический, от старых записей к новым) или нисходящий (то есть сначала новые записи) порядок сортировки.

В сочетании с фильтрами по времени getTransactionForAddress позволяет разработчикам запрашивать любой фрагмент истории Solana, начиная с любого момента времени и в любом порядке.

Например, Orb, наш новый обозреватель блоков Solana, использует RPC-метод getTransactionsForAddress для работы фильтра «Сначала старые»:

Чтобы запросить те же данные с помощью getSignaturesForAddress и getTransaction, потребовалось бы:

1. Найти точную временную метку первой транзакции
2. Найти подпись транзакции, соответствующую дате начала
3. Перебирать записи в обратном направлении от этой подписи с помощью before: lastSignature
4. Продолжать цикл, пока blockTime возвращаемых подписей не достигнет даты окончания
5. Реализовать задержку и логику повторных попыток, чтобы не превышать лимиты запросов и не терять данные

Такой процесс не только медленно выполняет запросы, но и сложен в настройке и подвержен ошибкам.

2. Расширенная фильтрация

Новый метод getTransactionsForAddress позволяет разработчикам фильтровать данные по диапазону времени (то есть временной метке Unix), слоту и статусу (например, успешно или с ошибкой). Эти фильтры обеспечивают более точный и детальный контроль над запросом необходимых данных.

Например, этот фильтр по времени использует временные метки Unix, чтобы получить все успешные транзакции, выполненные с 00:00 1 января 2025 года по 00:00 1 октября 2025 года по Гринвичу.

// 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 мы запустили совершенно новую архивную систему, созданную с нуля для оптимизации маршрутизации и путей хранения архива.

Новая система работает со всеми архивными RPC-методами Solana (например, getTransaction, getBlock, getInflationReward) и доступна пользователям всех бесплатных и платных планов.

Это означает, что каждый архивный метод на любом плане теперь работает в 2–10 раз быстрее: ниже задержка, выше производительность, а менять код не нужно.

Начало работы

RPC-метод getTransactionsForAddress с сегодняшнего дня общедоступен на всех платных планах. Его можно использовать с существующим RPC URL Helius. Метод gTFA стоит 100 кредитов за вызов и входит в вашу группу лимитов RPC-запросов.

Чтобы узнать, как работает метод, и начать его использовать, прочитайте справочник API и следуйте нашему краткому руководству по getTransactionsForAddress.