getTransactionsForAddress et données d’archive jusqu’à 10 fois plus rapides

Les défis liés à l’interrogation des données historiques sur Solana

Le registre de Solana contient toutes les transactions jamais envoyées on-chain. Ces données historiques comprennent chaque création de token, transfert, swap et interaction avec un programme depuis le bloc de genèse.

À ce jour, Solana a produit plus de 375 millions de blocs, et l’intégralité de son historique de transactions non élagué, du bloc de genèse à aujourd’hui, représente des centaines de téraoctets. 

Un accès rapide et fiable à ces données est essentiel pour pratiquement toutes les équipes qui développent aujourd’hui sur Solana. Les méthodes d’archivage de Solana alimentent aussi bien l’onglet d’historique des transactions de votre portefeuille préféré que votre explorateur et votre tableau de bord de portefeuille favoris. 

Jusqu’à présent, les développeurs ne disposaient que de deux options pour interroger les données d’archive, et toutes deux étaient pénibles à utiliser : 

1. getBlock
2. getSignaturesForAddress avec getTransaction

L’utilisation de getBlock est trop lente

Les développeurs peuvent d’abord essayer d’interroger getBlock pour remplir les données rétroactivement. Bien que possible, cette méthode est inutilement longue, coûteuse et gourmande en ressources :

1. Appelez getBlocks pour trouver les blocs confirmés dans votre plage de slots
2. Appelez getBlock sur chaque bloc pour obtenir tous les détails des transactions, les signatures ou les comptes
3. Analysez toutes les données pertinentes du bloc et stockez-les dans votre base de données
4. Répétez l’opération jusqu’à ce que tous les blocs soient traités

Bien que la méthode getBlock fonctionne bien pour les programmes très actifs (par exemple, pour indexer des tokens populaires comme USDC ou des programmes Solana comme Pump.fun), son utilisation pour de petits jeux de données spécifiques n’est pas pratique.

Exécuter getSignaturesForAddress et getTransaction en boucle

L’utilisation conjointe de getSignaturesForAddress (gSFA) et de getTransaction est une autre méthode courante pour remplir les données rétroactivement.

Cette approche en « boucle N+1 » récupère les signatures de transactions à plusieurs reprises, généralement par lots de 1 000, puis effectue des appels RPC par lots pour récupérer les détails de chaque transaction. 

Compte tenu du nombre considérable de requêtes RPC, les développeurs doivent mettre en œuvre une temporisation exponentielle et une logique de nouvelle tentative pour éviter d’atteindre les limites de débit et de perdre des données. 

Même si l’utilisation de gSFA et de getTransaction offre davantage de flexibilité que getBlock, elle reste coûteuse, complexe et sujette aux erreurs à grande échelle.

Avantages de getTransactionForAddress

La nouvelle méthode RPC getTransactionsForAddress réunit getSignaturesForAddress et getTransaction en un seul appel doté de puissantes fonctionnalités qui simplifient et accélèrent la création d’index et l’interrogation des données historiques.

Voici ses principales fonctionnalités :

1. Recherche inversée

Les méthodes RPC d’archivage existantes, telles que gSFA, obligeaient les développeurs à commencer par la transaction la plus récente et à remonter dans le temps.

Avec getTransactionForAddress, les développeurs peuvent désormais choisir un ordre de tri croissant (c’est-à-dire chronologique, de la plus ancienne à la plus récente) ou décroissant (c’est-à-dire de la plus récente à la plus ancienne). 

En l’associant à des filtres temporels, les développeurs peuvent utiliser getTransactionForAddress pour interroger n’importe quelle partie de l’historique de Solana, à partir de n’importe quel moment et dans n’importe quel ordre.

Par exemple, Orb, notre nouvel explorateur de blocs Solana, utilise la méthode RPC getTransactionsForAddress pour alimenter le filtre « Afficher les plus anciennes en premier » :

Pour interroger ces mêmes données avec getSignaturesForAddress et getTransaction, vous devriez :

1. Trouver l’horodatage exact correspondant à la première transaction
2. Trouver la signature de transaction correspondant à votre date de début
3. Remonter en boucle à partir de cette signature avec before: lastSignature 
4. Continuer la boucle jusqu’à ce que le champ blockTime des signatures renvoyées atteigne la date de fin
5. Écrire une logique de temporisation et de nouvelle tentative pour éviter d’atteindre les limites de débit et de perdre des données

Ce processus est non seulement lent à interroger, mais aussi frustrant à configurer et sujet aux erreurs.

2. Filtrage avancé

Avec la nouvelle méthode getTransactionsForAddress, les développeurs peuvent filtrer les données par plage temporelle (c’est-à-dire par horodatage Unix), slot et statut (par exemple, réussite ou échec). Ces filtres vous offrent un contrôle plus précis et granulaire pour interroger exactement les données dont vous avez besoin.

Par exemple, ce filtre temporel utilise des horodatages Unix pour recevoir toutes les transactions réussies effectuées entre le 1er janvier 2025 à 0 h 00 (GMT) et le 1er octobre 2025 à 0 h 00 (GMT).

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

3. Pagination basée sur un curseur

Lorsque vous devez interroger davantage de transactions que ne le permettent les limites par défaut de gTFA (1 000 signatures ou 100 enregistrements avec tous les détails des transactions), vous pouvez utiliser le champ paginationToken de la réponse pour récupérer la page suivante. Le champ paginationToken est une simple chaîne au format "slot:position" qui indique à l’API où reprendre.

Par exemple, cette requête utilise le champ paginationToken (un curseur) pour parcourir l’historique de l’adresse par lots 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);

Nouveau système d’archivage Solana

En plus de la nouvelle méthode getTransactionsForAddress, nous avons lancé un tout nouveau système d’archivage, entièrement reconstruit pour optimiser le routage et les chemins de stockage des archives.

Le nouveau système est activé pour toutes les méthodes RPC d’archivage Solana (par exemple, getTransaction, getBlock, getInflationReward) et est accessible aux utilisateurs de tous les forfaits gratuits et payants.

Cela signifie que chaque méthode d’archivage de chaque forfait est désormais 2 à 10 fois plus rapide : latence réduite, meilleures performances et aucune modification du code requise.

Commencer

La méthode RPC getTransactionsForAddress est accessible au public dès aujourd’hui avec tous les forfaits payants et peut être utilisée avec votre URL RPC Helius existante. La méthode gTFA coûte 100 crédits par appel et fait partie de votre groupe de limites de débit RPC.

Pour comprendre le fonctionnement de la méthode et commencer à l’utiliser, consultez la référence de l’API et suivez notre guide de démarrage rapide de getTransactionsForAddress.