Le lancement de Uniswap v4 approche, le mécanisme Hook cache des risques de sécurité
Uniswap v4 sera bientôt lancé. 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 des frais dynamiques, un design singleton, une comptabilité instantanée, le mécanisme Hook, ainsi que le support de la norme de jeton ERC1155. La v4 devrait être lancée après la mise à niveau Cancun d'Ethereum.
Parmi de nombreuses innovations, le mécanisme Hook attire l'attention en raison de son potentiel puissant. Il permet d'exécuter du code personnalisé à des moments spécifiques du cycle de vie d'un pool de liquidité, ce qui renforce considérablement l'évolutivité et la flexibilité du pool.
Cependant, le mécanisme Hook peut également être une arme à double tranchant. Bien qu'il soit puissant et flexible, l'utilisation sécurisée de Hook fait également face à des défis. La complexité de Hook entraîne inévitablement de nouveaux vecteurs d'attaque potentiels. Par conséquent, il est particulièrement important d'introduire systématiquement les problèmes de sécurité et les risques potentiels associés au mécanisme Hook, ce qui aidera à construire un Hook Uniswap v4 plus sûr.
Cet article présentera les concepts liés au mécanisme Hook dans Uniswap v4 et décrira les risques de sécurité associés.
Le mécanisme 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 monolithique et la comptabilité instantanée sont trois fonctionnalités clés permettant de réaliser des pools de liquidité personnalisés et un routage efficace à travers plusieurs pools.
Crochet
Hook désigne un contrat fonctionnant à différentes étapes du cycle de vie d'un pool de liquidités. L'équipe Uniswap espère qu'en introduisant Hook, cela permettra à quiconque de prendre des décisions d'équilibre. Cette approche peut permettre un soutien natif pour des frais dynamiques, l'ajout d'ordres limites sur la chaîne, ou la réalisation 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 ( chaque groupe contenant une paire de rappels ) :
avantInitialiser/aprèsInitialiser
avantModifierPosition/aprèsModifierPosition
avantÉchange/aprèsÉchange
avantDon/ aprèsDon
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 s'appuie 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 PoolManager.
PoolManager ajoute l'adresse du contrat locker à la file d'attente lockData et appelle son rappel lockAcquired.
Le contrat locker exécute sa logique dans le rappel. Pendant l'exécution, l'interaction du contrat locker avec la piscine peut entraîner un accroissement monétaire non nul. Cependant, à la fin de l'exécution, tous les accroissements doivent être réglés à zéro. De plus, si la file d'attente lockData n'est pas vide, seul le dernier contrat locker peut exécuter l'opération.
PoolManager vérifie l'état de la file d'attente lockData et de l'incrément de monnaie. Après vérification, PoolManager supprimera ce contrat de locker.
En résumé, le mécanisme de verrouillage empêche l'accès concurrent et garantit que toutes les transactions peuvent être liquidées. Le contrat de verrouillage demande un verrou dans l'ordre, puis exécute la transaction via le rappel lockAcquired. Avant et après chaque opération de pool, les rappels Hook correspondants seront déclenchés. Enfin, le PoolManager vérifiera l'état.
Cette méthode signifie que l'ajustement opérationnel concerne le solde net interne (, c'est-à-dire delta ), et non l'exécution d'un transfert immédiat. Toute modification sera enregistrée dans le solde interne de la piscine, tandis que le véritable transfert se fera à la fin de l'opération (, c'est-à-dire lock ). Ce processus garantit qu'il n'y a pas de jetons non réglés, maintenant ainsi l'intégrité des fonds.
En raison de l'existence du mécanisme de verrouillage, tous les comptes externes (EOA) ne peuvent pas interagir directement avec PoolManager. Au contraire, toute interaction doit passer par un contrat. Ce contrat sert de locker intermédiaire et doit demander un verrou avant d'effectuer toute opération sur le pool.
Il existe principalement deux scénarios d'interaction de contrat :
Le contrat locker provient de la bibliothèque de code officielle ou est déployé par l'utilisateur. Dans ce cas, nous pouvons considérer l'interaction comme se faisant via un routeur.
le contrat locker et Hook intégrés dans le même contrat, ou contrôlés par une entité tierce. Dans ce cas, nous pouvons considérer l'interaction comme se faisant via Hook. Dans ce cas, Hook joue à la fois le rôle du contrat locker et est responsable du traitement des rappels.
Modèle de menace
Avant de discuter des problèmes de sécurité pertinents, nous devons définir le modèle de menace. Nous considérons principalement les deux cas suivants :
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.
Dans la partie suivante, nous discuterons des problèmes de sécurité potentiels en fonction de ces deux modèles de menace.
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 les développeurs et leur Hook sont de bonne foi. 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 propres à la version v4. Dans Uniswap v4, Hook est un contrat intelligent capable d'exécuter une logique personnalisée avant ou après l'opération sur le pool central (, y compris l'initialisation, la modification de position, l'échange et la collecte de ). Bien que Hook devrait mettre en œuvre des interfaces standard, il permet également d'inclure une logique personnalisée. Par conséquent, notre discussion sera limitée à la logique impliquant l'interface Hook standard. Ensuite, nous tenterons d'identifier les sources potentielles de vulnérabilités, par exemple, comment Hook pourrait abuser de ces fonctions standard Hook.
Plus précisément, nous allons nous concentrer sur les deux types de Hook suivants :
Le premier type de hook, la garde des fonds des utilisateurs. Dans ce cas, un attaquant pourrait cibler ce hook pour transférer des fonds, entraînant une perte d'actifs.
Deuxième type de hook, stocker des données d'état clés dont dépendent les utilisateurs ou d'autres protocoles. Dans ce cas, un attaquant pourrait essayer de modifier l'état clé. Lorsque d'autres utilisateurs ou protocoles utilisent un état erroné, cela peut entraîner des risques potentiels.
Après une étude approfondie du dépôt Awesome Uniswap v4 Hooks, nous avons découvert plusieurs vulnérabilités graves. Ces vulnérabilités proviennent principalement des interactions à risque entre hook, PoolManager et des tiers externes, et peuvent être principalement classées en deux catégories : problèmes de contrôle d'accès et problèmes de validation des entrées.
Dans l'ensemble, nous avons identifié 22 projets pertinents ( en excluant les projets non liés à Uniswap v4 ). Parmi ces projets, nous estimons que 8 (36%) présentent des vulnérabilités. Parmi ces 8 projets vulnérables, 6 présentent des problèmes de contrôle d'accès et 2 sont susceptibles d'être affectés par des appels externes non fiables.
Problèmes de contrôle d'accès
Dans cette partie de la discussion, nous nous concentrons principalement sur les problèmes que les fonctions de rappel dans la v4 pourraient poser, y compris 8 rappels hook et le rappel lock. Ces fonctions ne devraient pouvoir être appelées que par PoolManager et non par d'autres adresses (, y compris EOA et contrats ). Par exemple, dans le cas où les récompenses sont distribuées par la clé du pool de fonds, si la fonction correspondante peut être appelée par n'importe quel compte, alors les récompenses pourraient être perçues de manière incorrecte.
Il est donc crucial pour les hooks 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 pool elle-même. En gérant strictement les autorisations d'accès, les pools de liquidités peuvent réduire considérablement les risques d'interactions non autorisées ou malveillantes avec les hooks.
Problème de vérification d'entrée
Dans Uniswap v4, en raison du mécanisme de verrouillage, les utilisateurs doivent obtenir un lock via le contrat avant d'effectuer toute opération de pool de liquidités. Cela garantit que le contrat participant actuellement à l'interaction est le contrat de verrouillage le plus récent.
Néanmoins, il existe un scénario d'attaque possible, à savoir des appels externes non fiables dus à une validation des entrées incorrecte dans certaines implémentations de Hook vulnérables :
Tout d'abord, le hook n'a pas vérifié le pool de liquidités avec lequel l'utilisateur souhaite interagir. Cela pourrait être un pool malveillant contenant des jetons frauduleux et exécutant une logique nuisible.
Deuxièmement, certaines fonctions hook clés permettent des appels externes arbitraires.
Les appels externes non fiables sont extrêmement dangereux, car ils peuvent entraîner divers types d'attaques, y compris les attaques par réentrance que nous connaissons bien.
Pour attaquer ces hooks vulnérables, un attaquant peut enregistrer un pool de fonds malveillant pour son jeton fictif, puis appeler le hook pour exécuter des opérations dans le pool de fonds. Lors de l'interaction avec le pool de fonds, la logique du jeton malveillant détourne le flux de contrôle pour mener à des actions nuisibles.
Mesures de prévention contre le modèle de menace I
Pour éviter de tels problèmes de sécurité liés aux hooks, il est essentiel d'effectuer un contrôle d'accès nécessaire sur les fonctions externes/publiques sensibles et de valider les paramètres d'entrée afin de vérifier les interactions. De plus, la protection contre les réentrées peut aider à garantir que les hooks ne soient pas exécutés plusieurs fois dans le flux logique standard. En mettant en œuvre des mesures de sécurité appropriées, le fonds de liquidités peut réduire les risques associés à de telles menaces.
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. Étant donné l'ampleur des implications, nous nous concentrons uniquement sur les problèmes de sécurité liés à la version v4. Par conséquent, la clé réside dans la capacité du hook fourni à gérer les actifs cryptographiques des utilisateurs lors des transferts ou des autorisations.
Étant donné que la méthode d'accès au hook détermine les autorisations qui peuvent être accordées au hook, nous classons les hooks en deux catégories :
Hook géré ( Managed Hooks ) : le hook n'est pas un point d'entrée. Les utilisateurs doivent interagir avec le hook via le routeur ( qui peut être fourni par Uniswap ).
Crochets autonomes( : le crochet est un point d'entrée qui permet aux utilisateurs d'interagir directement.
)# Hook de type gardien
Dans ce cas, les actifs cryptographiques de l'utilisateur ### comprennent des jetons natifs et d'autres jetons ( qui sont transférés ou autorisés au router. Étant donné que le PoolManager effectue une vérification des soldes, un hook malveillant n'est pas facile à utiliser pour 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 un attaquant via un hook.
)# Crochet indépendant
Lorsque Hook est utilisé comme point d'entrée, la situation devient plus complexe. Dans ce cas, étant donné que les utilisateurs peuvent interagir directement avec le hook, celui-ci obtient plus de pouvoir. Théoriquement, le hook peut exécuter n'importe quelle opération souhaitée grâce à cette interaction.
Dans la version v4, la vérification de la logique du code est très importante. Le principal problème est de savoir si la logique du code peut être manipulée. Si le hook est upgradable, cela signifie qu'un hook apparemment sûr peut devenir malveillant après une mise à niveau, ce qui constitue un risque majeur. Ces risques incluent :
L'agent évolutif ### peut être attaqué directement (；
Dispose d'une logique d'auto-destruction. Peut être attaqué dans le cas d'un appel conjoint à selfdestruct et create2.
)# Mesures de prévention pour le modèle de menace II
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 le comportement de gestion des frais ; tandis que pour les hooks indépendants, le principal point d'attention est de savoir s'ils sont évolutifs.
![Pourquoi dit-on que Hook est une "épée à double tranchant" pour Uniswap V4 ?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Conclusion
Cet article résume les mécanismes clés liés aux problèmes de sécurité des hooks d'Uniswap v4, propose deux modèles de menaces et décrit les risques de sécurité associés.
Dans les articles suivants, nous allons analyser en profondeur les problèmes de sécurité sous chaque modèle de menace.
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.
Le mécanisme Hook de Uniswap v4 présente des vulnérabilités de sécurité, les experts recommandent une utilisation prudente.
Le lancement de Uniswap v4 approche, le mécanisme Hook cache des risques de sécurité
Uniswap v4 sera bientôt lancé. 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 des frais dynamiques, un design singleton, une comptabilité instantanée, le mécanisme Hook, ainsi que le support de la norme de jeton ERC1155. La v4 devrait être lancée après la mise à niveau Cancun d'Ethereum.
Parmi de nombreuses innovations, le mécanisme Hook attire l'attention en raison de son potentiel puissant. Il permet d'exécuter du code personnalisé à des moments spécifiques du cycle de vie d'un pool de liquidité, ce qui renforce considérablement l'évolutivité et la flexibilité du pool.
Cependant, le mécanisme Hook peut également être une arme à double tranchant. Bien qu'il soit puissant et flexible, l'utilisation sécurisée de Hook fait également face à des défis. La complexité de Hook entraîne inévitablement de nouveaux vecteurs d'attaque potentiels. Par conséquent, il est particulièrement important d'introduire systématiquement les problèmes de sécurité et les risques potentiels associés au mécanisme Hook, ce qui aidera à construire un Hook Uniswap v4 plus sûr.
Cet article présentera les concepts liés au mécanisme Hook dans Uniswap v4 et décrira les risques de sécurité associés.
Le mécanisme 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 monolithique et la comptabilité instantanée sont trois fonctionnalités clés permettant de réaliser des pools de liquidité personnalisés et un routage efficace à travers plusieurs pools.
Crochet
Hook désigne un contrat fonctionnant à différentes étapes du cycle de vie d'un pool de liquidités. L'équipe Uniswap espère qu'en introduisant Hook, cela permettra à quiconque de prendre des décisions d'équilibre. Cette approche peut permettre un soutien natif pour des frais dynamiques, l'ajout d'ordres limites sur la chaîne, ou la réalisation 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 ( chaque groupe contenant une paire de rappels ) :
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 s'appuie 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 PoolManager.
PoolManager ajoute l'adresse du contrat locker à la file d'attente lockData et appelle son rappel lockAcquired.
Le contrat locker exécute sa logique dans le rappel. Pendant l'exécution, l'interaction du contrat locker avec la piscine peut entraîner un accroissement monétaire non nul. Cependant, à la fin de l'exécution, tous les accroissements doivent être réglés à zéro. De plus, si la file d'attente lockData n'est pas vide, seul le dernier contrat locker peut exécuter l'opération.
PoolManager vérifie l'état de la file d'attente lockData et de l'incrément de monnaie. Après vérification, PoolManager supprimera ce contrat de locker.
En résumé, le mécanisme de verrouillage empêche l'accès concurrent et garantit que toutes les transactions peuvent être liquidées. Le contrat de verrouillage demande un verrou dans l'ordre, puis exécute la transaction via le rappel lockAcquired. Avant et après chaque opération de pool, les rappels Hook correspondants seront déclenchés. Enfin, le PoolManager vérifiera l'état.
Cette méthode signifie que l'ajustement opérationnel concerne le solde net interne (, c'est-à-dire delta ), et non l'exécution d'un transfert immédiat. Toute modification sera enregistrée dans le solde interne de la piscine, tandis que le véritable transfert se fera à la fin de l'opération (, c'est-à-dire lock ). Ce processus garantit qu'il n'y a pas de jetons non réglés, maintenant ainsi l'intégrité des fonds.
En raison de l'existence du mécanisme de verrouillage, tous les comptes externes (EOA) ne peuvent pas interagir directement avec PoolManager. Au contraire, toute interaction doit passer par un contrat. Ce contrat sert de locker intermédiaire et doit demander un verrou avant d'effectuer toute opération sur le pool.
Il existe principalement deux scénarios d'interaction de contrat :
Le contrat locker provient de la bibliothèque de code officielle ou est déployé par l'utilisateur. Dans ce cas, nous pouvons considérer l'interaction comme se faisant via un routeur.
le contrat locker et Hook intégrés dans le même contrat, ou contrôlés par une entité tierce. Dans ce cas, nous pouvons considérer l'interaction comme se faisant via Hook. Dans ce cas, Hook joue à la fois le rôle du contrat locker et est responsable du traitement des rappels.
Modèle de menace
Avant de discuter des problèmes de sécurité pertinents, nous devons définir le modèle de menace. Nous considérons principalement les deux cas suivants :
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.
Dans la partie suivante, nous discuterons des problèmes de sécurité potentiels en fonction de ces deux modèles de menace.
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 les développeurs et leur Hook sont de bonne foi. 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 propres à la version v4. Dans Uniswap v4, Hook est un contrat intelligent capable d'exécuter une logique personnalisée avant ou après l'opération sur le pool central (, y compris l'initialisation, la modification de position, l'échange et la collecte de ). Bien que Hook devrait mettre en œuvre des interfaces standard, il permet également d'inclure une logique personnalisée. Par conséquent, notre discussion sera limitée à la logique impliquant l'interface Hook standard. Ensuite, nous tenterons d'identifier les sources potentielles de vulnérabilités, par exemple, comment Hook pourrait abuser de ces fonctions standard Hook.
Plus précisément, nous allons nous concentrer sur les deux types de Hook suivants :
Le premier type de hook, la garde des fonds des utilisateurs. Dans ce cas, un attaquant pourrait cibler ce hook pour transférer des fonds, entraînant une perte d'actifs.
Deuxième type de hook, stocker des données d'état clés dont dépendent les utilisateurs ou d'autres protocoles. Dans ce cas, un attaquant pourrait essayer de modifier l'état clé. Lorsque d'autres utilisateurs ou protocoles utilisent un état erroné, cela peut entraîner des risques potentiels.
Après une étude approfondie du dépôt Awesome Uniswap v4 Hooks, nous avons découvert plusieurs vulnérabilités graves. Ces vulnérabilités proviennent principalement des interactions à risque entre hook, PoolManager et des tiers externes, et peuvent être principalement classées en deux catégories : problèmes de contrôle d'accès et problèmes de validation des entrées.
Dans l'ensemble, nous avons identifié 22 projets pertinents ( en excluant les projets non liés à Uniswap v4 ). Parmi ces projets, nous estimons que 8 (36%) présentent des vulnérabilités. Parmi ces 8 projets vulnérables, 6 présentent des problèmes de contrôle d'accès et 2 sont susceptibles d'être affectés par des appels externes non fiables.
Problèmes de contrôle d'accès
Dans cette partie de la discussion, nous nous concentrons principalement sur les problèmes que les fonctions de rappel dans la v4 pourraient poser, y compris 8 rappels hook et le rappel lock. Ces fonctions ne devraient pouvoir être appelées que par PoolManager et non par d'autres adresses (, y compris EOA et contrats ). Par exemple, dans le cas où les récompenses sont distribuées par la clé du pool de fonds, si la fonction correspondante peut être appelée par n'importe quel compte, alors les récompenses pourraient être perçues de manière incorrecte.
Il est donc crucial pour les hooks 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 pool elle-même. En gérant strictement les autorisations d'accès, les pools de liquidités peuvent réduire considérablement les risques d'interactions non autorisées ou malveillantes avec les hooks.
Problème de vérification d'entrée
Dans Uniswap v4, en raison du mécanisme de verrouillage, les utilisateurs doivent obtenir un lock via le contrat avant d'effectuer toute opération de pool de liquidités. Cela garantit que le contrat participant actuellement à l'interaction est le contrat de verrouillage le plus récent.
Néanmoins, il existe un scénario d'attaque possible, à savoir des appels externes non fiables dus à une validation des entrées incorrecte dans certaines implémentations de Hook vulnérables :
Tout d'abord, le hook n'a pas vérifié le pool de liquidités avec lequel l'utilisateur souhaite interagir. Cela pourrait être un pool malveillant contenant des jetons frauduleux et exécutant une logique nuisible.
Deuxièmement, certaines fonctions hook clés permettent des appels externes arbitraires.
Les appels externes non fiables sont extrêmement dangereux, car ils peuvent entraîner divers types d'attaques, y compris les attaques par réentrance que nous connaissons bien.
Pour attaquer ces hooks vulnérables, un attaquant peut enregistrer un pool de fonds malveillant pour son jeton fictif, puis appeler le hook pour exécuter des opérations dans le pool de fonds. Lors de l'interaction avec le pool de fonds, la logique du jeton malveillant détourne le flux de contrôle pour mener à des actions nuisibles.
Mesures de prévention contre le modèle de menace I
Pour éviter de tels problèmes de sécurité liés aux hooks, il est essentiel d'effectuer un contrôle d'accès nécessaire sur les fonctions externes/publiques sensibles et de valider les paramètres d'entrée afin de vérifier les interactions. De plus, la protection contre les réentrées peut aider à garantir que les hooks ne soient pas exécutés plusieurs fois dans le flux logique standard. En mettant en œuvre des mesures de sécurité appropriées, le fonds de liquidités peut réduire les risques associés à de telles menaces.
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. Étant donné l'ampleur des implications, nous nous concentrons uniquement sur les problèmes de sécurité liés à la version v4. Par conséquent, la clé réside dans la capacité du hook fourni à gérer les actifs cryptographiques des utilisateurs lors des transferts ou des autorisations.
Étant donné que la méthode d'accès au hook détermine les autorisations qui peuvent être accordées au hook, nous classons les hooks en deux catégories :
Hook géré ( Managed Hooks ) : le hook n'est pas un point d'entrée. Les utilisateurs doivent interagir avec le hook via le routeur ( qui peut être fourni par Uniswap ).
Crochets autonomes( : le crochet est un point d'entrée qui permet aux utilisateurs d'interagir directement.
)# Hook de type gardien
Dans ce cas, les actifs cryptographiques de l'utilisateur ### comprennent des jetons natifs et d'autres jetons ( qui sont transférés ou autorisés au router. Étant donné que le PoolManager effectue une vérification des soldes, un hook malveillant n'est pas facile à utiliser pour 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 un attaquant via un hook.
)# Crochet indépendant
Lorsque Hook est utilisé comme point d'entrée, la situation devient plus complexe. Dans ce cas, étant donné que les utilisateurs peuvent interagir directement avec le hook, celui-ci obtient plus de pouvoir. Théoriquement, le hook peut exécuter n'importe quelle opération souhaitée grâce à cette interaction.
Dans la version v4, la vérification de la logique du code est très importante. Le principal problème est de savoir si la logique du code peut être manipulée. Si le hook est upgradable, cela signifie qu'un hook apparemment sûr peut devenir malveillant après une mise à niveau, ce qui constitue un risque majeur. Ces risques incluent :
L'agent évolutif ### peut être attaqué directement (；
Dispose d'une logique d'auto-destruction. Peut être attaqué dans le cas d'un appel conjoint à selfdestruct et create2.
)# Mesures de prévention pour le modèle de menace II
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 le comportement de gestion des frais ; tandis que pour les hooks indépendants, le principal point d'attention est de savoir s'ils sont évolutifs.
![Pourquoi dit-on que Hook est une "épée à double tranchant" pour Uniswap V4 ?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Conclusion
Cet article résume les mécanismes clés liés aux problèmes de sécurité des hooks d'Uniswap v4, propose deux modèles de menaces et décrit les risques de sécurité associés.
Dans les articles suivants, nous allons analyser en profondeur les problèmes de sécurité sous chaque modèle de menace.