L’écosystème Ethereum continue de témoin une vague d’activités qui amène des particuliers et des organisations à déployer des contrats symboliques, à ajouter des liquidités aux pools et à déployer des contrats intelligents pour prendre en charge un large éventail de modèles commerciaux. Bien que notable, cette croissance a également été criblée d’exploits de sécurité, laissant les protocoles de financement décentralisé (DeFi) vulnérables aux piratages et aux escroqueries.
Par exemple, les découvertes récentes de la société de renseignement cryptographique Chainalysis Afficher que les piratages liés à la cryptographie ont augmenté de 58,3 % depuis le début de l’année jusqu’en juillet 2022. Le rapport note en outre que 1,9 milliard de dollars ont été perdus à cause des piratages au cours de cette période – un chiffre qui n’inclut pas le piratage du pont Nomad de 190 millions de dollars qui survenu le 1er août 2022.
Bien que le code open source puisse être bénéfique pour l’industrie de la blockchain, il peut malheureusement être facilement étudié par les cybercriminels à la recherche d’exploits. Les audits de sécurité pour les contrats intelligents visent à résoudre ces problèmes, mais cette procédure manque de normes de l’industrie, ce qui crée de la complexité.
Une norme de l’industrie pour assurer la sécurité des contrats intelligents
Chris Cordi, président du groupe de travail sur les niveaux de sécurité EthTrust de l’Enterprise Ethereum Alliance (EEA), a déclaré à Cointelegraph qu’à mesure que l’industrie de la blockchain Ethereum se développe, le besoin d’un cadre mature pour évaluer la sécurité des contrats intelligents augmente également.
Afin de résoudre ce problème, Cordi, ainsi que plusieurs représentants de membres de l’AEE ayant une expertise en audit et en sécurité, ont contribué à la création du groupe de travail sur les niveaux de sécurité EthTrust en novembre 2020. L’organisation travaille depuis sur un projet de document de spécification de contrat intelligent, ou industrie standard, visant à améliorer la sécurité derrière les contacts intelligents.
Plus récemment, le groupe de travail a annoncé la publication de la spécification des niveaux de sécurité EthTrust v1. Chaals Nevile, directeur du programme technique de l’AEE, a déclaré à Cointelegraph que cette spécification décrit les vulnérabilités des contrats intelligents qu’un audit de sécurité approprié nécessite comme mesure minimale de qualité :
« Il est pertinent pour toutes les plates-formes de contrats intelligents basées sur EVM où les développeurs utilisent Solidity comme langage de codage. Dans une analyse récente de Splunk, cela représente bien plus des 3/4 des contrats du réseau principal. Mais il existe également des réseaux et des projets privés basés sur la pile technologique Ethereum mais exécutant leur propre chaîne. Cette spécification leur est aussi utile qu’aux utilisateurs du réseau principal pour les aider à sécuriser leur travail.
D’un point de vue technique, Nevile a expliqué que la nouvelle spécification décrit trois niveaux de tests que les organisations doivent prendre en compte lors de la réalisation d’audits de sécurité des contrats intelligents.
« Niveau [S] est conçu pour que, dans la plupart des cas, où les fonctionnalités communes de Solidity sont utilisées selon des modèles bien connus, le code testé puisse être certifié par un outil d’« analyse statique » automatisé », a-t-il déclaré.
Il a ajouté que le niveau [M] test rend obligatoire une analyse statique plus stricte, en notant que cela inclut des exigences où un auditeur humain est censé déterminer si l’utilisation d’une fonctionnalité est nécessaire ou si une déclaration sur les propriétés de sécurité du code est justifiée.
Nevile a en outre expliqué que le niveau [Q] test fournit une analyse de la logique métier implémentée par le code testé. « Il s’agit de s’assurer que le code ne présente pas de vulnérabilités de sécurité connues, tout en s’assurant qu’il implémente correctement ce qu’il prétend », a-t-il déclaré. Il existe également un test facultatif de « bonnes pratiques recommandées » qui peut aider à renforcer la sécurité derrière les contrats intelligents. Neville a dit :
« L’utilisation du dernier compilateur fait partie des ‘bonnes pratiques recommandées’. C’est assez simple dans la plupart des cas, mais il y a beaucoup de raisons pour lesquelles un contrat n’a peut-être pas été déployé avec la dernière version. D’autres bonnes pratiques incluent le signalement de nouvelles vulnérabilités afin qu’elles puissent être traitées dans une mise à jour de la spécification et l’écriture de code propre et facile à lire.
Dans l’ensemble, il y a 107 exigences dans l’ensemble de la spécification. Selon Nevile, environ 50 d’entre eux sont de niveau [S] exigences résultant de bogues dans scompilateurs d’olidité.
Une norme industrielle aidera-t-elle les organisations et les développeurs ?
Nevile a souligné que la spécification des niveaux de sécurité EthTrust vise en fin de compte à aider les auditeurs à démontrer aux clients qu’ils opèrent à un niveau approprié à l’industrie. « Les auditeurs peuvent se référer à cette norme de l’industrie pour établir une crédibilité de base », a-t-il déclaré.
Récent : les jeux Web3 intègrent des fonctionnalités pour stimuler la participation des femmes
Faisant la lumière sur cela, Ronghui Gu, PDG et co-fondateur de la société de sécurité blockchain CertiK, a déclaré à Cointelegraph que le fait d’avoir des normes comme celles-ci aide à garantir les processus et les directives attendus. Cependant, il a noté que de telles normes ne sont en aucun cas un « tampon en caoutchouc » pour indiquer qu’un contrat intelligent est entièrement sécurisé :
« Il est important de comprendre que tous les auditeurs de contrats intelligents ne sont pas égaux. L’audit de contrat intelligent commence par la compréhension et l’expérience de l’écosystème spécifique pour lequel un contrat intelligent est audité, ainsi que de la pile technologique et du langage de code utilisés. Tous les codes ou chaînes ne sont pas égaux. L’expérience est importante ici pour la couverture et les résultats.
Compte tenu de cela, Gu estime que les entreprises qui souhaitent faire auditer leurs contrats intelligents devraient regarder au-delà de la certification qu’un auditeur prétend avoir et prendre en compte la qualité, l’échelle et la réputation de l’auditeur. Parce que ces normes sont des lignes directrices, Gu a fait remarquer qu’il pense que cette spécification est un bon point de départ.
Du point de vue d’un développeur, ces spécifications peuvent s’avérer extrêmement bénéfiques. Mark Beylin, co-fondateur de Myco – un réseau social émergent basé sur la blockchain – a déclaré à Cointelegraph que ces normes seront extrêmement précieuses pour aider les développeurs de contrats intelligents à mieux comprendre à quoi s’attendre d’un audit de sécurité. Il a dit:
« Actuellement, il existe de nombreuses ressources dispersées pour la sécurité des contrats intelligents, mais il n’y a pas de règlement spécifique que les auditeurs suivront lors de l’évaluation de la sécurité d’un projet. En utilisant cette spécification, les auditeurs de sécurité et leurs clients peuvent être sur la même page pour savoir quel type d’exigences de sécurité sera vérifié.
Michael Lewellen, développeur et contributeur à la spécification, a en outre déclaré à Cointelegraph que ces spécifications aident en fournissant une liste de contrôle des problèmes de sécurité connus à vérifier. « De nombreux développeurs Solidity n’ont pas reçu d’éducation ou de formation formelle récente sur les aspects de sécurité du développement Solidity, mais la sécurité est toujours attendue. Avoir des spécifications comme celle-ci permet de comprendre plus facilement comment écrire du code de manière plus sécurisée », a-t-il déclaré.
Récent : Ethereum Merge invite les mineurs et les pools miniers à faire un choix
Lewellen a également noté que la plupart des exigences de spécification sont rédigées de manière simple, ce qui facilite la compréhension des développeurs. Cependant, il a fait remarquer qu’il n’est pas toujours clair pourquoi une exigence est incluse. « Certains ont des liens vers une documentation externe d’une vulnérabilité, mais d’autres non. Il serait plus facile pour les développeurs de comprendre s’ils disposaient d’exemples plus clairs de ce à quoi pourrait ressembler un code conforme et non conforme.
L’évolution des normes de sécurité des contrats intelligents
Tout bien considéré, la spécification du niveau de sécurité contribue à faire progresser l’écosystème Ethereum en établissant des lignes directrices pour les audits de contrats intelligents. Pourtant, Nevile a noté que l’aspect le plus difficile pour aller de l’avant est d’anticiper comment un exploit pourrait se produire. Il a dit:
« Cette spécification ne résout pas complètement ces défis. Ce que fait la spécification, cependant, c’est d’identifier certaines étapes, comme la documentation de l’architecture et de la logique métier derrière les contrats, qui sont importantes pour permettre un audit de sécurité approfondi.
Gu pense également que différentes chaînes commenceront à développer des normes similaires à mesure que Web3 progresse. Par exemple, certains développeurs de l’industrie Ethereum proposent leurs propres exigences en matière de contrats intelligents pour aider les autres. Par exemple, Samuel Cardillo, directeur de la technologie chez RTFKT, a récemment tweeté qu’il avait créé un système permettant aux développeurs d’évaluer publiquement les contrats intelligents en fonction des bons et des mauvais éléments en termes de développement :
Il y a quelques jours, j’ai lancé une petite feuille de calcul Google pour évaluer publiquement les contrats intelligents afin de sensibiliser et d’aider à la fois les collectionneurs et les développeurs – elle contiendra également ce qu’il faut faire et ne pas faire lors de l’élaboration d’un contrat.
https://t.co/2ixBpkNeoc— SamuelCardillo.eth – RTFKT (@CardilloSamuel) 15 août 2021
Bien que tout cela soit un pas dans la bonne direction, M. Gu a souligné que les normes mettent du temps à être largement adoptées. De plus, Nevile a expliqué que la sécurité n’est jamais statique. À ce titre, il a expliqué qu’il est possible pour les particuliers d’envoyer des questions au groupe de travail qui a rédigé la spécification. « Nous prendrons ces commentaires, ainsi que les discussions dans l’espace public plus large, car nous prévoyons de mettre à jour la spécification », a déclaré Nevile. Il a ajouté qu’une nouvelle version de la spécification sera produite d’ici six à dix-huit mois.