La gouvernance d’Uniswap examine une RFC proposant une exécution privée optionnelle des swaps avec les hooks v4 et UniswapX
Points clés
- •SilentSwap a soumis à la gouvernance d’Uniswap une demande de commentaires proposant un parcours optionnel d’exécution privée appelé « Swap Privately », qui ne modifierait pas les swaps standards ni les frais de pool.
- •L’architecture proposée combine les hooks Uniswap v4, qui restent en développement et non audités sur le mainnet, avec le routage fondé sur des enchères d’UniswapX afin de réduire la visibilité des transactions avant leur exécution.
- •La conception utilise des zk-SNARKs pour la protection de la confidentialité, parallèlement à un filtrage de conformité avant exécution, reflétant une évolution plus large du secteur vers une approche où confidentialité et conformité réglementaire sont considérées comme des objectifs compatibles.
- •La RFC répond à des vulnérabilités de longue date de la DeFi, notamment l’extraction de MEV, les attaques sandwich et les fuites liées à l’exécution, qui apparaissent lorsque l’intention de transaction devient visible avant le règlement.
- •La proposition reste soumise à l’examen de la communauté et n’a pas été approuvée, avec des questions non résolues concernant la complexité technique, les hypothèses de confiance, l’exposition juridique et la compréhension de la fonctionnalité par les utilisateurs.

La gouvernance d’Uniswap examine une demande de commentaires, ou RFC, qui introduirait un parcours optionnel d’exécution privée dans l’interface d’Uniswap. La proposition utiliserait les hooks Uniswap v4 et UniswapX afin de réduire la quantité d’informations de transaction exposées avant l’exécution d’un swap.
La RFC, soumise par SilentSwap, décrit la fonctionnalité proposée comme une option « Swap Privately ». Selon la proposition, les swaps standards resteraient inchangés et les frais de pool ne seraient pas affectés. La conception suggérée repose sur des zk-SNARKs et un filtrage de conformité avant exécution afin de permettre un traitement des transactions plus privé.
Le problème utilisateur qui sous-tend cette conception technique est simple : les swaps on-chain sont transparents. Cette transparence est une caractéristique centrale de la finance décentralisée, mais elle peut aussi révéler l’intention de transaction avant l’exécution. Lorsque cette information devient visible, des bots et des traders sophistiqués peuvent être en mesure de faire du front-running, de mener des attaques sandwich ou d’exploiter les utilisateurs d’autres manières.
Étant donné qu’Uniswap est l’une des interfaces de trading les plus utilisées de la DeFi, une discussion de gouvernance sur la confidentialité de l’exécution pourrait avoir une portée allant au-delà d’une simple fonctionnalité d’interface. La proposition reste un sujet de discussion et n’a été ni approuvée ni déployée.
Pourquoi la confidentialité des swaps est importante
Le trading en DeFi est confronté depuis longtemps à un problème de visibilité. Lorsque les utilisateurs soumettent des transactions, leurs intentions peuvent devenir visibles avant le règlement final. Des bots peuvent surveiller les transactions en attente, estimer leur impact probable sur le prix et insérer leurs propres transactions autour de celle d’un utilisateur. Cela peut conduire à une moins bonne exécution pour les traders ordinaires.
Le MEV, les attaques sandwich et les fuites liées à l’exécution sont des problèmes récurrents en DeFi depuis des années. Le terme MEV, abréviation de maximal extractable value, a été formalisé vers 2019 et est depuis devenu un défi structurel reconnu dans le trading basé sur Ethereum. Des infrastructures comme MEV-Boost de Flashbots, largement adoptées après la transition d’Ethereum vers la preuve d’enjeu, ont été conçues pour traiter certains aspects de ce problème au niveau de la construction des blocs. Certains utilisateurs s’appuient également sur des RPC privés, des agrégateurs, des contrôles de slippage ou des outils de routage plus avancés afin de réduire leur exposition. D’autres n’utilisent pas ces protections, soit parce qu’ils n’en ont pas connaissance, soit parce que ces outils ne font pas partie de leur flux de trading habituel.
Un parcours d’exécution privée viserait à rendre ce type de protection plus facilement accessible au niveau de l’interface. Cette distinction est importante, car la plupart des utilisateurs interagissent avec la DeFi via des frontends plutôt que directement avec des smart contracts. Si la confidentialité ou la protection contre le MEV reste limitée à des outils spécialisés, de nombreux utilisateurs pourraient ne jamais l’adopter.
Ajouter une option « Swap Privately » à une interface grand public rapprocherait cette protection du point où les utilisateurs initient leurs transactions. La RFC présente cette fonctionnalité comme optionnelle, et non comme un remplacement de l’exécution standard des swaps.
Les hooks v4 permettraient une conception plus flexible
Les hooks Uniswap v4 constituent un élément central de l’architecture proposée. Les hooks permettent aux développeurs de personnaliser le comportement des pools et la logique d’exécution autour des swaps. Cette flexibilité peut prendre en charge différentes conceptions de routage, structures de frais, mécanismes de gestion des ordres et fonctionnalités liées à la confidentialité. Uniswap v4 lui-même reste en développement et n’a pas encore été déployé sur le mainnet, ce qui signifie que la base technique de la fonctionnalité proposée est encore en cours d’audit et de test.
Dans le cadre de la RFC, les hooks v4 seraient utilisés comme partie de l’architecture d’exécution privée. UniswapX est également inclus dans la conception, car il prend déjà en charge une exécution des swaps plus flexible grâce à un système de routage fondé sur des enchères utilisant des fillers externes. UniswapX a été introduit en 2023 et intègre lui-même, par conception, certaines propriétés de protection contre le MEV, puisque les ordres sont exécutés off-chain par le biais d’enchères concurrentielles plutôt que soumis directement au mempool public. Ensemble, les deux composants pourraient fournir un parcours dans lequel les détails de transaction sont moins exposés avant l’exécution, tout en continuant de s’appuyer sur la liquidité et l’interface d’Uniswap.
La conception reste toutefois soumise à la discussion de gouvernance. Une RFC n’est pas un changement de gouvernance approuvé et ne signifie pas que la fonctionnalité est disponible. Il s’agit d’une proposition que la communauté peut examiner, critiquer, affiner ou rejeter.
Confidentialité et conformité sont abordées ensemble
L’un des éléments notables de la RFC est la combinaison de fonctionnalités de confidentialité avec un filtrage de conformité avant exécution. La proposition reflète une évolution plus large des discussions sur la confidentialité en DeFi, où confidentialité et conformité sont de plus en plus traitées comme des considérations de conception pouvant devoir coexister.
Les débats antérieurs dans la crypto présentaient souvent la confidentialité et la conformité comme des objectifs opposés : les transactions étaient soit visibles et conformes, soit privées et potentiellement suspectes. La RFC adopte une approche plus nuancée en cherchant à protéger les utilisateurs contre le front-running et les fuites de données tout en incluant des contrôles de conformité.
L’utilisation proposée des zk-SNARKs s’appuie sur une technologie qui a été éprouvée dans des projets comme Zcash, lancé en 2016, ainsi que dans les rollups zero-knowledge d’Ethereum, dont l’adoption s’est accrue depuis 2023. Les zk-SNARKs permettent à une partie de prouver qu’elle connaît une information sans révéler cette information elle-même, ce qui les rend pertinents à la fois pour la confidentialité et pour des conceptions de conformité à divulgation sélective.
Les utilisateurs peuvent souhaiter être protégés contre les fuites d’intention de transaction et les comportements d’exécution prédateurs. Dans le même temps, les régulateurs et les protocoles peuvent chercher à éviter des outils qui faciliteraient des activités sanctionnées ou d’autres abus. Les développeurs explorent donc des systèmes capables de protéger les utilisateurs légitimes tout en préservant une certaine forme de filtrage de conformité.
Cet équilibre est difficile et restera probablement contesté. Le fait que la gouvernance d’Uniswap discute d’un modèle impliquant des zk-SNARKs et un filtrage de conformité montre que le débat autour de la confidentialité en DeFi est devenu plus complexe.
L’approbation n’est pas garantie
La RFC ne doit pas être considérée comme un produit finalisé ou approuvé. La gouvernance d’Uniswap devrait encore évaluer si la conception est appropriée, si l’implémentation technique est sûre, si les hypothèses de conformité sont acceptables, si l’expérience utilisateur est claire et si la fonctionnalité introduit de nouveaux risques pour le protocole ou l’interface.
Les préoccupations potentielles comprennent la complexité technique, les hypothèses de confiance, les fournisseurs de filtrage, l’exposition juridique, les coûts et la question de savoir si les utilisateurs comprennent ce que « privé » signifie dans ce contexte. Ces questions sont centrales dans toute tentative d’ajouter une confidentialité de l’exécution à une grande interface DeFi.
La confidentialité de l’exécution est un sujet sensible, car un système mal conçu pourrait créer une fausse confiance ou de nouvelles surfaces d’attaque. Un système bien conçu pourrait rendre le trading on-chain plus sûr pour les utilisateurs ordinaires en réduisant l’exposition à certaines formes d’exécution prédatrice.
Le rôle d’Uniswap dans la structure de marché de la DeFi
La position d’Uniswap dans le trading décentralisé donne à la proposition une portée plus large. Lorsqu’Uniswap explore de nouveaux modèles d’exécution, d’autres protocoles DeFi, DEXs et agrégateurs sont susceptibles d’en évaluer les implications. Le protocole et l’interface sont profondément intégrés dans la manière dont les utilisateurs tradent on-chain.
D’autres plateformes de trading décentralisé ont déjà suivi différentes approches en matière de MEV et de protection de l’exécution. CoW Swap utilise des enchères par lots avec concurrence entre solveurs afin de réduire la capacité des bots à réordonner ou insérer des transactions. 1inch a intégré des fonctionnalités destinées à atténuer le front-running. La RFC d’Uniswap ajoute une autre approche de conception à cette discussion sectorielle en cours.
Une option de confidentialité au sein de ce flux de trading pourrait influencer ce que les utilisateurs attendent des autres exchanges décentralisés et agrégateurs. Elle pourrait également contribuer à une discussion plus large sur les standards d’exécution en DeFi.
Les utilisateurs ne devraient pas avoir besoin de comprendre le MEV à un niveau technique approfondi pour réduire le risque d’être exploités. Des outils au niveau de l’interface peuvent offrir des paramètres par défaut plus sûrs ou des options plus claires aux utilisateurs qui, autrement, s’appuient sur des parcours de soumission de transactions publics.
Pour l’instant, la RFC reste seulement une proposition. Elle indique un modèle possible dans lequel les swaps DeFi continueraient de se régler de manière transparente on-chain tout en exposant moins d’informations pendant la période où les utilisateurs sont les plus vulnérables aux fuites liées à l’exécution.
Cet article est basé sur la RFC de gouvernance d’Uniswap concernant la confidentialité native de l’exécution via les hooks v4 et UniswapX. Le rapport original de Bitcoinist a été rédigé par le News Desk et édité par Samuel Rae, sur la base d’informations publiées dans une documentation de source primaire.