3 min de lecture

Aperçu

Le 10 octobre 2022 (époque 358), Solana a ajouté la prise en charge de nouveaux types de versions de transactions grâce à un concept appelé «transactions versionnées ». Suite à cette modification, le runtime Solana prend désormais en charge deux types de transactions : « legacy » (transactions plus anciennes) et « 0 » (transactions incluant des tables de recherche d'adresses). Bien que les programmes sur la chaîne n'aient pas à adopter cette modification, de nombreuses applications côté client doivent être mises à jour afin d'éviter les erreurs liées aux différents types de transactions.

Dans ce guide, vous découvrirez les modifications techniques résultant du lancement des transactions versionnées de Solana, ainsi que la manière de mettre à jour votre code côté client pour prendre en charge ces changements.

Ce dont vous aurez besoin

• Node.js (version 16.15 ou supérieure) installé
• Expérience avec l'API JSON-RPC Web3 de Solana

Modifications du code côté client : version maximale prise en charge pour les transactions

Les requêtes JSON-RPC Solana qui renvoient une transaction incluent désormais un paramètre facultatif, `maxSupportedTransactionVersion`. Ce paramètre indique au moteur d'exécution la version la plus élevée des transactions à laquelle l'application doit s'attendre. À la date de rédaction de cet article (11/10/2022), deux valeurs peuvent être transmises :

• format hérité: ancien format de transaction ne présentant aucun avantage supplémentaire
• 0: prise en charge des tables de correspondance d'adresses

Si la requête renvoie une transaction dont la version est supérieure à celle définie dans `maxSupportedTransactionVersion` (c'est-à-dire si une transaction de version 0 est renvoyée alors que l'option « legacy » est sélectionnée), le moteur d'exécution renverra une erreur.

Comment éviter les erreurs dans les applications existantes

À l'heure actuelle, deux méthodes JSON-RPC natives de Solana sont concernées par cette modification et doivent inclure un paramètre « maxSupportedTransactionVersion » :

• getBlock
• getTransaction
  (Remarque : les méthodes non natives getParsedTransaction et getParsedBlock acceptent également ce paramètre)

Bien que le paramètre ` maxSupportedTransactionVersion ` soit facultatif dans les deux méthodes, il est recommandé de le définir sur 0 afin de prendre en charge tous les types de transactions et d'éviter les erreurs.

getBlock()

getBlock les appels de méthode devraient ajouter { maxSupportedTransactionVersion: 0 } après le slot pour rechercher :

const web3 = require("@solana/web3.js");
(async () => {
  const solana = new web3.Connection("https://example.solana-mainnet.quiknode.pro/0123456/");
  console.log(
    await solana.getBlock(
        94101948, 
        //ADD THIS 👇
        { maxSupportedTransactionVersion: 0 })
  );
})();

La classe renvoyée, `VersionedBlockResponse`, est très similaire à `BlockResponse`, mais présente une différence majeure. Le tableau `Transactions` inclura une classe `MessageV0` à la place de `Message`, ce qui vous permettra d'accéder à `addressTableLookups`. Pour plus de détails sur la classe `MessageV0`, consultez solana-labs.github.io/.

getTransaction()

getTransaction les appels de méthode devraient ajouter { maxSupportedTransactionVersion: 0 } après le identifiant de transaction pour rechercher :

const web3 = require("@solana/web3.js");
(async () => {
  const solana = new web3.Connection("https://example.solana-mainnet.quiknode.pro/0123456/");
  console.log(
    await solana.getTransaction(
        "D13jTJYXoQBcRY9AfT5xRtsew7ENgCkNs6mwwwAcUCp4ZZCEM7YwZ7en4tVsoDa7Gu75Jjj2FgLXNUz8Zmgedff",
        //ADD THIS 👇
        { maxSupportedTransactionVersion: 0 }
    )
  );
})();

Référence : edge.docs.solana.com/.../versioned-transactions

Résultats de l'analyse JSON

La Fondation Solana recommande désormais d’utiliser l’encodage JSON Parsed, car celui-ci inclut toutes les clés de compte de transaction (y compris celles issues des tables de correspondance) dans la liste « accountKeys » du message. Cela facilite la résolution des variations de solde détaillées dans les champs preBalances / postBalances et preTokenBalances / postTokenBalances. Si l'encodage « json » est utilisé à la place, les entrées des champs « preBalances » / « postBalances » et « preTokenBalances » / « postTokenBalances » peuvent faire référence à des clés de compte qui ne figurent PAS dans la liste « accountKeys » et doivent être identifiées à l'aide des entrées « loadedAddresses » présentes dans les métadonnées de la transaction. (Source : Fondation Solana).

Pour vos applications JavaScript, cela signifie simplement de modifier

• de `getTransaction() ` à ` getParsedTransaction() ` et
• de getBlock() à getParsedBlock()

Pour les requêtes cURL/CURL, définissez l'encodage sur « jsonParsed » :

{"encoding": "Parsed"}

Référence : docs.solana.com/...versioned-transaction-migration

Récapitulatif

Si vous utilisez déjà du code côté client et que vous vous servez de `getBlock` ou `getTransaction`, vous n'avez rien d'autre à faire ! Si vous utilisez Python ou cURL/CURL Requests, consultez notre documentation pour découvrir des exemples de code ici.

Les transactions versionnées sont là pour rester, et à mesure que de nouvelles versions seront mises en œuvre, vous devrez vous tenir au courant des mises à jour du réseau afin de vous assurer que votre dApp puisse prendre en charge les dernières versions. Pour rester informé des dernières actualités et informations concernant Solana, abonnez-vous à notre newsletter ou suivez-nous sur Twitter.

Si vous avez des questions ou si vous souhaitez discuter de votre projet, n'hésitez pas à nous envoyer un message sur Discord.

Nous ❤️ les commentaires ! 

Si vous avez des commentaires ou des questions concernant ce guide, n'hésitez pas à nous en faire part. Nous serions ravis d'avoir votre avis !