Réussissez l’atelier de cette leçon pour maîtriser la notion. Les points sont attribués une seule fois.
Lire la transaction comme une opération complète
À la fin, expliquez le schéma avec vos mots, résolvez le cas et justifiez la correction.
Prérequis : Un registre partagé · Coin, token, réseau et adresse
Niveau 2 · Intermédiaire →Parcours de lecture · 36 / 37 · Intermédiaire
Solana est un réseau programmable de couche 1.
L’essentiel
Solana est un réseau programmable de couche 1. SOL sert aux frais de transaction et au staking. Son modèle de comptes et de programmes diffère de celui d’Ethereum : instruction, compte de token et adresse de wallet ne doivent pas être assimilés à un transfert ERC-20.
Le mécanisme
Solana utilise la preuve d’enjeu ; la preuve d’histoire aide à établir l’ordre sans remplacer toutes les fonctions du consensus. Une transaction peut réunir plusieurs instructions. Ses frais dépendent de la transaction et des paramètres de priorité. Une réponse rapide doit être interprétée selon le niveau de confirmation et la politique d’acceptation de l’application.
Les points d’attention
L’analyse couvre dépendances aux validateurs et clients, accès RPC, autorités des programmes et contrôles propres aux tokens. Vérifiez le mint exact et le réseau avant un transfert. Les récompenses de staking dépendent des paramètres et des opérateurs ; elles sont distinctes du prix de SOL et ne garantissent pas un rendement positif en euros.
Comprendre en profondeur
Une transaction Solana regroupe des instructions, des comptes et les signatures autorisant les opérations. L’exécution est atomique : si une instruction échoue, les changements d’état de la transaction sont annulés, mais des frais peuvent rester dus. Distinguez ce résultat de l’exécution du niveau de confirmation. Avant de signer, examinez le programme appelé et les comptes concernés.
Limites et erreurs fréquentes
L’analyse couvre dépendances aux validateurs et clients, accès RPC, autorités des programmes et contrôles propres aux tokens. Vérifiez le mint exact et le réseau avant un transfert. Les récompenses de staking dépendent des paramètres et des opérateurs ; elles sont distinctes du prix de SOL et ne garantissent pas un rendement positif en euros.
Le mécanisme en un schéma
- 01Comptes et programmes
- 02Instructions
- 03Exécution atomique
- 04Confirmation et frais
Ces repères représentent des notions liées, pas nécessairement des étapes successives.
Lire l’explication
Une transaction Solana regroupe des instructions, des comptes et les signatures autorisant les opérations. L’exécution est atomique : si une instruction échoue, les changements d’état de la transaction sont annulés, mais des frais peuvent rester dus. Distinguez ce résultat de l’exécution du niveau de confirmation. Avant de signer, examinez le programme appelé et les comptes concernés.
Replacez le mécanisme dans son contexte
Une transaction fictive contient deux instructions. La première modifierait un compte de token ; la seconde échoue à l’exécution. Quelqu’un affirme que la première modification reste acquise parce qu’elle a été exécutée avant. Dessinez la frontière de transaction autour des deux instructions.
Appliquer dans l’atelier →Ce que ce mécanisme ne garantit pas
L’analyse couvre dépendances aux validateurs et clients, accès RPC, autorités des programmes et contrôles propres aux tokens. Vérifiez le mint exact et le réseau avant un transfert. Les récompenses de staking dépendent des paramètres et des opérateurs ; elles sont distinctes du prix de SOL et ne garantissent pas un rendement positif en euros.
La distinction qui change l’analyse
Si la seconde instruction échoue, les changements d’état de la première ne survivent pas comme réussite partielle de cette transaction. Dessinez une frontière autour de l’ensemble. Frais et confirmation restent des contrôles distincts du résultat atomique.
À vous de l’expliquer
Reprenez le cas ci-dessus. Nommez ce qui est établi, ce qui reste à vérifier et la preuve qui permettrait de conclure. Une réponse solide traite les deux côtés du schéma.
Appliquer la leçon à un cas
Une transaction fictive contient deux instructions. La première modifierait un compte de token ; la seconde échoue à l’exécution. Quelqu’un affirme que la première modification reste acquise parce qu’elle a été exécutée avant. Dessinez la frontière de transaction autour des deux instructions.
L’atomicité regroupe ces changements. Un échec ne signifie pas que la tentative est gratuite, et une transaction signée ne prouve pas à elle seule une exécution réussie.
Préparer une note de correction
Décrivez le passage et la correction proposée. Vous pourrez copier cette note pour la partager ; rien n’est envoyé. N’incluez aucune donnée personnelle ou confidentielle.