Bugs dans le compilateur Solidity : Plongée profonde

Les Contrats intelligents sont des accords qui s'exécutent tout seuls, écrits en code et qui tournent sur des plateformes blockchain comme Ethereum. Ils automatisent et font respecter les termes des contrats sans avoir besoin d'un intermédiaire. Cette technologie a rendu les processus plus transparents et efficaces dans des domaines comme la finance, la chaîne d'approvisionnement et l'immobilier. Plus de 47 milliards de dollars d'actifs numériques sont gérés par des contrats intelligents depuis novembre 2023. La plupart de ces contrats sont écrits dans un langage de programmation appelé Solidity, qui est compilé en bytecode pour fonctionner sur la plateforme Ethereum.

La qualité du compilateur est super importante pour la performance et la fiabilité des contrats intelligents. Comme pour tout logiciel, les Compilateurs Solidity peuvent avoir des Bugs. Ces bugs peuvent mener à un code incorrect déployé sur la blockchain, ce qui entraîne des problèmes de sécurité. Un exemple marquant s'est produit lorsqu'un défaut a transformé une fonctionnalité de sécurité bien fonctionnelle d'un contrat intelligent en une version défectueuse, entraînant une perte d'environ 73,5 millions de dollars après avoir été exploitée pendant plus de deux ans.

Comprendre les bugs dans les compilateurs Solidity est crucial pour améliorer la sécurité et la fiabilité des contrats intelligents. Cet article discute de notre étude systématique sur les bugs du compilateur Solidity, en se concentrant sur leurs caractéristiques, causes profondes et conséquences.

#Collecte et classification des bugs

Pour étudier ces bugs, nous avons d'abord rassemblé des données à partir de GitHub, en collectant plus de 1 210 problèmes signalés étiquetés comme "bug". Nous avons filtré les problèmes non résolus et les doublons, ce qui nous a donné un ensemble unique de bugs à analyser.

#Processus de classification des bugs

Pour classer ces bugs, nous avons traversé plusieurs tours d'analyse, où des équipes de chercheurs ont examiné des bugs sélectionnés au hasard et identifié leurs symptômes et causes profondes. Ils ont collaboré pour s'assurer qu'il y avait un accord sur les classifications, avec l'avis d'experts pour plus de précision.

#Symptômes des bugs

Grâce à notre analyse, nous avons identifié cinq symptômes principaux présentés par les bugs :

1. Plantage : Ce symptôme se produit lorsque le programme s'arrête de manière inattendue ou se comporte anormalement. Cela peut être dû à des fuites de mémoire ou à l'épuisement des ressources, et c'était le symptôme le plus commun dans nos bugs collectés.

   • Rejet de programme valide : Cela se produit lorsque le compilateur rejette à tort un programme valide, produisant un message d'erreur.
   • Message d'erreur peu informatif : Ici, le message d'erreur généré n'est pas utile pour les utilisateurs essayant de déboguer leur code.

2. Sortie incorrecte : Ce symptôme implique que le compilateur produit des résultats qui ne correspondent pas aux attentes des utilisateurs. Cela peut inclure des problèmes avec le bytecode ou les valeurs retournées.

3. Omission d'erreur : Cela décrit des situations où le compilateur ne parvient pas à détecter ou à signaler une erreur alors qu'il aurait dû.

4. Problème de performance : Ce symptôme fait référence à des situations où le bytecode généré ne fonctionne pas bien, possiblement à cause d'une mauvaise optimisation.

5. Bloquer : Dans une situation de blocage, le programme devient non réactif et cesse de fonctionner.

#Causes profondes des bugs

Nous avons constaté que les bugs identifiés pouvaient être retracés à douze causes profondes principales :

1. Erreur d'analyse sémantique : Des Erreurs se produisant lorsque le compilateur analyse le sens du programme au lieu de juste la syntaxe.
2. Erreur de vérification formelle : Problèmes survenant lors des contrôles de sécurité et des confirmations lors de la compilation du code.
3. Erreur de génération de code : Problèmes rencontrés lors de la conversion du code en différents formats exécutables.
4. Erreur de système de types : Erreurs dans la définition des types et opérations permis dans le langage de programmation.
5. Erreur de gestion des exceptions : Défis dans la réponse du compilateur aux situations inattendues lors de l'exécution du programme.
6. Erreur liée à la mémoire : Problèmes liés à l'allocation et à la gestion de la mémoire pendant le processus de compilation.
7. Erreur d'optimisation : Problèmes qui surviennent lors des efforts d'amélioration des performances du bytecode, notamment concernant la consommation de gaz.
8. Erreur d'analyse syntaxique : Erreurs liées aux règles de construction du code.
9. Erreur de documentation : Erreurs trouvées dans la documentation écrite dans le code.
10. Erreur de lecture-écriture : Problèmes survenant lorsque le compilateur interagit avec des fichiers sources et des tampons de données.
11. Erreur d'analyse Yul : Problèmes liés à l'analyse du code Yul, un langage intermédiaire utilisé dans Solidity.
12. Autres : Un fourre-tout pour les bugs qui ne rentrent pas dans d'autres catégories.

#Caractéristiques des bugs

La corrélation entre les symptômes et les causes profondes fournit un aperçu de la façon dont ces bugs se manifestent. Par exemple, la plupart des symptômes "Omission d'erreur" étaient liés à des erreurs d'analyse sémantique. Identifier ces relations peut guider une détection et une résolution de bugs plus efficaces.

La distribution des bugs varie également entre les différents composants du compilateur. Le composant de base reflète souvent la distribution générale, tandis que le composant de vérification formelle montre une incidence plus élevée de rejet de programmes valides, indiquant des besoins spécifiques de détection de bugs dans ce domaine.

#Caractéristiques des cas de test

Les cas de test qui révèlent des bugs partagent souvent des modèles communs. Par exemple, les erreurs provenant de problèmes d'analyse sémantique surviennent fréquemment à cause de problèmes de portée. En revanche, les erreurs de vérification formelle peuvent être déclenchées par des flux de données complexes qui nécessitent une manipulation soigneuse. Comprendre ces modèles peut mener à de meilleures stratégies de test.

#Oracles de test

Les oracles de test sont des mécanismes qui aident à déterminer si un test a réussi ou échoué, cruciaux pour noter la présence de bugs. Comme nos résultats l'indiquent, des oracles spéciaux sont nécessaires pour détecter efficacement les bugs caractérisés par des anomalies de sortie ou des messages d'erreur trompeurs.

1. Oracle de test sensible à la sortie : Utilisé pour vérifier la justesse des sorties, surtout pour des bugs qui ne plantent pas le programme.
2. Oracle de test sensible au message d'erreur : Axé sur l'assurance que les messages d'erreur fournissent des indications adéquates pour le débogage.
3. Oracle de test sensible à la validité : Vise à vérifier la validité du code et à identifier les échecs silencieux.

#Évaluation des Fuzzers

Nous avons évalué trois fuzzers existants conçus pour le compilateur Solidity afin de comprendre à quel point ils détectent efficacement les bugs identifiés.

#Critères de sélection des fuzzers

Nous avons choisi des fuzzers spécifiquement adaptés pour Solidity, incluant AFL-compiler-fuzzer, solfuzzer et Fuzzol. Chaque fuzzer a des caractéristiques uniques qui aident dans les tests, et l'objectif était d'évaluer leur performance sur une période donnée.

#Processus de fuzzing

Lors de l'évaluation, nous avons utilisé chaque fuzzer dans plusieurs scénarios de test. L'efficacité a été mesurée par le nombre de bugs détectés, en prêtant attention aux caractéristiques distinctes et aux limitations de chaque fuzzer.

#Résultats de l'évaluation des fuzzers

Dans notre évaluation, nous avons remarqué des résultats variés parmi les fuzzers. L'AFL-compiler-fuzzer a été le plus efficace pour découvrir des bugs, suivi de près par Fuzzol, tandis que solfuzzer a eu plus de mal à détecter quoi que ce soit.

Malgré quelques chevauchements dans la détection, les fuzzers ont mis en évidence des forces et des faiblesses différentes, montrant qu'ils abordent la détection de bugs sous différents angles. Notamment, les trois fuzzers ont eu du mal à détecter les erreurs sémantiques et de vérification formelle, indiquant que des améliorations sont nécessaires dans ces domaines.

#Amélioration de la détection des bugs

Notre étude fournit plusieurs idées pour améliorer la détection des bugs dans le compilateur Solidity. Les recommandations incluent le développement de mutateurs spécialisés axés sur des fonctionnalités clés comme la portée, les types et les flux de données pour révéler plus de bugs.

Les fuzzers ne devraient pas juste se fier aux plantages, mais devraient aussi analyser les sorties, les messages d'erreur et les signaux d'avertissement pour détecter des bugs subtils qui ne mènent pas à des échecs immédiats.

#Conclusion

Le compilateur Solidity joue un rôle crucial dans l'exécution des contrats intelligents, ce qui rend sa fiabilité essentielle. Grâce à une recherche systématique, nous avons caractérisé divers bugs dans le compilateur, identifié des causes profondes et suggéré des méthodes pour la détection et la résolution.

Alors que les contrats intelligents continuent de façonner l'avenir de la technologie, comprendre et améliorer la performance des compilateurs renforcera la sécurité et la fiabilité de l'écosystème blockchain. Les recherches futures devraient se concentrer sur le raffinement des méthodes de détection, notamment pour les défis uniques posés par l'environnement Solidity.