Uniswap v4 Mécanisme Hook : innovation et défis coexistent

Uniswap v4 sera bientôt lancé, cette version introduira plusieurs innovations majeures, y compris le support d'un nombre illimité de pools de liquidité par paire de trading et des frais dynamiques, un design singleton, la comptabilité instantanée, le mécanisme Hook, ainsi que le support de la norme de token ERC1155. Parmi celles-ci, le mécanisme Hook attire particulièrement l'attention en raison de son potentiel puissant.

Le mécanisme Hook permet d'exécuter du code personnalisé à des moments spécifiques du cycle de vie d'un pool de liquidité, ce qui améliore considérablement l'évolutivité et la flexibilité du pool. Cependant, cette flexibilité entraîne également de nouveaux défis en matière de sécurité. Cet article présentera de manière systématique les problèmes de sécurité et les risques potentiels associés au mécanisme Hook, afin de promouvoir le développement sûr de la communauté.

Mécanisme central d'Uniswap V4

Les trois fonctionnalités importantes d'Uniswap v4 sont Hook, architecture singleton et comptabilité instantanée.

Mécanisme Hook

Hook est un contrat qui fonctionne à différentes étapes du cycle de vie d'un pool de liquidités, permettant un soutien natif aux frais dynamiques, l'ajout d'ordres à prix fixe sur la chaîne, ou la distribution de grandes commandes via un teneur de marché à moyenne pondérée dans le temps (TWAMM).

Il y a actuellement huit rappels Hook, répartis en quatre groupes :

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

singleton, comptabilité éclair et mécanisme de verrouillage

L'architecture singleton et la comptabilité lightning visent à améliorer les performances. Tous les pools de liquidité sont conservés dans le même contrat intelligent PoolManager.

Le fonctionnement du mécanisme de verrouillage est le suivant :

1. Le contrat locker demande un lock sur PoolManager
2. PoolManager ajoute cette adresse de locker à la file d'attente et appelle son rappel.
3. Logique d'exécution du contrat locker, l'interaction avec le pool peut entraîner une augmentation non nulle de la monnaie.
4. PoolManager vérifie l'état de la file d'attente et de l'augmentation des devises, puis supprime ce locker après validation.

Cette méthode ajuste le solde net interne, plutôt que d'effectuer un transfert immédiat. Le transfert réel a lieu à la fin de l'opération, garantissant qu'il n'y ait pas de jetons non réglés.

Les comptes externes ne peuvent pas interagir directement avec PoolManager, ils doivent passer par un contrat. Il existe principalement deux scénarios d'interaction :

• Routeur du contrat locker ( déployé par l'utilisateur ou officiellement )
• Intégration du contrat locker et du contrat Hook dans le même 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 sur les vulnérabilités potentielles spécifiques à la version v4, qui se divisent principalement en deux catégories :

• Hook de garde des fonds des utilisateurs
• Hook pour stocker les données d'état clés

Les vulnérabilités découvertes proviennent principalement des interactions à risque entre hook, PoolManager et des tiers externes, et peuvent être classées en :

• Problèmes de contrôle d'accès
• Problèmes de vérification d'entrée

Parmi 22 projets pertinents, 8 ont des vulnérabilités, dont 6 présentent des problèmes de contrôle d'accès et 2 sont sensibles aux appels externes non fiables.

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

Les fonctions de rappel dans v4, les 8 rappels hook et les rappels de verrouillage ) ne devraient être appelés que par le PoolManager. Il est essentiel d'établir un mécanisme de contrôle d'accès solide.

Problème de validation d'entrée

Malgré le mécanisme de verrouillage, il existe encore des scénarios d'attaque potentiels :

• pool de fonds pour les interactions utilisateur non vérifiées de hook
• La fonction hook clé permet des appels externes arbitraires.

Cela pourrait entraîner des problèmes tels que des attaques par réentrance.

(# Mesures de prévention

• Mettre en œuvre un contrôle d'accès nécessaire pour les fonctions sensibles
• Vérifier les paramètres d'entrée
• Mise en œuvre de la protection contre la réentrée

![Pourquoi dit-on que Hook est une "épée à double tranchant" pour Uniswap V4 ?])https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp###

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

Nous avons divisé Hook en deux catégories :

• Hook géré : les utilisateurs interagissent avec le hook via le routeur
• Hook autonome : l'utilisateur interagit directement avec le hook

(# Hook de garde

Transférer les actifs de l'utilisateur au routeur. Un hook malveillant est difficile à voler directement, mais peut manipuler le mécanisme de gestion des frais.

)# Crochet indépendant

hook obtenir plus de pouvoir, peut exécuter n'importe quelle opération. Risque principal:

• Agent évolutif
• Avec une logique d'autodestruction

Mesures de prévention

• Évaluer si le hook est malveillant
• Suivre le comportement de gestion des coûts des hooks sous gestion
• Vérifiez si le hook indépendant est évolutif.

Conclusion

Cet article présente un aperçu des mécanismes clés et des risques de sécurité associés au mécanisme Hook d'Uniswap v4. Bien que le mécanisme Hook soit innovant, il entraîne également de nouveaux défis en matière de sécurité. Les articles suivants analyseront en profondeur les problèmes de sécurité sous chaque modèle de menace.

![Pourquoi dit-on que Hook est une "épée à double tranchant" pour Uniswap V4 ?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp###