L'IA peut-elle survivre dans le monde du chiffrement : 18 expériences de grands modèles
TechFlow SélectionTechFlow Sélection
L'IA peut-elle survivre dans le monde du chiffrement : 18 expériences de grands modèles
La création de benchmarks pourrait devenir un pont clé reliant les deux domaines de l'IA et de la cryptographie, catalysant l'innovation et offrant une orientation claire pour les futures applications.
Dédié à des analyses Web3 approfondiesRédaction : Wang Chao
Dans l’histoire des progrès technologiques, les technologies révolutionnaires apparaissent souvent indépendamment, chacune inaugurant une ère de transformation. Lorsque deux technologies révolutionnaires se rencontrent, leur convergence produit souvent un impact exponentiel. Aujourd’hui, nous sommes précisément à un moment historique où l’intelligence artificielle et la technologie cryptographique — deux innovations tout aussi disruptives — s’apprêtent à prendre ensemble le devant de la scène.
Nous imaginons que de nombreux défis du domaine de l’IA pourraient être résolus par la technologie cryptographique ; nous espérons que les agents d’IA construiront des réseaux économiques autonomes, accélérant ainsi l’adoption massive des crypto-actifs ; nous souhaitons également que l’IA accélère le développement des cas d’usage existants dans l’écosystème crypto. Des regards innombrables sont tournés vers ce point de convergence, des fonds massifs y affluent frénétiquement. Comme tout autre mot-clé à la mode, ce phénomène concentre l’appétit humain pour l’innovation, les aspirations envers l’avenir, mais aussi des ambitions et des convoitises difficiles à contenir.
Pourtant, au milieu de ce tumulte, nous connaissons très peu les questions les plus fondamentales : à quel point l’IA comprend-elle vraiment le domaine crypto ? Les agents dotés de grands modèles linguistiques (LLMs) ont-ils réellement la capacité d’utiliser des outils cryptographiques ? Quelles différences existent entre différents modèles lorsqu’ils accomplissent des tâches liées aux crypto-actifs ?
Les réponses à ces questions détermineront l’ampleur de l’interaction entre l’IA et la technologie crypto, et seront cruciales pour orienter les choix de produits et de voies technologiques dans ce domaine transversal. Pour explorer ces interrogations, j’ai mené une série d’expérimentations d’évaluation sur des grands modèles linguistiques. En évaluant leurs connaissances et compétences dans le domaine crypto, j’ai cherché à mesurer le niveau d’application de l’IA aux crypto-actifs, et à évaluer le potentiel et les défis de leur convergence.
Résumé des conclusions
Les grands modèles linguistiques excellent dans les bases de la cryptographie et de la blockchain, et possèdent une bonne compréhension de l’écosystème crypto, mais obtiennent de très mauvais résultats en calcul mathématique et en analyse de logiques métier complexes. En matière de clés privées et d’opérations basiques de portefeuille, les modèles disposent d’une base satisfaisante, mais font face à un défi majeur : la sauvegarde sécurisée des clés privées dans le cloud. De nombreux modèles peuvent générer du code de contrats intelligents fonctionnel dans des scénarios simples, mais sont incapables d’effectuer seuls des audits ou de créer des contrats complexes.
Les modèles commerciaux fermés dominent globalement, avec seulement Llama 3.1-405B qui se distingue parmi les modèles open source, tandis que tous les modèles open source à faible nombre de paramètres échouent largement. Cependant, il existe un fort potentiel : grâce à des techniques comme l’ingénierie des prompts, le raisonnement en chaîne de pensée (chain-of-thought) et l’apprentissage à partir de quelques exemples (few-shot learning), les performances de tous les modèles sont considérablement améliorées. Les meilleurs modèles atteignent déjà une faisabilité technique solide dans certains cas d’usage verticaux.
Détails de l’expérimentation
J’ai sélectionné 18 modèles linguistiques représentatifs pour cette évaluation, notamment :
-
Modèles fermés : GPT-4o, GPT-4o Mini, Claude 3.5 Sonnet, Gemini 1.5 Pro, Grok2 beta (fermé temporairement)
-
Modèles open source : Llama 3.1 8B/70B/405B, Mistral Nemo 12B, DeepSeek-coder-v2, Nous-hermes2, Phi3 3.8B/14B, Gemma2 9B/27B, Command-R
-
Modèles optimisés pour les mathématiques : Qwen2-math-72B, MathΣtral
Ces modèles couvrent les principaux modèles commerciaux et open source populaires, avec un écart de taille allant de 3,8 milliards à 405 milliards de paramètres — soit plus d’un facteur 100. Étant donné le lien étroit entre la technologie crypto et les mathématiques, deux modèles spécialement optimisés pour les maths ont également été inclus.
Les domaines de connaissance testés comprennent la cryptographie, les bases de la blockchain, la gestion des clés privées et des portefeuilles, les contrats intelligents, les DAO et la gouvernance, les mécanismes de consensus et les modèles économiques, les DApp / DeFi / NFT, ainsi que l’analyse des données on-chain. Chaque domaine est composé d’une série de questions et de tâches allant du facile au difficile, permettant non seulement d’évaluer les connaissances des modèles, mais aussi leurs performances dans des scénarios applicatifs simulés.
La conception des tâches est diversifiée : certaines proviennent de contributions d’experts en crypto, d’autres ont été générées avec l’aide de l’IA puis validées manuellement, afin d’assurer précision et niveau de difficulté. Certaines tâches utilisent des QCM simples, facilitant des tests automatisés standardisés et notés. D’autres emploient des formats plus complexes, avec une évaluation combinant automatisation, intervention humaine et IA. Toutes les tâches ont été évaluées selon une méthode de raisonnement zéro exemple (zero-shot), sans fournir aucun exemple, aucune piste de réflexion ni instruction spécifique.
L’expérience elle-même reste encore grossière, manquant de rigueur académique suffisante. Les questions et tâches utilisées ne couvrent qu’une infime partie du domaine crypto, et le cadre d’évaluation n’est pas mature. C’est pourquoi cet article ne présente pas de données expérimentales détaillées, mais met plutôt l’accent sur les observations et enseignements tirés.
Connaissances / Concepts
Au cours de l’évaluation, les grands modèles linguistiques ont excellé aux tests fondamentaux portant sur les algorithmes cryptographiques, les bases de la blockchain et les applications DeFi. Par exemple, dans une question ouverte sur la compréhension du concept de disponibilité des données, tous les modèles ont fourni une réponse correcte. Dans une autre tâche évaluant la maîtrise de la structure des transactions Ethereum, bien que les détails varient légèrement, toutes les réponses contenaient globalement les informations clés justes. Quant aux QCM portant sur des concepts, ils ne posaient aucun problème : presque tous les modèles affichent un taux de réussite supérieur à 95 %.
Les questions conceptuelles ne constituent absolument pas un obstacle pour les grands modèles.
Calcul / Logique métier
Cependant, dès qu’il s’agit de calculs concrets, la situation s’inverse radicalement. Une simple question de calcul sur l’algorithme RSA a mis la majorité des modèles en difficulté. Ce n’est guère surprenant : les grands modèles linguistiques fonctionnent principalement en identifiant et reproduisant des motifs présents dans leurs données d’entraînement, plutôt qu’en comprenant profondément la nature des concepts mathématiques. Cette limite est particulièrement visible face à des notions abstraites telles que l’arithmétique modulaire ou les puissances. Étant donné le lien étroit entre crypto et mathématiques, cela signifie que compter directement sur les modèles pour effectuer des calculs mathématiques liés à la crypto est peu fiable.
Leurs performances restent également décevantes dans d’autres tâches de calcul. Par exemple, une question simple sur le calcul de la perte impermanente (impermanent loss) dans un AMM, bien qu’elle ne requière pas de mathématiques avancées, n’a été correctement résolue que par 4 des 18 modèles. Une autre tâche encore plus basique — calculer la probabilité de production d’un bloc — a été ratée par tous les modèles. Oui, tous. Aucun n’a trouvé la réponse juste. Cela révèle non seulement les lacunes des LLMs en matière de calcul précis, mais aussi leurs difficultés importantes en analyse logique métier. À noter que même les modèles spécialisés en mathématiques n’ont montré aucun avantage significatif ici, offrant des performances décevantes.
Cependant, le problème des calculs mathématiques n’est pas insoluble. Si l’on demande aux LLMs de produire du code Python au lieu du résultat direct, le taux de réussite augmente fortement. Dans le cas de la question RSA mentionnée plus haut, la plupart des modèles ont généré du code Python exécutable et correct. Dans un environnement de production, on peut contourner la phase de calcul autonome du LLM en fournissant des algorithmes pré-définis, une approche similaire à celle adoptée par les humains face à de telles tâches. Au niveau de la logique métier, des performances bien meilleures peuvent être obtenues grâce à des prompts soigneusement conçus.
Gestion des clés privées et opérations de portefeuille
Si l’on me demandait quel serait le premier scénario d’utilisation des crypto-monnaies par un agent IA, je répondrais : le paiement. Les crypto-monnaies peuvent presque être considérées comme la monnaie native de l’IA. Contrairement aux obstacles nombreux rencontrés par les agents dans le système financier traditionnel, l’utilisation de la technologie crypto pour doter l’agent d’une identité numérique et gérer ses fonds via un portefeuille cryptographique constitue un choix naturel. Ainsi, la génération et la gestion des clés privées, ainsi que les différentes opérations de portefeuille, constituent les compétences de base minimales pour qu’un agent puisse utiliser de manière autonome le réseau crypto.
La génération sécurisée d’une clé privée repose sur la production de nombres aléatoires de haute qualité — une capacité que les grands modèles linguistiques ne possèdent clairement pas. Toutefois, leur compréhension de la sécurité des clés privées est satisfaisante : lorsqu’on leur demande de générer une clé privée, la majorité choisissent d’utiliser du code (par exemple via des bibliothèques Python) pour guider l’utilisateur à la générer lui-même. Même lorsque certains modèles donnent directement une clé privée, ils précisent clairement qu’il s’agit uniquement à des fins de démonstration, et non d’une clé sécurisée utilisable en pratique. Sur ce point, tous les grands modèles ont fait preuve d’un comportement satisfaisant.
La gestion des clés privées pose néanmoins des défis, principalement dus à des limitations architecturales techniques, et non à des insuffisances du modèle. Lorsqu’un modèle est déployé localement, la clé privée générée peut être considérée comme relativement sûre. Mais si l’on utilise un modèle commercial hébergé dans le cloud, on doit supposer que la clé privée est exposée à l’opérateur du modèle dès sa création. Or, pour un agent destiné à travailler de façon autonome, avoir accès à la clé privée est indispensable — ce qui signifie que la clé ne peut pas rester uniquement côté utilisateur. Dans ce cas, compter uniquement sur le modèle ne suffit plus à garantir la sécurité de la clé : il faut intégrer des environnements d’exécution fiables (TEE) ou des modules matériels de sécurité (HSM), ou d’autres services de sécurité supplémentaires.
En supposant que l’agent détienne déjà une clé privée de manière sécurisée, tous les modèles testés ont montré de bonnes capacités pour effectuer diverses opérations de base. Bien que les étapes ou le code produits contiennent souvent des erreurs, celles-ci peuvent être largement corrigées dans une architecture logicielle adaptée. Sur le plan technique, on peut dire qu’il n’y a plus beaucoup d’obstacles à ce que les agents effectuent de manière autonome des opérations de base sur les portefeuilles.
Contrats intelligents
La capacité à comprendre, utiliser, écrire et identifier les risques dans les contrats intelligents est essentielle pour qu’un agent IA puisse exécuter des tâches complexes dans le monde on-chain. C’est donc l’un des axes centraux de notre expérimentation. Les grands modèles montrent ici un potentiel marqué, mais révèlent aussi des limites flagrantes.
Dans les tests, pratiquement tous les modèles répondent correctement aux questions fondamentales sur les contrats, et identifient des bogues simples. En matière d’optimisation du gas, la majorité parvient à repérer les points critiques et à analyser les conflits potentiels. Toutefois, face à des logiques métiers profondes, les limites des grands modèles deviennent apparentes.
Par exemple, avec un contrat de vesting de token : tous les modèles comprennent correctement la fonctionnalité, et la plupart identifient plusieurs vulnérabilités de faible ou moyenne gravité. Mais aucune ne détecte spontanément une faille critique cachée dans la logique métier, pouvant entraîner, dans des cas particuliers, le blocage irréversible d’une partie des fonds. Dans plusieurs tests utilisant des contrats réels, les performances des modèles sont similaires.
Cela indique que la compréhension des contrats par les grands modèles reste superficielle, formelle, et manque de profondeur dans l’analyse logique métier. Toutefois, après indication complémentaire via prompt, certains modèles finissent par découvrir indépendamment la faille cachée. Sur cette base, on peut juger que, soutenus par une bonne ingénierie logicielle, les grands modèles sont déjà capables d’agir comme un « copilote » dans le domaine des contrats intelligents. Mais ils sont encore loin d’être prêts à assumer seuls des missions critiques comme l’audit complet d’un contrat.
Un point important : les tâches liées au code dans cette expérience concernaient principalement des contrats simples, avec moins de 2 000 lignes de code. Pour des projets plus vastes et complexes, sans fine-tuning ou ingénierie avancée de prompts, je pense que cela dépasse clairement les capacités actuelles des modèles, et ces cas n’ont donc pas été testés. Par ailleurs, cette évaluation ne porte que sur Solidity, et n’inclut pas d’autres langages comme Rust ou Move.
Outre ces tests, l’expérimentation couvre également des scénarios DeFi, les DAO et leur gouvernance, l’analyse des données on-chain, la conception des mécanismes de consensus et la tokenomie. Les grands modèles montrent dans ces domaines des compétences variées. Étant donné que de nombreux tests sont toujours en cours, et que les méthodes et cadres d’évaluation continuent d’évoluer, cet article n’aborde pas en détail ces sujets pour l’instant.
Différences entre modèles
Parmi tous les grands modèles évalués, GPT-4o et Claude 3.5 Sonnet confirment leur excellence dans d’autres domaines et s’imposent comme des leaders incontestés. Face aux questions de base, ces deux modèles donnent presque toujours des réponses exactes ; dans les analyses de scénarios complexes, ils offrent des analyses approfondies et bien argumentées. Même dans les tâches de calcul — domaine où les grands modèles sont généralement faibles — ils affichent un taux de réussite élevé, bien que ce terme doive être pris avec réserve : ils n’atteignent toujours pas un niveau de stabilité suffisant pour un usage en production.
Dans le camp des modèles open source, Llama 3.1-405B prend une avance nette grâce à sa taille imposante et à ses algorithmes avancés. Parmi les autres modèles open source à plus petit nombre de paramètres, aucune différence notable de performance ne se dégage. Malgré quelques variations mineures, tous sont très loin d’atteindre la moyenne.
Par conséquent, si l’on souhaite aujourd’hui développer des applications IA liées aux crypto-actifs, ces modèles à petit ou moyen nombre de paramètres ne sont pas des choix pertinents.
Deux modèles ont particulièrement attiré l’attention dans notre évaluation. Le premier est le modèle Phi-3 3.8B de Microsoft, le plus petit de l’expérience. Pourtant, avec moins de la moitié des paramètres, il atteint des performances comparables à celles des modèles 8B-12B, voire meilleures dans certaines catégories spécifiques. Ce résultat souligne l’importance de l’optimisation de l’architecture du modèle et des stratégies d’entraînement, au-delà de la simple augmentation du nombre de paramètres.
Le deuxième est le modèle Command-R de Cohere, une véritable « surprise » — négative. Moins connu que les autres, Cohere est pourtant une entreprise spécialisée dans les modèles B2B, dont on pouvait penser qu’elle avait des points communs avec le développement d’agents IA, ce qui justifiait son inclusion. Pourtant, ce modèle de 35 milliards de paramètres arrive en dernière position dans la plupart des tests, battu même par de nombreux modèles inférieurs à 10 milliards de paramètres.
Ce résultat interroge : Command-R a été lancé en mettant l’accent sur sa capacité de génération assistée par recherche (RAG), sans même publier de scores classiques de référence. Serait-il une « clé spécialisée », ne débloquant tout son potentiel que dans des scénarios très spécifiques ?
Limites de l’expérimentation
Cette série de tests nous a permis d’obtenir une première vision des capacités de l’IA dans le domaine crypto. Bien sûr, ces tests sont encore loin d’un niveau professionnel. La couverture de l’ensemble de données est insuffisante, les critères de quantification des réponses sont grossiers, et il manque un système de notation précis et raffiné, ce qui affecte la précision des résultats et pourrait conduire à sous-estimer certaines performances.
Méthodologiquement, l’expérimentation s’est limitée à une seule approche : l’apprentissage zéro exemple (zero-shot), sans explorer d’autres méthodes comme la chaîne de pensée (chain-of-thought) ou l’apprentissage à partir de quelques exemples (few-shot), qui pourraient mieux exploiter le potentiel des modèles. De plus, les paramètres des modèles ont été utilisés dans leur configuration standard, sans tester l’impact de réglages différents. Ces méthodes trop uniformes limitent notre évaluation globale du potentiel des modèles, et empêchent d’explorer pleinement leurs différences de performance dans des conditions spécifiques.
Bien que les conditions de test soient relativement rudimentaires, cette expérimentation a produit plusieurs enseignements précieux, utiles pour les développeurs concevant des applications.
Le domaine crypto a besoin de son propre benchmark
Dans le domaine de l’IA, les benchmarks jouent un rôle central. Le développement rapide du deep learning moderne remonte à ImageNet, réalisé par la professeure Fei-Fei Li en 2012 — un jeu de données et un benchmark standardisé dans le domaine de la vision par ordinateur.
En fournissant une norme d’évaluation commune, les benchmarks offrent non seulement aux développeurs des objectifs clairs et des points de référence, mais stimulent aussi le progrès technologique global. C’est pourquoi chaque nouveau grand modèle linguistique publié met en avant ses performances sur divers benchmarks. Ces résultats deviennent un « langage universel » des capacités du modèle, permettant aux chercheurs d’identifier des axes d’amélioration, aux développeurs de choisir le modèle le mieux adapté à une tâche, et aux utilisateurs de faire des choix éclairés basés sur des données objectives. Plus encore, les benchmarks anticipent souvent les futures directions des applications d’IA, orientant les investissements et les priorités de recherche.
Si nous croyons au potentiel énorme de la convergence entre l’IA et la technologie crypto, alors créer un benchmark dédié au domaine crypto devient une nécessité urgente. Un tel benchmark pourrait devenir un pont clé entre ces deux mondes, catalysant l’innovation et offrant une feuille de route claire pour les futures applications.
Toutefois, par rapport aux benchmarks matures d’autres domaines, construire un benchmark crypto présente des défis uniques : la technologie évolue rapidement, le corpus de connaissances n’est pas stabilisé, et il manque encore des consensus sur plusieurs axes fondamentaux. En tant que domaine transdisciplinaire, la crypto englobe la cryptographie, les systèmes distribués, l’économie, etc., avec une complexité bien supérieure à celle d’un domaine unique. Plus difficile encore : un benchmark crypto doit non seulement évaluer les connaissances, mais aussi la capacité réelle de l’IA à manipuler la technologie crypto — ce qui impose de concevoir une nouvelle architecture d’évaluation. La rareté des jeux de données pertinents ajoute encore à la difficulté.
La complexité et l’importance de cette tâche rendent impossible sa réalisation par une seule personne ou équipe. Elle exige la collaboration multiple : utilisateurs, développeurs, experts en cryptographie, chercheurs crypto, et d’autres spécialistes interdisciplinaires. Elle repose sur une large participation communautaire et un consensus collectif. C’est pourquoi ce benchmark doit faire l’objet d’un débat plus large : car il ne s’agit pas seulement d’un travail technique, mais d’une réflexion profonde sur la manière dont nous comprenons cette technologie émergente.
Post-scriptum : Ce sujet est loin d’être clos. Dans mes prochains articles, j’approfondirai les idées concrètes et les défis liés à la construction d’un benchmark IA pour le domaine crypto. L’expérimentation continue : nous affinons constamment les modèles testés, enrichissons les jeux de données, améliorons le cadre d’évaluation et optimisons l’ingénierie des tests automatisés. Dans un esprit d’ouverture et de collaboration, toutes les ressources associées — jeux de données, résultats, cadre d’évaluation, code de tests automatisés — seront publiées en open source comme biens communs.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
