← Derniers articles
💻 computer science

Malicious Code Detection in Smart Contracts via Opcode Vectorization

Cet article propose une approche basée sur l'apprentissage automatique pour la détection de code malveillant dans les contrats intelligents en classifiant et en simplifiant les opcodes, puis en comparant l'efficacité des méthodes de vectorisation N-Gram et TF-IDF sur les opcodes bruts et traités afin d'optimiser l'extraction de caractéristiques pour l'entraînement du classificateur.

Auteurs originaux : Huanhuan Zou, Zongwei Li, Xiaoqi Li

Publié 2026-02-03
📖 5 min de lecture🧠 Analyse approfondie

Auteurs originaux : Huanhuan Zou, Zongwei Li, Xiaoqi Li

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez la blockchain comme un immense registre numérique public où les gens écrivent des « contrats intelligents » (smart contracts). Considérez ces contrats non pas comme des documents juridiques, mais comme des distributeurs automatiques autonomes. Vous insérez de l'argent, la machine vérifie les règles et, si tout est correct, elle vous donne un snack. Si le code à l'intérieur de la machine est cassé ou contient un piège caché (code malveillant), vous pourriez perdre votre argent, ou la machine pourrait s'arrêter complètement.

Ce document est comme une équipe de gardiens de sécurité essayant de comprendre comment repérer un distributeur automatique cassé ou truqué avant que quelqu'un ne soit blessé. Voici comment ils ont procédé, expliqué simplement :

1. Le Problème : Trop de Langages

Les contrats intelligents sont écrits en code, mais la blockchain ne lit pas la version en « anglais » (le code source) que les humains écrivent. Elle ne comprend qu'un langage très spécifique et robotique appelé Opcodes.

  • L'analogie : Imaginez que le contrat est une recette. Les humains lisent la recette en anglais (« Ajoutez deux tasses de farine »). La blockchain, cependant, ne comprend qu'une liste de commandes chimiques (« Mélanger l'ingrédient A avec l'ingrédient B »).
  • Le problème : Il existe des centaines de ces commandes chimiques. Si vous les listez simplement de manière aléatoire, il est difficile pour un ordinateur de faire la différence entre une recette sûre et une recette empoisonnée.

2. La Solution : Grouper et Compter

Les auteurs ont décidé d'apprendre à un ordinateur comment lire ces commandes robotiques en les transformant en une simple liste de nombres (vecteurs). Ils ont procédé en trois étapes :

  • Étape A : Grouper les commandes (Simplification)
    Au lieu de traiter chaque commande comme unique, ils ont regroupé les commandes similaires.

    • Analogie : Imaginez que vous avez 32 types différents de boutons « Pousser » (Pousser1, Pousser2... Pousser32). Au lieu de mémoriser 32 boutons différents, les auteurs ont décidé de les appeler tous simplement « Pousser ». Ils ont fait de même pour d'autres groupes comme « Sauter » ou « Mathématiques ». Cela a réduit le bruit et rendu la liste plus courte et plus facile à étudier.
  • Étape B : Regarder les paires (N-Gramme)
    Ils ne se sont pas contentés de regarder des commandes isolées ; ils ont regardé des paires de commandes qui se suivent.

    • Analogie : Si vous voyez le mot « Sel » dans une recette, c'est courant. Mais si vous voyez « Sel » suivi immédiatement de « Poison », c'est un signal d'alarme. Ils ont observé ces paires (comme « Pousser » puis « Sauter ») pour comprendre le flux du contrat.
  • Étape C : Peser l'importance (TF-IDF)
    Ils ont utilisé une astuce mathématique pour déterminer quelles paires étaient réellement importantes.

    • Analogie : Si presque toutes les recettes sûres utilisent la paire « Mélanger puis Verser », cette paire n'est pas très spéciale. Mais si une paire de commandes spécifique n'apparaît que dans les recettes « empoisonnées », cette paire est un indice majeur. Ils ont attribué des scores élevés aux paires rares et suspectes, et des scores faibles aux plus communes.

3. L'Expérience : Entraîner les détectives

Une fois qu'ils ont transformé les contrats en ces listes numérotées, ils les ont injectées dans cinq différents « ordinateurs détectives » (modèles de Machine Learning comme les Arbres de Décision et les Forêts Aléatoires) pour voir s'ils pouvaient repérer les mauvais contrats.

  • Le résultat : Ils ont testé deux méthodes.
    1. Méthode 1 : Regarder simplement la liste brute des commandes.
    2. Méthode 2 : Regarder les paires simplifiées et leurs scores d'importance (la méthode décrite ci-dessus).
  • Le dénouement : La deuxième méthode (regarder les paires) a fonctionné légèrement mieux pour un détective spécifique (l'Arbre de Décision), mais globalement, les résultats ont été mitigés.

4. Le Grand Obstacle : Pas assez d'exemples malveillants

Le plus gros problème auquel les auteurs ont été confrontés n'était pas les mathématiques, mais les données.

  • L'analogie : Imaginez que vous essayez d'apprendre à un chien à reconnaître un loup. Vous montrez au chien 500 photos de moutons, mais vous n'avez que 80 photos de loups.
  • La réalité : Dans le monde réel, la plupart des contrats intelligents sont sûrs. Les contrats malveillants sont rares. Comme ils ne possédaient qu'un nombre infime de « mauvais » contrats à étudier, les modèles informatiques ont été confus. Ils ne pouvaient pas apprendre le schéma d'un « loup » car ils n'avaient pas assez de photos de loups pour comparer avec les moutons.

5. Le Futur : Construire une plus grande bibliothèque

Les auteurs concluent que bien que leur méthode de traduction du code robotique en nombres soit une bonne idée, ils ont besoin de plus de données pour prouver qu'elle fonctionne parfaitement.

  • Ce qu'ils prévoient de faire ensuite : Ils veulent construire un robot (un crawler web) pour collecter automatiquement des milliers de contrats sur Internet afin de créer une bibliothèque beaucoup plus vaste. Ils veulent également essayer d'enseigner à l'ordinateur en utilisant des contrats « non étiquetés » (où l'ordinateur doit deviner de lui-même lesquels sont mauvais), car trouver autant de contrats connus comme étant « mauvais » est extrêmement difficile.

En résumé :
Le papier propose une manière ingénieuse de traduire le langage robotique des contrats intelligents dans un format que les ordinateurs peuvent facilement comparer. Ils ont découvert que l'observation des paires de commandes aide, mais ils se sont heurtés à un mur car il y a simplement trop peu d'exemples de « mauvais » contrats dans le monde pour entraîner leur système efficacement. Ils ont besoin de plus de données avant que leur garde de sécurité ne puisse être pleinement digne de confiance.

Noyé(e) sous les articles dans votre domaine ?

Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.

Essayer Digest →