Résumé Technique : Audits de Smart Contracts Découplés via des LLM Légers

Énoncé du Problème

Les smart contracts, étant immuables une fois déployés sur les blockchains, sont hautement susceptibles de vulnérabilités de sécurité pouvant mener à des pertes financières catastrophiques (par exemple, le hack de la DAO). Bien que les grands modèles de langage (LLM) aient montré un potentiel prometteur pour l'audit de sécurité automatisé, les approches existantes font face à trois limitations critiques :

1. Inefficacité Computationnelle : Les solutions actuelles de pointe (SOTA) reposent sur des LLM monolithiques massifs (7B–34B de paramètres) qui nécessitent un VRAM GPU substantiel (dépassant souvent 12–24 Go), les rendant inaccessibles pour les développeurs indépendants et les petites équipes utilisant du matériel grand public standard.
2. Manque de Résultats Actionnables : De nombreuses approches se concentrent principalement sur la détection binaire de vulnérabilités, négligeant le besoin critique de classification de la sévérité et de recommandations de remédiation spécifiques et actionnables.
3. Failles Architecturales : Les stratégies de prompting unifiées forcent un modèle unique à effectuer simultanément diverses tâches de raisonnement (détection, explication, sévérité, recommandation), ceant une propagation d'erreurs, des hallucinations de format et une latence élevée.

Méthodologie

Les auteurs proposent un cadre end-to-end découplé et efficace qui utilise des LLM open-source légers (0,6B–4B de paramètres) pour répliquer le flux de travail des experts en sécurité humains. Le cadre divise le processus d'audit en quatre modules spécialisés et séquentiels :

1. Détecteur de Vulnérabilité : Une tâche de classification pour identifier si le code contient des vulnérabilités.
2. Explicateur de Vulnérabilité : Une tâche générative pour expliquer la nature de la vulnérabilité et la manière dont elle peut être exploitée.
3. Déterminant de Sévérité : Une tâche de classification pour assigner un niveau de sévérité (Faible, Moyen, Élevé).
4. Recommandeur : Une tâche générative pour fournir des correctifs de code actionnables pour la remédiation.

Composants Techniques Clés

• Adaptateurs de Bas Rang Stabilisés par Rang (rsLoRA) : Au lieu d'un fine-tuning complet ou d'un LoRA standard, les auteurs emploient le rsLoRA. Cette technique modifie le facteur d'échelle en $\gamma_r = \alpha / \sqrt{r}$, empêchant l'effondrement du gradient et permettant des rangs plus élevés sans sacrifier l'efficacité des paramètres.
• Mécanisme de Vote Multi-Prompt : Pour les tâches de classification (Détection et Sévérité), le modèle traite cinq templates de prompts distincts. Le résultat final est déterminé par un vote à la majorité, avec un score de confiance calculé sur la base du consensus.
• Agrégation de Chaîne de Vérification (CoVe) Modifiée : Pour les tâches génératives (Explication et Recommandation), le cadre utilise un "Générateur de Candidats" pour produire plusieurs réponses préliminaires indépendantes. Un "Agrégateur" personnalisé utilise ensuite une stratégie CoVe modifiée pour :
  1. Ancrer le contexte dans le code.
  2. Générer des questions de vérification pour chaque candidat.
  3. Répondre indépendamment à ces questions pour vérifier les affirmations.
  4. Synthétiser un rapport unique et vérifié, en écartant les hallucinations.
• Distillation de Connaissances : Pour améliorer les capacités de raisonnement des modèles étudiants (Qwen3-4B), les auteurs distillent le raisonnement de type "Chain-of-Thought" (CoT) d'un modèle enseignant puissant (Qwen3-30B-A3B). Les sorties CoT de l'enseignant sont utilisées comme données d'entraînement pour enseigner au modèle étudiant le raisonnement étape par étape.

Construction du Dataset

L'étude a utilisé deux datasets distincts dérivés de sources réputées (Code4rena, Shieldify Security, et des projets à haut TVL) :

• Dataset de Détection : 930 échantillons de code vulnérables et 969 échantillons bénins. Les échantillons bénins ont été traités à l'aide d'un algorithme d'échantillonnage stratifié basé sur les graphes pour assurer une parité de longueur avec les extraits vulnérables, évitant ainsi que le modèle n'apprenne des biais de longueur superficiels.
• Dataset de Vulnérabilité : Plus de 1 000 échantillons contenant du code couplé à des métadonnées d'audit (explications, sévérité, recommandations). Ce dataset a été divisé en utilisant une stratégie de stratification sensible aux projets (Project-Aware) pour éviter la fuite de données entre les ensembles d'entraînement et de test.

Résultats Expérimentaux

Le cadre a été évalué par rapport aux modèles de code d'état de l'art (SOTA) denses (ex: CodeLlama-34B, DeepSeek-Coder-33B, Qwen2.5-Coder-32B) sous des configurations Zero-Shot et Fine-Tuned.

• Détection de Vulnérabilité : Le modèle 0,6B proposé a atteint une précision de 98,25 % et un score F1 de 0,9824, surpassant tous les modèles de référence, y compris les modèles 34B fine-tunés.
• Classification de la Sévérité : Le cadre a atteint une précision de 64,58 % et un score F1 macro de 0,5877.
• Tâches Génératives (Explication & Recommandation) : En utilisant une métrique de type "LLM-as-a-Judge" (LMUnit 70B), le cadre a obtenu des scores d'alignement de 0,4375 pour les explications et 0,7639 pour les recommandations, surpassant nettement les meilleurs modèles de référence (qui marquaient respectivement ~0,22 et ~0,37).
• Efficacité des Ressources : L'approche découplée opère avec environ 3,11 Go de VRAM pour la classification et 8,64 Go de VRAM pour la génération, s'adaptant confortablement au matériel grand public (8–12 Go de VRAM), alors que les références SOTA nécessitent 21–24 Go.

Contributions Clés et Constats

1. Architecture Découplée : L'article démontre que la séparation des flux de travail d'audit complexes en modules spécialisés surpasse significativement le prompting monolithique unifié, réduisant la propagation d'erreurs et les hallucinations.
2. Supériorité des Modèles Légers : L'étude valide empiriquement que des modèles légers hautement optimisés (0,6B–4B) avec un fine-tuning ciblé et des stratégies d'agrégation peuvent systématiquement surpasser des modèles denses beaucoup plus grands (7B–34B) dans des tâches de sécurité spécifiques.
3. Biais de Centralité de Sévérité (SCB) : Une découverte empirique inédite révèle que les LLM actuels (tant en zero-shot qu'en fine-tuned) présentent un "Biais de Centralité de Sévérité", où ils tendent de manière disproportionnée vers une sévérité "Moyenne" pour minimiser la perte, échouant à distinguer précisément les cas limites "Faibles" et "Élevés". Le cadre proposé atténue ce biais mais ne l'élimine pas totalement.
4. Optimisation Synergique : Les études d'ablation confirment que la combinaison de rsLoRA, de la distillation de connaissances et de l'agrégation CoVe modifiée crée un effet synergique, où la suppression de n'importe quel composant entraîne une dégradation significative des performances.

Signification

L'article prétend établir un benchmark critique pour les recherches futures en audit assisté par LLM en prouvant que la démocratisation de la sécurité des smart contracts est réalisable sur du matériel grand public standard. En s'éloignant des modèles monolithiques gourmands en ressources vers un pipeline modulaire et léger, les auteurs offrent une voie pratique pour intégrer l'audit de sécurité continu ("shift-left") dans les flux de travail de développement quotidiens sans nécessiter d'instances GPU cloud coûteuses. L'identification du Biais de Centralité de Sévérité souligne également un défi spécifique, non encore traité, dans l'évaluation automatisée des risques que les recherches futures devront affronter.