Le mécanisme Hook de Uniswap v4 : potentiel et risques coexistent
Uniswap v4 sera bientôt lancé, et cette mise à jour introduit de nombreuses nouvelles fonctionnalités, y compris le support d'un nombre illimité de pools de liquidités par paire de trading et de frais dynamiques, une conception singleton, une comptabilité instantanée, un mécanisme Hook, ainsi que le support de la norme de jetons ERC1155. Parmi celles-ci, le mécanisme Hook a suscité une large 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 des pools de liquidité, améliorant considérablement l'évolutivité et la flexibilité des pools. Cependant, le mécanisme Hook peut également être une épée à double tranchant. Bien qu'il soit puissant et flexible, l'utilisation sécurisée des Hooks représente également un défi non négligeable. La complexité des Hooks entraîne inévitablement de nouveaux vecteurs d'attaque potentiels.
Cet article introduira les concepts liés au mécanisme Hook dans Uniswap v4 et décrira les risques de sécurité associés.
Mécanisme central d'Uniswap v4
Avant d'entrer dans les détails, nous devons avoir une compréhension de base du mécanisme d'Uniswap v4. Selon l'annonce officielle et le livre blanc, Hook, l'architecture singleton et la comptabilité instantanée sont trois fonctionnalités importantes permettant de réaliser des pools de liquidités personnalisés et un routage efficace à travers plusieurs pools.
Mécanisme Hook
Hook désigne un contrat fonctionnant à différentes étapes du cycle de vie d'un pool de liquidités, visant à permettre à quiconque de prendre des décisions équilibrées. De cette manière, il est possible de réaliser un support natif pour des frais dynamiques, d'ajouter des ordres limites sur la chaîne, ou de disperser de grands ordres via un teneur de marché par moyenne pondérée dans le temps (TWAMM).
Actuellement, il y a huit callbacks Hook, répartis en quatre groupes ( chaque groupe contient une paire de callbacks ) :
avantInitialiser/aprèsInitialiser
avantModifierPosition/aprèsModifierPosition
avantÉchange/aprèsÉchange
avantDonner/aprèsDonner
Singleton, comptabilité instantanée et mécanisme de verrouillage
L'architecture singleton et la comptabilité instantanée visent à améliorer les performances en réduisant les coûts et en garantissant l'efficacité. Elle introduit un nouveau contrat singleton, où tous les pools de liquidité sont conservés dans le même contrat intelligent. Ce design singleton repose sur un PoolManager pour stocker et gérer l'état de tous les pools.
La version v4 introduit la comptabilité instantanée et le mécanisme de verrouillage. Le fonctionnement du mécanisme de verrouillage est le suivant :
Le contrat locker demande un lock sur le PoolManager.
PoolManager ajoute l'adresse du contrat locker à la file lockData et appelle son rappel lockAcquired.
Le contrat de locker exécute sa logique dans le rappel. L'interaction avec la piscine pendant l'exécution peut entraîner un accroissement monétaire non nul, mais à la fin de l'exécution, tous les accroissements doivent être réglés à zéro.
PoolManager vérifie l'état de la file d'attente lockData et de l'augmentation de la monnaie. Après vérification, supprimez ce contrat locker.
En général, le mécanisme de verrouillage empêche l'accès simultané et garantit que toutes les transactions peuvent être liquidées. Cette approche signifie que les ajustements opérationnels concernent le solde net interne, plutôt que d'effectuer un transfert instantané. Toute modification sera enregistrée dans le solde interne du pool, tandis que le transfert réel aura lieu à la fin de l'opération.
En raison de l'existence du mécanisme de verrouillage, tous les comptes externes (EOA) ne peuvent pas interagir directement avec PoolManager. Toute interaction doit se faire via un contrat. Il existe principalement deux scénarios d'interaction avec le contrat :
Le contrat locker provient de la bibliothèque de code officielle ou est déployé par l'utilisateur. Cette situation peut être considérée comme une interaction via un routeur.
Les contrats locker et Hook intégrés dans le même contrat, ou contrôlés par une entité tierce. Cette situation peut être considérée comme une interaction via Hook.
Modèle de menace
Avant de discuter des problèmes de sécurité connexes, nous devons déterminer le modèle de menace. Les deux principales situations à considérer sont les suivantes :
Modèle de menace I : Le Hook lui-même est bienveillant, 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
Le modèle de menace I se concentre sur les vulnérabilités liées au Hook lui-même. Ce modèle de menace suppose que le développeur et son Hook ne sont pas malveillants. Cependant, les vulnérabilités connues existantes des contrats intelligents peuvent également apparaître dans le Hook.
Nous choisissons de nous concentrer sur les vulnérabilités potentielles spécifiques à la version v4, en portant principalement attention aux deux types de Hook suivants :
Hook de garde des fonds des utilisateurs. Un attaquant peut cibler ce Hook pour transférer des fonds, entraînant une perte d'actifs.
Hook pour stocker des données d'état critiques nécessaires aux utilisateurs ou à d'autres protocoles. Un attaquant pourrait tenter de modifier des états critiques, ce qui pourrait entraîner des risques potentiels lorsque d'autres utilisateurs ou protocoles utilisent un état erroné.
Après étude, nous avons identifié plusieurs vulnérabilités graves, principalement issues des interactions de risque entre Hook, PoolManager et des tiers externes, pouvant être classées en deux catégories : problèmes de contrôle d'accès et problèmes de validation des entrées.
Problèmes de contrôle d'accès
Les fonctions de rappel dans v4 peuvent poser des problèmes, y compris 8 rappels Hook et des rappels de verrouillage. Ces fonctions ne devraient être appelées que par PoolManager et ne devraient pas être appelées par d'autres adresses. Pour les Hook, il est essentiel d'établir un mécanisme de contrôle d'accès robuste, surtout s'ils peuvent être appelés par d'autres parties en dehors de la piscine elle-même.
Problème de validation d'entrée
Malgré la présence d'un mécanisme de verrouillage, il existe un scénario d'attaque possible, à savoir les appels externes non fiables causés par une validation des entrées incorrecte dans certaines implémentations de Hook vulnérables :
Hook n'a pas vérifié le pool de fonds avec lequel l'utilisateur souhaite interagir. Il pourrait s'agir d'un pool de fonds malveillant contenant des jetons faux et exécutant une logique nuisible.
Certaines fonctions Hook clés permettent des appels externes arbitraires.
Les appels externes non fiables sont extrêmement dangereux et peuvent entraîner divers types d'attaques, y compris des attaques par réentrance.
Mesures de prévention
Pour éviter de tels problèmes de sécurité liés à Hook, il est essentiel de valider les interactions en exécutant correctement les contrôles d'accès nécessaires sur les fonctions externes/publiques sensibles et en validant les paramètres d'entrée. De plus, la protection contre les réentrées peut aider à garantir que Hook n'est pas exécuté plusieurs fois dans le flux de logique standard.
Problèmes de sécurité dans le modèle de menace II
Dans ce modèle de menace, nous supposons que le développeur et son Hook sont malveillants. La clé est de savoir si le Hook fourni peut traiter les transferts d'actifs cryptographiques ou l'autorisation de l'utilisateur.
Selon la méthode d'accès au Hook, nous classons les Hooks en deux catégories :
Hook de type hébergé : Hook n'est pas un point d'entrée. Les utilisateurs doivent interagir avec Hook via le routeur.
Hook autonome : Hook est le point d'entrée, permettant aux utilisateurs d'interagir directement avec lui.
Hook de garde
Les actifs cryptographiques des utilisateurs sont transférés ou autorisés à un routeur. Comme le PoolManager effectue une vérification du solde, il est difficile pour un Hook malveillant de voler directement ces actifs. Cependant, il existe encore des surfaces d'attaque potentielles, par exemple, le mécanisme de gestion des frais de la version v4 pourrait être manipulé par des attaquants via un Hook.
Hook indépendant
Lorsque Hook est utilisé comme point d'entrée, la situation devient plus complexe. Hook a acquis plus de pouvoir et peut théoriquement exécuter n'importe quelle opération souhaitée par le biais de cette interaction.
Dans la version v4, la validation de la logique du code est très importante. Le principal problème réside dans la capacité à manipuler la logique du code. Si le Hook est évolutif, cela signifie qu'un Hook apparemment sûr peut devenir malveillant après une mise à niveau, ce qui représente un risque majeur. Ces risques incluent :
L'agent évolutif ( peut être directement attaqué )
Doté d'une logique d'auto-destruction. Peut être attaqué dans le cas d'un appel conjoint de selfdestruct et de create2.
Mesures de prévention
Un point crucial est d'évaluer si le Hook est malveillant. Plus précisément, pour les Hooks gérés, nous devrions nous concentrer sur les comportements de gestion des frais ; tandis que pour les Hooks indépendants, le principal point d'intérêt est de savoir s'ils sont évolutifs.
Conclusion
Cet article présente un aperçu des mécanismes clés liés aux problèmes de sécurité des Hooks dans Uniswap v4 et propose deux modèles de menaces ainsi que les risques de sécurité associés. Bien que le mécanisme Hook soit puissant, il entraîne également de nouveaux défis en matière de sécurité. Les développeurs et les utilisateurs doivent être pleinement conscients de ces risques potentiels et prendre des mesures de prévention appropriées pour garantir la sécurité des actifs lors de l'utilisation d'Uniswap v4.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
10 J'aime
Récompense
10
6
Partager
Commentaire
0/400
NightAirdropper
· 08-06 06:42
Jouer jusqu'à la fin
Voir l'originalRépondre0
WenAirdrop
· 08-05 22:14
Le potentiel est vraiment grand.
Voir l'originalRépondre0
consensus_failure
· 08-05 22:11
La sécurité avant tout.
Voir l'originalRépondre0
CryptoPhoenix
· 08-05 22:06
Le risque est une nouvelle naissance
Voir l'originalRépondre0
GateUser-74b10196
· 08-05 22:05
Pas étonnant que ce soit une mise à jour épique.
Voir l'originalRépondre0
LayerZeroHero
· 08-05 22:02
Les nouvelles fonctionnalités sont très dangereuses.
Mécanisme Hook de Uniswap v4 : défis de sécurité derrière des fonctionnalités puissantes
Le mécanisme Hook de Uniswap v4 : potentiel et risques coexistent
Uniswap v4 sera bientôt lancé, et cette mise à jour introduit de nombreuses nouvelles fonctionnalités, y compris le support d'un nombre illimité de pools de liquidités par paire de trading et de frais dynamiques, une conception singleton, une comptabilité instantanée, un mécanisme Hook, ainsi que le support de la norme de jetons ERC1155. Parmi celles-ci, le mécanisme Hook a suscité une large 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 des pools de liquidité, améliorant considérablement l'évolutivité et la flexibilité des pools. Cependant, le mécanisme Hook peut également être une épée à double tranchant. Bien qu'il soit puissant et flexible, l'utilisation sécurisée des Hooks représente également un défi non négligeable. La complexité des Hooks entraîne inévitablement de nouveaux vecteurs d'attaque potentiels.
Cet article introduira les concepts liés au mécanisme Hook dans Uniswap v4 et décrira les risques de sécurité associés.
Mécanisme central d'Uniswap v4
Avant d'entrer dans les détails, nous devons avoir une compréhension de base du mécanisme d'Uniswap v4. Selon l'annonce officielle et le livre blanc, Hook, l'architecture singleton et la comptabilité instantanée sont trois fonctionnalités importantes permettant de réaliser des pools de liquidités personnalisés et un routage efficace à travers plusieurs pools.
Mécanisme Hook
Hook désigne un contrat fonctionnant à différentes étapes du cycle de vie d'un pool de liquidités, visant à permettre à quiconque de prendre des décisions équilibrées. De cette manière, il est possible de réaliser un support natif pour des frais dynamiques, d'ajouter des ordres limites sur la chaîne, ou de disperser de grands ordres via un teneur de marché par moyenne pondérée dans le temps (TWAMM).
Actuellement, il y a huit callbacks Hook, répartis en quatre groupes ( chaque groupe contient une paire de callbacks ) :
Singleton, comptabilité instantanée et mécanisme de verrouillage
L'architecture singleton et la comptabilité instantanée visent à améliorer les performances en réduisant les coûts et en garantissant l'efficacité. Elle introduit un nouveau contrat singleton, où tous les pools de liquidité sont conservés dans le même contrat intelligent. Ce design singleton repose sur un PoolManager pour stocker et gérer l'état de tous les pools.
La version v4 introduit la comptabilité instantanée et le mécanisme de verrouillage. Le fonctionnement du mécanisme de verrouillage est le suivant :
Le contrat locker demande un lock sur le PoolManager.
PoolManager ajoute l'adresse du contrat locker à la file lockData et appelle son rappel lockAcquired.
Le contrat de locker exécute sa logique dans le rappel. L'interaction avec la piscine pendant l'exécution peut entraîner un accroissement monétaire non nul, mais à la fin de l'exécution, tous les accroissements doivent être réglés à zéro.
PoolManager vérifie l'état de la file d'attente lockData et de l'augmentation de la monnaie. Après vérification, supprimez ce contrat locker.
En général, le mécanisme de verrouillage empêche l'accès simultané et garantit que toutes les transactions peuvent être liquidées. Cette approche signifie que les ajustements opérationnels concernent le solde net interne, plutôt que d'effectuer un transfert instantané. Toute modification sera enregistrée dans le solde interne du pool, tandis que le transfert réel aura lieu à la fin de l'opération.
En raison de l'existence du mécanisme de verrouillage, tous les comptes externes (EOA) ne peuvent pas interagir directement avec PoolManager. Toute interaction doit se faire via un contrat. Il existe principalement deux scénarios d'interaction avec le contrat :
Le contrat locker provient de la bibliothèque de code officielle ou est déployé par l'utilisateur. Cette situation peut être considérée comme une interaction via un routeur.
Les contrats locker et Hook intégrés dans le même contrat, ou contrôlés par une entité tierce. Cette situation peut être considérée comme une interaction via Hook.
Modèle de menace
Avant de discuter des problèmes de sécurité connexes, nous devons déterminer le modèle de menace. Les deux principales situations à considérer sont les suivantes :
Problèmes de sécurité dans le modèle de menace I
Le modèle de menace I se concentre sur les vulnérabilités liées au Hook lui-même. Ce modèle de menace suppose que le développeur et son Hook ne sont pas malveillants. Cependant, les vulnérabilités connues existantes des contrats intelligents peuvent également apparaître dans le Hook.
Nous choisissons de nous concentrer sur les vulnérabilités potentielles spécifiques à la version v4, en portant principalement attention aux deux types de Hook suivants :
Hook de garde des fonds des utilisateurs. Un attaquant peut cibler ce Hook pour transférer des fonds, entraînant une perte d'actifs.
Hook pour stocker des données d'état critiques nécessaires aux utilisateurs ou à d'autres protocoles. Un attaquant pourrait tenter de modifier des états critiques, ce qui pourrait entraîner des risques potentiels lorsque d'autres utilisateurs ou protocoles utilisent un état erroné.
Après étude, nous avons identifié plusieurs vulnérabilités graves, principalement issues des interactions de risque entre Hook, PoolManager et des tiers externes, pouvant être classées en deux catégories : problèmes de contrôle d'accès et problèmes de validation des entrées.
Problèmes de contrôle d'accès
Les fonctions de rappel dans v4 peuvent poser des problèmes, y compris 8 rappels Hook et des rappels de verrouillage. Ces fonctions ne devraient être appelées que par PoolManager et ne devraient pas être appelées par d'autres adresses. Pour les Hook, il est essentiel d'établir un mécanisme de contrôle d'accès robuste, surtout s'ils peuvent être appelés par d'autres parties en dehors de la piscine elle-même.
Problème de validation d'entrée
Malgré la présence d'un mécanisme de verrouillage, il existe un scénario d'attaque possible, à savoir les appels externes non fiables causés par une validation des entrées incorrecte dans certaines implémentations de Hook vulnérables :
Hook n'a pas vérifié le pool de fonds avec lequel l'utilisateur souhaite interagir. Il pourrait s'agir d'un pool de fonds malveillant contenant des jetons faux et exécutant une logique nuisible.
Certaines fonctions Hook clés permettent des appels externes arbitraires.
Les appels externes non fiables sont extrêmement dangereux et peuvent entraîner divers types d'attaques, y compris des attaques par réentrance.
Mesures de prévention
Pour éviter de tels problèmes de sécurité liés à Hook, il est essentiel de valider les interactions en exécutant correctement les contrôles d'accès nécessaires sur les fonctions externes/publiques sensibles et en validant les paramètres d'entrée. De plus, la protection contre les réentrées peut aider à garantir que Hook n'est pas exécuté plusieurs fois dans le flux de logique standard.
Problèmes de sécurité dans le modèle de menace II
Dans ce modèle de menace, nous supposons que le développeur et son Hook sont malveillants. La clé est de savoir si le Hook fourni peut traiter les transferts d'actifs cryptographiques ou l'autorisation de l'utilisateur.
Selon la méthode d'accès au Hook, nous classons les Hooks en deux catégories :
Hook de type hébergé : Hook n'est pas un point d'entrée. Les utilisateurs doivent interagir avec Hook via le routeur.
Hook autonome : Hook est le point d'entrée, permettant aux utilisateurs d'interagir directement avec lui.
Hook de garde
Les actifs cryptographiques des utilisateurs sont transférés ou autorisés à un routeur. Comme le PoolManager effectue une vérification du solde, il est difficile pour un Hook malveillant de voler directement ces actifs. Cependant, il existe encore des surfaces d'attaque potentielles, par exemple, le mécanisme de gestion des frais de la version v4 pourrait être manipulé par des attaquants via un Hook.
Hook indépendant
Lorsque Hook est utilisé comme point d'entrée, la situation devient plus complexe. Hook a acquis plus de pouvoir et peut théoriquement exécuter n'importe quelle opération souhaitée par le biais de cette interaction.
Dans la version v4, la validation de la logique du code est très importante. Le principal problème réside dans la capacité à manipuler la logique du code. Si le Hook est évolutif, cela signifie qu'un Hook apparemment sûr peut devenir malveillant après une mise à niveau, ce qui représente un risque majeur. Ces risques incluent :
Mesures de prévention
Un point crucial est d'évaluer si le Hook est malveillant. Plus précisément, pour les Hooks gérés, nous devrions nous concentrer sur les comportements de gestion des frais ; tandis que pour les Hooks indépendants, le principal point d'intérêt est de savoir s'ils sont évolutifs.
Conclusion
Cet article présente un aperçu des mécanismes clés liés aux problèmes de sécurité des Hooks dans Uniswap v4 et propose deux modèles de menaces ainsi que les risques de sécurité associés. Bien que le mécanisme Hook soit puissant, il entraîne également de nouveaux défis en matière de sécurité. Les développeurs et les utilisateurs doivent être pleinement conscients de ces risques potentiels et prendre des mesures de prévention appropriées pour garantir la sécurité des actifs lors de l'utilisation d'Uniswap v4.