Le mécanisme Hook de Uniswap v4 : opportunités et défis coexistent

Uniswap v4 sera bientôt lancé, et cette version introduira de nombreuses fonctionnalités innovantes, dont le mécanisme Hook qui est particulièrement remarquable. Hook permet d'exécuter du code personnalisé à des nœuds spécifiques du cycle de vie des pools de liquidité, améliorant ainsi considérablement l'évolutivité et la flexibilité des pools. Cependant, cette puissante fonctionnalité entraîne également de nouveaux défis en matière de sécurité.

Cet article, en tant qu'introduction à une série, vise à présenter de manière systématique les problèmes de sécurité et les risques potentiels liés au mécanisme Hook, afin de promouvoir le développement sécurisé de la communauté. Nous croyons que ces idées contribueront à construire un écosystème Uniswap v4 Hook plus sûr.

Mécanisme central de Uniswap V4

Avant d'explorer en profondeur les problèmes de sécurité, nous devons d'abord comprendre quelques mécanismes clés de Uniswap v4 :

Mécanisme Hook

Hook est un contrat qui fonctionne à différentes étapes du cycle de vie d'un pool de liquidités. Actuellement, il y a 8 rappels Hook, répartis en 4 groupes :

• avantInitialiser/aprèsInitialiser
• avantModifierPosition/aprèsModifierPosition
• avantÉchange/aprèsÉchange
• avantDon/ aprèsDon

Grâce au mécanisme Hook, il est possible de prendre en charge de manière native des frais dynamiques, d'ajouter des ordres à prix limite sur la chaîne, de réaliser des fonctions telles que la mise en marché par moyen arithmétique pondéré dans le temps pour des commandes dispersées, (TWAMM).

Architecture Singleton et comptabilité éclair

Uniswap v4 adopte une architecture à instance unique, toutes les pools de liquidité sont conservées dans un même contrat intelligent. Cela repose sur un PoolManager pour stocker et gérer l'état de toutes les pools.

La comptabilité par éclair est un nouveau mécanisme de comptabilité. Les opérations ne transfèrent plus directement des jetons, mais ajustent plutôt le solde net interne. Le transfert réel est effectué à la fin de l'opération.

mécanisme de verrouillage

Le mécanisme de verrouillage empêche l'accès concurrent et garantit que toutes les transactions peuvent être liquidées. Le processus principal est le suivant :

1. demande de verrouillage du contrat locker
2. PoolManager ajoute l'adresse du locker à la file d'attente et appelle son rappel.
3. logique d'exécution du locker, interaction avec le pool
4. PoolManager vérifie l'état, supprime le locker

En raison du mécanisme de verrouillage, les comptes externes ne peuvent pas interagir directement avec PoolManager, ils doivent passer par un contrat.

Modèle de menace

Nous considérons principalement deux modèles de menace:

• Modèle de menace I : Hook lui-même est bénin, mais présente des vulnérabilités
• Modèle de menace II : Hook lui-même est malveillant

Problèmes de sécurité dans le modèle de menace I

Nous nous concentrons principalement sur les vulnérabilités potentielles spécifiques à la version v4, en particulier celles impliquant la logique des interfaces Hook standard. Nous mettons l'accent sur deux types de Hook :

1. Hook pour la garde des fonds des utilisateurs
2. Hook pour stocker les données d'état clés

En analysant des exemples de projets communautaires, nous avons découvert certaines vulnérabilités graves, principalement classées en deux catégories :

Problèmes de contrôle d'accès

La fonction de rappel Hook ne doit être appelée que par le PoolManager. Un manque de contrôle d'accès peut entraîner des opérations non autorisées, telles que la collecte incorrecte de récompenses, etc.

Problème de validation des entrées

Dans certaines implémentations de Hook, une validation d'entrée inappropriée peut conduire à des appels externes non fiables. Les attaquants peuvent attaquer ces Hooks en enregistrant des pools de fonds malveillants.

Problèmes de sécurité dans le modèle de menace II

Nous allons discuter des Hooks en deux catégories :

Hook de type hébergement

Les utilisateurs interagissent avec Hook via le routeur. Bien qu'il soit difficile de voler des actifs directement, il est possible de manipuler le mécanisme de gestion des frais.

Crochet autonome

Les utilisateurs peuvent interagir directement avec Hook, lui donnant plus de pouvoir. Si Hook est évolutif, cela pourrait constituer un risque majeur.

Mesures de prévention

Pour le modèle de menace I:

• Mettre en œuvre les contrôles d'accès nécessaires
• Vérifiez les paramètres d'entrée
• Ajouter une protection contre les réentrées

Concernant le modèle de menace II :

• Évaluer si le Hook est malveillant
• Suivre les comportements de gestion des frais ( de type fiduciaire )
• Vérifiez si la mise à niveau ( de l'indépendant ) est possible.

Cet article explore les problèmes de sécurité du mécanisme Hook de Uniswap v4. Dans les articles suivants, nous procéderons à une analyse plus approfondie des problèmes de sécurité sous chaque modèle de menace.