Hoskinson Alerte Sur Code Dangereux Et Eip-7702

Imaginez un instant qu’un portefeuille d’échange, réputé ultra-sécurisé, se vide en un éclair sans déclencher d’alarme immédiate. C’est précisément ce scénario qu’a mis en lumière récemment Charles Hoskinson, le fondateur de Cardano, en partageant une analyse technique qui pointe du doigt un mécanisme encore relativement récent d’Ethereum. Derrière l’alerte se cache une discussion brûlante autour d’EIP-7702, une fonctionnalité de délégation qui, selon certains experts, aurait permis à un attaquant de balayer les fonds d’un hot wallet Binance avec une efficacité troublante.

L’alerte de Charles Hoskinson sur un code particulièrement sensible

Sur son compte X, Charles Hoskinson a publié un message laconique mais percutant : « Attention, il y a du code sérieusement dangereux dehors. » Il accompagnait cette mise en garde d’une analyse détaillée signée CyberSatoshi. Cette publication reconstruit le bytecode d’un contrat baptisé sweeper, prétendument conçu pour cibler spécifiquement l’infrastructure de portefeuille de Binance. Hoskinson n’a pas validé chaque détail de l’analyse, mais le simple fait qu’il la relaie a suffi à relancer un débat déjà vif dans la communauté Ethereum.

L’analyse de CyberSatoshi ne se contente pas de décrire un vol classique. Elle met en parallèle deux questions cruciales. La première concerne la manière dont l’attaquant a obtenu le droit d’agir au nom du portefeuille. La seconde porte sur ce que la fonctionnalité de délégation d’Ethereum a ensuite rendu possible une fois cette permission acquise. C’est cette seconde partie qui intrigue le plus les spécialistes de la sécurité blockchain.

Un sweeper taillé sur mesure pour l’architecture Binance

Selon la reconstruction proposée par CyberSatoshi, le contrat laissait systématiquement 1 ETH dans le portefeuille après avoir balayé le solde natif. Cette manœuvre apparemment anodine aurait empêché le système automatisé de file d’attente du hot wallet de détecter un manque de gaz et de déclencher une alerte. L’idée est simple : éviter que la machine interne ne bascule en mode secours et n’alerte les équipes de sécurité.

Le code comportait également une boucle de traitement des tokens. Celle-ci vérifiait les soldes via des appels de bas niveau et poursuivait son exécution même lorsqu’une opération individuelle échouait. Ainsi, un token blacklisté ou temporairement non responsive ne bloquait pas l’ensemble du processus. L’attaquant pouvait continuer à extraire les actifs restants sans interruption.

Plus troublant encore, une fonction d’exécution sur mesure aurait autorisé le portefeuille compromis à appeler un vault externe. Ce coffre-fort détenait, selon l’analyse, environ 823 millions de dollars en USDC. Comme le vault identifiait Binance 14 comme son contrôleur, les appels passés via ce portefeuille pouvaient atteindre des fonds situés en dehors du solde immédiat du hot wallet. CyberSatoshi présente le contrat comme ayant été conçu spécifiquement pour l’architecture interne de Binance. Ces affirmations restent bien sûr celles de l’analyste, mais elles soulèvent des questions concrètes sur la résilience des systèmes de trésorerie des grands exchanges.

EIP-7702 : ce que permet réellement la délégation

Pour comprendre l’enjeu, il faut revenir au fonctionnement d’EIP-7702. Cette proposition d’amélioration d’Ethereum introduit un nouveau type de transaction qui permet à un compte contrôlé par une clé privée (EOA, ou Externally Owned Account) de déléguer son exécution à un code déployé à une autre adresse. En temps normal, un EOA ne peut agir que via des signatures issues de sa clé privée. Avec la délégation, il devient capable d’exécuter de la logique de smart contract dans son propre contexte de compte.

Cette capacité ouvre la porte à des fonctionnalités pratiques : regrouper plusieurs opérations dans une seule transaction, ou permettre à un tiers de payer les frais de gaz. Chaque autorisation de délégation précise une chaîne, une adresse de délégué et un nonce, le tout accompagné d’une signature cryptographique. Le protocole récupère le compte autorisant à partir de cette signature et vérifie le nonce avant d’appliquer la délégation.

Le code délégué reçoit un accès non restreint au compte. Il doit être audité avec la plus grande attention par le propriétaire du portefeuille.

Spécification EIP-7702

CyberSatoshi reconnaît explicitement que l’attaque présumée nécessitait soit la clé privée brute, soit un accès illimité à l’infrastructure de signature de Binance 14. La spécification elle-même n’explique pas comment ces identifiants ont pu être obtenus. Elle établit en revanche clairement qu’une délégation ne peut pas être imposée à un compte arbitraire sans autorisation valide. Sans signature correcte, le mécanisme reste inerte.

Le rôle des nonces et le batch d’autorisations

L’un des points les plus techniques de l’analyse concerne l’utilisation de 50 autorisations pré-signées couvrant des nonces consécutifs. L’objectif aurait été de « rattraper » le portefeuille Binance 14 alors que son compteur de transactions évoluait. Les règles d’Ethereum traitent les autorisations dans l’ordre. Lorsqu’une autorisation échoue à une vérification, le protocole passe simplement à la suivante. Une entrée valide fixe la délégation et incrémente le nonce du compte autorisant.

Il devient donc possible que plusieurs autorisations successives pour le même compte deviennent valides au fur et à mesure que le nonce avance. Lorsque plusieurs entrées valides coexistent, c’est la dernière délégation valide qui détermine l’adresse de code utilisée. Ce comportement va plus loin qu’un simple batch dans lequel une seule autorisation pourrait prendre effet. Les règles permettent effectivement à plusieurs entrées consécutives de réussir, selon le nonce de départ et les signatures fournies.

Selon CyberSatoshi, la délégation a compressé l’ensemble des transferts d’actifs en une seule opération. Ce gain de temps aurait réduit la fenêtre d’intervention possible pour les équipes de sécurité de l’échange. L’analyste affirme par ailleurs que, sans ce mécanisme, les défenses internes auraient probablement stoppé le vol après trois transactions seulement. Cette dernière assertion reste une hypothèse contre-factuelle, mais elle illustre bien la perception du risque que certains associent désormais à EIP-7702.

Les mises en garde explicites de la spécification Ethereum

Les auteurs d’EIP-7702 n’ont pas caché les dangers potentiels. La section sécurité du document souligne que le code autorisé dispose d’un accès non restreint au compte. Il doit donc être audité de très près par le propriétaire du portefeuille. La liste des protections recommandées pour les contrats délégués inclut la prévention des rejeux et des signatures couvrant la valeur de la transaction, le gaz, la destination et les données d’appel.

Une délégation mal implémentée peut laisser un attaquant avec un contrôle quasi total sur le compte signataire. De plus, la délégation persiste au-delà de la transaction qui l’installe. Un échec d’exécution ne provoque pas le rollback des indicateurs de délégation déjà traités. Pour retirer une délégation, le protocole autorise une autorisation valide pointant vers l’adresse zéro, ce qui efface le code de délégation du compte.

Pourquoi cette affaire relance le débat sur la sécurité des exchanges

Les grands exchanges comme Binance gèrent des volumes colossaux et des architectures de hot wallets particulièrement complexes. L’idée qu’un contrat puisse être conçu pour exploiter précisément ces particularités internes – files d’attente automatisées, seuils d’alerte, reconnaissance de contrôleurs – force à repenser certains modèles de sécurité. Même si l’obtention initiale des autorisations reste le point le plus opaque de l’affaire, la rapidité d’exécution permise par la délégation change la donne.

Dans un environnement où les fonds peuvent être déplacés en une seule transaction compressée, la fenêtre de réaction des équipes de sécurité se réduit drastiquement. Les systèmes de monitoring traditionnels, souvent calés sur des séquences de plusieurs transactions, peuvent se retrouver pris de court. Cette réalité pousse de nombreux acteurs à revoir leurs procédures de signature et leurs politiques de délégation.

Les implications pour les utilisateurs et les développeurs

Pour les utilisateurs finaux, le message est clair : toute fonctionnalité de délégation doit être abordée avec une extrême prudence. Signer une autorisation qui confère un accès large à un code tiers revient à remettre les clés de sa maison à un inconnu, même temporairement. Les portefeuilles et les interfaces qui proposent de telles fonctionnalités doivent absolument expliciter les risques et imposer des garde-fous visibles.

Du côté des développeurs, l’épisode rappelle l’importance des audits indépendants et de la conception défensive. Un contrat destiné à être délégué doit intégrer des mécanismes de limitation de portée, des listes blanches strictes et des contrôles de nonce robustes. La tentation de privilégier la flexibilité au détriment de la sécurité se paie souvent cher dans l’écosystème blockchain.

Les équipes d’exchanges, quant à elles, doivent désormais intégrer dans leurs modèles de menace la possibilité que des autorisations pré-signées soient stockées et utilisées de manière opportuniste. La rotation des nonces, la limitation stricte des droits de signature et la surveillance en temps réel des changements de délégation deviennent des priorités absolues.

Un contexte plus large de tensions autour d’Ethereum

Cette alerte intervient dans un climat déjà tendu autour de certaines évolutions techniques d’Ethereum. Chaque nouvelle fonctionnalité destinée à améliorer l’expérience utilisateur – batching, account abstraction, délégation – introduit inévitablement de nouvelles surfaces d’attaque. La communauté se divise régulièrement entre ceux qui privilégient l’innovation rapide et ceux qui appellent à une prudence accrue.

Charles Hoskinson, en tant que figure de proue de Cardano, n’a jamais caché ses critiques envers certaines approches d’Ethereum. Son message n’est donc pas anodin. En pointant du doigt un « code sérieusement dangereux », il force la conversation à sortir du cercle des spécialistes techniques pour atteindre un public plus large. La question n’est plus seulement de savoir si EIP-7702 est utile, mais si les protections actuelles sont suffisantes face à des acteurs motivés et bien informés.

Ce que l’on sait vraiment… et ce qui reste flou

Il est important de distinguer les faits établis des hypothèses. La reconstruction du bytecode et l’analyse du comportement du sweeper relèvent du travail de CyberSatoshi. Hoskinson a choisi de relayer cette analyse sans nécessairement endosser chaque affirmation. La spécification EIP-7702, elle, est publique et ses avertissements de sécurité sont explicites. En revanche, la manière exacte dont les autorisations de signature ont pu être obtenues n’est pas documentée dans les sources disponibles.

Cette zone d’ombre est cruciale. Sans compromission initiale de la clé ou de l’infrastructure de signature, la délégation seule ne suffit pas. L’affaire illustre donc moins une faille pure d’EIP-7702 qu’une combinaison dangereuse entre accès non autorisé et capacité d’exécution accélérée. C’est cette combinaison qui rend le scénario particulièrement préoccupant pour les opérateurs de grands volumes.

Vers une prise de conscience collective

L’épisode pousse l’ensemble de l’écosystème à reconsidérer l’équilibre entre facilité d’usage et robustesse sécuritaire. Les fonctionnalités de délégation répondent à une demande réelle : simplifier les interactions, réduire les frictions, permettre de nouvelles expériences. Mais elles ne peuvent être déployées à grande échelle qu’à condition que les risques soient clairement compris et mitigés.

Les échanges d’informations techniques, même lorsqu’ils relèvent d’analyses non officielles, jouent un rôle important dans cette prise de conscience. En partageant l’analyse de CyberSatoshi, Hoskinson a contribué à élargir le cercle des personnes informées. Reste maintenant à voir comment les équipes de développement d’Ethereum et les opérateurs d’exchanges intégreront ces enseignements dans leurs prochaines itérations.

La sécurité blockchain n’est jamais un état stable. Elle est un processus permanent d’adaptation face à des adversaires inventifs. L’affaire du sweeper présumé de Binance, qu’elle soit entièrement confirmée ou non, sert déjà de cas d’école. Elle rappelle que chaque nouvelle primitive technique doit être évaluée non seulement pour ce qu’elle permet de construire, mais aussi pour ce qu’elle permet de casser.

Les leçons à retenir pour l’avenir proche

Plusieurs enseignements se dégagent déjà. Premier point : les autorisations de délégation doivent être traitées avec le même niveau de protection que les clés privées elles-mêmes. Deuxième point : les systèmes de monitoring doivent être capables de détecter des changements de comportement en une seule transaction, et non plus uniquement sur des séquences plus longues. Troisième point : la conception de contrats destinés à être délégués exige une discipline extrême en matière de limitation des droits.

Enfin, la communication autour de ces sujets techniques doit rester accessible. Trop souvent, les discussions restent confinées à des cercles d’initiés. Des voix comme celle de Hoskinson permettent de faire sortir ces enjeux de la sphère purement technique et de les placer dans le débat public. C’est à ce prix que l’écosystème pourra progresser sans multiplier les incidents coûteux.

Dans les semaines et mois à venir, il sera intéressant d’observer si d’autres analyses viennent confirmer ou nuancer les affirmations de CyberSatoshi. Il sera tout aussi important de suivre les éventuelles mises à jour des recommandations de sécurité autour d’EIP-7702. La vigilance collective reste, aujourd’hui plus que jamais, le meilleur rempart contre les mauvaises surprises.

L’histoire de ce code « sérieusement dangereux » n’est peut-être qu’un chapitre supplémentaire dans la longue chronique des incidents de sécurité crypto. Mais elle a le mérite de mettre en lumière un mécanisme encore mal maîtrisé par une partie de la communauté. En forçant le débat, elle contribue, paradoxalement, à renforcer la résilience globale de l’écosystème. À condition, bien sûr, que les leçons soient réellement tirées et appliquées.

Les prochains mois diront si EIP-7702 reste perçu comme une avancée utile ou s’il devient le symbole d’une innovation déployée trop vite. Pour l’instant, l’alerte de Charles Hoskinson a au moins le mérite d’avoir placé le sujet sous les projecteurs. Et dans un domaine où l’opacité favorise souvent les attaquants, la lumière reste le premier outil de défense.