Construire des contrats intelligents sur Solana : un guide du débutant sur Rust

Comprendre l'environnement d'exécution de Solana

1. Solana utilise un environnement d'exécution parallélisé appelé Sealevel, qui permet à des milliers de contrats intelligents, appelés programmes, de s'exécuter simultanément sur différents comptes.

2. Contrairement à l'EVM d'Ethereum, Solana ne s'appuie pas sur une machine à états globale ; au lieu de cela, chaque programme fonctionne sur des données de compte isolées, appliquant des modèles stricts de propriété et d'autorisation.

3. Les programmes sur Solana sont compilés avec le bytecode Berkeley Packet Filter (BPF), ce qui oblige les développeurs à écrire en Rust ou C et à compiler sur cette architecture cible.

4. L'exonération du loyer du compte est obligatoire : chaque compte en chaîne doit contenir suffisamment de SOL pour couvrir le loyer de stockage, sinon il risque d'être effacé du grand livre.

5. Les frais de transaction sont déterministes et extrêmement faibles, calculés sur la base des unités de calcul consommées plutôt que sur l'estimation du gaz, ce qui rend la prévision des coûts plus précise.

Configuration de la pile de développement Rust

1. Installez rustup via le programme d'installation officiel de Rust pour gérer les chaînes d'outils, puis ajoutez la cible BPF avec rustup target add bpfel-unknown-elf .

2. Utilisez la CLI Solana pour configurer votre validateur local, générer des paires de clés et déployer des programmes : des commandes telles que solana-test-validator lancent instantanément un cluster local.

3. L’ancrage n’est pas obligatoire mais largement adopté ; il résume les éléments passe-partout tels que la sérialisation des comptes, la gestion du CPI et les définitions d'erreurs dans des macros et des traits réutilisables.

4. La caisse du programme Solana fournit des types de base tels que Pubkey, AccountInfo et ProgramResult, constituant la base de chaque programme Solana.

5. Le débogage repose en grande partie sur la journalisation via msg ! macros : elles apparaissent dans les journaux de transactions et sont essentielles pour suivre le flux d'exécution pendant le développement.

Écrire votre premier programme en chaîne

1. Un programme minimal exporte un point d'entrée ! macro qui accepte les données d'instruction et une tranche de références de compte, servant d'unique interface avec le runtime.

2. La désérialisation des instructions doit être explicite : les développeurs analysent manuellement les octets bruts ou utilisent la macro de dérive InstructionData d'Anchor pour générer automatiquement des sérialiseurs.

3. Chaque compte transmis au programme doit être validé pour la propriété, la mutabilité, le statut de signataire et l'exonération de loyer avant qu'une mutation d'état ne se produise.

4. Les programmes ne peuvent pas stocker directement des structures de données arbitraires : ils conservent leur état en écrivant des octets sérialisés dans des tampons de données de compte, souvent en utilisant Borsh ou bincode.

5. Les invocations inter-programmes (CPI) nécessitent la construction de structures d'instructions avec des comptes correctement signés ; le fait de ne pas inclure un signataire requis entraînera un échec immédiat de la transaction.

Flux de travail de test et de déploiement

1. Les tests unitaires s'exécutent hors chaîne à l'aide de solana-program-test , simulant la création de compte, la soumission d'instructions et les assertions d'état sans interaction réseau.

2. Les tests d'intégration déploient des programmes compilés sur un validateur de tests local et simulent des interactions client réelles à l'aide de @solana/web3.js dans TypeScript.

3. Le déploiement sur devnet nécessite de financer l'adresse du programme avec SOL et d'exécuter le programme solana déployer , qui télécharge le bytecode ELF et attribue une Pubkey unique.

4. Les programmes évolutifs sont déployés avec des comptes tampon et des autorisations de mise à niveau : cette séparation permet d'appliquer une logique de correctif sans migrer les données utilisateur.

5. La gestion des versions est manuelle : il n'y a pas de registre de versions de contrat intégré, les développeurs intègrent donc des identifiants de version dans les données de compte ou des discriminants d'instructions.

Foire aux questions

Q : Puis-je utiliser JavaScript ou Python pour rédiger des contrats intelligents Solana ? R : Non. Solana exécute uniquement le bytecode BPF. Seuls Rust et C compilent de manière fiable vers cette cible. Les langages de haut niveau peuvent générer une logique côté client ou des définitions IDL mais ne peuvent pas remplacer les programmes en chaîne.

Q : Pourquoi est-ce que j'obtiens le message « Compte appartenant à un autre programme » lorsque j'essaie de modifier un compte ? R : Cela se produit lorsque le champ du propriétaire du compte pointe vers la Pubkey d'un autre programme. Seul le programme propriétaire peut écrire sur ses comptes, sauf si cela est explicitement délégué via CPI ou des adresses dérivées du programme.

Q : Que se passe-t-il si mon programme dépasse le budget de calcul lors de l'exécution ? R : La transaction s'arrête immédiatement, annule tous les changements d'état et renvoie une erreur « ComputationalBudgetExceeded ». Les développeurs doivent optimiser les boucles, limiter les itérations et éviter les allocations de mémoire illimitées.

Q : Est-il possible de lire les données du compte d'un autre programme sans l'invoquer ? R : Oui. Tout compte marqué comme non exécutable et lisible publiquement peut être récupéré via des points de terminaison RPC comme getAccountInfo . Cependant, les programmes exécutables et les données privées restent inaccessibles sans autorisations appropriées.