Comment fonctionnent les transactions sur Solana ?

Chaque frais étant payé lors de l'exécution d'une transaction, il est utile de comprendre leur fonctionnement. Une transaction se compose de trois parties :

une ou plusieurs instructions
un tableau de comptes à lire ou à écrire
une ou plusieurs signatures
un blockhash récent ou un nonce

Une instruction est la plus petite unité de logique d'exécution sur Solana. Les instructions sont des appels permettant de mettre à jour l'état global de Solana. Elles invoquent des programmes qui appellent le runtime Solana pour mettre à jour l'état (par exemple, appeler le Token Program pour transférer des tokens de votre compte vers un autre compte). Vous pouvez assimiler une instruction à un appel de fonction sur un smart contract Ethereum.

Une différence majeure entre Ethereum et Solana réside dans le nombre d'appels de fonctions au sein d'une seule transaction, lié au nombre d'instructions. La prise en charge de plusieurs instructions par transaction est un avantage pour les développeurs, car ils n'ont pas besoin de créer des smart contracts personnalisés pour enchaîner des fonctions dans une seule transaction. Chaque instruction peut être un appel de fonction distinct, exécuté dans l'ordre au sein de la transaction. Les transactions sont atomiques, ce qui signifie que si l'une de ces instructions échoue, l'ensemble de la transaction échoue, et seuls les frais de transaction vous seront facturés. C'est comparable à l'échec d'une transaction dû à un slippage incorrect sur Ethereum.

Une autre différence importante à retenir est l'utilisation d'un blockhash récent plutôt que d'un nonce incrémental pour les transactions. Lorsqu'un portefeuille souhaite effectuer une transaction, un blockhash récent est extrait du cluster afin de créer une transaction valide. Ce blockhash récent ne rend la transaction valide que pendant 150 blocs après sa récupération. Cela empêche les signatures de transaction à longue durée de vie d'être exécutées bien plus tard.

Cross-Program Invocation (CPI)

Un Cross-Program Invocation (CPI) se produit lorsqu'un programme Solana appelle une instruction sur un autre programme pendant l'exécution de la transaction d'origine. Le CPI est le principal mécanisme de composition entre programmes Solana, mais le modèle de compte influe sur la conception du graphe d'appels : la transaction doit inclure tous les comptes que l'ensemble de la chaîne CPI lira ou écrira avant le début de l'exécution.

Le programme appelé hérite uniquement des privilèges de signature et d'écriture accordés à l'appelant, et consomme le même budget de calcul de transaction. Utilisez invoke lorsque tous les signataires requis ont signé la transaction d'origine. Utilisez invoke_signed lorsque le programme appelant doit signer pour l'un de ses PDAs avec des seeds de signataire.

Niveaux de confirmation

Les lectures RPC, les abonnements et la logique de confirmation des transactions peuvent choisir un niveau de commitment. C'est l'équivalent Solana du choix du nombre de confirmations de blocs Ethereum à attendre, à la différence que les niveaux sont explicites :

processed : la vue la plus récente traitée par le nœud. À utiliser uniquement pour une UI optimiste ou des flux tolérant les retours en arrière.
confirmed : un bloc ayant reçu les votes d'une supermajorité du stake. À utiliser par défaut pour la plupart des confirmations en production et le statut des transactions côté utilisateur.
finalized : l'état de confirmation le plus fort. À utiliser avant toute action hors chaîne irréversible, comme les paiements en monnaie fiduciaire, l'expédition de marchandises ou les enregistrements de règlement définitif.

Si une méthode RPC accepte le commitment et que vous l'omettez, la valeur par défaut est généralement finalized. Les clients en production doivent tout de même définir le commitment explicitement afin que la latence de l'interface, le comportement de l'indexeur et la politique de règlement soient intentionnels.