Comment utiliser getTransaction

​

Cas d’utilisation courants

• Vérification de transaction : Confirmer qu’une transaction a été traitée et vérifier son résultat (succès ou échec).
• Affichage de l’historique des transactions : Montrer aux utilisateurs les détails de leurs transactions passées dans un portefeuille ou un explorateur.
• Audit et analyse : Examiner les spécificités d’une transaction, y compris les instructions exécutées, les frais payés et les comptes impliqués.
• Débogage des transactions échouées : Inspecter les champs logMessages et err dans les métadonnées pour comprendre pourquoi une transaction a échoué.
• Indexation des données : Extraire des informations spécifiques des transactions pour le stockage et l’analyse hors chaîne.

​

Paramètres de la requête

1. transactionSignature (chaîne, requis) : La signature de transaction encodée en base-58 que vous souhaitez interroger.
2. options (objet, optionnel) : Un objet de configuration optionnel qui peut inclure :
   • commitment (chaîne, optionnel) : Spécifie le niveau d’engagement (par exemple, "finalized", "confirmed"). Si non fourni, l’engagement par défaut du nœud est utilisé (généralement "finalized").
   • encoding (chaîne, optionnel) : L’encodage pour les données transaction. Valeurs courantes :
     • "json" : Retourne les données de transaction dans un format JSON structuré (mais les instructions peuvent encore être encodées en base64).
     • "jsonParsed" : Retourne les données de transaction avec les instructions spécifiques au programme analysées dans un format JSON lisible par un humain lorsque cela est possible. C’est souvent l’encodage le plus utile pour l’analyse.
     • "base58" : Retourne les données de transaction sous la forme d’une chaîne encodée en base-58.
     • "base64" : Retourne les données de transaction sous la forme d’une chaîne encodée en base-64.
     • Par défaut à "json" si non spécifié par Helius, mais le défaut de Solana pourrait être différent. Il est préférable de spécifier cela.
   • maxSupportedTransactionVersion (nombre, optionnel) : La version maximale de transaction que le point de terminaison RPC doit traiter.
     • Réglez sur 1 pour inclure les transactions legacy, v0, et v1.
     • Si omis, ou réglé en dessous de la version de la transaction, la requête échoue avec une erreur JSON-RPC -32015 (Transaction version (1) is not supported by the requesting client). Toujours régler ceci sur 1. Voir Support de Transaction v1.

​

Structure de la réponse

• slot (u64) : Le numéro de slot dans lequel la transaction a été incluse dans un bloc.
• blockTime (i64 | null) : Le timestamp Unix estimé (secondes depuis l’époque) lorsque le bloc contenant la transaction a été produit. Peut être null si non disponible.
• meta (objet | null) : Un objet contenant des métadonnées sur l’exécution de la transaction. Peut être null si la transaction a échoué avant d’être traitée ou si les métadonnées ne sont pas disponibles.
  • err (objet | null) : Un objet d’erreur si la transaction a échoué, sinon null.
  • fee (u64) : Les frais en lamports payés pour la transaction.
  • preBalances (tableau de u64) : Soldes en lamports des comptes impliqués avant que la transaction ne soit traitée.
  • postBalances (tableau de u64) : Soldes en lamports des comptes impliqués après que la transaction a été traitée.
  • preTokenBalances (tableau d’objets | null) : Soldes des jetons des comptes de jetons impliqués avant la transaction.
  • postTokenBalances (tableau d’objets | null) : Soldes des jetons des comptes de jetons impliqués après la transaction.
  • innerInstructions (tableau d’objets | null) : Un tableau d’instructions exécutées dans le cadre des CPI (Cross-Program Invocations) dans cette transaction.
  • logMessages (tableau de chaînes | null) : Un tableau de messages de log émis par les instructions de la transaction et toutes les instructions internes.
  • loadedAddresses (objet, optionnel) : Spécifie les comptes chargés à partir des tables de recherche d’adresse pour cette transaction. Contient les tableaux de clés publiques writable et readonly.
  • returnData (objet, optionnel) : Données retournées par la transaction via sol_set_return_data et sol_get_return_data. Contient programId (chaîne) et data (tableau : [string, encoding]).
  • computeUnitsConsumed (u64, optionnel) : Le nombre d’unités de calcul consommées par cette transaction.
• transaction (objet | tableau) : La structure même de la transaction. Le format dépend du paramètre encoding :
  • Si encoding est "jsonParsed" ou "json" : Un objet avec message (contenant accountKeys, instructions, recentBlockhash, etc.) et signatures (tableau de chaînes).
  • Si encoding est "base58", "base64" : Un tableau [encoded_string, encoding_format_string].
• version (“legacy” | nombre | non défini) : La version de la transaction. Peut être "legacy" pour les transactions plus anciennes ou un nombre (0 ou 1) pour les transactions versionnées. undefined si maxSupportedTransactionVersion n’est pas défini et la transaction est versionnée. Une transaction v1 porte également un objet transactionConfig dans son message avec le budget de calcul (computeUnitLimit, heapSize, loadedAccountsDataSizeLimit, priorityFee), remplaçant les instructions du programme ComputeBudget. Son priorityFee est le total des frais en lamports, et non en micro-lamports par unité de calcul.

{
  "jsonrpc": "2.0",
  "result": {
    "blockTime": 1635900000,
    "meta": {
      "err": null,
      "fee": 5000,
      "innerInstructions": [],
      "logMessages": [
        "Program Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS invoke [1]",
        "Program log: Memo 'Hello, Solana!'",
        "Program Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS success"
      ],
      "postBalances": [
        499999999999994999, 
        1000000000
      ],
      "postTokenBalances": [],
      "preBalances": [
        500000000000000000, 
        1000000000
      ],
      "preTokenBalances": [],
      "rewards": [],
      "status": { "Ok": null },
      "computeUnitsConsumed": 200
    },
    "slot": 98765432,
    "transaction": {
      "message": {
        "accountKeys": [
          "SysvarRent111111111111111111111111111111111",
          "Vote111111111111111111111111111111111111111"
        ],
        "instructions": [
          {
            "parsed": {
              "type": "vote",
              "info": {
                "votePubkey": "Vote111111111111111111111111111111111111111",
                "slot": 123,
                "hash": "abc..."
              }
            },
            "program": "vote",
            "programId": "Vote111111111111111111111111111111111111111"
          }
        ],
        "recentBlockhash": "xyz..."
      },
      "signatures": [
        "sig1..."
      ]
    },
    "version": "legacy"
  },
  "id": 1
}

​

Exemples de code

# Replace <TRANSACTION_SIGNATURE> with an actual signature
curl -X POST -H "Content-Type: application/json" -d \
  '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getTransaction",
    "params": [
      "<TRANSACTION_SIGNATURE>",
      {
        "encoding": "jsonParsed",
        "maxSupportedTransactionVersion": 1
      }
    ]
  }' \
  <YOUR_RPC_URL>

const { Connection } = require('@solana/web3.js');

async function getTransactionDetails(signature) {
  // Replace with your RPC endpoint
  const connection = new Connection('https://mainnet.helius-rpc.com/?api-key=<api-key>');

  try {
    const transaction = await connection.getTransaction(signature, {
      maxSupportedTransactionVersion: 1, // Required for legacy, v0, and v1 transactions
      // commitment: 'confirmed', // Optional: specify commitment level
    });

    if (transaction) {
      console.log('Transaction Details:');
      console.log(`  Slot: ${transaction.slot}`);
      console.log(`  Block Time: ${transaction.blockTime ? new Date(transaction.blockTime * 1000).toLocaleString() : 'N/A'}`);
      console.log(`  Fee: ${transaction.meta ? transaction.meta.fee : 'N/A'} lamports`);
      console.log(`  Status: ${transaction.meta && transaction.meta.err ? 'Failed' : 'Success'}`);
      if (transaction.meta && transaction.meta.err) {
        console.log(`    Error: ${JSON.stringify(transaction.meta.err)}`);
      }
      // console.log(JSON.stringify(transaction, null, 2)); // Log full transaction details

      if (transaction.meta && transaction.meta.logMessages) {
        console.log('  Log Messages:');
        transaction.meta.logMessages.forEach(log => console.log(`    ${log}`));
      }

    } else {
      console.log('Transaction not found or not confirmed.');
    }
  } catch (error) {
    console.error(`Error fetching transaction ${signature}:`, error);
  }
}

// Replace with an actual transaction signature from Mainnet-beta or your test environment
const exampleSignature = '5h4zCwobYsdL3mY26FgfXy8c4rTPkX6gYVXW8w2tTjCXZMWzE9jX9p8Q2Y8Yj9p8ZQ8Yj9p8ZQ8Yj9p8ZQ8Yj9'; // Replace with a real signature
// getTransactionDetails(exampleSignature);

// Example of a known transaction (you'll need to find a recent one on an explorer)
// getTransactionDetails('2xNdnHjZDmJRy1L6jC1mF87K3V9nXZo2bY6vA8GzQ3T7bS9xU8cM7sR5eD3fG2hJ1aB0cE9lK6mN5pP4qR7');

console.log("Please replace 'exampleSignature' with a real transaction signature to run the example.");

​

Conseils pour les développeurs

• Finalité de la transaction : Assurez-vous de faire une requête avec un niveau commitment approprié. Demander une transaction qui n’a pas atteint l’engagement spécifié aboutira à null.
• Volume de données : L’objet de réponse peut être très grand, surtout pour les transactions complexes avec de nombreuses instructions ou des journaux détaillés. Soyez conscient de cela lors du traitement des données.
• jsonParsed vs. json : Bien que jsonParsed soit très pratique, la prise en charge de l’analyse dépend des capacités du nœud RPC pour des programmes spécifiques. Si un programme n’est pas reconnu, ses instructions peuvent revenir à un format moins analysé même avec jsonParsed.
• Transactions versionnées : Réglez toujours maxSupportedTransactionVersion: 1 dans vos options de requête pour vous assurer que votre application peut gérer à la fois les transactions legacy et versionnées. Sinon, vous pourriez manquer des données ou rencontrer des erreurs pour les nouveaux formats de transaction.
• Différences entre les fournisseurs RPC : Bien que l’API de base soit standard, certains fournisseurs RPC pourraient offrir une analyse améliorée ou des champs supplémentaires. Helius, par exemple, fournit une analyse riche des transactions.