CZ : Les explorateurs de blocs devraient filtrer les transactions indésirables pour réduire le risque d'empoisonnement d'adresses
CZ : Les explorateurs de blocs devraient filtrer les transactions indésirables pour réduire le risque d'empoisonnement d'adresses
L'empoisonnement d'adresses (également appelé empoisonnement de l'historique des transactions) est devenu discrètement l'une des menaces les plus persistantes au niveau de l'interface utilisateur sur Ethereum et d'autres réseaux EVM. Les attaquants n'ont pas besoin de casser la cryptographie ou d'exploiter des contrats intelligents ; ils exploitent les habitudes humaines – en particulier la tendance à copier une adresse de l'historique des transactions récentes après avoir seulement vérifié les premiers et derniers caractères. Pour une explication claire du fonctionnement de ces escroqueries dans la pratique, consultez l'explication d'Etherscan sur les attaques d'empoisonnement d'adresses. (info.etherscan.com)
Début 2026, l'ampleur de ces campagnes est difficile à ignorer. Une étude du CyLab de l'Université Carnegie Mellon (basée sur des données on-chain sur plusieurs années) a documenté des centaines de millions de tentatives d'empoisonnement et a souligné que la cause première est la convivialité : de longues adresses hexadécimales, la troncature dans les interfaces et les comportements de copier-coller peu sûrs. (cylab.cmu.edu)
Dans ce contexte, CZ a récemment relancé la discussion autour d'une idée simple : arrêter de faire apparaître les transferts indésirables évidents dès le départ. Bien que la majeure partie de la conversation publique se concentre sur les applications de portefeuille, le même principe d'expérience utilisateur s'applique aux explorateurs de blocs – car ce sont les explorateurs que les utilisateurs, les équipes de support, les analystes et même les interfaces de portefeuille "lisent" souvent l'historique des transactions.
Pourquoi l'empoisonnement d'adresses continue de fonctionner
La plupart des attaques d'empoisonnement d'adresses suivent un schéma répétable :
- Un escroc génère une adresse ressemblante (correspondant souvent au début et à la fin d'une adresse de contrepartie réelle).
- Il effectue un transfert "poussière" (valeur infime, parfois même un événement de token qui ressemble à un transfert) afin que l'historique de la victime devienne "pollué".
- Plus tard, la victime copie la mauvaise adresse de son historique et envoie un paiement réel à l'attaquant.
Etherscan note que ces attaques ne sont pas limitées à une seule interface ; elles peuvent apparaître sur tous les explorateurs, portefeuilles et autres interfaces Web3. (info.etherscan.com)
Le point de CZ : le filtrage des indésirables est une correction UX, pas un changement de protocole
L'argument principal de CZ est simple : si une interface peut identifier un schéma d'empoisonnement (ou une adresse empoisonnée connue), elle devrait avertir ou bloquer – et si une transaction est effectivement un spam sans valeur, elle devrait être cachée par défaut pour réduire le risque d'erreur de copier-coller. Les rapports discutant de ses commentaires mettent en évidence deux orientations pratiques :
- Détecter et bloquer les destinations empoisonnées connues (une "requête blockchain" plus des renseignements sur les menaces)
- Ne pas afficher les transactions de spam de valeur négligeable dans les vues d'historique (financefeeds.com)
C'est là que les explorateurs de blocs font partie de la solution : de nombreux portefeuilles et outils de suivi de portefeuille s'appuient sur les API des explorateurs et les flux d'activité de type explorateur. Si les explorateurs présentent les transferts indésirables avec le même poids visuel que les paiements réels, ils amplifient involontairement l'"empreinte UI" de l'attaquant.
Les explorateurs de blocs ont déjà filtré les indésirables – ce n'est pas nouveau
L'industrie a déjà expérimenté des "contrôles de visibilité" au niveau de l'explorateur. Par exemple, BlockBeats a précédemment rapporté qu'Etherscan avait mis à jour sa vue par défaut pour ne pas afficher les transferts de tokens sans valeur en réponse aux escroqueries de type empoisonnement, tout en permettant aux utilisateurs de réactiver la visibilité dans les paramètres. (theblockbeats.info)
C'est un précédent important : le filtrage au niveau de l'interface utilisateur ne modifie pas la vérité on-chain. Il modifie ce qui est mis en évidence, ce qui est réduit, et ce qui nécessite un clic supplémentaire – exactement le type de friction qui peut prévenir des erreurs coûteuses.
La partie difficile : filtrer sans nuire aux cas d'utilisation légitimes
Les critiques du filtrage agressif soulèvent souvent une préoccupation légitime : et si les "petits transferts" étaient légitimes ?
En 2025-2026, cette question est plus importante car l'industrie évolue vers :
- Des frais plus bas et un débit plus élevé sur les L2 et les chaînes haute performance
- L'automatisation on-chain (bots, keepers, résolveurs d'intentions)
- Les agents IA qui peuvent dépendre de micro-paiements ou de règlements à haute fréquence
CZ a reconnu une version de ce compromis : si l'avenir inclut des micro-transactions IA-IA, un filtrage généralisé basé uniquement sur la valeur pourrait masquer une activité réelle – pourtant, les mêmes capacités d'IA peuvent également être utilisées pour classer les spams plus précisément lorsque cet avenir arrive (c'est-à-dire, une détection plus intelligente plutôt que de simples seuils).
Un juste milieu raisonnable pour les explorateurs est de :
- Cacher par défaut le "spam probable", pas la "faible valeur"
- Fournir une bascule "Afficher l'activité cachée" en un clic
- Offrir des étiquettes explicables (pourquoi quelque chose a été caché : 0 valeur, schéma de token usurpé, cluster d'empoisonnement connu, score de similarité élevé, etc.)
- Conserver une vue des journaux bruts / événements pour les utilisateurs avancés et les auditeurs.
Cela préserve la transparence tout en protégeant la majorité des utilisateurs du mode d'échec le plus courant : copier la mauvaise adresse à partir d'un flux pollué.
Ce que les explorateurs et les portefeuilles devraient faire (liste de contrôle pratique)
1) Arrêter de tronquer les adresses par défaut dans les contextes à haut risque
Si une interface doit tronquer, elle devrait prendre en charge le tap-to-expand (appui pour développer), mettre en évidence les différences, et afficher des indicateurs visuels stables (identicons, noms, étiquettes de contacts).
2) Ajouter des "avertissements de similarité" au moment de l'envoi
Le moment le plus sûr pour intervenir est avant la signature. Si la destination est très similaire à une adresse récemment utilisée (mais pas identique), l'interface utilisateur devrait forcer une confirmation délibérée.
3) Traiter la visibilité du spam comme un paramètre de sécurité
"Cacher le spam suspecté" devrait être activé par défaut, avec des contrôles clairs pour examiner les éléments cachés.
4) Utiliser des checksums partout où c'est possible
Pour les adresses de type Ethereum, l'encodage par checksum MIXE de casse EIP-55 aide à détecter les fautes de frappe et réduit certaines classes d'erreurs de copie. Voir la spécification ERC-55 (EIP-55). (eips-wg.github.io)
5) Maintenir un carnet d'adresses local (et encourager les listes blanches)
Une entrée de contact enregistrée est plus difficile à empoisonner que "ce qui apparaît en dernier dans l'historique".
Ce que les utilisateurs peuvent faire dès aujourd'hui pour réduire le risque d'empoisonnement d'adresses
Même si les explorateurs et les portefeuilles améliorent le filtrage, les utilisateurs devraient supposer que les tentatives d'empoisonnement continueront – car envoyer de la poussière coûte peu cher, et les attaquants s'automatisent à grande échelle. Voici des habitudes qui réduisent considérablement le risque :
- Ne jamais copier une adresse de destinataire de l'historique des transactions à moins de la vérifier entièrement.
- Pour les gros transferts, envoyer d'abord une petite transaction de test.
- Privilégier les sources d'adresses fiables (votre propre carnet d'adresses, les contreparties vérifiées, les codes QR provenant d'un canal authentifié).
- Comparer manuellement plus que les 4 premiers / derniers caractères – vérifiez également le segment du milieu.
- Utiliser un flux de signature qui vous oblige à vérifier l'adresse complète sur un écran de confiance.
Ce dernier point est là où un portefeuille matériel modifie significativement le profil de risque.
Où OneKey s'intègre dans ce modèle de sécurité
L'empoisonnement d'adresses est fondamentalement un problème de tromperie UI, donc la défense la plus robuste consiste à séparer "ce que vous voyez sur un écran potentiellement compromis" de "ce que vous approuvez sur un écran de confiance".
Un portefeuille matériel comme OneKey aide en gardant les clés privées hors ligne et en exigeant la confirmation des transactions sur l'appareil – ainsi, lorsque votre navigateur, dApp, ou historique des transactions est pollué par des transferts indésirables, vous avez toujours la possibilité de vérifier l'adresse du destinataire et le montant sur l'écran du matériel avant de signer.
Si vous interagissez fréquemment avec le DeFi, envoyez des stablecoins, ou gérez des portefeuilles opérationnels, la combinaison :
- filtrage des indésirables au niveau de l'explorateur / portefeuille, et
- vérification matérielle sur appareil
est l'un des moyens les plus pratiques de réduire les pertes dues à l'empoisonnement d'adresses sans sacrifier les avantages d'auto-custodie des blockchains publiques.
Lectures complémentaires
- Etherscan : Qu'est-ce qu'une attaque d'empoisonnement d'adresses ?
- CMU CyLab : Étude sur l'empoisonnement d'adresses blockchain à grande échelle (cylab.cmu.edu)
- Standard Ethereum : Adresses checksum ERC-55 (EIP-55) (eips-wg.github.io)
