Depuis le lancement d'Uniswap v4 sur le mainnet, le mécanisme des Hooks est devenu l'une des innovations les plus suivies du DeFi. La plateforme de lancement de memecoin Flaunch sur Base utilise les Hooks pour implémenter un prix de prévente fixe et un mécanisme de liquidation automatique à la mise en ligne ; le protocole de liquidité Bunni v2 utilise les Hooks pour construire des modèles de liquidité programmable et de re-collatéralisation ; cette année, les tokens basés sur les Hooks comme SATO, uPEG (Unipeg) et Slonks ont également enregistré des augmentations de plusieurs dizaines de fois en peu de temps.
Cependant, parallèlement à la prospérité de l'écosystème des Hooks, les attaques exploitant les défauts d'implémentation des Hooks augmentent également de manière significative. Cet article abordera le mécanisme des Hooks d'Uniswap v4, analysera progressivement sa pile d'appel principale, et aidera les projets à comprendre les vulnérabilités potentielles qu'il peut contenir.
Sécurité des Hooks Uniswap v4
1. Introduction
Le changement architectural le plus notable d'Uniswap v4 par rapport à v3 est l'introduction du mécanisme des Hooks (crochets) : il permet aux développeurs de connecter des contrats personnalisés aux événements du cycle de vie d'un pool de liquidité, en injectant une logique arbitraire à des moments clés tels que les swaps, l'ajout/retrait de liquidité ou l'initialisation.
Les principaux changements de v4 sont les suivants :
- Mode Singleton : L'état de tous les pools est géré de manière centralisée par un seul contrat PoolManager, sans déployer de contrat indépendant pour chaque pool.
- Flash accounting : Les changements de soldes intermédiaires pendant une transaction sont enregistrés uniquement dans un stockage transitoire, et le règlement final n'a lieu qu'à la fin de la transaction.
- Mécanisme des Hooks : Chaque pool peut être lié à un contrat Hook. Le PoolManager rappellera ce contrat à des moments clés (beforeInitialize, beforeSwap, afterAddLiquidity, etc.).
- Hooks non remplaçables : Une fois un pool initialisé, l'adresse du Hook liée est fixée de manière permanente (l'adresse du Hook liée au pool ne peut pas être modifiée, mais l'évolutivité du contrat Hook lui-même dépend de son implémentation).
À l'époque de v3, les développeurs devaient uniquement faire confiance au protocole Uniswap lui-même ; à l'époque de v4, la sécurité de chaque pool dépend du Hook auquel il est lié. Les Hooks transforment l'AMM d'une primitive financière fixe en une infrastructure financière programmable, mais le modèle de sécurité s'est également fragmenté du niveau « protocole » au niveau « pool ».
2. Architecture des Hooks
2.1 PoolManager et modèle unlock/callback
Le contrat central de v4 est le PoolManager singleton. Toute opération modifiant l'état d'un pool (swap, ajout/retrait de liquidité) doit d'abord appeler PoolManager.unlock() pour obtenir une autorisation de rappel ponctuelle, puis effectuer l'action spécifique dans unlockCallback(). À la fin du processus, le PoolManager vérifie si le registre est équilibré :
Si NonzeroDeltaCount != 0, la transaction revert directement. C'est la contrainte centrale du flash accounting de v4. Tout Hook peut temporairement déséquilibrer les comptes pendant son exécution, mais il doit les régler avant la fin de la transaction, sinon toute la transaction est annulée.
Chaque pool est identifié de manière unique par la structure PoolKey, qui inclut le champ hooks :
Le PoolId est calculé par keccak256(PoolKey). Par conséquent, des adresses de Hook différentes créeront des pools différents. Cela signifie également que le PoolManager ne vérifie pas si une adresse de Hook a déjà été utilisée pour d'autres pools ; le même contrat Hook peut être lié simultanément à plusieurs pools.
2.2 Les bits de permissions du Hook encodés dans l'adresse
Un design contre-intuitif de v4 est que les permissions d'un Hook ne sont pas déterminées par une variable interne au contrat, mais par l'adresse de déploiement du contrat Hook.
Le PoolManager vérifie les 14 bits de poids faible de l'adresse du Hook pour déterminer si celui-ci doit être appelé à un certain point du cycle de vie :
Par exemple, BEFORE_SWAP_FLAG = 1 << 7. Si le 7ème bit de l'adresse du Hook est à 1, le PoolManager appellera beforeSwap() de ce Hook avant un swap ; sinon, même si le contrat Hook implémente beforeSwap(), il ne sera jamais appelé par le PoolManager.
Cela signifie que lors du déploiement d'un Hook, il faut utiliser CREATE2 + salt pour calculer une adresse dont les bits de poids faible correspondent exactement aux permissions cibles. Uniswap fournit officiellement l'outil HookMiner à cette fin :
Un décalage entre les bits de permission et l'implémentation des fonctions peut causer deux types de problèmes :
(1) Implémenter une fonction hook, mais l'adresse n'encode pas le bit de permission correspondant — Le PoolManager n'appellera jamais cette fonction, la logique est inutile.
(2) L'adresse encode un bit de permission, mais le hook n'implémente pas la fonction correspondante — Lors du rappel, le PoolManager peut provoquer un revert (causant un DOS) ou un échec de validation de la valeur de retour, empêchant l'exécution de l'opération concernée.
C'est aussi un obstacle naturel à la mise à niveau des Hooks : si un Hook est évolutif via un proxy, l'adresse de déploiement reste la même lors de la mise à niveau. Ainsi, après une mise à niveau, on ne peut modifier que l'implémentation des fonctions hook existantes, pas en ajouter de nouveaux types. Pour prévoir une capacité d'extension future, il faut préalablement inclure tous les bits de permission potentiellement utilisés lors du déploiement initial.
2.3 BaseHook et un piège de contrôle d'accès souvent négligé
Le contrat abstrait BaseHook, fourni dans les anciennes versions de la périphérie d'Uniswap v4, permet aux développeurs de l'hériter pour implémenter des Hooks personnalisés. Un rôle important de BaseHook est de fournir le modificateur onlyPoolManager pour la fonction unlockCallback() :
Cependant — et c'est un piège de conception très facile à négliger — les premières versions de BaseHook n'ajoutaient la protection onlyPoolManager que pour unlockCallback, sans aucune protection pour les autres fonctions de rappel hook (beforeSwap, afterSwap, beforeAddLiquidity, etc.). Le contrôle d'accès pour ces fonctions doit être ajouté explicitement par le développeur du Hook.
3. Lecture pas à pas du cycle de vie d'un Hook
Prenons un swap exact-input comme exemple pour analyser la pile d'appel complète depuis l'initiation de la transaction par l'utilisateur jusqu'au règlement.
3.1 Initialisation du pool et liaison du Hook
N'importe qui peut appeler PoolManager.initialize() pour créer un nouveau pool :
isValidHookAddress ne vérifie que la compatibilité entre les bits de permission de l'adresse et le champ fee. Il ne vérifie pas si le Hook est déjà utilisé par d'autres pools, ni si ce Hook « accepte » ce PoolKey. Si le Hook n'implémente pas de logique de liste blanche ou de liaison à un seul pool dans beforeInitialize, n'importe qui peut créer un nouveau pool utilisant le même Hook mais avec une paire de tokens arbitraire, déclenchant ainsi tous les rappels ultérieurs du Hook.
3.2 beforeSwap et BeforeSwapDelta
L'entrée du processus de swap est PoolManager.swap(). Avant d'exécuter la logique centrale du swap, il appelle Hooks.beforeSwap() :
La valeur de retour de beforeSwap est un triplet (bytes4, BeforeSwapDelta, uint24) :
- bytes4 : Doit être égal à IHooks.beforeSwap.selector, sinon le PoolManager revert directement.
- BeforeSwapDelta : Les ajustements de delta que le Hook apporte au token spécifié et au token non spécifié pendant ce swap.
- uint24 : Valeur de remplacement des frais LP dynamiques (n'est actif que si le pool a activé les frais dynamiques).
BeforeSwapDelta est un alias pour int256, où les 128 bits de poids fort représentent le delta du token spécifié (celui dont la quantité est précisée par l'utilisateur), et les 128 bits de poids faible représentent le delta du token non spécifié :
Il est important de noter que la sémantique de BeforeSwapDelta est la suivante : si le Hook prélève des frais, il doit renvoyer une valeur positive ; s'il rembourse des tokens, il doit renvoyer une valeur négative. Les développeurs peuvent facilement inverser le signe ; de plus, la correspondance entre spécifié et non spécifié dépend de params.zeroForOne et du signe de amountSpecified. Une erreur d'écriture peut facilement entraîner une inversion des tokens.
Le PoolManager ajoutera directement le specifiedDelta retourné par beforeSwap à amountToSwap :
Cette ligne implique une sémantique cruciale : le Hook peut retenir le montant du swap. Lorsque hookDeltaSpecified est égal à -params.amountSpecified, amountToSwap devient directement zéro, ce qui équivaut à ce que le Hook prenne entièrement en charge ce swap — c'est ce qu'on appelle un Hook Asynchrone ou un Hook à Courbe Personnalisée.
Les Hooks Asynchrones représentent la catégorie de modèles de conception présentant le risque le plus élevé dans v4 : ils remplacent essentiellement la logique de swap d'Uniswap par la propre logique du Hook. Si le Hook contient une vulnérabilité ou est malveillant, les fonds des utilisateurs ne sont plus protégés par la logique de tarification native d'Uniswap, mais dépendent principalement de la justesse de l'implémentation du Hook lui-même.
3.3 Règlement des Delta et NonzeroDeltaCount
Les delta retournés par beforeSwap et afterSwap ne déclenchent pas immédiatement des transferts, mais sont enregistrés dans le registre interne du PoolManager :
Chaque fois que le delta cumulé d'un token passe de zéro à non-zéro, NonzeroDeltaCount s'incrémente ; lorsqu'il revient à zéro, il se décrémente. Comme mentionné en 2.1, si à la fin de unlock() NonzeroDeltaCount != 0, toute la transaction revert.
Le Hook équilibre son delta via deux actions : settle() (transfert vers le PoolManager) et take() (retrait du PoolManager) :
La sémantique de sécurité apportée par ce mécanisme est claire : tout le monde doit finalement équilibrer ses comptes. Mais cela garantit seulement la « conservation des comptes », pas leur « exactitude ». Si un Hook retourne un delta malveillamment construit dans beforeSwap, le PoolManager enregistrera fidèlement ce delta, et tant qu'il est finalement équilibré par settle, la transaction réussit — même si cela signifie que le Hook peut, en falsifiant l'état métier, amener le système à croire à tort que l'attaquant possède certains droits sur des actifs, ce que le PoolManager ne peut pas détecter au niveau métier.
L'incident de sécurité précédent du protocole Cork en est un exemple, car son Hook contenait une vulnérabilité, et avant d'être attaqué, il avait été audité par quatre sociétés d'audit. En rétrospective, nous avons constaté :
- Le scope de trois des quatre audits n'incluait pas le contrat CorkHook.
- La seule société ayant audité CorkHook a identifié certains problèmes de code et soumis des suggestions d'amélioration, mais n'a pas couvert complètement le problème de contrôle d'accès.
- Un autre auditeur indiquait clairement dans son rapport : « an interesting follow-up engagement would be to prove the invariants for the CorkHook functions that are being invoked by different components verified within the scope of this engagement ». Cette recommandation, rétrospectivement, était très pertinente.
Cela révèle un nouvel angle mort de l'audit à l'ère des Hooks v4 : l'explosion de la complexité des protocoles fait que la définition du scope devient elle-même une décision de sécurité. Les chaînes d'interaction entre les Hooks et les autres contrats du protocole sont très longues, et auditer uniquement le contrat Hook est insuffisant pour détecter les problèmes combinatoires inter-contrats ; à l'inverse, auditer les contrats périphériques en excluant le Hook du scope laisse échapper la plus grande surface d'attaque de l'ère v4.
4. Réflexion
En mettant en parallèle les mécanismes du protocole et l'analyse post-mortem de l'attaque sur Cork, on peut résumer plusieurs points clés du modèle de sécurité des Hooks v4 :
(1) Si les fonctions de rappel d'un Hook dépendent du contexte d'appel fourni par le PoolManager, elles doivent explicitement limiter les appels au seul PoolManager. BaseHook ne le fait pas pour les développeurs ; c'est le piège de conception de v4 qui entre le plus en conflit avec l'expérience générale d'audit de contrats.
(2) La relation de liaison entre un Hook et un pool n'est pas restreinte par le PoolManager. Les développeurs doivent impérativement implémenter une liste blanche de pools ou une liaison à un pool unique dans beforeInitialize.
(3) Les bits de permission de l'adresse du Hook doivent correspondre strictement à l'implémentation des fonctions. L'adresse calculée doit inclure préalablement tous les bits de permission potentiellement nécessaires à l'avenir.
(4) Les Hooks Asynchrones / à Courbe Personnalisée sont essentiellement des implémentations de swap entièrement personnalisées. Ils ne bénéficient d'aucune protection au niveau du protocole Uniswap et doivent être audités selon les standards d'un « contrat financier entièrement autonome ».
(5) La « conservation » de la comptabilité Delta n'équivaut pas à son « exactitude ». NonzeroDeltaCount == 0 garantit seulement que le registre est finalement équilibré, pas que son contenu n'a pas été manipulé de manière malveillante.
(6) La confusion entre types de tokens sur différents marchés est une nouvelle surface d'attaque à l'ère de v4. Lorsqu'un protocole permet aux utilisateurs de créer des marchés, la validation sémantique des tokens est obligatoire et ne peut reposer uniquement sur des vérifications d'interface.
Chaque Hook constitue un domaine de confiance indépendant, et la sécurité de chaque pool est déterminée par le Hook auquel il est lié. La complexité de l'audit de sécurité d'un Hook n'est donc plus « d'auditer un code », mais « d'auditer un sous-protocole complet » — ce changement implique une évolution méthodologique pour les projets comme pour les auditeurs.
Voir l'article original
