Quel problème Uniswap v4 essaie de résoudre
Uniswap v3 était une avancée en termes d'efficacité du capital. La liquidité concentrée permettait aux LP de concentrer leurs dépôts dans une fourchette de prix choisie, de sorte que les mêmes dollars pouvaient générer plus de frais qu'une position v2 en plage complète. La contrepartie était la complexité : gérer les ranges, surveiller la perte impermanente et payer du gaz pour rééquilibrer.
Le design de la v3 comportait aussi une limitation structurelle à laquelle peu d'utilisateurs retail avaient pensé. Chaque nouveau pool était un nouveau smart contract, déployé par la factory v3. Des centaines de pools signifiaient des centaines de contrats, chacun avec son propre storage, et chaque swap devait sauter d'un contrat à l'autre pour router à travers les paires. Cela rendait le gaz cher au moment même où Ethereum essayait de scaler ses Layer 2.
Uniswap v4 repense l'architecture autour de ce problème. Au lieu d'un contrat par pool, le protocole regroupe quasiment tout dans un contrat unique, le singleton, qui détient toute la liquidité et dispatche chaque action via un seul point d'entrée. Les hooks sont la fonctionnalité qui rend ce nouveau design suffisamment flexible pour conserver la variété qu'offrait la v3, sans la surcharge de déploiement.
Comment le design singleton de la v4 modifie le protocole
Le changement architectural majeur de la v4 est le singleton. Dans la v3, déployer un nouveau pool signifiait déployer un nouveau contrat. Dans la v4, les pools sont en pratique des enregistrements au sein d'un seul contrat, et ce même contrat gère chaque swap, mint et burn. Cela a trois conséquences pratiques pour les utilisateurs.
Premièrement, les swaps multi-hop deviennent moins chers. Un swap allant de USDC à WETH puis à UNI touchait autrefois deux ou trois contrats de pool. Dans la v4, il n'en touche qu'un seul. Cela ressemble à de la plomberie, mais sur le mainnet cela peut faire la différence entre un swap économiquement viable et un utilisateur poussé vers un Layer 2 ou un exchange centralisé.
Deuxièmement, le singleton peut détenir de l'ETH natif au lieu de WETH wrapped. La compta des pools était autrefois une histoire de tokens wrappés, car chaque action nécessitait un contrat capable de recevoir des transferts ERC-20. Avec un contrat unique et un modèle de flash accounting, le singleton peut créditer et débiter l'ETH directement, ce qui épargne aux utilisateurs le gaz du wrap et de l'unwrap.
Troisièmement, le gaz est encore réduit par un motif de transient storage que l'équipe appelle « flash accounting ». Au lieu de faire entrer et sortir les tokens du pool à chaque action, le singleton suit les deltas en interne et ne règle les soldes de tokens qu'à la fin de la transaction. Résultat : la v4 est sensiblement moins chère à utiliser pour swapper que la v3, ce qui compte pour les LP actifs et pour les stratégies qui rééquilibrent souvent.
Il y a cependant un compromis facile à manquer. Concentrer tout le DEX dans un seul contrat concentre aussi le rayon d'impact d'un bug. Une vulnérabilité sérieuse dans le singleton serait une vulnérabilité touchant simultanément chaque pool de la v4. C'est l'image miroir architecturale du risque fragmenté de la v3, et c'est en partie pourquoi l'équipe a passé plus d'un an sur les audits avant le déploiement plus large.
Ce qu'est réellement un hook Uniswap v4
Un hook est un smart contract que le singleton appelle à des points spécifiques du cycle de vie d'un pool. Les événements du cycle de vie exposés par le protocole incluent beforeSwap et afterSwap, beforeModifyLiquidity et afterModifyLiquidity, ainsi que beforeDonate et afterDonate. Un hook s'enregistre auprès d'un pool, et le singleton y délègue l'exécution à l'étape concernée.
On peut voir un pool en v4 comme étant composé de hooks et d'une position de liquidité. Le pool utilise toujours la mathématique à produit constant qui fait la réputation d'Uniswap, sauf si le hook la modifie. Le hook a le droit de lire les paramètres du swap, de lire l'état du pool, et de renvoyer un résultat que le singleton utilisera ensuite. Point crucial, le hook peut aussi rejeter l'action en faisant échouer la transaction.
Pour que cela fonctionne, l'équipe v4 a introduit un système de permissions pour les hooks. Chaque adresse de hook encode les événements du cycle de vie qu'il implémente, et le singleton utilise les bits de poids faible de l'adresse du hook pour consulter un drapeau indiquant quels callbacks déclencher. C'est une astuce d'optimisation de gas, mais cela signifie aussi que les permissions d'un hook sont visibles à partir de son adresse seule, ce qui est utile pour les intégrateurs et les tableaux de bord.
Pour les développeurs, le modèle pratique est le suivant : on déploie un contrat qui implémente les callbacks qui nous intéressent, on l'enregistre auprès du pool que l'on souhaite personnaliser, et dès lors, chaque action sur le pool passe par notre code. On construit en substance un petit AMM, ou un gestionnaire de marché automatisé, par-dessus la couche de règlement d'Uniswap.
Ce que les hooks permettent réellement : des AMM personnalisés et des frais dynamiques
L'argumentaire marketing autour des hooks est qu'« Uniswap devient une plateforme au lieu d'un produit ». C'est globalement vrai, et la façon la plus simple de comprendre pourquoi consiste à passer en revue ce que les hooks peuvent réellement faire.
Frais dynamiques et à plusieurs niveaux. Un hook peut modifier les frais prélevés sur un swap en fonction de certaines conditions. Par exemple, un hook pour stablecoins pourrait facturer une fraction de point de base quand le prix est proche de la parité, et un fee plus élevé quand la volatilité est forte. Un hook pourrait aussi facturer un fee différent selon que le swap fait monter ou baisser le prix, ce qui constitue une forme primitive de capture de MEV pour les LPs.
Courbes d'AMM personnalisées. Le pool v4 par défaut utilise toujours la formule du produit constant x*y=k, mais un hook peut en pratique exécuter n'importe quel modèle de pricing. On peut construire un invariant de type stableswap pour les paires à faible volatilité, une courbe hybride de style Curve, une courbe gaussienne ou à retour à la moyenne pour des actifs synthétiques, ou même un hook qui suit entièrement un oracle externe. Le pool devient une plateforme de liquidité à usage général, Uniswap fournissant le règlement, le routage et le modèle de sécurité du singleton.
Ordres limites onchain et TWAMM. Un hook beforeModifyLiquidity peut transformer des ajouts de liquidité sur une seule plage de ticks en ordres limites : le LP spécifie une fourchette de prix, et le hook mint et burn des positions à mesure que le prix du marché traverse cette fourchette. Les stratégies de market maker à moyenne pondérée dans le temps, où un ordre important est découpé en de nombreux petits swaps sur plusieurs heures, peuvent également être exprimées sous forme de hook.
Oracles onchain et protections pour les LPs. Un hook peut écrire un TWAP, un VWAP ou toute autre statistique en storage à chaque swap, que d'autres contrats peuvent lire à moindre coût. Les hooks peuvent aussi imposer des règles comme « pas de swap dans le dernier bloc d'une fenêtre d'une minute », ce qui constitue une forme rudimentaire mais utile de protection anti-MEV, ou implémenter des kill switches qui mettent en pause un pool si certaines conditions sont réunies.
ETH natif et remboursements de gas. Comme le singleton détient de l'ETH, les hooks peuvent mettre en place des rebates de gas en ETH pour les LPs, ou verser des récompenses de MEV en ETH plutôt que dans le token échangeable. C'est marginal pour un utilisateur individuel, mais c'est un levier structurel pour les concepteurs de protocoles cherchant à attirer de la liquidité.
Rien de tout cela n'est automatique. Chaque fonctionnalité ci-dessus nécessite qu'un développeur construise, déploie et maintienne un hook. Uniswap livre une boîte à outils, pas une liste de fonctionnalités.
Les risques de sécurité liés au code de hook non audité
Chaque nouveau hook est une nouvelle surface de smart contract, et c'est la partie de l'histoire v4 qui mérite le plus d'attention. En v3, les contrats qui détenaient la liquidité formaient un ensemble relativement restreint et bien audité. En v4, n'importe qui peut enregistrer un hook auprès d'un pool, et ce hook est exécuté dans le chemin critique de chaque swap, mint et burn de ce pool.
Les risques se répartissent en quelques catégories, et les LPs doivent connaître chacune d'elles avant de déposer des fonds dans un pool activé par un hook.
Bugs logiques dans le hook. Un bug dans beforeSwap ou beforeModifyLiquidity peut corrompre la comptabilité du pool, permettre des retraits supérieurs aux dépôts, ou geler entièrement le pool. Comme le singleton fait foi, le hook ne peut pas voler directement des tokens, mais il peut laisser le pool dans un état exploitable par une transaction suivante, souvent dans le même bloc.
Réentrance et interférences entre hooks. Les hooks sont des contrats externes, et un hook malveillant peut réentrer dans le singleton ou appeler d'autres hooks sur le même pool. Le protocole dispose de verrous de réentrance, mais la surface d'interaction entre hooks est nouvelle et n'a pas encore été éprouvée en conditions réelles. Deux hooks attachés au même pool, par exemple, peuvent se composer de manières qu'aucun audit individuel n'a couvertes.
Clés d'admin et upgradabilité. De nombreux hooks sont déployés avec une adresse de propriétaire qui peut modifier les paramètres, mettre en pause le comportement, ou upgrader le contrat. Une clé d'admin est un point unique de défaillance : une clé compromise peut modifier le comportement du hook alors que le pool est toujours actif, et les LPs peuvent n'avoir aucun moyen propre de retirer leurs fonds avant que le changement ne prenne effet. Un multisig avec timelock est mieux qu'un EOA, mais cela reste de la confiance.
Manipulation d'oracle. Les hooks qui lisent des oracles externes, ou qui modifient les fees en fonction du prix, ne sont aussi sûrs que l'oracle lui-même. Un oracle manipulé peut inciter un hook à facturer un swap à fee zéro qui draine les LPs, ou à verrouiller le pool dans un état favorable à l'attaquant.
Risque concentré au sein du singleton. Un bug de hook qui affecte un pool n'affecte que ce pool. Mais certaines catégories de bugs, en particulier ceux qui interagissent avec la comptabilité de l'ETH natif par le singleton, pourraient en principe se propager à de nombreux pools à la fois. Ce n'est pas propre à v4, mais le singleton rend la topologie plus dangereuse que l'architecture par pool de v3.
Le résumé honnête est que les hooks sont la partie de v4 qu'un utilisateur occasionnel ne peut pas évaluer seul. « Ce pool utilise un hook » n'est pas une mention à ignorer. L'hypothèse prudente est de traiter tout hook comme un smart contract tiers qui a la garde du chemin de swap, et de mettre en balance le risque supplémentaire avec le rendement supplémentaire.
MEV, protection des LPs et gains réalistes
La valeur extractible maximale, c'est-à-dire le profit que les producteurs de blocs et les searchers peuvent capturer en réordonnançant, insérant ou censurant des transactions, est l'un des coûts de fond persistants pour les LPs. Les attaques en sandwich, en particulier, extraient de la valeur des swaps en tradant avant et après la transaction de l'utilisateur. Les LPs absorbent la perte parce que le prix effectif du pool est moins favorable que le prix accepté par l'utilisateur.
Les hooks sont un outil crédible pour réduire ce coût. Un hook beforeSwap peut vérifier si la transaction fait partie d'un sandwich, à l'aide de schémas commit-reveal, de mémos signés ou de chemins de transaction privés, et faire échouer le swap s'il en détecte un. Un hook peut aussi imposer que les swaps ne se règlent qu'à certaines positions dans le bloc, facturer des fees plus élevés aux transactions qui ressemblent à des sandwiches, ou découper les gros swaps en plus petits morceaux atomiques plus difficiles à sandwicher.
De l'autre côté, les hooks sont aussi une nouvelle surface de MEV. Un hook disposant d'un accès privilégié aux paramètres du swap et à l'état du pool peut être utilisé par son opérateur pour front-runner les utilisateurs sur ce pool. Le protocole ne peut pas empêcher cela, tout comme il ne peut pas empêcher un opérateur d'oracle de manipuler son oracle. La mitigation est la même que dans le reste de la DeFi : réputation, audits, monitoring public, et une communauté prête à retirer sa liquidité quand un hook se comporte mal.
Le gain réaliste pour des LPs sérieux est réel mais limité. Un hook bien conçu sur un pool profond peut réduire sensiblement la sélection adverse, qui est le terme technique pour « mon trade s'est fait cueillir ». Cela se traduit par un APR net plus élevé, parfois de plusieurs points de pourcentage. Ce n'est pas un tour de magie, et ce n'est pas un substitut à la compréhension du pool dans lequel on se trouve.
Ce que cela implique pour les fournisseurs de liquidité et les développeurs
Si vous êtes un LP, l'univers de la v4 exige un flux de travail légèrement différent de celui de la v3. Avant de déposer, vous devriez pouvoir répondre à quatre questions. Quel hook est attaché à ce pool, et que fait-il réellement ? Qui peut modifier les paramètres du hook, et selon quel calendrier ? Le hook a-t-il été audité, et par qui ? Quel est le mode de défaillance si le hook cesse complètement de fonctionner, votre position est-elle toujours retirable ?
Si la réponse à l'une de ces questions est « je ne sais pas », le pool n'est pas le bon endroit pour placer l'essentiel de votre capital. Un rendement provenant d'un hook que vous ne pouvez pas évaluer est un rendement qui peut disparaître du jour au lendemain. Le même conseil qui s'appliquait à la v3 s'applique encore plus à la v4 : dimensionnez vos positions en fonction de ce que vous seriez prêt à perdre dans le pire cas de bug de smart contract, et non en fonction de l'APY affiché.
Si vous êtes un développeur, les hooks constituent une véritable expansion de l'espace de conception. Vous pouvez déployer un AMM personnalisé en quelques semaines plutôt qu'en quelques mois, vous pouvez itérer sur les courbes de prix sans forker Uniswap, et vous pouvez composer avec le routeur v4 existant, ce qui vous donne un accès à la liquidité que vous devriez autrement amorcer vous-même. Le revers de la médaille, c'est que vous livrez également un produit de sécurité. Les équipes de hooks les plus réfléchies de l'écosystème v4 traitent les audits, les programmes de bug bounty et la gestion des incidents comme faisant partie du produit, et non comme une charge accessoire.
Une remarque pratique pour les deux groupes : la v4 est intentionnellement plus permissionless que la v3, et l'équipe a clairement indiqué qu'elle ne curera pas de liste par défaut de hooks « approuvés ». Le marché est censé effectuer ce travail à travers la réputation, les tableaux de bord et les agrégateurs. Tant que ces signaux ne seront pas matures, chaque décision concernant un hook sera une décision personnelle en matière de risque.
Comment suivre les hooks Uniswap v4 de manière intelligente
Les hooks Uniswap v4 évoluent rapidement, et l'actualité les concernant aussi. De nouveaux designs de hooks, des audits, des exploits et des migrations sont annoncés sur les forums de recherche, les fils de gouvernance et les blogs de projets, et lire chacun d'eux isolément est une bataille perdue d'avance. Zippfeed met en avant les titres concernant les hooks Uniswap v4 avec une notation de sentiment (bullish, neutral ou bearish) et une cote d'importance, afin que vous puissiez distinguer les véritables évolutions du protocole du battage médiatique et identifier quels hooks gagnent une liquidité réelle plutôt qu'une part de marché marketing.
