getTransactionsForAddress e dados históricos até 10x mais rápidos

Desafios de consultar dados históricos na Solana

O ledger da Solana armazena todas as transações já enviadas on-chain. Esses dados históricos incluem cada mint, transferência, swap e interação com programas que ocorreu desde o bloco gênese.

Até hoje, a Solana produziu mais de 375 milhões de blocos, e seu histórico completo de transações, sem poda, desde o bloco gênese até hoje ocupa centenas de terabytes. 

Acessar esses dados com rapidez e confiabilidade é essencial para praticamente todas as equipes que desenvolvem na Solana atualmente. Os métodos de arquivamento da Solana viabilizam desde a aba de histórico de transações da sua carteira favorita até seu explorador e painel de portfólio favoritos. 

Até agora, os desenvolvedores tinham apenas duas opções para consultar dados históricos, e ambas são problemáticas: 

1. getBlock
2. getSignaturesForAddress mais getTransaction

Usar getBlock é lento demais

Primeiro, os desenvolvedores podem tentar consultar getBlock para preencher os dados retroativamente. Embora seja possível, esse método consome tempo, recursos e dinheiro desnecessariamente:

1. Chame getBlocks para encontrar blocos confirmados no seu intervalo de slots
2. Chame getBlock em cada bloco para obter todos os detalhes, assinaturas ou contas das transações
3. Analise todos os dados relevantes do bloco e armazene-os no seu banco de dados
4. Repita até concluir todos os blocos

Embora o método getBlock funcione bem para programas movimentados (por exemplo, ao indexar tokens populares, como USDC, ou programas da Solana, como Pump.fun), usá-lo para conjuntos de dados pequenos e específicos não é prático.

Executar getSignaturesForAddress e getTransaction em loop

Usar getSignaturesForAddress (gSFA) junto com getTransaction é outra forma comum de preencher dados retroativamente.

Essa abordagem de “loop N+1” busca repetidamente as assinaturas das transações, normalmente 1.000 por vez, e depois faz chamadas RPC em lote para buscar os detalhes de cada transação. 

Devido ao enorme número de solicitações RPC, os desenvolvedores precisam implementar backoff exponencial e lógica de repetição para evitar atingir limites de taxa e perder dados. 

Embora usar gSFA e getTransaction seja mais flexível do que getBlock, ainda é caro, complexo e sujeito a erros em grande escala.

Benefícios de getTransactionForAddress

O novo método RPC getTransactionsForAddress combina getSignaturesForAddress com getTransaction em uma única chamada, com recursos avançados que tornam a criação de índices e a consulta de dados históricos mais fáceis e rápidas.

Veja os principais recursos:

1. Busca reversa

Os métodos RPC de arquivamento existentes, como gSFA, exigiam que os desenvolvedores começassem pela transação mais recente e retrocedessem.

Com getTransactionForAddress, agora os desenvolvedores podem escolher entre a ordem crescente (ou seja, cronológica, começando pela mais antiga) ou decrescente (ou seja, começando pela mais recente). 

Combinado com filtros baseados em tempo, getTransactionForAddress permite que os desenvolvedores consultem qualquer parte do histórico da Solana, a partir de qualquer momento e em qualquer ordem.

Por exemplo, o Orb, nosso novo explorador de blocos da Solana, usa o método RPC getTransactionsForAddress para viabilizar o filtro “Mostrar mais antigas primeiro”:

Se quisesse consultar esses mesmos dados usando getSignaturesForAddress e getTransaction, você precisaria:

1. Encontrar o timestamp exato correspondente à primeira transação
2. Encontrar a assinatura da transação correspondente à data inicial
3. Retroceder em loop a partir dessa assinatura usando before: lastSignature 
4. Continuar o loop até que blockTime das assinaturas retornadas alcance a data final
5. Criar lógica de backoff e repetição para evitar atingir limites de taxa e perder dados

Esse processo não só torna a consulta lenta, como também é frustrante de configurar e sujeito a erros.

2. Filtragem avançada

Com o novo método getTransactionsForAddress, os desenvolvedores podem filtrar por intervalo de tempo (ou seja, timestamp Unix), slot e status (por exemplo, concluída ou com falha). Esses filtros oferecem um controle mais preciso e granular para consultar exatamente os dados de que você precisa.

Por exemplo, este filtro baseado em tempo usa timestamps Unix para receber todas as transações bem-sucedidas que ocorreram entre 1º de janeiro de 2025, à meia-noite (GMT), e 1º de outubro de 2025, à meia-noite (GMT).

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

3. Paginação baseada em cursor

Quando precisar consultar mais transações do que os limites padrão do gTFA (1.000 assinaturas ou 100 registros com todos os detalhes das transações), você poderá usar o paginationToken da resposta para buscar a próxima página. O paginationToken é uma string simples no formato "slot:position" que informa à API de onde continuar.

Por exemplo, esta consulta usa o paginationToken (um cursor) para percorrer o histórico do endereço em lotes de 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);

Novo sistema de arquivamento da Solana

Além do novo método getTransactionsForAddress, lançamos um sistema de arquivamento totalmente novo, reconstruído do zero para otimizar as rotas de roteamento e armazenamento do arquivo.

O novo sistema está habilitado para todos os métodos RPC de arquivamento da Solana (por exemplo, getTransaction, getBlock, getInflationReward) e disponível para usuários de todos os planos gratuitos e pagos.

Isso significa que todos os métodos de arquivamento, em todos os planos, agora são de 2 a 10 vezes mais rápidos — menor latência, melhor desempenho e nenhuma alteração de código necessária.

Comece agora

O método RPC getTransactionsForAddress está disponível publicamente a partir de hoje em todos os planos pagos e pode ser usado com sua URL RPC existente da Helius. O método gTFA custa 100 créditos por chamada e faz parte do seu grupo de limites de taxa de RPC.

Para saber como o método funciona e começar a usá-lo, leia a referência da API e siga nosso guia de início rápido do getTransactionsForAddress.