Développement de contrats intelligents : comparaison de deux cadres de référence

Quand j'ai commencé à développer avec Solidity, j'ai vite laissé tomber les IDE en ligne et adopté Hardhat comme nouveau framework principal. Après quelques mois passés à construire des projets et à créer un workflow autour, je me suis senti à l'aise avec sa configuration réseau, sa stratégie de test et son organisation de projet.

Mais quand quelqu'un a dit que les performances de Foundry étaient vraiment impressionnantes, ça m'a donné envie de comparer sérieusement ces deux frameworks populaires pour le développement de contrats intelligents.

Pour faire une évaluation juste, j'ai créé les mêmes projets avec les deux outils et j'ai utilisé le même contrat MiniBank et les mêmes paramètres de test. Cette expérience pratique a montré que les performances, l'expérience des développeurs et le flux de travail diffèrent beaucoup entre ces deux outils, et ça vaut le coup d'y jeter un œil si tu dois choisir entre les deux.

La première fois qu'on les configure, c'est assez différent dans les deux frameworks. Foundry crée un fichier de configuration foundry.toml basé sur des paires clé-valeur, un peu comme le fichier hardhat.config.js de Hardhat. Les deux permettent aussi de personnaliser les dossiers source, les répertoires de sortie de compilation, etc.

La structure par défaut des dossiers est assez différente dans Foundry, mais plusieurs réseaux ne peuvent pas être configurés directement dans le fichier de configuration, car Hardhat fait un super boulot pour gérer plusieurs réseaux. Les autres paramètres dans foundry.toml sont liés aux options de test, comme la verbosité ou les paramètres du compte et les options de prix du gaz.

Par exemple, au lieu d'écrire de longs chemins d'importation, tu peux écrire des mappages courts qui rendent ton code plus lisible et plus facile à maintenir.

Les frameworks sont super différents dans la façon dont ils gèrent les dépendances :

• Hardhat utilise l'écosystème npm bien connu, qui est tout de suite accessible aux développeurs JavaScript.
• Pour installer les contrats OpenZeppelin, il suffit de taper la commande npm install
• Foundry utilise la gestion des dépendances par sous-module Git via l'outil CLI forge
• Les dépendances sont stockées dans un dossier lib/ et ajoutées dans un fichier .gitmodules, contrairement à package.json.

Cette méthode prendra n'importe quel dépôt GitHub qui inclut des contrats intelligents comme dépendance et te permettra d'être plus flexible dans le choix des bibliothèques.

Tu peux indiquer le nom de l'organisation et du dépôt GitHub, et aussi, si tu veux, la branche ou la balise à installer. Une fois que Forge est installé, tu peux utiliser la commande de remappage Forge pour voir les chemins d'importation par défaut que Foundry va utiliser, que tu peux ensuite personnaliser avec des fichiers de configuration.

L'un des domaines dans lesquels Hardhat excelle est son expérience de débogage. Le framework propose aussi l'utilisation de console.log par défaut, qui ressemble au style de débogage attendu dans le développement JavaScript. Cette fonctionnalité est largement mise en avant comme argument de vente et peut être facilement suivie par les développeurs pour comprendre comment l'exécution s'est déroulée et ce qui ne va pas.

Foundry a besoin d'une autre façon de se connecter aux contrats. Même si on peut installer et importer Hardhat à la main et installer un contrat de console, le mieux serait de copier un contrat de console spécialisé dans ton projet.

Dans le cas des fichiers de test en particulier, le contrat DSTest inclus comprend des événements de journalisation tels que logstring, logint et logaddress qui peuvent être émis sans aucune dépendance supplémentaire.

L'expérience de test est peut-être le truc qui différencie le plus ces deux frameworks.

Approche de test Hardhat

Hardhat se base sur des modèles de test JavaScript standard :

• Utilise les blocs describe et it avec Mocha comme bibliothèque d'assertion par défaut.
• Les fichiers de test peuvent ressembler à ce style plus naturel des développeurs qui connaissent bien le développement web
• Propose des noms de tests descriptifs qui indiquent clairement leur but
• Modèles asynchrones familiers
• La courbe d'apprentissage est minime pour ceux qui connaissent déjà le développement web moderne

Approche de test de la fonderie

Foundry fonctionne de manière complètement différente :

• Les tests sont développés sous forme de contrats intelligents Solidity, qui héritent de DSTest
• Tous les tests sont des fonctions qui commencent par test ou testFail.
• Toutes les assertions sont faites via le contrat DSTest hérité.
• Les fichiers de test sont de vrais contrats intelligents utilisés pour les tests

La méthode Foundry a pas mal de conséquences :

• Les contrats de test doivent être instanciés dans une procédure setUp() similaire à beforeEach dans les clients JavaScript.
• La méthode de contrat de répartition de l'ETH implique une syntaxe particulière avec des paramètres de valeur entre accolades.
• La courbe d'apprentissage initiale assez raide peut être compensée par le fait qu'il n'est pas nécessaire de gérer des opérations asynchrones.

Foundry propose un concept appelé « cheat codes » qui offre des outils de test super puissants. Ce sont des fonctions spéciales à une adresse de contrat spécifique qui te permettent d'accéder à l'état de la blockchain pendant les tests.

Tu peux :

• Change pas le numéro de bloc actuel.
• Ne te fais pas passer pour d'autres comptes.
• Revendique certains comportements contractuels.

Pour utiliser les codes de triche, tu dois définir une interface et l'instancier en tant que variable d'état à l'adresse spéciale de la triche. Une fois la configuration effectuée, il est possible de tricher avec des fonctions telles que :

• vm.prank() pour définir l'appel de contrat suivant vers un autre destinataire
• vm.roll() pour faire avancer la blockchain jusqu'à un certain point

La différence de performance entre les frameworks est importante et se voit tout de suite. Avec les mêmes contrats et scénarios de test, j'ai eu des résultats intéressants sur le temps de compilation et d'exécution des tests :

Ces différences de performance sont plus marquées quand le projet devient plus compliqué.

Les avantages en termes de performances sont indéniables, et les noms des tests Solidity ne peuvent pas être aussi descriptifs que ceux de JavaScript, ce qui peut rendre l'intention du test obscure. Le système de codes de triche, bien que puissant, nécessite un certain temps d'apprentissage.

Le déploiement est un domaine où Hardhat offre une meilleure expérience développeur pour le moment. Le framework accepte :

• Scripts de déploiement basés sur JavaScript
• Connexion avec plein de réseaux
• Charge la configuration via des variables d'environnement
• Gérer avec élégance les situations de déploiement compliquées

Les scripts de déploiement basés sur JavaScript sont actuellement obligatoires dans Foundry, mais ça peut être un peu galère quand les constructeurs doivent avoir leurs arguments fournis. La solution suggérée, c'est de créer des scripts bash de déploiement pour gérer la complexité des déploiements, mais l'équipe de développement est en train de bosser sur des solutions de déploiement plus avancées.

C'est l'un des points faibles les plus importants de Foundry par rapport à Hardhat, qui a un écosystème de déploiement bien développé.

Foundry a un outil CLI qui permet d'interagir avec la blockchain et d'interroger les contrats intelligents. C'est un outil super pratique qui te permet de :

• Appelez les fonctions du contrat.
• Interroger l'état de la blockchain
• Fais plein d'actions blockchain depuis la ligne de commande

Même si cast offre toutes les fonctionnalités pour interagir avec la blockchain, il faut créer des lignes de commande compliquées pour faire des opérations complexes. Comme pour le déploiement, ça peut demander des scripts bash pour éviter de taper plein de fois des commandes longues.

Foundry montre un énorme potentiel grâce à ses performances incroyables, sa communauté active et sa méthode créative pour tester les contrats intelligents. Sa structure est super pour les cycles de développement rapides et offre des outils de test géniaux qui peuvent vraiment accélérer le développement une fois qu'on a compris comment les utiliser.

Mais bon, Foundry continue à se développer, surtout pour les outils de déploiement et l'expérience des développeurs. Foundry a des atouts sympas pour les développeurs qui préfèrent un modèle hybride avec :

• Foundry pour le développement et le test de contrats
• Casque de chantier pour le déploiement et les scripts

Les utilisateurs qui sont plus habitués aux outils JavaScript standard et aux pratiques de déploiement établies pourraient être plus productifs avec Hardhat maintenant, même si la décision dépend encore une fois de ton expérience et de ta capacité à adopter de nouveaux outils.