Uniswap V4 Singleton : Comment ça marche ? (Aperçu technique)

Architecture de base d'Uniswap V4 Singleton

1. Uniswap V4 introduit un contrat déployé unique connu sous le nom de Singleton , remplaçant le modèle de déploiement par pool utilisé dans les versions précédentes.

2. Cette conception élimine la duplication de code redondante entre les pools et permet la création de pools dynamiques sans nouveaux déploiements de contrat.

3. Le Singleton agit comme un registre central, stockant tous les états du pool dans ses propres emplacements de stockage à l'aide d'un schéma de dérivation d'adresses déterministe.

4. Chaque pool est identifié par une clé unique composée d'adresses de jetons, de niveaux de frais et de paramètres de hook facultatifs, permettant une identification précise en chaîne sans indexation externe.

5. La disposition du stockage est optimisée avec des structures compressées et une manipulation au niveau des bits pour minimiser les frais généraux de gaz lors des opérations de swap et de liquidité.

Mécanisme d'intégration de crochet

1. Les hooks sont des modules logiques arbitraires que les développeurs peuvent attacher à des pools spécifiques au moment de la création, exécutés avant ou après les événements de swap de base et de liquidité.

2. Un hook doit être conforme à une interface prédéfinie et être pré-approuvé par le module de gouvernance avant enregistrement dans le registre hook de Singleton.

3. L'exécution se produit via un appel délégué à partir du contexte Singleton, préservant l'accès au stockage spécifique au pool tout en isolant l'état du hook.

4. Les rappels Hook reçoivent des données d'entrée structurées, notamment les montants des swaps, l'impact sur les prix et les limites des ticks, ce qui permet des points d'intervention précis.

5. Plusieurs hooks peuvent être chaînés pour un seul pool, avec un ordre d'exécution déterminé par leur séquence d'enregistrement et appliqué via une validation interne de la pile d'appels.

Améliorations concentrées des liquidités

1. Les positions de liquidité conservent le modèle concentré introduit dans la V3, mais bénéficient de la prise en charge d'une mise à l'échelle dynamique des frais basée sur des signaux de volatilité en temps réel intégrés dans les ticks de prix.

2. L’espacement des ticks n’est plus fixe par niveau de frais ; au lieu de cela, il s’adapte à la profondeur de la liquidité et à la fréquence des mouvements de prix observés dans des fenêtres d’observation définies.

3. La gestion des positions permet désormais des opérations de retrait et de dépôt partiels sans recalcul complet de la position, réduisant ainsi le coût du gaz jusqu'à 37 % dans les scénarios de référence.

4. Le suivi de la croissance des frais utilise une accumulation incrémentielle par tick plutôt que des instantanés globaux, améliorant ainsi la précision lors des oscillations de prix à haute fréquence.

5. Les fournisseurs de liquidité peuvent spécifier des fenêtres Oracle personnalisées pour l'accumulation des frais basés sur TWAP, dissociant ainsi les entrées de tarification des dépendances d'horodatage de bloc.

Techniques d'optimisation des gaz

1. Le bytecode est minimisé grâce à la compression des opcodes EVM et à la réutilisation des signatures de fonctions communes dans la logique de répartition interne.

2. Les lectures de stockage sont regroupées à l'aide de modèles de mise en cache SLOAD dans les fonctions internes, supprimant ainsi les récupérations d'emplacements redondantes lors des échanges en plusieurs étapes.

3. Les protections contre la réentrée sont mises en œuvre via des indicateurs à un seul bit au lieu de verrous basés sur la cartographie, ce qui permet d'économiser plus de 2 200 gaz par opération protégée.

4. Les opérations mathématiques exploitent une arithmétique non contrôlée où les conditions de débordement sont prouvées impossibles, vérifiées via des outils d'analyse statique formelle.

5. L'initialisation du pool ignore l'initialisation à zéro des plages de stockage inutilisées, en s'appuyant sur la sémantique de valeur nulle par défaut d'EVM pour les emplacements non attribués.

Foire aux questions

Q : Les positions de liquidité V3 existantes peuvent-elles être migrées directement vers la V4 ? R : Non. La V4 nécessite un redéploiement explicite des positions en raison de changements dans les calculs de ticks, la disposition du stockage et les structures d'état prenant en charge les hooks. Les outils de migration automatisés ne font pas partie du protocole de base.

Q : La logique de hook peut-elle être mise à niveau après la création du pool ? R : Non. Les références de hook sont immuables une fois qu’un pool est initialisé. Changer de comportement nécessite de créer un nouveau pool avec des paramètres de hook mis à jour.

Q : Comment Singleton empêche-t-il les collisions de stockage entre des pools non liés ? R : Il utilise un hachage cryptographique de la clé du pool (tokenA, tokenB, fee, hook) comme préfixe de stockage principal, garantissant une allocation d'emplacement déterministe et résistante aux collisions.

Q : Les échanges flash sont-ils toujours pris en charge dans la V4 ? R : Oui. La fonctionnalité Flash Swap reste intacte et fonctionne de manière identique à la V3, avec la possibilité supplémentaire de déclencher des hooks enregistrés pendant la phase de rappel du prêt flash.