La vérification du code source d’un contrat Ethereum relie un programme lisible au bytecode présent à une adresse précise. Sa question centrale est la suivante : les fichiers sources et les paramètres de compilation fournis permettent-ils de reproduire le code comparé ? Une correspondance apporte une preuve sur cette relation. La correction du programme, son audit et sa sécurité nécessitent d’autres éléments.
Pour interpréter la mention « vérifié », il faut donc identifier l’adresse concernée, les données de compilation et le type de correspondance annoncé. Voici comment lire ces informations sans leur attribuer une portée excessive.
Du code source au bytecode déployé
Les développeurs écrivent le code source d’un contrat dans un langage de haut niveau, comme Solidity. Ils le compilent ensuite en bytecode pour que la machine virtuelle Ethereum, ou EVM, puisse exécuter sa logique. Le code source et le bytecode correspondent ainsi à deux représentations liées du programme.
La vérification du code source consiste à contrôler si les sources fournies se compilent en un bytecode correspondant à celui exécuté à l’adresse du contrat étudié. L’adresse délimite la comparaison : le résultat ne s’étend pas à tous les contrats portant un nom similaire.
L’intérêt pratique est la lisibilité. Le code source facilite l’examen du comportement dans un langage de haut niveau, sans devoir lire des instructions machine. Cette possibilité d’examen ne prouve pas qu’une analyse de sécurité a effectivement eu lieu. Ces distinctions sont présentées dans la documentation Ethereum sur la vérification du code source.
Pour situer cette comparaison dans le fonctionnement général d’un programme, notre guide explique les liens entre code, état et appels d’un smart contract Ethereum.
Ce qu’établit une compilation reproductible
La compilation est déterministe lorsque les mêmes fichiers sources et les mêmes paramètres de compilation sont utilisés. Ces paramètres comprennent notamment la version du compilateur et la configuration de l’optimiseur. La reproductibilité dépend donc de l’ensemble des données fournies, et pas uniquement d’un fichier source affiché.
Lorsqu’une correspondance est établie, elle relie ces données au bytecode comparé. Pour lire un résultat, cherchez quels fichiers et quels paramètres il décrit. Le seul nom d’un compilateur ne documente pas suffisamment cet ensemble.
Cette explication comporte une limite. La documentation Ethereum précise que la présentation consistant à recompiler puis à comparer est simplifiée ; elle mentionne des exceptions, notamment les variables immuables. Le présent article ne décrit pas leur traitement par les outils. Un écart réel demanderait une analyse de ses circonstances : ce schéma général ne permet pas d’en diagnostiquer la cause.
La conclusion doit rester précise : les données indiquées ont produit une correspondance selon la méthode de comparaison documentée. Pour déterminer si cela établit aussi l’identité exacte des fichiers sources, il faut examiner le traitement des métadonnées.
Correspondance complète et correspondance partielle
Certaines différences dans les sources, notamment des commentaires ou des noms de variables, peuvent laisser le bytecode compilé inchangé. Des fichiers différents peuvent donc correspondre au même bytecode lorsque leurs différences n’affectent pas la comparaison. Un commentaire lisible reste une explication à examiner ; une simple correspondance du bytecode ne prouve pas sa présence dans les sources d’origine.
La documentation décrit un contrôle d’identité plus précis utilisant l’empreinte des métadonnées ajoutée au bytecode. Si le bytecode et cette empreinte correspondent aux sources et aux paramètres fournis, la méthode de vérification complète décrite établit l’identité exacte des sources, à l’octet près.
Cette conclusion suppose que les deux comparaisons aboutissent effectivement. Lorsque les empreintes des métadonnées diffèrent ou ne sont pas prises en compte, la documentation parle de correspondance partielle. Conservez cette distinction dans votre lecture. Si le résultat ne précise pas le traitement des métadonnées, la portée de la preuve d’identité reste indéterminée.
Même une identité exacte demeure un résultat sur l’identité du code. Elle ne démontre pas que son comportement est correct ou sûr.
Pourquoi « vérifié » ne suffit pas à établir un audit ou la sécurité
Un audit constitue une forme de revue indépendante du code. La vérification formelle étudie, quant à elle, la conformité à des propriétés spécifiées au moyen d’un modèle et d’une spécification formels. Ces démarches répondent à des questions supplémentaires par rapport à la reproduction du bytecode. Les conclusions formelles restent délimitées par les propriétés, la spécification et le modèle retenus.
Un audit a également ses limites. Le guide Ethereum sur la sécurité des smart contracts rappelle que les audits ne détectent pas tous les défauts. Un document attestant une revue doit donc conserver son périmètre et ses réserves.
La déduction est la suivante : puisque la vérification des sources établit une correspondance, tandis que l’audit et les méthodes formelles examinent d’autres questions, son résultat seul n’établit ni la réalisation d’un audit, ni la correction du programme, ni sa sécurité. Cela ne signifie pas qu’un contrat vérifié est nécessairement dangereux, incorrect ou dépourvu d’audit. Ces appréciations demandent leurs propres preuves.
Le mot « vérification » apparaît aussi dans un autre contexte : la validation d’une transaction Ethereum. Ce sujet est distinct de la correspondance entre sources et bytecode examinée ici.
Un exemple hypothétique : deux fiches de vérification
Imaginons un exercice pédagogique comportant deux fiches fictives pour une même adresse de contrat inventée. La fiche A identifie les sources, les paramètres du compilateur et une correspondance du bytecode, mais indique que les métadonnées ont été exclues. La fiche B identifie ses sources et ses paramètres, puis signale une correspondance du bytecode et de l’empreinte des métadonnées ajoutée à celui-ci.
Dans la terminologie de la documentation, A décrit une correspondance partielle. B décrit une correspondance complète selon la méthode annoncée. La différence porte sur la précision de la preuve d’identité des sources : B inclut la comparaison des métadonnées nécessaire à la conclusion d’identité exacte.
Supposons maintenant qu’aucune fiche ne fournisse de preuve de revue indépendante. On en déduit seulement que ces documents n’établissent pas l’existence d’un audit. Affirmer qu’aucun audit n’a jamais eu lieu serait tout aussi injustifié. L’exercice montre comment conserver une incertitude sans la transformer en assurance ou en accusation.
Une liste de contrôle en lecture seule
La liste suivante découle des exigences de comparaison et du rôle distinct de l’analyse de sécurité. Elle sert à organiser des documents existants, sans effectuer de transaction ni signer de demande dans un portefeuille.
- Identifier la cible. Relever l’adresse du contrat à laquelle s’applique le résultat.
- Identifier les données de compilation. Noter les fichiers sources, la version du compilateur et les paramètres de l’optimiseur documentés.
- Lire le résultat. Distinguer une correspondance explicitement annoncée d’un simple affichage des sources.
- Conserver le type de correspondance. Relever si les empreintes des métadonnées correspondent, diffèrent ou ont été exclues. Laisser toute catégorie inexpliquée en suspens.
- Examiner séparément la sécurité. Consigner les preuves de revue indépendante ou d’analyse formelle, avec leur périmètre et leurs limites.
- Formuler une conclusion mesurée. Décrire ce qui correspond et ce qui reste non établi. Cette liste ne certifie pas la sécurité du contrat.
Lorsque des informations manquent, la conclusion correspondante reste ouverte. L’utilité de cette lecture consiste à rendre cette frontière visible, sans laisser une étiquette remplacer les éléments nécessaires.
Article pédagogique préparé avec l’aide de l’IA à partir de la documentation primaire fournie. L’exemple fictif illustre la lecture des preuves.