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

Uniswap v4 sera bientôt lancé, cette mise à jour introduira plusieurs innovations majeures, y compris le support d'un nombre illimité de pools de liquidités et de frais dynamiques, un design singleton, une comptabilité instantanée, un mécanisme Hook, ainsi que le support de la norme de jeton ERC1155. Parmi ces innovations, le mécanisme Hook est particulièrement remarqué pour sa grande extensibilité et sa flexibilité.

Le mécanisme Hook permet d'exécuter du code personnalisé à des nœuds spécifiques du cycle de vie du pool de liquidités, ce qui améliore considérablement l'évolutivité et la flexibilité du pool. Cependant, cette fonctionnalité puissante entraîne également de nouveaux défis en matière de sécurité. Cet article présentera systématiquement les problèmes de sécurité et les risques potentiels liés au mécanisme Hook, afin de promouvoir la construction d'un Uniswap v4 Hook plus sûr par la communauté.

Mécanisme principal de Uniswap V4

Avant d'entrer dans les détails, nous devons avoir une compréhension de base des mécanismes clés de Uniswap v4. Les Hooks, l'architecture singleton et la comptabilité instantanée sont trois fonctionnalités essentielles permettant de réaliser des pools de liquidités personnalisés et un routage inter-pools efficace.

Mécanisme Hook

Hook est un contrat qui fonctionne à différentes étapes du cycle de vie des pools de liquidités. En introduisant Hook, l'équipe d'Uniswap espère réaliser des décisions d'équilibre plus flexibles. 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

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

L'architecture singleton et la comptabilité lightning visent à améliorer la performance en réduisant les coûts et en augmentant l'efficacité. Le nouveau contrat singleton PoolManager a été introduit pour stocker et gérer l'état de tous les pools.

Le flux de travail du système de comptabilité par éclair et du mécanisme de verrouillage est le suivant :

1. Le contrat locker demande un lock au PoolManager
2. PoolManager ajoute l'adresse du locker à la file d'attente et appelle son callback lockAcquired.
3. le locker exécute la logique dans le rappel, l'interaction avec le pool peut entraîner un accroissement monétaire non nul
4. PoolManager vérifie l'état de la file d'attente et des augmentations de monnaie, puis supprime le locker après validation.

Ce mécanisme garantit que toutes les transactions peuvent être réglées, maintenant l'intégrité des fonds. En raison de l'existence du mécanisme de verrouillage, les comptes externes ne peuvent pas interagir directement avec le PoolManager, mais 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 sur les vulnérabilités potentielles spécifiques à la version v4, qui se divisent principalement en deux catégories :

• Problème de contrôle d'accès : La fonction de rappel Hook peut être appelée par des personnes non autorisées.
• Problème de validation des entrées : Une validation incorrecte des entrées dans l'implémentation de Hook entraîne des appels externes non fiables.

Ces problèmes peuvent entraîner des pertes financières ou une altération de l'état critique.

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

Selon le mode d'accès de Hook, on peut diviser en :

• Hook de type hébergé : les utilisateurs interagissent avec Hook via le routeur
• Hook autonome : les utilisateurs peuvent interagir directement avec le Hook

Les hooks de type hébergé sont difficiles à utiliser pour voler des actifs, mais peuvent manipuler le mécanisme de gestion des frais. Les hooks autonomes obtiennent plus de permissions, et s'ils sont évolutifs, des risques de sécurité importants existent.

Mesures de prévention

Pour le modèle de menace I, des contrôles d'accès appropriés et une validation des entrées doivent être mis en œuvre, et la protection contre la réentrance doit être prise en compte.

Pour le modèle de menace II, il est nécessaire d'évaluer si le Hook est malveillant. Pour les Hooks gérés, il faut se concentrer sur la gestion des coûts, tandis que pour les Hooks indépendants, il faut vérifier s'ils sont évolutifs.

Construire un Hook sécurisé pour Uniswap v4 nécessite un effort conjoint des développeurs et des utilisateurs, cherchant un équilibre entre innovation et sécurité. À l'avenir, nous effectuerons une analyse plus approfondie des problèmes de sécurité dans chaque modèle de menace.