> ## 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. # Support de la Transaction v1 > Préparez votre intégration Solana pour la transaction v1 : définissez maxSupportedTransactionVersion à 1, passez à un SDK compatible v1, et lisez les frais de priorité depuis transactionConfig. Agave 4.2 introduit la transaction v1 ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)). Une fois la porte de fonctionnalité activée sur le réseau principal, les portefeuilles et programmes commencent à soumettre des transactions v1, et toute requête qui récupère les données de transaction complètes doit opter pour les recevoir. Cette page couvre les changements, les points d'extrémité Helius affectés et comment mettre à jour votre code. Pour la liste complète de vérification d'Agave 4.2, y compris les types de récompenses, les sémantiques de mise à jour des comptes et le minutage des créneaux, voir la [checklist de migration Agave 4.2](https://www.helius.dev/blog/agave-4-2-migration-checklist). ## Ce qui change dans la transaction v1 Les transactions Legacy et v0 restent inchangées. Pour la plupart des intégrations, deux choses concernant la transaction v1 sont importantes : * **Vous devez opter pour la recevoir.** Les requêtes pour les données complètes de transaction nécessitent `maxSupportedTransactionVersion: 1`, et votre bibliothèque client nécessite une version capable de désérialiser v1. * **Le budget de calcul passe dans l'en-tête du message.** Un message v1 transporte un objet `transactionConfig` avec `computeUnitLimit`, `heapSize`, `loadedAccountsDataSizeLimit`, et `priorityFee`. Il n'y a pas d'instructions de programme ComputeBudget dans une transaction v1. Le format de transmission change également (un nouvel octet de version et des signatures à la fin de la transaction), mais cela n'affecte que le code qui décode les octets de transaction bruts. Voir [Décodez les octets de transaction bruts](#décodez-les-octets-de-transaction-bruts-avec-un-analyseur-compatible-v1) ci-dessous. Dans les réponses JSON, une transaction v1 rapporte `"version": 1` et son `message` inclut `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` signifie que cette transaction paie 50,000 lamports au total. Un champ `null` signifie que l'expéditeur ne l'a pas défini. Les messages Legacy et v0 omettent complètement `transactionConfig`. ## Définir maxSupportedTransactionVersion à 1 Chaque requête qui retourne des données complètes de transaction doit déclarer la version de transaction la plus élevée qu'elle peut gérer. Définissez `maxSupportedTransactionVersion: 1` sur : * [`getTransaction`](/docs/fr/rpc/guides/gettransaction) * [`getBlock`](/docs/fr/rpc/guides/getblock) * [`getTransactionsForAddress`](/docs/fr/rpc/gettransactionsforaddress) avec `transactionDetails: "full"` * [`transactionSubscribe`](/docs/fr/rpc/websocket/transaction-subscribe) avec `transactionDetails: "accounts"` ou `"full"` * [`blockSubscribe`](/docs/fr/api-reference/rpc/websocket/blocksubscribe) Une requête qui omet le paramètre, ou le définit à `0`, échoue avec l'erreur JSON-RPC `-32015` dès qu'elle touche une transaction v1 : ```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 } ``` Pour `getBlock`, une seule transaction v1 n'importe où dans le bloc fait échouer la requête entière. Si vous voyez `-32015` dans vos journaux, le projet échoue déjà sur les transactions versionnées. ```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 } ] } ``` ## Mettez à niveau votre SDK avant d'augmenter la valeur Définir `maxSupportedTransactionVersion: 1` indique au nœud de retourner des transactions v1. Votre bibliothèque client doit encore les désérialiser. Mettez à niveau d'abord, puis changez le paramètre : | Client | Version minimale avec support de la transaction v1 | | ----------------------------------------------- | -------------------------------------------------- | | `@solana/kit` | 8.0 | | `@solana/web3.js` | v3 | | Rust `solana-sdk` / `solana-transaction-status` | Une version basée sur les crates Agave 4.2 | | `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 | Les anciennes implémentations `VersionedTransaction.deserialize` en JavaScript ne gèrent que les versions Legacy et v0 et lancent une exception sur un octet de version `0x81`. Les anciens protos de Yellowstone précèdent les champs de message v1, donc les consommateurs gRPC sur ces versions ne voient jamais `transactionConfig`. Pour les clients gRPC Go, régénérez à partir des derniers protos de Yellowstone et `solana-storage-proto`. ## Lire les frais de priorité à partir de transactionConfig Le code qui estime le frais de priorité d'une transaction en recherchant des instructions de programme ComputeBudget (`ComputeBudget111111111111111111111111111111`, `setComputeUnitPrice`, `setComputeUnitLimit`) lit chaque transaction v1 comme payant zéro. Sur v1, les valeurs résident dans `message.transactionConfig`, et les unités diffèrent : | Format | Où se trouve le frais | Unité | | ---------- | --------------------------------- | ----------------------------------- | | Legacy, v0 | Instruction `setComputeUnitPrice` | Micro-lamports par unité de calcul | | v1 | `transactionConfig.priorityFee` | Lamports totaux pour la transaction | Ne portez pas le calcul `price × computeUnitLimit ÷ 1e6` hérité sur `priorityFee`. C'est déjà le total. ```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); } ``` Branchez sur `transactionConfig` (ou sur `version === 1`) plutôt que sur la présence d'instructions ComputeBudget, car une transaction héritée sans frais de priorité n'a aucune non plus. ## Décodez les octets de transaction bruts avec un analyseur compatible v1 Cette section ne s'applique que si vous consommez des octets de transaction bruts, par exemple à partir de [preconfSubscribe](/docs/fr/pre-confirmations/preconf-subscribe), [preprocessedSubscribe](/docs/fr/preprocessed-transactions/preprocessed-subscribe), ou d'une réponse RPC codée `base64`. Si vous travaillez avec des réponses `json` ou `jsonParsed`, passez-le. La transaction v1 modifie la disposition du fil de deux manières : * **Octet de version.** Une transaction v1 commence par `0x81` (décimal 129). Une transaction v0 commence par `0x80`. * **Les signatures passent à la fin.** Les transactions Legacy et v0 mettent d'abord les signatures, puis le message. La transaction v1 met d'abord le message et les signatures en dernier, donc les décodeurs de style `bincode` qui s'attendent à un tableau de signatures en tête échouent sur les octets v1. Disposition octet par octet d'une transaction Solana v1 : octet de version, en-tête, masque de configuration, spécificateur de durée de vie, nombre d'adresses et d'instructions, trois adresses de 32 octets, configuration des unités de calcul, en-tête d'instruction, indices, discriminants, lamports, et une signature de 64 octets à la fin Pour un aperçu champ par champ du format de fil v1, voir [Transaction v1 dans l'article sur les versions de transaction Solana](https://www.helius.dev/blog/solana-transaction-versions#transaction-v1). Utilisez un décodeur qui comprend la disposition v1 : * **Rust :** [`agave-transaction-view`](https://docs.rs/agave-transaction-view) analyse Legacy, v0, et v1 sur place. [`wincode`](https://docs.rs/wincode), le sérialiseur compatible bincode utilisé par les SDK Solana actuels, décode également v1 en `VersionedTransaction`. * **JavaScript / TypeScript :** `@solana/kit` 8.0+ ou `@solana/web3.js` v3. Les décodeurs personnalisés doivent vérifier le premier octet : `0x81` signifie v1 et les signatures suivent le message au lieu de le précéder. ## Liste de vérification 1. Recherchez `getBlock`, `getTransaction`, `getTransactionsForAddress`, `transactionSubscribe`, et `blockSubscribe`, y compris les corps JSON-RPC bruts et les wrappers SDK comme `connection.getParsedTransaction`. 2. Mettez à niveau vers un SDK compatible v1. 3. Définissez `maxSupportedTransactionVersion: 1` sur chaque appel trouvé à l'étape 1. 4. Remplacez la recherche d'instruction ComputeBudget par une vérification `transactionConfig`, et traitez `priorityFee` comme des lamports totaux. 5. Remplacez les décodeurs bruts de style `bincode` par `agave-transaction-view` ou un SDK mis à jour. 6. Augmentez les dépendances de streaming aux versions du tableau ci-dessus. 7. Recherchez les journaux pour `-32015` après le changement pour confirmer que rien n'échoue encore. Pour une plongée technique sur les spécifications des versions de transaction Solana, les formats de fil et les exemples, lisez notre article, [Versioning des Transactions Solana : Legacy, v0 et v1](https://www.helius.dev/blog/solana-transaction-versions). ## En relation Paramètres, forme de réponse et exemples pour récupérer une seule transaction. Récupérez un bloc complet, y compris chaque transaction qu'il contient. Historique des transactions filtrées et paginées pour toute adresse en un appel. Chaque changement important d'Agave 4.2, avec des étapes de remédiation.