Comment migrer d’Ethereum vers Solana : guide pour les développeurs

Quel est le sujet de cet article ?

Ethereum est l’une des innovations les plus importantes de ces dernières années. Pour la première fois dans l’histoire, nous disposons d’une plateforme mondiale et décentralisée conçue pour la coordination sociale, capable de révolutionner de nombreux secteurs. Malgré son importance, l’environnement d’exécution d’Ethereum, l’Ethereum Virtual Machine (EVM), n’est pas adapté, dans son état actuel, aux applications destinées au grand public. Il s’agit d’un réseau monothread basé sur le gas, avec des frais volatils. À l’inverse, Solana se distingue comme un réseau à haut débit et à faible latence. Son infrastructure parallélisée offre des frais faibles et prévisibles. Elle répond directement aux limites de l’EVM et améliore sa conception d’origine, ce qui en fait un choix convaincant pour les développeurs souhaitant créer des applications évolutives et efficaces.

Cet article est un guide de migration complet destiné aux développeurs EVM qui souhaitent créer des applications sur Solana. Il présente les différences fondamentales entre les deux réseaux, notamment les mécanismes de consensus d’Ethereum et de Solana, leur façon de traiter les transactions et les langages utilisés pour développer des contrats intelligents. Il aborde ensuite le modèle de comptes de Solana, qui propose une approche plus uniforme et polyvalente des comptes. L’article explore également Solang et Neon EVM, deux outils compatibles avec Solidity qui améliorent l’expérience de développement sur Solana.

Différences fondamentales

Cette section présente les différences essentielles entre Ethereum et Solana, deux blockchains qui cherchent à créer une machine à états décentralisée pour la coordination mondiale. Leurs mécanismes de consensus, leurs méthodes de traitement des transactions et les langages utilisés pour développer des contrats intelligents diffèrent toutefois considérablement. Une compréhension approfondie de ces différences fondamentales met en évidence l’avantage distinct de Solana sur Ethereum en tant que machine à états mondiale hautement performante.

Mécanismes de consensus

Les mécanismes de consensus sont à la base de tous les réseaux blockchain. Ils déterminent comment les transactions sont vérifiées et comment les blocs sont ajoutés à la blockchain de manière sécurisée, efficace et décentralisée. Ethereum et Solana sont tous deux des réseaux Proof of Stake (PoS). Bien qu’ils reposent tous deux sur le PoS, leurs méthodes pour parvenir à un consensus diffèrent en raison de leurs règles de confirmation.

Ethereum utilise Gasper, une combinaison de Casper the Friendly Finality Gadget (Casper-FFG) et de l’algorithme de sélection de fork LMD-GHOST. Cette combinaison constitue le mécanisme de consensus qui sécurise Ethereum.

Casper est un système de finalité basé sur le PoS qui fait passer l’état de confirmation d’un bloc à « finalisé ». Un bloc est considéré comme finalisé sur Ethereum lorsque les deux tiers du stake total votent en faveur de son inclusion et qu’un autre bloc est construit par-dessus. Puisque la finalité exige que les deux tiers du stake total reconnaissent un bloc comme canonique, un attaquant ne peut pas créer une autre chaîne finalisée sans posséder ou manipuler les deux tiers du stake total et sans en détruire au moins un tiers par slashing. Casper permet aux nouveaux participants de se synchroniser en toute confiance avec la chaîne canonique. 

LMD-GHOST est l’acronyme de « Latest Message-Driven Greedy Heaviest Observed Sub-Tree ». Cet algorithme détermine quel fork d’Ethereum suivre. Pour cela, il choisit le fork qui a reçu le plus de soutien, c’est-à-dire le plus de « poids », de la part des validateurs du réseau, d’où l’expression « greedy heaviest sub-tree ». Il veille ensuite à ne prendre en compte que le message le plus récent de chaque validateur. Chaque fois qu’un nouveau bloc est proposé sur Ethereum, les validateurs utilisent cette règle pour décider s’il doit intégrer la chaîne canonique.

En comparaison, Solana utilise des hachages Proof of History (PoH) pour parvenir à un consensus. Malgré son nom ambigu, le PoH n’est pas un algorithme de consensus. Il s’agit d’un moyen de prouver le temps dans un réseau hostile. Plus précisément, c’est une fonction cryptographique d’horodatage qui permet aux nœuds de s’accorder sur l’ordre des événements sans communiquer entre eux. Le leader, c’est-à-dire le validateur qui ajoute des entrées au registre, horodate les blocs afin de prouver qu’un certain temps s’est écoulé depuis le bloc précédent. 

L’ajout de ces horodatages établit un historique, car ils prouvent que les données existaient à un moment précis. Cet historique est créé à l’aide d’une fonction de hachage séquentielle résistante aux préimages, dans laquelle chaque hachage dépend du précédent. Les fonctions de délai vérifiables (VDF) jouent un rôle central dans la génération de ces hachages. Elles garantissent que chaque hachage s’appuie sur le précédent et intègre le temps écoulé depuis sa création. L’intégration des VDF ajoute une dimension temporelle au processus de hachage, ce qui permet de créer sur Solana une séquence vérifiable d’événements horodatés.

Après avoir vu comment le mécanisme Proof of History de Solana crée une séquence fiable d’événements grâce à des horodatages cryptographiques, il est essentiel de comprendre comment il s’intègre au mécanisme de consensus de Solana, Tower BFT. Tower Byzantine Fault Tolerance (BFT) est la variante du modèle traditionnel de consensus Byzantine Fault Tolerance utilisée par Solana et optimisée pour le PoH. Tower BFT utilise l’historique créé par le PoH comme cadre de référence. Ce cadre permet aux validateurs de voter efficacement et précisément sur l’état du registre. Avec Tower BFT, les validateurs émettent des votes qui restent verrouillés pendant une longue période et les engagent de plus en plus à mesure que de nouveaux votes sont ajoutés. Grâce au PoH, les validateurs peuvent prendre des décisions plus rapides et mieux informées sur l’état du registre sans avoir à communiquer entre eux. La combinaison du PoH et de Tower BFT accélère le consensus et renforce la sécurité et la fiabilité du réseau. Elle produit un environnement blockchain évolutif et à haut débit dans lequel les transactions sont rapidement confirmées.

Traitement des transactions et environnements d’exécution

L’efficacité et l’évolutivité d’une blockchain dépendent principalement de ses capacités de traitement des transactions et de son environnement d’exécution. Ces facteurs déterminent la vitesse d’exécution des transactions et le rapport coût-efficacité des opérations sur le réseau. La méthode de traitement des transactions d’une blockchain et les particularités de ses environnements d’exécution influencent considérablement l’expérience développeur.

L’environnement d’exécution d’Ethereum fonctionne comme une machine à pile déterministe et monothread appelée Ethereum Virtual Machine (EVM). Elle se comporte comme une fonction mathématique. Autrement dit, l’EVM produit une sortie déterministe à partir d’une entrée donnée. Il est utile de définir Ethereum comme doté d’une fonction de transition d’état : f(S, T) = S’. À partir d’un ancien état (S) et d’un nouvel ensemble de transactions valides (T), l’EVM produit un nouvel état de sortie valide (S’). Pour un même ensemble de transactions, l’EVM aboutira toujours au même état final. Cette propriété est essentielle au maintien de la cohérence entre les nœuds du réseau.

L’EVM traite les transactions de façon séquentielle. Ce traitement garantit que chaque transaction s’exécute dans un environnement qui reflète fidèlement l’état du réseau à cet instant. L’exécution séquentielle permet de calculer précisément les changements d’état et les coûts en gas. Cette prévisibilité permet aux développeurs et aux utilisateurs de comprendre clairement le résultat et le coût des transactions.

Ethereum simplifie l’environnement d’exécution des contrats intelligents en adoptant un modèle d’exécution monothread. Les développeurs bénéficient ainsi de changements d’état prévisibles, puisque chaque transaction est traitée séquentiellement. Cette prévisibilité rend l’environnement de développement d’Ethereum sans doute plus accessible aux nouveaux développeurs, qui peuvent davantage se concentrer sur la logique de leurs contrats intelligents que sur les complexités de l’exécution. Cette simplicité complique toutefois l’évolutivité. Le traitement séquentiel limite le débit du réseau. Cela peut entraîner une congestion, un allongement des délais d’attente des transactions et une hausse des frais de gas lorsque la demande est forte. Puisque chaque transaction consomme du gas, les développeurs doivent optimiser son utilisation. Cette optimisation vise à améliorer l’expérience utilisateur globale et à limiter les effets des périodes de congestion, pendant lesquelles un code inefficace peut rendre les applications inutilisables pour l’utilisateur moyen.

Les développeurs Solana n’ont pas à optimiser l’utilisation du gas comme les développeurs Ethereum. Solana est conçue comme une machine à états à haut débit et à faible latence appelée Solana Virtual Machine (SVM). Sealevel est un composant essentiel de la SVM. Ce moteur d’exécution traite les transactions en parallèle. Sur Solana, chaque transaction indique à l’environnement d’exécution les parties de l’état qu’elle lira ou modifiera lors de son exécution. L’environnement traite en parallèle les transactions qui ne sont pas en conflit et celles qui lisent le même état. Sealevel optimise l’exécution des contrats intelligents en répartissant la charge de travail des transactions entre plusieurs threads du matériel d’un validateur. Ainsi, pendant que le validateur traite une transaction sur un cœur, une autre peut être traitée simultanément sur un autre cœur.

Le parallélisme natif de Solana réduit considérablement le coût des transactions. Les transactions Solana comportent deux types de frais : des frais de base et des frais de priorité. Les frais de base sont fixés à 5 000 lamports par signature ; la plupart des transactions ne comportent qu’une signature. Les frais de priorité sont facultatifs et permettent aux transactions d’être prioritaires par rapport aux autres. Le planificateur accorde une priorité non déterministe aux transactions dont les frais de priorité sont plus élevés. Les frais de transaction sont souvent inférieurs à 0,001 USD, avec des frais moyens hors vote compris entre 0,000005 et 0,00007 SOL. La limite supérieure est plus élevée qu’à l’accoutumée en raison de l’utilisation récemment accrue des frais de priorité. Au cours actuel du SOL, soit environ ~98,96 $, ces frais représentent approximativement entre 0,000494 et 0,006968 USD. 

Ces frais sont également prévisibles. Solana utilise des marchés de frais localisés pour gérer la demande. L’espace de bloc est structuré de manière à empêcher un foyer d’activité particulier, par exemple le mint très attendu d’un NFT, de monopoliser cet espace et d’augmenter les frais sur l’ensemble du réseau. Seules les transactions qui tentent d’accéder à un foyer précis très demandé voient leurs frais augmenter. Les marchés de frais localisés permettent d’appliquer des frais de priorité sans déclencher de véritable guerre du gas. Cette localisation diffère des réseaux basés sur le gas comme Ethereum, où les transactions sont traitées séquentiellement et où la congestion globale entraîne des frais volatils.

Ethereum est un environnement d’exécution monothread qui ne traite qu’un contrat à la fois. Il n’exploite actuellement pas les processeurs multicœurs modernes, ce qui entraîne une sous-utilisation du matériel des validateurs. La volonté de maintenir des exigences matérielles faibles pour les nœuds accentue les limites d’Ethereum en matière de traitement des transactions. À l’inverse, les capacités de traitement parallèle de Solana lui permettent de traiter davantage de transactions en utilisant tous les cœurs disponibles d’un validateur. Associée aux marchés de frais localisés, cette capacité fait de Solana une machine à états mondiale nettement plus performante. 

Langages de contrats intelligents

Le principal langage utilisé pour développer des contrats intelligents sur Ethereum est Solidity. Il s’agit d’un langage à typage statique utilisant des accolades, conçu pour créer des contrats intelligents qui s’exécutent sur l’EVM. Il est fortement influencé par JavaScript, C++ et Python, ce qui facilite sa prise en main pour les développeurs qui connaissent déjà ces langages.

Yul est un langage intermédiaire de bas niveau optimisé pour les blockchains compatibles avec l’EVM. Yul offre aux développeurs un meilleur contrôle sur l’exécution du bytecode. Il est donc très efficace pour ajuster précisément la consommation de gas et gérer d’autres opérations de bas niveau. Les développeurs peuvent créer des contrats plus efficaces en programmant directement en Yul ou en l’utilisant comme cible de compilation.

Vyper est un langage populaire inspiré de Python qui met l’accent sur la simplicité et la sécurité. Il offre volontairement moins de fonctionnalités que Solidity afin de réduire la complexité et les éventuelles vulnérabilités de sécurité. La philosophie de conception de Vyper privilégie avant tout la lisibilité et l’auditabilité. Cette approche a inspiré le développement de langages similaires, comme Fe, et de langages compilés vers Vyper, comme Dasy.

Rust est la lingua franca du développement de contrats intelligents, familièrement appelés programmes, sur Solana. C’est un langage rapide et efficace en mémoire, dont les performances sont comparables à celles du C++. Ces caractéristiques le rendent adapté au développement d’applications pour un réseau à haut débit et à faible latence. Le riche système de types et le modèle de propriété de Rust garantissent la sécurité de la mémoire et des threads, obligeant les développeurs à créer des applications fiables et sécurisées. 

Bien que Rust présente une courbe d’apprentissage abrupte pour les personnes qui découvrent la programmation système, il permet en contrepartie de créer du code robuste et efficace. La plupart des développements en Rust sont réalisés avec Anchor. Anchor est un framework prescriptif qui simplifie le développement de programmes en réduisant le code répétitif, en effectuant plusieurs contrôles de sécurité courants et en rationalisant le processus de (dé)sérialisation. Une connaissance avancée de Rust est donc moins indispensable pour débuter. À titre indicatif, la documentation d’Anchor recommande aux utilisateurs de connaître les neuf premiers chapitres du livre Rust, autrement dit les principes de base de Rust. Solana Playground propose plusieurs tutoriels Anchor pour vous aider à démarrer.

Bien que Rust soit privilégié, les développeurs ne sont pas limités à ce langage. C, C++ et tout langage ciblant le backend BPF de LLVM, c’est-à-dire tout langage pouvant être compilé en bytecode BPF, peuvent être utilisés. Pour les développeurs qui connaissent les langages inspirés de Python comme Vyper, Seahorse Lang permet d’écrire des programmes en Python. Ils bénéficient ainsi de la simplicité de Python tout en conservant les mêmes garanties de sécurité que s’ils programmaient en Rust. Plusieurs ressources utiles, comme Seahorse University et Seahorse Cookbook, sont disponibles pour vous aider à commencer à programmer sur Solana dès aujourd’hui.

Les développeurs qui migrent d’Ethereum vers Rust ne sont pas obligés de se limiter à Rust. Bien qu’il soit recommandé d’apprendre et d’utiliser des frameworks comme Anchor et Seahorse en raison de leur popularité et de leurs garanties de sécurité, cela n’est pas toujours possible. Grâce aux avancées récentes de Solang et de Neon Labs, avec leur compilateur et leur environnement de développement compatible avec l’EVM, les développeurs peuvent utiliser Solidity pour développer des programmes. Solidity a toute sa place sur Solana. Pour commencer à développer des programmes en Solidity, nous devons examiner plus en détail les particularités du modèle de programmation de Solana. Il est essentiel que les développeurs qui effectuent cette transition comprennent le modèle de comptes de Solana, car celui-ci constitue la base du développement des programmes et des interactions sur le réseau.

Comprendre le modèle de comptes

Ethereum classe les comptes en deux grandes catégories : les comptes détenus en externe (EOA) et les comptes de contrat. Les EOA sont le type de compte standard des utilisateurs. Ils sont contrôlés par des clés privées et peuvent détenir des soldes en Ether, envoyer des transactions et interagir avec des comptes de contrat. Les comptes de contrat se distinguent quant à eux par le fait que leurs opérations sont régies par le code du contrat intelligent qu’ils contiennent. Ils ne peuvent pas initier de transactions de manière autonome et ne peuvent agir qu’en réponse aux transactions reçues d’EOA ou d’autres comptes de contrat.

Solana adopte un modèle plus uniforme, dans lequel les comptes sont considérés comme des conteneurs polyvalents qui stockent les données de manière persistante. Ce modèle permet à n’importe quel compte d’être un programme, ce qui estompe la frontière traditionnelle entre compte et contrat intelligent. Contrairement à Ethereum, où le code et l’état sont regroupés dans un même compte, les programmes Solana sont sans état. Ils ne stockent donc aucun état en interne. Toutes les données dont ils ont besoin pour fonctionner sont stockées dans un compte distinct et transmises par référence avec une transaction. La transmission des comptes par référence permet de déployer un programme générique capable d’interagir avec différents comptes. Le modèle de comptes de Solana sépare le code des données, favorisant ainsi un environnement de développement plus efficace et modulaire. C’est un avantage pour les utilisateurs qui souhaitent interagir avec plusieurs protocoles sans déplacer leurs actifs entre différents programmes. Sur Solana, tout est un compte. 

Les comptes Solana peuvent être répartis en comptes exécutables et non exécutables. Pour faire simple, les comptes exécutables peuvent exécuter du code. Les comptes non exécutables servent à stocker des données et ne peuvent pas exécuter de code, car ils n’en contiennent aucun.

Les comptes exécutables contiennent des programmes. Les programmes peuvent posséder des comptes supplémentaires, lire ou créditer d’autres comptes, modifier des données ou débiter les comptes qu’ils possèdent. Les comptes exécutables peuvent être subdivisés en programmes on-chain et programmes natifs. Les programmes on-chain sont du code écrit par les utilisateurs et déployé sur le réseau. Ils peuvent être mis à niveau par leur autorité de mise à niveau, généralement le compte qui les a déployés. Les programmes natifs forment un sous-ensemble particulier de comptes exécutables, comparable aux contrats précompilés d’Ethereum, mais offrant des fonctionnalités plus larges. Ces programmes sont intégrés au cœur de Solana et fournissent les fonctionnalités nécessaires au fonctionnement des validateurs. Le System Program est un exemple de programme natif. Il est chargé de créer de nouveaux comptes, d’allouer les données des comptes, d’attribuer les comptes aux programmes, de transférer des lamports depuis les comptes qu’il possède et de payer les frais de transaction. Vous trouverez une liste complète des programmes natifs ici.

Qu’ils soient exécutables ou non, tous les comptes possèdent les mêmes champs : 

• Un champ lamports pour suivre le solde natif d’un compte en SOL
• Un champ de données, qui désigne le tableau d’octets de données brutes stocké par le compte
• Un champ propriétaire indiquant le programme autorisé à modifier ce compte
• Un champ signataire, utilisé dans les transactions pour indiquer si le compte peut approuver des transactions
• Un champ modifiable pour préciser si les données d’un compte peuvent être modifiées. Ce champ facilite le traitement parallèle en marquant les comptes inclus dans les transactions comme étant en lecture seule ou modifiables
• Un champ exécutable pour indiquer si un compte stocke un programme
• Un champ d’époque de loyer pour indiquer la prochaine époque à laquelle le compte devra payer un loyer

Le loyer est un coût de stockage qui permet de maintenir les comptes actifs sur Solana et de garantir leur conservation dans la mémoire des validateurs. Les comptes doivent donc conserver un solde minimal pour rester actifs. Le loyer réduit le gonflement de l’état en permettant au réseau de récupérer à terme les comptes inutilisés ou insuffisamment approvisionnés. À la suite de mises à jour récentes, aucun compte du mainnet ne paie désormais de loyer. Tous les comptes doivent au contraire être exemptés de loyer dès leur création. Un compte est exempté s’il conserve un solde minimal équivalent à deux années de loyer. Des outils tels que Test Drive et la sous-commande rent de Solana CLI permettent d’estimer la quantité de SOL nécessaire pour qu’un compte soit exempté. Cette approche diffère du système d’allocation des ressources d’Ethereum, où le stockage persiste tant qu’il n’est pas explicitement effacé. L’approche de Solana offre une structure de coûts plus prévisible pour le stockage de l’état tout en limitant son gonflement.

Adresses et Program Derived Addresses (PDA)

Tous les comptes sont identifiés par leur adresse, une clé publique unique de 32 octets. Cela diffère du modèle de données d’Ethereum, où les adresses font 20 octets. Solana utilise ed25519, c’est-à-dire un schéma de signature EdDSA qui emploie SHA-512 et la courbe elliptique Curve22519, pour générer les adresses. Un compte doit correspondre à un point de la courbe ed25519 pour disposer d’une paire de clés valide. 

Les Program Derived Addresses (PDA) sont des comptes générés hors courbe à l’aide d’un bump, c’est-à-dire une valeur qui décale la sortie hors de la courbe. Les PDA nécessitent trois éléments principaux : l’adresse de leur programme parent, un ensemble de seeds et un bump. Les seeds forment un tableau de chaînes pouvant contenir des valeurs arbitraires. Toutefois, la plupart des développeurs créent des seeds spécifiques liées aux variables d’état du programme parent afin de produire des structures de données similaires à des tables de hachage. Une PDA est donc créée en hachant l’ID du programme, les seeds et le bump à l’aide de la fonction de hachage SHA-512.

Les PDA sont placées hors courbe afin que seul le programme dont une PDA est dérivée puisse signer en son nom. Cela fluidifie le déroulement des transactions en générant leurs signatures par programmation, afin que les dApps sans confiance puissent fonctionner sans intervention.

Interagir avec un compte

Une transaction Ethereum est une action qui modifie l’état et qui est initiée par un EOA. Les contrats intelligents ne peuvent pas initier de transactions de manière autonome ; ils peuvent uniquement y réagir. Le code du contrat détermine ces réactions, et le coût d’exécution de la transaction est mesuré en gas. Les utilisateurs doivent fournir suffisamment d’Ether pour couvrir ces frais de gas.

Les transactions Ethereum effectuent généralement une seule opération, comme l’appel d’une fonction précise d’un contrat intelligent. Bien qu’une seule transaction puisse entraîner plusieurs changements d’état au sein d’un contrat, tous ces changements restent limités au périmètre de cet appel de contrat.

Sur Solana, une transaction comprend un tableau de comptes à lire ou modifier, une ou plusieurs signatures et une ou plusieurs instructions. Une instruction est une directive pour l’invocation d’un seul programme. Il s’agit de la plus petite unité de logique d’exécution et de l’unité opérationnelle la plus fondamentale. Les instructions précisent le programme à exécuter, tous les comptes concernés et les données opérationnelles. Les programmes interprètent les données d’une instruction et agissent sur les comptes indiqués. Cette structure permet à une seule transaction d’effectuer de manière atomique une série d’actions dans plusieurs programmes. Toutes les instructions réussissent ou échouent donc ensemble. Le déroulement des transactions de Solana diffère du modèle d’Ethereum, où une transaction est généralement liée à un seul contrat intelligent ou à une action d’un EOA.

Les Cross-Program Invocations (CPI) permettent à un programme d’en invoquer un autre au cours de la même transaction. Le nombre d’octets de données de compte facturés par unité de calcul lors d’une CPI est de 250. Cela représente environ 50 Mo pour 200 000 unités. Les CPI permettent d’utiliser des signatures générées par programmation lors d’appels entre programmes. Ce mécanisme est comparable à un contrat intelligent Ethereum qui appelle efficacement et atomiquement un autre contrat. Toutefois, le programme appelant est suspendu jusqu’à ce que le programme invoqué ait terminé de traiter l’instruction. La réentrance est limitée à l’autorécursion directe, avec une profondeur maximale fixe de 4. Cela évite qu’un programme en invoque un autre depuis un état intermédiaire sans savoir qu’il pourrait être rappelé ultérieurement.

Pour des raisons d’efficacité, les transactions Solana respectent une limite de taille, similaire à la limite de gas d’Ethereum. L’accent porte toutefois sur le volume des données. Les transactions Solana respectent les normes IPv6 Maximum Transmission Unit (MTU) afin de garantir une transmission fiable des données. Une fois l’espace nécessaire réservé à l’en-tête, 1 232 octets restent disponibles pour les données du paquet. Solana a introduit les transactions versionnées pour prendre en charge plusieurs formats de transaction et surmonter les contraintes de taille. En plus du format historique, c’est-à-dire le format de transaction d’origine, la Version 0 a été publiée pour prendre en charge les Address Lookup Tables (ALT). Les ALT stockent les adresses on-chain dans une structure de données semblable à une table, où chaque adresse est indexée à l’aide d’un index u8 de 1 octet. Cela réduit considérablement la taille des transactions, car chaque compte ne nécessite plus que 1 octet au lieu de 32.

Solang

Solang est un compilateur Solidity pour Solana et Polkadot. Il vise à assurer la compatibilité des fichiers sources avec la version 0.8 du compilateur Solidity de l’EVM, avec quelques adaptations aux architectures de Solana et Polkadot. L’un des aspects majeurs de Solang est son utilisation de LLVM, une puissante infrastructure de compilation. La flexibilité de LLVM permettra à Solang de prendre en charge d’autres langages de programmation à l’avenir, facilitant ainsi les implémentations et les compilations. Cette caractéristique correspond à l’objectif de Solang : simplifier la transition des développeurs vers Solana ou Polkadot et élargir le champ du développement en Solidity. Solang fait l’objet d’un développement continu axé sur l’amélioration de la compatibilité, de l’efficacité et de la simplicité d’utilisation. Les développeurs Ethereum qui souhaitent exploiter leurs compétences sur plusieurs chaînes doivent impérativement comprendre Solang et ses particularités.

Installation

Il existe plusieurs façons d’installer Solang. Sur Mac, vous pouvez télécharger Solang avec Brew à l’aide d’un tap privé :

brew install hyperledger/solang/solang

Une autre méthode consiste à utiliser les conteneurs Solang. Cette solution est idéale si vous préférez utiliser Docker, car les nouvelles images sont automatiquement mises à disposition dans ces conteneurs. Il existe un tag v.0.3.3 et un tag latest :

docker pull ghcr.io/hyperledger/solang:latest

L’une des façons les plus simples d’installer et d’utiliser Solang passe par Ancor. Pour commencer, vérifiez que Rust et Node.js sont installés sur votre système. Les utilisateurs de Windows devront également configurer le Sous-système Windows pour Linux. Nous devons maintenant installer la suite d’outils de Solana. Sur Mac et Linux, vous pouvez le faire avec la commande suivante :

 sh -c "$(curl -sSfL https://release.solana.com/v1.17.13/install)"

Si vous préférez une autre version du logiciel, remplacez « v1.17.13 » par le tag de version approprié. Vous pouvez également utiliser l’un des noms de canaux symboliques suivants : stable, beta ou edge. Selon votre système, vous devrez peut-être mettre à jour votre variable d’environnement PATH. Si ce message s’affiche, copiez et collez la commande recommandée ci-dessous pour mettre à jour PATH. Vous pouvez confirmer la version souhaitée de solana en exécutant solana --version.

Sous Windows, ouvrez une instance de l’invite de commandes en tant qu’administrateur. Copiez et collez la commande suivante pour télécharger le programme d’installation de Solana dans un répertoire temporaire :

cmd /c "curl https://release.solana.com/v1.17.13/solana-install-init-x86_64-pc-windows-msvc.exe --output C:\solana-install-tmp\solana-install-init.exe --create-dirs"

Ensuite, copiez et collez la commande suivante pour installer la dernière version de Solana : C:\solana-install-tmp\solana-install-init.exe v1.17.13. Une fois l’installation terminée, appuyez sur Entrée.

Fermez la fenêtre de l’invite de commandes, puis ouvrez-en une nouvelle en tant qu’utilisateur standard. Vérifiez que la version souhaitée de solana est installée en exécutant solana –-version.

Installez ensuite Anchor.

Il est recommandé d’installer Anchor à l’aide du gestionnaire de versions Anchor (avm). Vous pouvez le faire via cargo avec la commande suivante :

cargo install -git https://github.com/coral-xyz/anchor avm --locked --force.

Installez et utilisez ensuite la dernière version :

avm install latest
avm use latest

# Verify the installation
avm –version

Anchor 0.28 permet aux développeurs de compiler directement avec Solang. Vous pouvez créer un nouveau projet Solang avec la commande anchor init project_name —solidity. Elle crée un nouveau programme Solang ainsi qu’un fichier de test montrant comment interagir avec le programme via le client.

Si vous utilisez Visual Studio Code, envisagez d’installer l’extension Solang pour bénéficier de la coloration syntaxique. Désactivez toute autre extension Solidity active afin de garantir le bon fonctionnement de l’extension Solang.

Création d’un nouveau projet

Créez un nouveau projet avec la commande anchor-init project_name –solidity. Elle crée un nouveau répertoire portant le nom de votre projet. Le paramètre Solidity indique à Anchor que nous souhaitons utiliser Solang. Le répertoire ./solidity du projet contient un programme de démarrage. Le contrat se présente comme suit :

@program_id("F1ipperKF9EfD821ZbbYjS319LXYiBmjhzkkf5a26rC")
contract test {
    bool private value = true;

    @payer(payer)
    constructor() {
        print("Hello, World!");
    }

    /// A message that can be called on instantiated contracts.
    /// This one flips the value of the stored `bool` from `true`
    /// to `false` and vice versa.
    function flip() public {
            value = !value;
    }

    /// Simply returns the current value of our `bool`.
    function get() public view returns (bool) {
            return value;
    }
}

Ce programme possède un constructor pour créer le programme, initialiser la variable d’état value avec true et consigner « Hello, World! » dans les journaux du programme. La fonction flip met à jour la variable d’état lorsqu’elle est appelée. La fonction get renvoie la valeur actuelle de la variable d’état. Cela ressemble à un smart contract Solidity classique, à quelques particularités près. La différence la plus importante réside dans l’utilisation d’annotations.

Annotations

Les annotations servent à gérer les comptes. Notez l’annotation @program_id(“...”). Elle permet de spécifier l’adresse on-chain du programme lorsqu’elle est connue à l’avance. Pour appeler un contrat via un appel externe, le programme doit soit comporter la notation @program_id, soit être appelé à l’aide de l’argument {program_id: … } :

@program_id(“...”);

contract Foo {
	function hello() public pure {
		print(“Hello”);
	}
}

contract Foo2 {
	function bye() public pure {
		print(“Bye”);
	}
}

contract Bar {
	function new_foo() external {
		Foo.new();
	}
}

contract Bar2 {
	function new_foo(address new_foo_id) external {
		Foo2.new{program_id: new_foo_id}();
	}
}

Lorsque nous avons créé un nouveau projet, l’exemple de contrat fourni comportait l’annotation @payer au-dessus du constructeur. Cette annotation définit le compte qui paiera l’initialisation du compte de données du programme. La syntaxe @payer(payer) déclare un compte nommé payer, qui sera requis pour chaque appel au constructeur.

Lorsqu’un contrat est instancié, il nécessite un compte de programme pour contenir le code exécutable et un compte de données pour enregistrer les variables d’état. Le compte de données peut être créé dans le code côté client, puis transmis à la transaction qui invoque le constructeur. Il peut également être créé par le constructeur. Au minimum, l’annotation @payer doit être fournie. Une seed et un bump doivent être fournis si le compte de données est un PDA. L’annotation @seed spécifie une seed servant à dériver le PDA. Il peut s’agir d’une chaîne littérale ou d’une chaîne hexadécimale au format hex”1234”. Si elle précède un argument, l’annotation de seed doit faire référence à un argument de type bytes, address ou à un tableau d’octets de longueur fixe. L’annotation @bump spécifie la valeur utilisée pour produire une adresse hors courbe. Elle doit correspondre à un seul octet de type bytes1. L’annotation facultative @space permet de spécifier la taille du compte de données. Il s’agit d’une expression uint64 qui peut être une constante ou utiliser l’un des arguments du constructeur. Selon la documentation de Solang, @space doit au minimum correspondre à la taille indiquée lors de l’exécution de la commande solang -v :

$ solang compile --target solana -v examples/solana/flipper.sol
...
info: contract flipper uses at least 17 bytes account data
…

Si un programme ne possède pas de constructeur, ces annotations peuvent être associées à un constructeur vide. La documentation de Solang fournit l’exemple suivant :

@program_id("Foo5mMfYo5RhRcWa4NZ2bwFn4Kdhe8rNK5jchxsKrivA")
contract Foo {

    @space(500 + 12)
    @seed("Foo")
    @payer(payer)
    constructor(@seed bytes seed_val, @bump bytes1 bump_val) {
        // ...
    }
}

Les annotations de fonction servent à déclarer les comptes nécessaires aux fonctions externes :

• @account(foo) déclare le compte foo comme compte en lecture seule
• @mutableAccount(bar) déclare le compte bar comme compte modifiable
• @signer(fizz) déclare le compte fizz comme signataire en lecture seule
• @mutableSigner(buzz) déclare le compte buzz comme signataire modifiable

Les comptes déclarés avec l’annotation @payer sur le constructeur sont accessibles depuis celui-ci. Les comptes déclarés avec des annotations de fonction sont disponibles dans le vecteur tx.accounts. Par exemple, vous utiliserez tx.accounts.ichigo pour accéder au compte déclaré @account(ichigo). Cela renverra la structure intégrée AccountInfo. Cette structure suit celle que nous avons décrite dans la section « Comprendre le modèle de compte ». Les noms diffèrent légèrement :

• key : l’adresse ou la clé publique du compte. Elle est de type address
• lamports : le solde en lamports du compte. Il est de type uint64
• data : les données du compte. Elles sont de type bytes
• owner : le propriétaire du compte. Il est de type address
• rent_epoch : la prochaine époque à laquelle le loyer du compte sera dû. Elle est de type uint64
• is_signer : indique si le compte a signé la transaction. Il est de type bool
• is_writable : indique si le compte est accessible en écriture dans cette transaction. Il est de type bool
• executable : indique si le compte est un programme. Il est de type bool

Limites

Les principales incompatibilités entre Solang et le développement Ethereum traditionnel sont les suivantes :

• msg.sender n’est pas disponible sur Solana. Avec le modèle de compte, un contrat Rust peut accéder à différents comptes de données. Lequel considérer comme l’appelant ? Dans de nombreux cas, il est impossible d’identifier un compte unique comme appelant. De plus, le runtime ne dispose d’aucun mécanisme permettant de récupérer les comptes appelants
• Il n’existe aucune fonction ecrecover(), mais une fonction signatureVerify() permet de vérifier les signatures ed25519.
• Les instructions try-catch ne fonctionnent pas. Le runtime interrompt l’exécution et annule l’intégralité de la transaction si un appel externe ou la création d’un contrat échoue.
• Les définitions d’erreurs et les annulations accompagnées de messages d’erreur ne fonctionnent pas encore
• Le transfert de valeur native avec un appel de fonction ne fonctionne pas.
• De nombreuses fonctions intégrées de Yul ne sont pas disponibles. Solang prend en charge la plupart des fonctions intégrées, mais les opérations liées à la mémoire et à la chaîne ne sont pas implémentées.
• Le format ERC-20 n’est pas actuellement pris en charge. Les tokens SPL sont définis conformément au Token Program. Le Token Program est la méthode native de Solana pour créer, émettre, transférer et brûler des tokens. Le fichier spl_token.sol doit être copié dans votre arborescence source et importé là où la bibliothèque SplToken est requise

De plus, les registres de la SVM ont une largeur de 64 bits. Les entiers de 64 bits, comme uint64 et int64, sont donc préférables aux entiers de 256 bits. Une opération utilisant des types de plus de 64 bits, comme uint256 ou int256, est divisée en plusieurs opérations. Elle est donc plus lente et consomme davantage d’unités de calcul.

Concernant les adresses, un littéral d’adresse doit être spécifié avec la syntaxe address"36VtvSbE6jVGGQytYWSaDPG7uZphaxEjpJHUUpuUbq4D". La syntaxe hexadécimale d’Ethereum, par exemple 0xE0f5206BBD039e7b0592d8918820024e2a7437b9, n’est pas prise en charge. Tous les soldes et toutes les valeurs sur Solana ont une largeur de 64 bits. Les fonctions intégrées pour les adresses, à savoir .balance(), .transfer() et .send(), utilisent donc des entiers de 64 bits.

Solang offre aux développeurs EVM une voie prometteuse pour explorer l’écosystème Solana, mais présente plusieurs limites qui exigent une attention particulière. Le passage au modèle de compte de Solana n’est pas une simple modification syntaxique : il représente un changement fondamental dans la logique des smart contracts. Certaines fonctions, certains modèles de programmation et certaines fonctionnalités propres à l’EVM ne sont pas disponibles avec Solang. Les développeurs ne peuvent pas porter un smart contract Ethereum vers Solang et s’attendre à ce qu’il fonctionne sans modifications importantes. Les fonctionnalités manquantes, comme l’absence de définitions d’erreurs appropriées et d’annulations accompagnées de messages d’erreur, peuvent être très pénalisantes. Il est toutefois important de reconnaître que Solang évolue constamment et que chaque mise à jour vise à améliorer l’expérience des développeurs Solidity sur Solana. Solang offre plusieurs avantages distincts pour améliorer cette expérience.

Avantages

Malgré ces limites, plusieurs fonctions intégrées et choix de conception améliorent l’expérience des développeurs. Par exemple, les contrats développés avec Solang peuvent interagir avec des programmes Anchor. Pour cela, vous pouvez générer une interface Solidity à partir de l’IDL d’un programme Anchor. IDL signifie « Interface Description Language ». Il s’agit essentiellement d’un fichier JSON qui contient toutes les spécifications d’un programme. Il inclut tout ce que vous devez savoir pour interagir avec un programme Anchor. Anchor génère automatiquement une IDL lors du développement d’un programme avec son framework. Ce mécanisme est très similaire aux ABI sur Ethereum. Pour générer une interface Solidity à partir d’une IDL, utilisez la commande suivante : solang idl [-output directory] [IDL file]. Le fichier peut ensuite être importé avec la syntaxe import “...”;.

Solang fournit la bibliothèque Solana, un ensemble de bibliothèques permettant aux contrats Solidity d’interagir avec des instructions propres à Solana. Solang fournit la bibliothèque SPL Token pour émettre, brûler et transférer des tokens. Elle peut être considérée comme un équivalent d’ERC-20 et d’ERC-721. Solang fournit également la bibliothèque System Instructions, qui permet aux développeurs d’interagir avec le System Program de Solana.

Solang inclut également certaines fonctionnalités intégrées qui peuvent être importées avec solana. Elles comprennent les structures AccountMeta et AccountInfo. La structure AccountMeta sert à spécifier les comptes à transmettre à la cible lors d’un appel externe, c’est-à-dire un CPI. La structure AccountMeta se présente comme suit :

• pubkey : l’adresse ou la clé publique du compte. Elle est de type address
• is_writable : indique si la cible peut écrire dans ce compte. Il est de type bool
• is_signer : indique si la cible peut considérer que ce compte a signé la transaction. Il est de type bool

Si l’argument accounts est omis dans un appel externe, le compilateur Solang génère automatiquement un tableau AccountMeta. Cela fonctionne uniquement si la fonction est déclarée comme externe. Dans le cas contraire, le tableau AccountMeta doit être créé manuellement conformément à l’ordre des comptes spécifié dans l’IDL. Si un appel donné ne nécessite aucun compte, transmettez un vecteur vide : {accounts: []}. La documentation de Solang fournit un exemple concret montrant comment construire le tableau AccountMetas :

function build_this() external {
	// When calling a constructor from an external function, the data account for the contract
	// 'BeingBuilt' should be passed as the 'BeingBuilt_dataAccount' in the client code.
	BeingBuilt.new("my_seed");
}

function build_that(address data_account, address payer_account) public {
	AccountMeta[3] metas = [
		AccountMeta({
			pubkey: data_account,
      is_signer: true,
      is_writable: true
		}),
    AccountMeta({
    	pubkey: payer_account,
      is_signer: true,
      is_writable: true
    }),
    AccountMeta({
      pubkey: address"11111111111111111111111111111111",
      is_writable: false,
      is_signer: false
    })
  ];
  BeingBuilt.new{accounts: metas}("my_seed");

	// No accounts are needed in this call, so we pass an empty vector.
	BeingBuilt.say_this{accounts: []}("It's summertime!");
}

Solang possède également des fonctions intégrées pour :

• Calculer le solde minimal requis pour créer un compte donné
• Créer un PDA pour une adresse de programme à partir des seeds et du bump fournis
• Trouver un PDA pour une adresse de programme à partir des seeds et du bump fournis

Solang comble l’écart entre Solana et Ethereum en proposant un compilateur doté d’un riche ensemble d’outils qui facilite la transition des développeurs EVM. Malgré ses limites, Solang offre plusieurs fonctionnalités pour améliorer l’expérience des développeurs, notamment la possibilité d’interagir avec les programmes Anchor, d’accéder à des bibliothèques propres à Solana et d’utiliser des fonctions intégrées. L’intégration de concepts familiers tels que les IDL et les normes de tokens réduit encore la courbe d’apprentissage. Ne pas avoir à se soucier du gas ni à l’optimiser est également un avantage appréciable. Solang représente une étape importante vers l’interopérabilité entre Solana et Ethereum. Pour les développeurs EVM qui souhaitent rejoindre l’univers hautement performant de Solana, Solang constitue un outil potentiel.

Neon EVM

Solang n’est pas la seule option offerte aux développeurs Solidity qui souhaitent construire sur Solana. Neon EVM se présente comme la première EVM parallélisable au monde. Il s’agit d’un environnement Ethereum entièrement compatible sur Solana. Cette solution synergique permet à quiconque le souhaite de faire évoluer des dApps Ethereum sur Solana tout en bénéficiant d’une expérience conviviale pour les développeurs. Ceux-ci peuvent déployer leurs dApps sans reconfigurer leurs smart contracts, écrits dans leurs langages préférés et à l’aide de leurs outils habituels.

Architecture

Neon EVM se compose de trois éléments principaux : le programme Neon EVM, Neon Proxy et Neon DAO.

Neon EVM est un programme Solana qui accepte des transactions similaires à celles d’Ethereum et les traite sur Solana conformément aux règles de l’EVM. Ces transactions de type Ethereum envoyées à Neon EVM sont appelées Neon Transactions. Elles constituent un sous-ensemble de méthodes JSON RPC conformes à l’API JSON-RPC d’Ethereum.

Neon Proxy permet aux développeurs Ethereum de porter leurs dApps vers Neon avec un minimum de modifications. Il encapsule les transactions EVM dans des transactions Solana et constitue une solution conteneurisée pour les Neon Operators. Ces opérateurs exécutent des serveurs Neon Proxy, acceptent les paiements en NEON et effectuent des paiements en SOL dans l’écosystème Solana. NEON est à la fois un token utilitaire et un token de gouvernance : les Neon Operators le collectent pour payer les frais de gas nécessaires à l’exécution des transactions, tandis que ses détenteurs peuvent participer à Neon DAO.

Neon DAO est un modèle de gouvernance communautaire conçu pour donner aux détenteurs de tokens NEON un pouvoir de décision concernant Neon EVM. Elle réunit des utilisateurs, des opérateurs, des contributeurs ainsi que des développeurs du cœur et des applications, qui délibèrent collectivement sur les règles de gouvernance et l’évolution du protocole. La DAO fonctionne au moyen de différentes assemblées décentralisées consacrées à l’écosystème, au développement et à la sécurité. Chaque assemblée facilite la prise de décisions collaborative et l’examen des propositions dans son domaine. L’assemblée consacrée à l’écosystème supervise la croissance durable de celui-ci et gère les fonds destinés aux subventions et aux initiatives. L’assemblée consacrée au développement gère les mises à niveau techniques du programme Neon et les interventions d’urgence. L’assemblée consacrée à la sécurité protège la trésorerie de Neon et le programme Neon contre les menaces potentielles.

Compatibilité EVM

Neon EVM facilite les interactions avec l’EVM sur Solana en :

• Implémentant la plupart des méthodes de l’API JSON-RPC d’Ethereum
• Utilisant un proxy spécialisé pour gérer les appels Ethereum
• S’adaptant aux différences et aux limites imposées par l’architecture de Solana

Interagir avec Neon EVM revient à utiliser n’importe quelle autre EVM. Les développeurs peuvent utiliser les méthodes familières de l’API RPC en les dirigeant vers Neon Proxy, pour une expérience de développement fluide. Les principales fonctionnalités comprennent :

• La compatibilité avec les smart contracts Solidity et Vyper, ainsi qu’avec les outils de développement Ethereum standard comme Metamask, Foundry et Remix
• La prise en charge sans modification de la plupart des opcodes Ethereum
• L’acceptation des requêtes de transaction Ethereum de type 0 ou legacy. Les transactions EIP-1559 ne sont actuellement pas prises en charge

Certaines adaptations sont bien entendu nécessaires pour que Neon EVM fonctionne correctement sur Solana. Les différences notables comprennent :

• Neon EVM prend en charge tous les contrats précompilés définis sur evm.code. Toutefois, les contrats Solidity contenant les appels suivants ne seront pas exécutés : bigModExp, bn256Add, bn256ScalarMult et bn256Pairing. Neon EVM devra implémenter des appels système Solana pour prendre en charge ces contrats à l’avenir
• Bien que la majorité des opcodes soient pris en charge sans modification, les opcodes COINBASE, PREVRANDAO (FKA DIFFICULTY), GASLIMIT, BASEFEE et GAS ne le sont pas. Appelés opcodes variants, ils sont adaptés à une utilisation dans Neon EVM.
• La consommation de gas et le calcul des frais diffèrent de ceux d’Ethereum. Ils se traduisent généralement par des coûts inférieurs, car Solana fait office de couche de règlement
• Les méthodes transfer() et send() de Solidity ne sont pas protégées contre la réentrance dans Neon EVM en raison de différences dans le calcul du gas
• Le modèle de compte de Solana influe sur le stockage des smart contracts, avec des fonctionnalités de stockage et des autorisations d’accès différentes pour les comptes exécutables et non exécutables
• Neon EVM utilise des transactions versionnées, ce qui limite à 64 le nombre maximal de comptes utilisés dans une même transaction
• Neon EVM utilise le Berkeley Packet Filter (BPF) de Solana, avec une mémoire de tas limitée à 256 Ko. Cela limite la taille des appels de contrat et nécessite des stratégies d’optimisation pour gérer efficacement l’utilisation de la mémoire
• Les fonctions temporelles telles que block.number et block.timestamp se comportent différemment. Il est fortement déconseillé aux développeurs de les utiliser lors du développement sur Neon EVM

Même si Neon EVM offre un environnement familier et compatible, les développeurs EVM doivent connaître les principales différences et s’y adapter pour réussir leur migration et leur développement sur Solana.

Connexion à un RPC Neon

Les développeurs peuvent facilement se connecter à un RPC Neon à l’aide de Chainlist. Ils peuvent se connecter au Mainnet ou au Devnet de Neon EVM. Cliquez sur Connect Wallet dans la fenêtre du Mainnet ou du Devnet, puis sur Approve lorsque votre wallet s’affiche.

Les utilisateurs doivent choisir l’opérateur optimal avant d’envoyer des transactions à Neon EVM. Développez les détails de la carte pour afficher les endpoints RPC disponibles pour chaque réseau :

Si vous choisissez un opérateur différent de celui fourni par défaut lors de la connexion du wallet, une connexion manuelle sera nécessaire. La documentation de Neon EVM propose des guides complets pour se connecter à un Proxy avec Foundry, Hardhat, Remix et Truffle. Nous verrons comment établir la connexion avec Foundry dans la section consacrée au déploiement.

Une fois connectés, les développeurs peuvent utiliser le Neon Faucet pour obtenir des tokens NEON ou d’autres tokens de test ERC-20. Ils peuvent également utiliser l’endpoint request_neon pour demander des tokens par programmation :

curl -i -X POST \
	-d '{"wallet": "Your wallet", "amount": 1}' \
	'http://localhost:3333/request_neon'

Cette commande envoie une requête POST afin de recevoir des tokens à l’adresse de wallet spécifiée.

Cycle de vie des transactions et frais de gas

L’exécution d’une transaction depuis une dApp Ethereum sur Solana via Neon EVM comporte trois étapes principales :

• Un utilisateur initie une transaction signée de type Ethereum, dirigée vers un endpoint RPC Neon
• La transaction est transmise à Neon Proxy via l’API Ethereum. Le Proxy estime le gas requis pour exécuter la transaction, lance sa diffusion en encapsulant la transaction de type Ethereum dans une transaction Solana, puis envoie la transaction encapsulée à Neon EVM. Cela produit un reçu Solana ainsi qu’un reçu Neon EVM correspondant à la transaction. Le smart contract Neon désencapsule la transaction, vérifie la signature de l’utilisateur et charge l’état de l’EVM depuis le stockage Solana. La transaction est exécutée dans le BPF de Solana
• Solana et Neon EVM mettent à jour leurs états pour finaliser la requête de transaction

Voici l’ensemble du cycle de vie d’une transaction dans Neon EVM, de son lancement à son exécution. Les développeurs peuvent consulter NeonScan pour voir les dernières transactions et les derniers blocs, ainsi que pour rechercher des comptes, des tokens, des blocs ou des hachages de transaction.

Les développeurs peuvent également envoyer des transactions sans gas. Cette fonctionnalité a été mise en œuvre pour aider les utilisateurs ne disposant pas de suffisamment de tokens NEON pour couvrir leurs premiers frais de transaction. Les développeurs peuvent obtenir un pack initial de transactions sans gas en contactant info@neonevm.org. Le Proxy Operator choisi par le développeur continuera de traiter ces transactions, mais Neon en couvrira le coût. Un minimum de trois transactions sans gas est généralement offert à chaque nouveau compte Neon.

Le processus des transactions sans gas est le suivant :

• Un utilisateur final initie une transaction via une dApp
• La dApp demande le prix actuel du gas au Proxy Operator choisi. Si le compte est éligible, le Proxy Operator marque le compte Neon comme autorisé à effectuer un nombre défini de transactions sans gas
• Pour ces transactions, la dApp affiche un coût de gas nul
• L’utilisateur final signe la transaction sans frais de gas
• Le Proxy Operator exécute la transaction, les frais de gas en SOL étant payés par la Neon Foundation

La documentation de Neon EVM fournit l’extrait suivant pour montrer comment demander une transaction sans gas :

try {
	// Get gasless transaction if user account is eligible
  const rawGasPrice = await axios.post(rpcApiUrl, {
  	method: 'neon_gasPrice',
    params: [{ from: address }],
    jsonrpc: "2.0",
    id: new Date().getTime()
   })

   tx.gasPrice = rawGasPrice.data?.result;
	} catch (e) {
  	//Else, get standard GAS price
   	setError('Can\'t retrieve gas price for transaction')

    const rawGasPrice = await web3.eth.getGasPrice();

    tx.gasPrice = web3.utils.toHex(rawGasPrice);
} finally {
    setTx(tx)
}

NeonPass

NeonPass est un outil permettant de transférer des tokens entre Solana et Neon EVM. Il permet de transférer facilement des actifs entre les Associated Token Accounts de Solana et les comptes de tokens ERC-20 de Neon EVM. NeonPass utilise le contrat d’interface de Neon EVM et un stockage de comptes spécialisé. Les tokens de la Solana Program Library (SPL) sont encapsulés dans une interface ERC-20 au sein du contrat factory de Neon EVM. Les SPL peuvent ainsi être stockés dans des comptes de tokens ERC-20 compatibles avec les dApps Solidity. NeonPass permet le transfert bidirectionnel de tokens entre des comptes Solana et Neon EVM. Contrairement aux bridges traditionnels qui verrouillent les actifs et en émettent de nouveaux, il déplace directement les tokens entre les deux types de comptes. Cela permet une transition fluide des tokens Solana et Neon EVM.

Déploiement

Les développeurs peuvent déployer sur Neon EVM à l’aide de Hardhat, Foundry, Truffle et Remix. Comme la manière la plus simple d’utiliser Solang passe par Anchor, tous les tests sont effectués en TypeScript. Toutefois, tous les adeptes de Solidity peuvent enfin tester et déployer des dApps Solidity sur Solana via Foundry.

Tout d’abord, vérifiez qu’un wallet compatible avec l’EVM est connecté au Devnet de Neon EVM. Clonez ensuite l’exemple de projet Foundry de Neon et accédez à son répertoire :

git clone https://github.com/neonlabsorg/neon-tutorials
cd neon-tutorials/foundry

Installez ensuite Foundryup, le programme d’installation de la chaîne d’outils Foundry, puis exécutez foundryup pour installer les derniers binaires précompilés (nightly), à savoir force, cast, anvil et chisel :

curl -L https://foundry.paradigm.xyz | bash
foundryup

Installez les bibliothèques requises :

forge install foundry-rs/forge-std --no-commit
forge install openzeppelin/openzeppelin-contracts --no-commit

Récupérez maintenant la clé privée de votre compte de wallet. Dans Metamask, par exemple, vous pouvez afficher votre clé privée en cliquant sur le menu hamburger, puis en accédant à Account Details > Show Private Key. Vous devrez alors saisir votre mot de passe. Cliquez sur Confirm pour accéder à la clé privée de votre compte. N’oubliez pas de ne jamais communiquer cette clé et prenez les mesures nécessaires pour la protéger.

Créez ensuite un fichier .env contenant les variables suivantes :

RPC_URL_DEVNET=https://devnet.neonevm.org
CHAIN_ID_DEVNET=245022926
RPC_URL_MAINNET=https://neon-proxy-mainnet.solana.p2p.org
CHAIN_ID_MAINNET=245022934
PRIVATE_KEY=
VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api

Remplacez <YOUR_PRIVATE_KEY> par votre clé privée, puis exécutez source .env.

Pour compiler les contrats du projet, accédez au répertoire src, puis exécutez forge build. La console doit indiquer que l’exécution du compilateur a réussi. Vous pouvez également tester les contrats à l’aide de la commande forge test. Pour déployer le contrat du projet, exécutez la commande suivante :

forge create --rpc-url $RPC_URL_DEVNET --private-key $PRIVATE_KEY src/TestERC20/TestERC20.sol:TestERC20 --constructor-args "Test ERC20 Token" "TERC20" --legacy

Vous devriez obtenir une sortie semblable à la suivante :

[⠰] Compiling...
No files changed, compilation skipped
Deployer: 0x4455E84Eaa56a01676365D4f86348B311969a4f4
Deployed to: 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9
Transaction hash: 0x6de9dab8a526cbac33008056d185b93dff725605efb791bf116b6bece4f0c486

Pour vérifier votre contrat, exécutez la commande suivante :

forge verify-contract --chain-id $CHAIN_ID_DEVNET  src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout

Remplacez <contract_address> par l’adresse de votre smart contract. Vous devriez recevoir une réponse OK avec une URL pointant vers l’adresse du contrat sur BlockScout, l’explorateur Devnet de Neon. Vous pouvez également configurer votre fichier .env pour utiliser NeonScan à la place de BlockScout, qui prend aussi en charge le Devnet.

Avantages et limites

Les développeurs qui recherchent une expérience similaire à celle d’Ethereum devraient choisir Neon EVM. Cet environnement compatible avec l’EVM envoie des transactions de type Ethereum et utilise des outils familiers. Des fonctionnalités comme NeonPass, la prise en charge de la plupart des opcodes EVM et les transactions sans gas facilitent considérablement la transition vers Solana. Neon EVM n’est toutefois pas parfait. Il présente certaines limites, notamment la nécessité de modifier la logique des smart contracts pour l’adapter à l’infrastructure de Solana, le fonctionnement sous les contraintes du Berkeley Packet Filter (BFP) et des modèles de compte de Solana, ainsi que certaines restrictions sur les opcodes et les contrats précompilés. Il est essentiel de comprendre et de maîtriser ces nuances pour réussir un déploiement sur Solana depuis un environnement compatible avec l’EVM.

Migrations passées

Plusieurs tâches complexes doivent être menées à bien pour qu’un grand protocole Ethereum puisse être déployé sur une chaîne non-EVM. Il faut notamment recruter des ingénieurs ne travaillant pas avec Solidity pour reconstruire entièrement la base de code, trouver des partenaires d’audit fiables, faire auditer à nouveau la nouvelle base de code et adapter les contrats de gouvernance afin de faire appliquer les décisions de la DAO. Ces opérations peuvent coûter des millions de dollars et nécessiter des mois de travail intensif. Ce n’est pas envisageable pour la plupart des projets. Pourtant, certains l’ont déjà fait.

Helium est un réseau LoRaWAN qui vise à créer une infrastructure sans fil décentralisée pour prendre en charge les appareils de l’Internet des objets (IoT). Pour cela, il utilise des hotspots, de petits appareils à faible consommation comparables à des antennes-relais miniatures, qui se connectent à d’autres hotspots sur de longues distances. Initialement déployé sur sa propre blockchain de couche 1 (L1), Helium a vu son équipe de développement proposer une migration vers Solana avec la HIP 70. Cette migration devait permettre à Helium d’améliorer sa disponibilité, sa composabilité et la rapidité de l’expérience utilisateur, tout en maintenant un niveau de sécurité élevé et de faibles coûts d’utilisation. La communauté a voté massivement en faveur de la proposition, et Helium a migré vers Solana en avril 2023. Scott Sigel, COO de Helium, a décrit la migration comme un événement sans histoire : aucun problème n’est survenu sur le réseau ou dans l’infrastructure de Helium. Un rêve pour tout ingénieur. L’équipe a également détaillé l’intégralité du processus de migration dans une série de guides publiés dans sa documentation. La migration de Helium a été un immense succès et a grandement profité à la communauté.

Cette migration n’est pas un cas isolé. The Render Network, la première plateforme décentralisée de rendu par GPU au monde, a réussi à faire migrer son infrastructure principale d’Ethereum vers Solana en novembre 2023. La communauté a voté en faveur de la RNP-002 pour migrer vers Solana. Jules Urbach, fondateur de Render, a décrit cette migration comme un tournant décisif. Il a déclaré : « La vitesse exceptionnelle des transactions de Solana, ses faibles coûts et son engagement en faveur d’une architecture à l’échelle du Web en font la solution idéale pour The Render Network, alors que nous poursuivons le développement d’une infrastructure de métavers évolutive et décentralisée. »

La migration de Render n’a pas eu d’effets particulièrement négatifs sur ses utilisateurs. Ceux-ci peuvent transférer leurs fonds d’Ethereum vers Solana à l’aide de l’Upgrade Assistant de Render. Ils connectent leur portefeuille Ethereum, indiquent le montant de RNDR qu’ils souhaitent migrer, puis attendent que leurs tokens soient transférés vers le portefeuille Solana spécifié. 

Maker est un projet Ethereum emblématique. Son objectif est de libérer le potentiel de la finance décentralisée grâce à la Maker Platform, une plateforme inclusive conçue pour renforcer l’autonomie économique et garantir un accès équitable au marché financier mondial. La plateforme comprend MakerDAO, chargé d’administrer le projet Maker, et le protocole Maker pour le DAI, « la première monnaie impartiale au monde et le principal stablecoin décentralisé ». Rune Christensen, fondateur de Maker, a publié un tweet sur l’utilisation d’un fork de la base de code de Solana pour développer une appchain Maker : 

Les migrations sont intrinsèquement complexes. Malgré les coûts financiers, réputationnels et temporels liés à la migration de toute l’infrastructure d’un projet d’Ethereum vers Solana, des projets choisissent Solana. Avec des outils comme Solang et Neon EVM, les migrations ne doivent pas nécessairement être complexes. Comme celle de Helium, une migration peut se dérouler sans histoire et n’avoir que peu ou pas d’effets négatifs sur les fonds des utilisateurs, à l’image de celle de The Render Network. Solana est la blockchain la plus performante du marché, conçue pour fonctionner à l’échelle du Web. C’est la plateforme idéale pour développer, et de plus en plus de projets en prennent conscience.

Conclusion

Solidity est la lingua franca du développement de smart contracts. Depuis sa création, l’EVM est l’environnement dominant pour les smart contracts. Elle présente toutefois des faiblesses. Les applications grand public à l’échelle du Web nécessitent un réseau à haut débit et à faible latence pour assurer leur fonctionnement. L’environnement monothread d’Ethereum, fondé sur des frais de gas volatils, ne peut pas prendre en charge un projet de réseau d’infrastructure physique décentralisé (DePIN) à haut débit comme Helium. 

Face à ces défis, Solana s’impose comme une alternative puissante. Le meilleur moyen de profiter pleinement des avantages de Solana consiste à développer directement sur Solana. Grâce aux avancées récentes, des outils comme Solang et Neon EVM permettent aux développeurs EVM intéressés de migrer en utilisant des outils et des langages qu’ils connaissent déjà. Cet article propose un guide complet de l’architecture de Solana, la compare à Ethereum et explique comment un développeur EVM peut commencer à développer sur Solana. Solana est la blockchain la plus performante du marché. Elle gagne en popularité et en notoriété, tout en attirant des applications grand public reconnues. Pourquoi attendre qu’Ethereum passe à l’échelle lorsque vous pouvez profiter dès aujourd’hui des avantages d’une blockchain rapide et évolutive ?

Si vous avez lu jusqu’ici, merci, anon ! Saisissez votre adresse e-mail ci-dessous pour ne manquer aucune actualité concernant Solana. Vous souhaitez aller plus loin ? Rejoignez notre Discord pour commencer dès aujourd’hui à bâtir l’avenir sur la blockchain la plus performante.

Ressources complémentaires

• Évaluer Solana pour un usage en entreprise : guide complet
• Neon EVM
• Documentation de Solang pour Solana
• Le livre de Rust
• Le modèle de programmation de Solana : introduction au développement sur Solana
• Tower BFT : l’implémentation haute performance de PBFT par Solana
• Qu’est-ce que la SVM ? La machine virtuelle de Solana