Taxonomie des abus de marché

Curiosité

1. Pourquoi un contrat de jeton a-t-il besoin d’une clé d’administration s’il est censé être sans permission ?
2. Comment deux ordres identiques peuvent-ils donner des prix différents en fonction de celui qui les soumet en premier ?
3. Si le code ne peut pas empêcher l’ingénierie sociale, quelle partie du marché reste vulnérable ?

Explorer

Partie IUne taxonomie des abus de marché

1. Les abus de marché se répartissent en six couches distinctes, chacune exploitant une faiblesse structurelle spécifique. La couche contrat concerne les pouvoirs conservés, comme la frappe ou le gel ; la couche structure de marché comprend les pools peu liquides et la conception des courbes ; la couche d’ordonnancement exploite le séquencement des transactions ; la couche d’activité fictive gonfle le volume et le nombre de détenteurs ; la couche sociale manipule la confiance par l’usurpation d’identité ; et la couche portefeuille vide les actifs par le phishing. Chaque couche relève de l’un des quatre défenseurs (le code, la conception du marché, la cryptographie ou les personnes), et ce niveau montre que des outils existent déjà pour chacune. Il s’adresse aussi bien aux développeurs qu’aux utilisateurs.
2. La couche contrat est celle où le vol commence souvent. Si un développeur conserve l’autorité de frappe, il peut créer de nouveaux jetons à volonté et les vendre au détriment des détenteurs existants. Les fonctions de gel lui permettent d’empêcher certains portefeuilles de vendre, piégeant de fait les capitaux. Les proxys upgradables permettent aux développeurs de remplacer le code sous-jacent après le lancement. Ce ne sont pas des bugs ; ce sont des fonctionnalités qui créent une surface d’attaque. Supprimer ces clés élimine la menace, mais supprime aussi la capacité de corriger des erreurs critiques ou de réagir aux urgences.
3. Les attaques d’ordonnancement sont le fait de quiconque peut voir les transactions en attente avant qu’elles ne soient ordonnées. Le front-running se produit lorsqu’un trader voit un ordre en attente et soumet sa propre transaction avec des frais plus élevés pour être exécuté en premier. Le sandwich consiste à acheter juste avant le gros swap d’une victime et à revendre immédiatement après, en profitant de l’impact sur le prix provoqué par ce swap. Ces pertes retombent sur les traders ordinaires, qui obtiennent de moins bons prix d’exécution. Les limites de slippage plafonnent les pertes potentielles, mais n’empêchent pas l’attaque elle-même.
4. Les attaques au lancement exploitent la rapidité d’une tarification au premier arrivé. Les snipers achètent des jetons dès le tout premier bloc d’un lancement, souvent au moyen de bundles qui regroupent plusieurs transactions pour une inclusion atomique. Les portefeuilles Sybil permettent à un seul acteur de contrôler de nombreuses adresses, ce qui masque la concentration et permet de farmer les récompenses par portefeuille. Ces attaques reposent sur la création peu coûteuse d’adresses et sur des structures de récompense non linéaires par rapport aux avoirs. Leur détection exige généralement d’analyser a posteriori les graphes de financement.
5. L’activité fictive gonfle les indicateurs qui attirent l’attention. Le wash trading consiste à acheter et vendre des jetons entre ses propres portefeuilles pour créer un volume artificiel. Les bots de volume enchaînent les transactions pour grimper dans les classements de tendances, tandis que l’envoi massif de dust crée de faux nombres de détenteurs. Quand chaque transaction paie des frais, le wash trading devient coûteux, mais quand les algorithmes de tendance pondèrent les portefeuilles uniques, les attaques Sybil deviennent rentables. Ces distorsions trompent les investisseurs sur l’intérêt réel du marché.
6. La couche sociale exploite la confiance humaine plutôt que le code. Les promotions payantes non déclarées, l’usurpation de comptes officiels et les pump-and-dumps coordonnés ne nécessitent aucune vulnérabilité technique. Les sites de phishing et les approbations malveillantes vident directement les portefeuilles des utilisateurs. Le code peut rendre ces attaques visibles grâce à la vérification de l’historique on-chain, mais il ne peut pas les empêcher. Ces menaces résident dans le comportement des personnes, non dans la logique des contrats.

Partie IICe que le code peut corriger, et ce qu’il ne peut pas corriger

7. La logique du contrat définit ce qui est possible. Si le code conserve une fonction de frappe accessible uniquement à un administrateur, cette clé reste une surface d’attaque permanente. Supprimer entièrement l’autorité de frappe élimine le risque d’inflation incontrôlée. De même, supprimer les variables de taxe de vente ou les fonctions de gel empêche les honeypots et les abus de liste noire. Ce sont des choix binaires : le pouvoir existe, ou il n’existe pas.
8. La structure du marché détermine l’ordre d’exécution. En traitement séquentiel, le premier achat d’un bloc obtient le meilleur prix. Les mécanismes de compensation par lots regroupent les transactions sur une fenêtre de temps et les exécutent toutes à un prix de compensation unique et uniforme. Cela neutralise le front-running et les sandwichs au sein du lot, car chaque ordre obtient le même prix : passer en premier, ou encadrer l’ordre de quelqu’un d’autre, ne rapporte rien.
9. Certains risques sont bornés, mais pas éliminés. Un créateur détenant quarante pour cent de l’offre peut la liquider, faisant chuter le prix au détriment des premiers acheteurs. Le code peut verrouiller l’offre d’un créateur ou la soumettre à un vesting, mais il ne peut pas empêcher un détenteur dont les jetons sont déverrouillés de vendre. Il s’agit d’un risque de marché, distinct du vol. Acheter dans un bloc antérieur peut aussi encore rapporter. Les concepteurs doivent accepter que la volatilité due aux gros détenteurs est une caractéristique inhérente des marchés sans permission, et non un bug à corriger.
10. L’ingénierie sociale se situe en dehors du code. Les liens de phishing, les comptes usurpés et les promotions payantes exploitent la confiance humaine, et non des vulnérabilités informatiques. Aucun smart contract ne peut vérifier si un influenceur a déclaré sa participation avant de faire le call d’un jeton. Ces attaques persistent quelle que soit la sécurité technique, car elles agissent sur l’attention et la croyance, et non sur des transitions d’état.
11. Un document de conception honnête indique quelles classes d’attaques sont éliminées par le code, lesquelles sont neutralisées par les mécanismes de marché et lesquelles restent irréductibles, car liées au comportement humain. Il énonce explicitement : l’abus de frappe est impossible ; les attaques sandwich sont atténuées par le traitement par lots ; le phishing reste une responsabilité de sécurité personnelle. Cette transparence permet aux utilisateurs d’évaluer correctement leur risque plutôt que de supposer une sécurité totale.
12. Ouvrez un explorateur de blocs pour un jeton EVM dont le code source est vérifié et cherchez des fonctions comme `mint`, `pause` ou `owner` ; sur Solana, vérifiez plutôt les autorités de frappe et de gel ainsi que l’autorité de mise à niveau du programme. Vérifiez si ces fonctions peuvent être appelées par n’importe qui ou si elles sont réservées à une adresse précise. Si aucune fonction de ce type n’existe et que le contrat n’est pas upgradable, ces vecteurs d’attaque sont structurellement absents, et pas simplement désactivés.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• Chainalysis, Crypto Crime Report (2024)
• P. Daian et al., 'Flash Boys 2.0' (IEEE S&P 2020)
• SPL Token documentation
• OpenZeppelin proxy documentation
• E. Budish, P. Cramton & J. Shim, 'The High-Frequency Trading Arms Race' (QJE 2015)