Verwendung von getTransaction

​

Häufige Anwendungsfälle

• Transaktionsüberprüfung: Bestätigung, dass eine Transaktion verarbeitet wurde, und Überprüfung ihres Ergebnisses (Erfolg oder Misserfolg).
• Anzeige des Transaktionsverlaufs: Anzeigen von Benutzern die Details ihrer vergangenen Transaktionen in einem Wallet oder Explorer.
• Prüfung und Analyse: Untersuchung der Einzelheiten einer Transaktion, einschließlich ausgeführter Anweisungen, bezahlter Gebühren und beteiligter Konten.
• Fehlerbehebung bei fehlgeschlagenen Transaktionen: Überprüfung der Felder logMessages und err in den Metadaten, um zu verstehen, warum eine Transaktion fehlgeschlagen ist.
• Datenindexierung: Extrahieren spezifischer Informationen aus Transaktionen für die Offline-Speicherung und Analyse.

​

Anforderungsparameter

1. transactionSignature (string, erforderlich): Die base-58-kodierte Transaktionssignatur, die Sie abfragen möchten.
2. options (object, optional): Ein optionales Konfigurationsobjekt, das Folgendes enthalten kann:
   • commitment (string, optional): Gibt das Commitment Level an (z.B. "finalized", "confirmed"). Wenn nicht angegeben, wird das Standard-Commitment des Knotens verwendet (normalerweise "finalized").
   • encoding (string, optional): Die Kodierung für die transaction Daten. Übliche Werte:
     • "json": Gibt die Transaktionsdaten in einem strukturierten JSON-Format zurück (aber Anweisungen können dennoch base64-codiert sein).
     • "jsonParsed": Gibt die Transaktionsdaten mit programmierspezifischen Anweisungen zurück, die, sofern möglich, in ein menschenlesbares JSON-Format konvertiert wurden. Dies ist oft die nützlichste Kodierung für die Analyse.
     • "base58": Gibt die Transaktionsdaten als base-58-kodierten String zurück.
     • "base64": Gibt die Transaktionsdaten als base-64-kodierten String zurück.
     • Standardmäßig auf "json", wenn nicht von Helius angegeben, aber die Standardeinstellung von Solana könnte unterschiedlich sein. Es ist am besten, dies anzugeben.
   • maxSupportedTransactionVersion (number, optional): Die maximale Transaktionsversion, die der RPC-Endpunkt verarbeiten soll.
     • Setzen Sie auf 1, um Legacy-, v0- und v1-Transaktionen einzubeziehen.
     • Wenn weggelassen oder niedriger als die Version der Transaktion eingestellt, schlägt die Anfrage mit dem JSON-RPC-Fehler -32015 (Transaction version (1) is not supported by the requesting client) fehl. Setzen Sie dies immer auf 1. Siehe Transaction v1 support.

​

Antwortstruktur

• slot (u64): Die Slotnummer, in der die Transaktion in einem Block enthalten war.
• blockTime (i64 | null): Der geschätzte Unix-Zeitstempel (Sekunden seit Epoche), als der Block, der die Transaktion enthält, erzeugt wurde. Kann null sein, wenn nicht verfügbar.
• meta (object | null): Ein Objekt, das Metadaten über die Ausführung der Transaktion enthält. Kann null sein, wenn die Transaktion vor der Verarbeitung fehlgeschlagen ist oder wenn Metadaten nicht verfügbar sind.
  • err (object | null): Ein Fehlerobjekt, wenn die Transaktion fehlgeschlagen ist, ansonsten null.
  • fee (u64): Die in Lamports gezahlten Gebühren für die Transaktion.
  • preBalances (array of u64): Lamport-Salden der beteiligten Konten vor der Verarbeitung der Transaktion.
  • postBalances (array of u64): Lamport-Salden der beteiligten Konten nach der Verarbeitung der Transaktion.
  • preTokenBalances (array of objects | null): Token-Salden der beteiligten Token-Konten vor der Transaktion.
  • postTokenBalances (array of objects | null): Token-Salden der beteiligten Token-Konten nach der Transaktion.
  • innerInstructions (array of objects | null): Ein Array von Anweisungen, die als Teil von CPI (Cross-Program Invocations) innerhalb dieser Transaktion ausgeführt wurden.
  • logMessages (array of string | null): Ein Array von Protokollmeldungen, die von den Anweisungen der Transaktion und allen inneren Anweisungen ausgegeben wurden.
  • loadedAddresses (object, optional): Gibt die Konten an, die aus Adressnachschlagetabellen für diese Transaktion geladen wurden. Enthält writable und readonly Arrays öffentlicher Schlüssel.
  • returnData (object, optional): Vom Transaktionsprozess zurückgegebene Daten über sol_set_return_data und sol_get_return_data. Enthält programId (String) und data (Array: [string, encoding]).
  • computeUnitsConsumed (u64, optional): Die Anzahl der Recheneinheiten, die von dieser Transaktion verbraucht wurden.
• transaction (object | array): Die Transaktionsstruktur selbst. Das Format hängt vom Parameter encoding ab:
  • Wenn encoding ist "jsonParsed" oder "json": Ein Objekt mit message (enthält accountKeys, instructions, recentBlockhash, etc.) und signatures (Array von Strings).
  • Wenn encoding ist "base58", "base64": Ein Array [encoded_string, encoding_format_string].
• version (“legacy” | number | undefined): Die Version der Transaktion. Kann "legacy" für ältere Transaktionen oder eine Zahl (0 oder 1) für versionierte Transaktionen sein. undefined, wenn maxSupportedTransactionVersion nicht festgelegt ist und die Transaktion versioniert ist. Eine v1-Transaktion enthält auch ein transactionConfig-Objekt in ihrem message mit dem Compute-Budget (computeUnitLimit, heapSize, loadedAccountsDataSizeLimit, priorityFee), das Anweisungen des ComputeBudget-Programms ersetzt. Ihr priorityFee ist die Gesamtgebühr in Lamports, nicht die Mikrolamports pro Recheneinheit.

{
  "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
}

​

Code-Beispiele

# 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.");

​

Entwickler-Tipps

• Transaktionsendgültigkeit: Stellen Sie sicher, dass Sie mit einem geeigneten commitment-Level abfragen. Das Anfordern einer Transaktion, die das angegebene Commitment nicht erreicht hat, führt zu null.
• Datenmenge: Das Antwortobjekt kann sehr groß sein, insbesondere bei komplexen Transaktionen mit vielen Anweisungen oder detaillierten Protokollen. Beachten Sie dies beim Verarbeiten der Daten.
• jsonParsed vs. json: Obwohl jsonParsed sehr praktisch ist, hängt die Unterstützung beim Parsen von den Fähigkeiten des RPC-Knotens für bestimmte Programme ab. Wenn ein Programm nicht erkannt wird, könnten seine Anweisungen auch mit jsonParsed auf ein weniger geparstes Format zurückfallen.
• Versionierte Transaktionen: Setzen Sie maxSupportedTransactionVersion: 1 immer in Ihren Anfrageoptionen, um sicherzustellen, dass Ihre Anwendung sowohl Legacy- als auch versionierte Transaktionen verarbeiten kann. Andernfalls könnten Sie Daten verpassen oder Fehler bei neueren Transaktionsformaten erhalten.
• Unterschiede zwischen RPC-Anbietern: Während die Kern-API standardisiert ist, könnten einige RPC-Anbieter erweitertes Parsing oder zusätzliche Felder bieten. Helius bietet beispielsweise umfassendes Transaktionsparsing.