> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Unterstützung von Transaktionen v1 > "Bereiten Sie Ihre Solana-Integration für Transaktion v1 vor: Setzen Sie maxSupportedTransactionVersion auf 1, aktualisieren Sie auf ein v1-fähiges SDK und lesen Sie prioritäre Gebühren aus transactionConfig." Agave 4.2 führt Transaktion v1 ein ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)). Sobald das Feature-Gate im Mainnet aktiviert ist, beginnen Wallets und Programme mit der Einreichung von v1-Transaktionen, und jede Anfrage, die vollständige Transaktionsdaten abruft, muss sich dafür entscheiden, sie zu empfangen. Diese Seite behandelt, was sich ändert, welche Helius-Endpunkte betroffen sind und wie Sie Ihren Code aktualisieren. Für die vollständige Agave 4.2-Checkliste, einschließlich Belohnungstypen, Kontenaktualisierungssemantik und Slot-Timing, siehe die [Agave 4.2-Migrations-Checkliste](https://www.helius.dev/blog/agave-4-2-migration-checklist). ## Was ändert sich in Transaktion v1 Legacy- und v0-Transaktionen bleiben unverändert. Für die meisten Integrationen sind zwei Dinge bei Transaktion v1 wichtig: * **Sie müssen sich dafür entscheiden, sie zu empfangen.** Anfragen für vollständige Transaktionsdaten benötigen `maxSupportedTransactionVersion: 1`, und Ihre Client-Bibliothek benötigt eine Version, die v1 deserialisieren kann. * **Das Berechnungsbudget verschiebt sich in den Nachrichten-Header.** Eine v1-Nachricht enthält ein `transactionConfig`-Objekt mit `computeUnitLimit`, `heapSize`, `loadedAccountsDataSizeLimit` und `priorityFee`. Es gibt keine CalculateBudget-Programmanweisungen in einer v1-Transaktion. Das Kabel-Format ändert sich ebenfalls (ein neues Versionsbyte und Signaturen am Ende der Transaktion), aber das betrifft nur Code, der rohe Transaktionsbytes dekodiert. Siehe [Dekomprimieren von rohen Transaktionsbytes](#dekodieren-sie-rohe-transaktionsbytes-mit-einem-v1-fähigen-parser) unten. In JSON-Antworten meldet eine v1-Transaktion `"version": 1` und ihr `message` enthält `transactionConfig`: ```json theme={"system"} { "version": 1, "transaction": { "signatures": ["..."], "message": { "accountKeys": ["..."], "instructions": [ { "programIdIndex": 3, "accounts": [0, 1], "data": "3Bxs4..." } ], "recentBlockhash": "...", "transactionConfig": { "computeUnitLimit": 200000, "heapSize": null, "loadedAccountsDataSizeLimit": 200000, "priorityFee": 50000 } } } } ``` `"priorityFee": 50000` bedeutet, dass diese Transaktion insgesamt 50.000 Lamports zahlt. Ein `null`-Feld bedeutet, dass der Absender es nicht gesetzt hat. Legacy- und v0-Nachrichten lassen `transactionConfig` vollständig aus. ## Setzen Sie maxSupportedTransactionVersion auf 1 Jede Anfrage, die vollständige Transaktionsdaten zurückgibt, muss die höchste Transaktionsversion deklarieren, die sie verarbeiten kann. Setzen Sie `maxSupportedTransactionVersion: 1` auf: * [`getTransaction`](/docs/de/rpc/guides/gettransaction) * [`getBlock`](/docs/de/rpc/guides/getblock) * [`getTransactionsForAddress`](/docs/de/rpc/gettransactionsforaddress) mit `transactionDetails: "full"` * [`transactionSubscribe`](/docs/de/rpc/websocket/transaction-subscribe) mit `transactionDetails: "accounts"` oder `"full"` * [`blockSubscribe`](/docs/de/api-reference/rpc/websocket/blocksubscribe) Eine Anfrage, die den Parameter auslässt oder auf `0` setzt, schlägt mit JSON-RPC-Fehler `-32015` fehl, sobald sie eine v1-Transaktion berührt: ```json theme={"system"} { "jsonrpc": "2.0", "error": { "code": -32015, "message": "Transaction version (1) is not supported by the requesting client. Please use \"maxSupportedTransactionVersion\" in your request." }, "id": 1 } ``` Für `getBlock` schlägt eine v1-Transaktion im Block die gesamte Anfrage fehl. Wenn Sie `-32015` in Ihren Protokollen sehen, schlägt das Projekt bereits bei versionierten Transaktionen fehl. ```json getTransaction theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getTransaction", "params": [ "2id3YC2jK9G5Wo2phDx4gJVAew8DcY5NAojnVuao8rkxwPYPe8cSwE5GzhEgJA2y8fVjDEo6iR6ykBvDxrTQrtpb", { "encoding": "jsonParsed", "commitment": "confirmed", "maxSupportedTransactionVersion": 1 } ] } ``` ```json getBlock theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getBlock", "params": [ 341197053, { "encoding": "jsonParsed", "transactionDetails": "full", "maxSupportedTransactionVersion": 1 } ] } ``` ```json getTransactionsForAddress theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getTransactionsForAddress", "params": [ "86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY", { "transactionDetails": "full", "encoding": "jsonParsed", "limit": 100, "maxSupportedTransactionVersion": 1 } ] } ``` ```json transactionSubscribe theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "transactionSubscribe", "params": [ { "accountInclude": ["86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY"] }, { "commitment": "confirmed", "encoding": "jsonParsed", "transactionDetails": "full", "maxSupportedTransactionVersion": 1 } ] } ``` ## Aktualisieren Sie Ihr SDK, bevor Sie den Wert erhöhen Das Setzen von `maxSupportedTransactionVersion: 1` teilt dem Knoten mit, v1-Transaktionen zurückzugeben. Ihre Client-Bibliothek muss sie dennoch deserialisieren. Aktualisieren Sie zuerst und ändern Sie dann den Parameter: | Client | Mindestversion mit Unterstützung für Transaktionen v1 | | ----------------------------------------------- | ----------------------------------------------------- | | `@solana/kit` | 8.0 | | `@solana/web3.js` | v3 | | Rust `solana-sdk` / `solana-transaction-status` | Eine auf Agave 4.2-Paketen basierte Veröffentlichung | | `yellowstone-grpc-client` | 13.3.0 | | `yellowstone-grpc-proto` | 12.6.0 | | `helius-laserstream` (JavaScript) | 0.8.4 | | `helius-laserstream` (Rust) | 0.6.3 | | `helius-laserstream` (Go) | 0.2.0 | Ältere `VersionedTransaction.deserialize`-Implementierungen in JavaScript verarbeiten nur Legacy und v0 und werfen bei einem führenden `0x81`-Byte einen Fehler. Ältere Yellowstone-Protos sind vor den v1-Nachrichtenfeldern, daher sehen gRPC-Verbraucher in diesen Versionen nie `transactionConfig`. Für Go gRPC-Clients, regenerieren Sie von den neuesten Yellowstone-Protos und `solana-storage-proto`. ## Lesen Sie prioritäre Gebühren aus transactionConfig Code, der die Prioritätsgebühr einer Transaktion schätzt, indem er nach ComputeBudget-Programmanweisungen sucht (`ComputeBudget111111111111111111111111111111`, `setComputeUnitPrice`, `setComputeUnitLimit`), liest jede v1-Transaktion als zahlen null. In v1 befinden sich die Werte in `message.transactionConfig`, und die Einheiten unterscheiden sich: | Format | Wo die Gebühr lebt | Einheit | | ---------- | ------------------------------- | ------------------------------------- | | Legacy, v0 | `setComputeUnitPrice`-Anweisung | Mikro-Lamports pro Berechnungseinheit | | v1 | `transactionConfig.priorityFee` | Gesamte Lamports für die Transaktion | Portieren Sie nicht die Legacy `price × computeUnitLimit ÷ 1e6`-Mathematik auf `priorityFee`. Es ist bereits die Summe. ```typescript priority-fee.ts theme={"system"} import bs58 from "bs58"; const COMPUTE_BUDGET = "ComputeBudget111111111111111111111111111111"; /** Total priority fee in lamports for a `json`-encoded transaction. */ function priorityFeeLamports(tx: any): number { const message = tx.transaction.message; // v1: the header carries the total directly. if (message.transactionConfig) { return message.transactionConfig.priorityFee ?? 0; } // Legacy and v0: derive it from ComputeBudget instructions. let microLamportsPerCu = 0n; let computeUnitLimit: bigint | null = null; let otherInstructions = 0; for (const ix of message.instructions) { if (message.accountKeys[ix.programIdIndex] !== COMPUTE_BUDGET) { otherInstructions++; continue; } const data = bs58.decode(ix.data); const view = new DataView(data.buffer, data.byteOffset, data.byteLength); if (data[0] === 2) computeUnitLimit = BigInt(view.getUint32(1, true)); if (data[0] === 3) microLamportsPerCu = view.getBigUint64(1, true); } // Without an explicit limit, the runtime grants 200,000 CU per non-ComputeBudget instruction, capped at 1,400,000. const limit = computeUnitLimit ?? BigInt(Math.min(otherInstructions * 200_000, 1_400_000)); return Number((microLamportsPerCu * limit) / 1_000_000n); } ``` Verzweigen Sie auf `transactionConfig` (oder auf `version === 1`), anstatt auf das Vorhandensein von ComputeBudget-Anweisungen zu achten, da eine Legacy-Transaktion ohne Prioritätsgebühr ebenfalls keine hat. ## Dekodieren Sie rohe Transaktionsbytes mit einem v1-fähigen Parser Dieser Abschnitt gilt nur, wenn Sie rohe Transaktionsbytes konsumieren, zum Beispiel von [preconfSubscribe](/docs/de/pre-confirmations/preconf-subscribe), [preprocessedSubscribe](/docs/de/preprocessed-transactions/preprocessed-subscribe) oder einer `base64`-kodierten RPC-Antwort. Wenn Sie mit `json`- oder `jsonParsed`-Antworten arbeiten, überspringen Sie es. Transaktion v1 ändert das Drahtlayout auf zwei Arten: * **Versionsbyte.** Eine v1-Transaktion beginnt mit `0x81` (dezimal 129). Eine v0-Transaktion beginnt mit `0x80`. * **Signaturen verschieben sich ans Ende.** Legacy und v0 platzieren Signaturen zuerst, dann die Nachricht. Transaktion v1 platziert die Nachricht zuerst und die Signaturen zuletzt, so dass `bincode`-Decoder, die ein führendes Signaturfeld erwarten, bei v1-Bytes fehlschlagen. Byte-für-Byte-Layout einer Solana-Transaktion v1: Versionsbyte, Header, Konfigurationsmaske, Lebenszeit-Spezifizierer, Adress- und Anweisungszählungen, drei 32-Byte-Adresse, Compute-Unit-Konfiguration, Anweisungs-Header, Indices, Discriminatoren, Lamports und eine 64-Byte-Signatur am Ende Für eine Schritt-für-Schritt-Walkthrough des v1-Drahtformats siehe [Transaktion v1 im Solana-Transaktionsversionsartikel](https://www.helius.dev/blog/solana-transaction-versions#transaction-v1). Verwenden Sie einen Decoder, der das v1-Layout versteht: * **Rust:** [`agave-transaction-view`](https://docs.rs/agave-transaction-view) analysiert Legacy, v0 und v1 vor Ort. [`wincode`](https://docs.rs/wincode), der bincode-kompatible Serializer, der von aktuellen Solana-SDKs verwendet wird, dekodiert auch v1 in `VersionedTransaction`. * **JavaScript / TypeScript:** `@solana/kit` 8.0+ oder `@solana/web3.js` v3. Benutzerdefinierte Decoder müssen das erste Byte überprüfen: `0x81` bedeutet v1 und die Signaturen folgen der Nachricht anstatt sie voranzustellen. ## Checkliste 1. Durchsuchen Sie `getBlock`, `getTransaction`, `getTransactionsForAddress`, `transactionSubscribe` und `blockSubscribe`, einschließlich roher JSON-RPC-Körperschaften und SDK-Wrapper wie `connection.getParsedTransaction`. 2. Aktualisieren Sie auf ein v1-fähiges SDK. 3. Setzen Sie `maxSupportedTransactionVersion: 1` bei jedem in Schritt 1 gefundenen Aufruf. 4. Ersetzen Sie das Scannen von ComputeBudget-Anweisungen durch eine `transactionConfig`-Prüfung, und behandeln Sie `priorityFee` als Gesamtlaports. 5. Ersetzen Sie `bincode`-Style-Rohdecoder durch `agave-transaction-view` oder ein aktualisiertes SDK. 6. Aktualisieren Sie Streaming-Abhängigkeiten auf die Versionen in der Tabelle oben. 7. Durchsuchen Sie Protokolle nach `-32015` nach der Änderung, um sicherzustellen, dass nichts mehr fehlschlägt. Für einen technischen Deep Dive in die Solana-Transaktionsversionsspezifikationen, Drahtformate und Beispiele, lesen Sie unseren Artikel, [Solana Transaction Versioning: Legacy, v0 und v1](https://www.helius.dev/blog/solana-transaction-versions). ## Verwandt Parameter, Antwortform und Beispiele zum Abrufen einer einzelnen Transaktion. Laden Sie einen vollständigen Block, einschließlich jeder darin enthaltenen Transaktion. Gefilterte, paginierte Transaktionshistorie für jede Adresse in einem Aufruf. Jede Agave 4.2-breaking changes mit Maßnahmen zur Behebung.