Passer d'EVM à SVM (Solana) nécessite de comprendre plusieurs différences clés entre les machines virtuelles. Cet article passera en revue plusieurs de ces différences, notamment les comptes, les frais, les transactions, les contrats intelligents (programmes) et bien plus encore. Il explorera également la configuration du développeur, y compris les outils et les SDK.
À la fin, les développeurs auront les connaissances nécessaires pour commencer leur voyage Solana.
Comprendre les différences fondamentales
Pour commencer, examinons la différence la plus significative entre EVM et SVM : la conception du modèle de compte.
Modèle de compte
Contrairement à Ethereum, Solana a été conçu pour tirer parti de plusieurs cœurs et prendre en charge les transactions parallèles. Pour y parvenir, Solana utilise un modèle de compte.
Un compte sur Solana est un enregistrement dans le grand livre Solana qui contient des données (un compte de données) ou est un programme exécutable (un contrat intelligent ou un programme sur Solana).
Comme Ethereum, chaque compte possède un identifiant d’adresse. Cependant, contrairement à Ethereum, où chaque contrat intelligent est un compte dont la logique d’exécution et le stockage sont liés, les contrats intelligents de Solana sont entièrement apatrides. L'État doit être transmis aux comptes pour qu'ils puissent être exécutés.
Regardons un exemple de code. Dans le code Solidity ci-dessous, l'état est lié au contrat intelligent avec la ligne int private count = 0.
Avec Rust (Solana), il existe une structure dans le contrat intelligent indiquant initialize_counter. Ce compteur initial crée un compte avec un compte de 0. Le compte est transmis à ce compteur pour incrémenter le compte. Cela empêche l’état d’être conservé dans le contrat intelligent lui-même.
Avec Solana, les données sont stockées dans des comptes séparés en dehors du programme. Pour exécuter la logique dans un programme, transmettez le compte sur lequel effectuer l'exécution.
Dans le cas de ce programme de compteur, transmettez un compte de compteur au programme lors de l'appel de la fonction d'incrémentation, et le programme incrémente ensuite la valeur dans le compte de compteur.
Avantages de la conception du modèle de compte
L'un des principaux avantages de ce modèle de compte est la réutilisabilité du programme.
Avec l'interface ERC20 sur Ethereum, chaque fois qu'un développeur crée un nouveau jeton, il doit redéployer le contrat intelligent ERC20 sur Ethereum avec ses valeurs spécifiées. Ce redéploiement entraîne un coût élevé.
Mais avec Solana, il n'est pas nécessaire de créer et de déployer un nouveau contrat intelligent pour créer un nouveau token. Au lieu de cela, créez un nouveau compte, appelé compte mint, à l'aide du programme de jetons Solana, en transmettant des détails tels que le nombre de jetons, les points décimaux, qui peut frapper, et plus encore.
Et cela peut être fait en envoyant simplement une transaction au programme de jetons. En utilisant la CLI de la bibliothèque de programmes Solana, par exemple, il ne s'agit que d'une seule commande :
Marchés de frais locaux
Un autre avantage du modèle de compte est que les marchés de frais sont locaux par compte.
Sur Ethereum, les marchés des frais sont mondiaux. Si une collection NFT devient virale et que tout le monde la frappe, les frais augmentent pour tout le monde. Mais sur Solana, étant donné que les marchés de frais sont locaux par compte, seules les personnes qui montent cette collection NFT paient les frais élevés. Les utilisateurs non participants ne sont pas concernés.
Frais
Examinons plus en détail les frais. Sur Solana, les frais sont répartis en trois catégories : frais de base, frais prioritaires et loyer. Regardons chacun.
Les frais de base sont calculés en fonction du nombre de signatures dans une transaction. Chaque signature coûte 5000 lamports (0,000000001 sol = 1 lamport). Si une transaction comporte 5 signatures, les frais de base sont de 25 000 lamports.
Les frais de priorité sont des frais facultatifs qui peuvent être ajoutés à une transaction pour lui donner la priorité. Ces frais sont basés sur le nombre d'unités de calcul utilisées dans la transaction. Semblables au gaz Ethereum, ces frais sont une simple mesure des ressources informatiques nécessaires à la transaction.
Le montant final, le loyer, s'apparente davantage à une caution. Lorsque les développeurs créent des comptes ou allouent de l'espace sur le réseau, ils doivent déposer SOL pour que le réseau conserve leur compte. Le loyer est calculé en fonction du nombre d'octets stockés sur le réseau et des frais de base supplémentaires sont facturés pour l'attribution de l'espace.
Transactions
Sur Solana, l'exécution du programme commence par la soumission d'une transaction au cluster. Chaque transaction sur Solana se compose de quatre parties :
Une ou plusieurs instructions. Les instructions sont la plus petite logique d'exécution sur Solana. Ils peuvent être considérés comme des appels de fonction sur un contrat intelligent Ethereum. Ils invoquent des programmes qui appellent le runtime Solana pour mettre à jour l'état (par exemple, en appelant le programme de jetons pour transférer des jetons d'un compte à un autre).
Un éventail de comptes à partir desquels lire ou écrire
Une ou plusieurs signatures
Un blockhash récent ou occasionnel. Au lieu d'utiliser un nonce incrémentiel comme sur Ethereum, sur Solana, un blockhash récent est extrait du cluster. Avec ce blockhash, la transaction n'est valable que pour 150 blocs, ce qui empêche l'exécution de signatures de transaction de longue durée à une date beaucoup plus tardive.
Une autre différence significative entre Ethereum et Solana est qu'avec Solana, les transactions peuvent avoir plusieurs instructions (appels de fonction sur Ethereum). Cela signifie qu’il n’est pas nécessaire de créer des contrats intelligents personnalisés pour enchaîner les fonctions en une seule transaction. Chaque instruction peut être un appel de fonction distinct, effectué dans l'ordre dans la transaction. Les transactions sont également atomiques : si une instruction échoue, la transaction entière échouera.
Limites des transactions
Comme pour les limitations de gaz Ethereum, il existe des limitations d'unités de calcul sur les transactions Solana.
D'autres limitations incluent :
Chaque compte référencé peut contenir au maximum 12 000 000 d’unités de calcul utilisées par bloc.
Les instructions ne peuvent être appelées qu'à une profondeur de 4 avant que la transaction ne soit annulée.
Pool de mémoire
Contrairement à Ethereum, Solana n'a pas de pools de mémoire. Les validateurs Solana transmettent toutes les transactions à un maximum de quatre leaders selon le calendrier des leaders. Ne pas avoir de pool de mémoire force les transactions à passer d'un leader à l'autre jusqu'à l'expiration du blockhash, mais cela réduit également la surcharge de potins à travers le cluster.
L'environnement de développement Solana
Examinons maintenant certains des outils de développement sur Solana.
Langages de programmation
Alors qu'Ethereum utilise principalement Solidity pour rédiger des contrats intelligents, Solana utilise Rust. Si vous quittez Ethereum, pensez au framework Anchor ou Neon, qui peuvent tous deux aider les développeurs à démarrer plus rapidement en leur permettant de créer Solana à l'aide d'outils EVM familiers.
Comme Ethereum, des SDK côté client sont disponibles pour la plupart des langages de programmation les plus populaires, notamment JavaScript, Python et Java.
Outils de développement
Solana n'a pas actuellement d'équivalent à Foundry, mais il dispose d'un large ensemble d'outils équivalents à ceux utilisés pour Solidity.
Pour une analyse plus approfondie, voici une liste plus large de ressources pour les développeurs.
Création de contrats intelligents
Lors de la création de programmes sur Solana (ou lors de la migration de contrats intelligents Ethereum existants), il existe plusieurs différences fondamentales, trop nombreuses pour être couvertes ici. Mais examinons quelques-uns des plus courants :
La cartographie n'existe pas directement sur Solana. Utilisez plutôt des adresses dérivées du programme. Tout comme le mappage, les adresses dérivées du programme permettent de créer un mappage à partir d'une clé ou d'un compte vers une valeur stockée en chaîne.
Sur Solana, les programmes sont évolutifs par défaut. Un contrat intelligent peut être mis à niveau par une simple commande CLI solana program déployer <program_filepath>.
Lors de la rédaction d’un contrat intelligent de solidité, il est courant de vérifier msg.sender ou tx.origin. Il n'y a pas d'équivalent à cela sur Solana. Chaque transaction peut avoir plusieurs signataires, et la personne qui envoie la transaction n'est pas nécessairement celle qui a signé la transaction.
Pour plus d'informations sur les programmes et comment les déployer, consultez ce guide.
Apprendre encore plus
Ce sont quelques-unes des différences les plus critiques entre le développement sur Ethereum et Solana. Il y a bien sûr encore beaucoup à apprendre. Et la meilleure façon de commencer est de se lancer directement ! Voici quelques ressources pour les prochaines étapes :
Le Solana Playground où les développeurs peuvent écrire, créer et déployer des programmes Solana à partir du navigateur
Une introduction au développement de Solana à l'aide de Solana Playground
Un aperçu plus détaillé des différences entre le développement sur Ethereum et Solana
Le Bootcamp Solana
