getTransactionsForAddress y datos de archivo hasta 10 veces más rápidos

Desafíos de consultar datos históricos en Solana

El ledger de Solana contiene todas las transacciones enviadas on-chain. Estos datos históricos incluyen cada acuñación, transferencia, swap e interacción con programas que ha ocurrido desde el bloque génesis.

Hasta la fecha, Solana ha producido más de 375 millones de bloques, y su historial completo de transacciones sin depurar, desde el bloque génesis hasta hoy, ocupa cientos de terabytes. 

Acceder a estos datos de forma rápida y confiable es esencial para prácticamente todos los equipos que desarrollan en Solana actualmente. Los métodos de archivo de Solana hacen posible todo, desde la pestaña del historial de transacciones de tu wallet favorita hasta tu explorador y panel de portafolio preferidos. 

Hasta ahora, los desarrolladores solo tenían dos opciones para consultar datos de archivo, y ambas eran problemáticas: 

1. getBlock
2. getSignaturesForAddress más getTransaction

Usar getBlock es demasiado lento

Primero, los desarrolladores pueden intentar consultar getBlock para rellenar datos anteriores. Aunque es posible, este método requiere demasiado tiempo, dinero y recursos:

1. Llama a getBlocks para encontrar los bloques confirmados en tu rango de slots
2. Llama a getBlock en cada bloque para obtener todos los detalles, firmas o cuentas de las transacciones
3. Analiza todos los datos relevantes del bloque y guárdalos en tu base de datos
4. Repite el proceso hasta completar todos los bloques

Aunque el método getBlock funciona bien para programas con mucha actividad (por ejemplo, para indexar tokens populares como USDC o programas de Solana como Pump.fun), no es práctico para conjuntos de datos pequeños y específicos.

Recorrer getSignaturesForAddress y getTransaction en un bucle

Usar getSignaturesForAddress (gSFA) junto con getTransaction es otra forma común de rellenar datos anteriores.

Este enfoque de “bucle N+1” obtiene repetidamente firmas de transacciones, normalmente 1,000 a la vez, y después realiza llamadas RPC por lotes para obtener los detalles de cada transacción. 

Debido a la enorme cantidad de solicitudes RPC, los desarrolladores necesitan implementar backoff exponencial y lógica de reintentos para evitar alcanzar los límites de tasa y perder datos. 

Aunque usar gSFA e getTransaction ofrece más flexibilidad que getBlock, a gran escala sigue siendo costoso, complicado y propenso a errores.

Ventajas de getTransactionForAddress

El nuevo método RPC getTransactionsForAddress combina getSignaturesForAddress con getTransaction en una sola llamada. Ofrece potentes funciones que permiten crear índices y consultar datos históricos de forma más fácil y rápida.

Estas son las funciones principales:

1. Búsqueda inversa

Los métodos RPC de archivo existentes, como gSFA, obligaban a los desarrolladores a comenzar por la transacción más reciente y retroceder.

Con getTransactionForAddress, los desarrolladores ahora pueden elegir entre un orden ascendente (es decir, cronológico, comenzando por el más antiguo) o descendente (es decir, comenzando por el más reciente). 

En combinación con los filtros por tiempo, los desarrolladores pueden usar getTransactionForAddress para consultar cualquier parte del historial de Solana, desde cualquier momento y en cualquier orden.

Por ejemplo, Orb, nuestro nuevo explorador de bloques de Solana, usa el método RPC getTransactionsForAddress para habilitar el filtro “Mostrar los más antiguos primero”:

Si quisieras consultar estos mismos datos con getSignaturesForAddress e getTransaction, tendrías que:

1. Encontrar la marca de tiempo exacta correspondiente a la primera transacción
2. Encontrar la firma de transacción correspondiente a tu fecha de inicio
3. Retroceder desde esa firma en un bucle con before: lastSignature 
4. Continuar el bucle hasta que el valor blockTime de las firmas devueltas alcance la fecha de finalización
5. Escribir lógica de backoff y reintentos para evitar alcanzar los límites de tasa y perder datos

Este proceso no solo hace que la consulta sea lenta, sino que también es frustrante de configurar y propenso a errores.

2. Filtrado avanzado

Con el nuevo método getTransactionsForAddress, los desarrolladores pueden filtrar por intervalo de tiempo (es decir, marca de tiempo Unix), slot y estado (por ejemplo, completada o fallida). Estos filtros te dan un control más preciso y granular para consultar exactamente los datos que necesitas.

Por ejemplo, este filtro por tiempo usa marcas de tiempo Unix para recibir todas las transacciones exitosas que ocurrieron entre el 1 de enero de 2025 a las 12:00 a. m. (GMT) y el 1 de octubre de 2025 a las 12:00 a. m. (GMT).

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

3. Paginación basada en cursor

Cuando necesitas consultar más transacciones que los límites predeterminados de gTFA (1,000 firmas o 100 registros con todos los detalles de las transacciones), puedes usar el valor paginationToken de la respuesta para obtener la siguiente página. paginationToken es una cadena simple con el formato "slot:position" que indica a la API desde dónde continuar.

Por ejemplo, esta consulta usa paginationToken (un cursor) para recorrer el historial de la dirección en 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);

Nuevo sistema de archivo de Solana

Además del nuevo método getTransactionsForAddress, lanzamos un sistema de archivo completamente nuevo, reconstruido desde cero para optimizar las rutas del router y del almacenamiento de archivo.

El nuevo sistema está habilitado para todos los métodos RPC de archivo de Solana (por ejemplo, getTransaction, getBlock, getInflationReward) y está disponible para usuarios de todos los planes gratuitos y de pago.

Esto significa que todos los métodos de archivo en todos los planes ahora son entre 2 y 10 veces más rápidos: menor latencia, mejor rendimiento y sin necesidad de cambiar el código.

Comienza ahora

El método RPC getTransactionsForAddress está disponible públicamente desde hoy en todos los planes de pago y puedes usarlo con tu URL RPC de Helius actual. El método gTFA cuesta 100 créditos por llamada y forma parte de tu grupo de límites de tasa de RPC.

Para aprender cómo funciona el método y comenzar a usarlo, consulta la referencia de la API y sigue nuestra guía de inicio rápido de getTransactionsForAddress.