Analyse des Hooks Uniswap v4 : Conception architecturale, vulnérabilités courantes et bonnes pratiques de protection
Depuis le lancement d'Uniswap v4, le mécanisme de Hook est l'une des innovations les plus suivies dans la DeFi, permettant d'attacher des contrats personnalisés aux événements du cycle de vie des pools de liquidité. Cette flexibilité a stimulé la créativité, comme le montre Flaunch pour les lancements de memecoin, Bunni v2 pour la liquidité programmable, et d'autres projets qui ont généré des gains substantiels.
Cependant, cette flexibilité s'accompagne de nouveaux risques de sécurité. La sécurité d'un pool v4 dépend désormais entièrement du Hook qui lui est attaché, fragmentant le modèle de sécurité au niveau du pool. L'article analyse l'architecture de v4, centrée sur le PoolManager unique et le modèle de comptabilité "flash accounting" qui impose un solde final des deltas. Il explique comment les permissions d'un Hook sont encodées dans son adresse de déploiement via des bits, une conception contre-intuitive.
Des pièges majeurs sont mis en évidence : les contrats Hook doivent implémenter eux-mêmes des contrôles d'accès explicites pour leurs fonctions de rappel, le lien entre un Hook et un pool n'est pas restreint par défaut, et les Hooks asynchrones (ou Custom Curve) remplacent entièrement la logique d'échange d'Uniswap, nécessitant une audit extrêmement rigoureux. L'incident de sécurité du Cork Protocol illustre les nouveaux angles morts en matière d'audit dans ce paradigme, où la complexité des interactions exige une analyse systémique.
En résumé, chaque Hook constitue un domaine de confiance indépendant, transformant l'audit de sécurité en une revue complète d'un sous-protocole, ce qui représente un défi méthodologique majeur pour les projets et les auditeurs.
marsbit06/22 08:10
