Les dark pools émergent rapidement comme la prochaine frontière du secteur de la finance décentralisée (DeFi) d'Ethereum. Les conceptions de dark pool atténuent des problèmes tels que l'incertitude des prix et la mauvaise confidentialité des échanges onchain - des problèmes qui ont rendu les investisseurs extérieurs méfiants à l'égard de la DeFi, malgré des avantages évidents tels que l'accès à une liquidité 24/7 et des mécanismes de génération de rendement novateurs.

Dans cet article, nous donnons un aperçu des dark pools et explorons leur rôle dans la finance traditionnelle et la DeFi. Nous expliquons également le fonctionnement des dark pools natifs des crypto-monnaies et discutons des obstacles potentiels à une adoption plus large des dark pools onchain.

Introduction : Les dark pools dans la finance traditionnelle

Bien que cela semble sinistre et illégal, les dark pools sont en fait un composant de longue date du système financier traditionnel (hautement réglementé). Ci-dessous se trouve une définition d'un dark pool provenant d'Investopedia:

Un dark pool est un forum financier ou une bourse organisé(e) de manière privée pour le négoce de titres. Les dark pools permettent aux investisseurs institutionnels de trader sans exposition jusqu'après l'exécution et la déclaration de la transaction. Les dark pools sont un type de système de négoce alternatif (ATS) qui donne à certains investisseurs l'opportunité de passer de gros ordres et d'effectuer des transactions sans révéler publiquement leurs intentions lors de la recherche d'un acheteur ou d'un vendeur.

Les dark pools sont populaires parmi les investisseurs institutionnels, les personnes à valeur nette élevée, les fonds spéculatifs, les sociétés de fonds communs de placement et autres entités souhaitant effectuer des transactions à grande échelle de manière anonyme. Le désir de mener des transactions de manière anonyme découle de la sensibilité des prix du marché à la demande et à l'offre perçues (augmentée par les plateformes de négociation électroniques qui permettent des réponses quasi instantanées même à de faibles signaux). Cela est particulièrement vrai pour les bourses traditionnelles où le carnet d'ordres est public et où les gens peuvent passer ou annuler des ordres à leur guise.

Le carnet d'ordres dans une bourse à carnet d'ordres limité central (CLOB) est public. (source)

Supposons qu'Alice passe un ordre de vente sur le marché pour vendre 500 actions Tesla sur une bourse. Il s'agit d'un petit ordre qui aura à peine d'impact sur le prix des actions Tesla proposées sur la bourse. Cependant, Alice passant un ordre de vente de 10 millions d'actions de stock Tesla est une autre histoire.

Dans ce scénario, un important ordre de vente visible dans le carnet d'ordres signale une baisse potentielle de la demande de l'action Tesla. Les firmes de trading sophistiquées, en particulier celles utilisant des algorithmes de trading à haute fréquence (HFT), sont susceptibles de percevoir ce signal. Elles peuvent agir rapidement en vendant leurs avoirs avant que l'ordre d'Alice ne soit exécuté, anticipant une baisse du cours de l'action Tesla. Par conséquent, la valeur marchande des actions Tesla pourrait diminuer, entraînant un prix d'exécution plus défavorable pour Alice. Si Alice n'utilise pas de techniques de trading avancées, son trade pourrait finir par une perte car la baisse de prix se produit avant que son ordre ne soit exécuté.

Le problème est encore compliqué par la présence defirmes HFTqui utilisent des algorithmes propriétaires capables de répondre en temps réel à l'activité dans un carnet d'ordres centralisé (CLOB) échange. Voici quelques scénarios hypothétiques:

Frontrunning

Imaginez Alice, une investisseuse, décide de vendre un grand nombre d'actions Tesla sur une bourse traditionnelle. Si elle place son ordre de vente sur le marché, les détails de cet ordre, y compris la taille et l'intention, deviennent visibles publiquement pour les autres participants avant que la transaction ne soit finalisée. Une entreprise de trading sophistiquée, équipée d'algorithmes de trading à haute vitesse, pourrait remarquer cet important ordre et agir rapidement sur cette information.

Par exemple, la société de trading pourrait décider de vendre ses propres actions Tesla avant que l'ordre d'Alice ne soit exécuté, en anticipant que son important ordre de vente fera baisser le prix de l'action. Ce faisant, la société verrouille un prix plus élevé pour ses actions avant que le marché ne réagisse à la vente d'Alice. Une fois que l'important ordre d'Alice est exécuté, l'afflux d'actions qui frappe le marché fait baisser le prix, et la société de trading peut alors racheter les mêmes actions à un taux réduit, profitant de la différence.

Cette pratique, appelée frontrunning, exploite la visibilité de l'ordre d'Alice pour obtenir un avantage financier à ses dépens. Le résultat pour Alice est un prix d'exécution pire pour son échange car le marché réagit négativement avant que son ordre ne soit complet. Le frontrunning est un problème important dans les systèmes financiers traditionnels où les carnets de commandes sont publics, permettant à certains participants d'agir sur l'information avant que d'autres n'aient la chance.

Citation qui s'estompe

Prenons l'exemple d'Alice, mais cette fois-ci en nous concentrant sur le comportement des teneurs de marché, c'est-à-dire des entités qui proposent des offres d'achat et de vente sur une bourse. Supposons que l'important ordre de vente d'Alice devienne visible dans le carnet d'ordres public de la bourse. Un teneur de marché avait initialement une offre d'achat de actions Tesla à 200 $ chacune. En voyant l'important ordre de vente d'Alice, le teneur de marché pourrait soupçonner que l'offre accrue fera baisser le prix des actions Tesla.

Pour éviter d'acheter des actions à 200 $ seulement pour voir leur valeur diminuer, le teneur de marché annule ou modifie rapidement son ordre d'achat. Cette action, connue sous le nom de quote fading, élimine efficacement la liquidité du marché. Lorsque l'ordre de vente d'Alice s'exécute enfin, il reste moins d'acheteurs et elle doit se contenter d'un prix plus bas - peut-être 195 $ au lieu de 200 $.

Le fait de citer de manière injuste désavantage les traders comme Alice en permettant aux fournisseurs de liquidité d'ajuster leurs citations en fonction d'une connaissance semblable à celle d'initiés des transactions des autres participants. Comme le carnet de commandes est public sur les bourses à carnet d'ordres limités centralisées (CLOB), les teneurs de marché peuvent voir les ordres entrants en temps réel et réagir en conséquence. Malheureusement, Alice n'a aucun moyen d'empêcher son trade d'être affecté par cette pratique, car elle découle de la transparence du carnet de commandes lui-même.

Pourquoi les dark pools?

Les dark pools sont apparus dans la finance traditionnelle en réponse aux problèmes susmentionnés. Contrairement à une bourse « éclairée », les dark pools exécutent des transactions en dehors des bourses publiques telles que le NYSE (New York Stock Exchange) et le Nasdaq. Les ordres soumis par les acheteurs et les vendeurs sont directement appariés et seul l'opérateur central dispose des informations sur le carnet de commandes.

Plus important encore, chaque personne qui négocie via un dark pool n'est consciente que de ses propres ordres et du prix de compensation. À moins que l'opérateur central ne divulgue des informations, il est impossible de connaître quoi que ce soit sur les autres utilisateurs - comme leurs identités et la taille/valeur des ordres - même lors de la négociation d'actifs avec des contreparties.

Cela a plusieurs implications pour les personnes qui souhaitent échanger avec une exposition minimale aux fluctuations du marché. Plus précisément, les traders peuvent effectuer des transactions à grande échelle sans télégraphier leur intention d'acheter ou de vendre une action particulière au public et réduire l'impact d'une transaction sur le marché boursier. Cela augmente la certitude qu'une transaction importante ne subira pas de préemption ou de fadeur de devises et que le vendeur (ou l'acheteur) bénéficiera du meilleur prix disponible.

Supposons qu’Alice décide de vendre 10 milliards d’actions Tesla dans un dark pool, en fixant un prix de vente de 1 $ par action. Le dark pool identifie et fait correspondre l’ordre d’Alice avec l’ordre correspondant de Bob d’acheter 10 milliards d’actions Tesla à la même valorisation. Lorsque la transaction est exécutée, le public n’est pas au courant des détails de la transaction jusqu’à ce qu’elle soit réglée. Ce n’est qu’à ce moment-là que le marché apprend que 10 milliards d’actions ont changé de mains, mais sans connaître l’identité de l’acheteur ou du vendeur, protégeant ainsi les intentions et les stratégies commerciales des deux parties.

Nous pouvons voir comment le trading via un pool sombre protège les intérêts d'Alice et améliore la qualité de l'exécution et la certitude du prix de compensation :

• Bob ne sait rien d'Alice et sait seulement qu'il a reçu 10 milliards d'actions Tesla pour 10 milliards de dollars, et quelqu'un a reçu 10 milliards de dollars pour ces actions. Bob ne peut pas faire baisser le cours car le carnet de commandes est caché - Bob doit prévoir d'acheter réellement des actions pour savoir si quelqu'un a 10 milliards d'actions à vendre (cette information est connue une fois que l'ordre est exécuté).
• Il est difficile de faire du frontrunning sur le trade d'Alice car l'opérateur central obscurcit les détails des ordres d'achat et de vente en attente et de la liquidité du marché. La seule façon pour le trade d'Alice de devenir une information publique est si l'administrateur du dark pool partage l'information avec des parties externes (C'est illégal, cependant).

Aujourd'hui, il existe des dizaines de pools en activité et les estimations suggèrent que 40 pour cent des transactions électroniques sont effectuées via des dark poolsLa popularité croissante des dark pools a coïncidé avec...réglementation croissante, en particulier compte tenu de l'accès privilégié des opérateurs de pool aux informations sur les ordres en attente (Credit Suisse et Barclays ont été condamnés à une amende combinée de 150 millions de dollars en 2016 pour avoir divulgué des informations sur les transactions de dark pool à des parties externes).

Dark pools dans DeFi

(source)

Si les dark pools sont nécessaires dans TradFi, ils sont sans doute encore plus critiques dans DeFi en raison de la transparence inhérente des systèmes de blockchain et des défis que cela crée pour maintenir la confidentialité des transactions et la qualité de l'exécution. Cela est particulièrement vrai pour les échanges décentralisés (DEXes) qui facilitent les transactions électroniques et offrent des fonctionnalités similaires aux bourses traditionnelles.

• Les nœuds d'archivage peuvent interroger la blockchain pour obtenir des informations sur les transactions historiques interagissant avec un pool AMM et les recouper avec l'activité onchain associée à une adresse particulière. Cela rend trivial pour quiconque de copier les stratégies de trading employées par les traders alpha.
• Le mempool qui stocke des informations sur les transactions en attente est public et disponible pour toute personne connectée à un nœud complet. Cela rend les utilisateurs de DEX susceptibles au problème de la fade de citation où les gens annulent les ordres d'achat/vente en réponse à une grande transaction capable de déplacer le marché, ce qui entraîne une exécution au pire prix pour les traders.
• L'état post-transaction d'un DEX peut être calculé de manière triviale par quiconque observe le mempool, ce qui ouvre la porte à l'extraction malveillante de la valeur extractible maximale (MEV) par des validateurs et des bots MEV. Ces acteurs peuvent observer l'impact d'un échange sur le pool DEX et décider de frontrunner ou d'intercaler la transaction si la simulation des changements d'état révèle des profits potentiels. (Le fait que les utilisateurs envoient des transactions "en clair" pour les inclure dans un bloc aggrave le problème.)
• La transaction DEX pourrait échouer si un producteur de blocs censure délibérément la transaction d'un utilisateur. Comme les informations sur le compte sont publiquement disponibles, les validateurs peuvent établir des profils pour des adresses spécifiques et choisir de discriminer ces contreparties lors du traitement des transactions.
• Les validateurs pourraient voir des informations sur une transaction et décider de l'exclure du bloc suivant. Les utilisateurs ne peuvent pas obscurcir les détails de la transaction aux validateurs ou éviter de divulguer l'intention d'acheter/vendre des jetons.

(Source)

Ces problèmes ont conduit à ce que les DEX traditionnels ne soient plus populaires auprès des gros investisseurs et des traders institutionnels qui sont sensibles au prix et à la qualité de l'exécution. Le DeFi en est la plus grande victime, car les DEX ne parviennent pas à supplanter les échanges TradFi malgré plusieurs avantages tels que les transactions sans frontières et l'exécution transparente et sans confiance pour les utilisateurs. De nouvelles alternatives comme CowSwapetUniswapXont semblé résoudre le problème, mais réintroduisent le besoin de faire confiance à un opérateur central, similaire au fonctionnement des pools sombres traditionnels. Alors que les pools sombres dans le domaine de la finance traditionnelle sont privés dans le sens où les informations de compte sont cachées aux autres, ces données restent accessibles à la banque ou à l'opérateur, ce qui les rend vulnérables aux abus ou aux fuites si les administrateurs sont moins compétents ou malhonnêtes.

Amener des dark pools onchain n'est pas seulement possible mais représente une approche optimale pour la construction de plates-formes de trading décentralisées offrant une exécution de qualité sans trop dépendre des opérateurs centraux. Alors que la transparence inhérente des blockchains - où tout le monde peut vérifier l'exactitude computationnelle en exécutant un nœud - peut sembler en contradiction avec la fonctionnalité de dark pool, ce défi peut être surmonté. La solution réside dans la technologie de confidentialité améliorante (PET), une approche cryptographique qui permet de dissimuler les informations tout en maintenant l'intégrité des mises à jour du grand livre. Cela nous permet d'exploiter la vérifiabilité de la blockchain tout en introduisant les fonctionnalités de confidentialité essentielles au fonctionnement du dark pool.

La construction de dark pools décentralisés peut sembler impossible étant donné que les blockchains sont conçues pour être transparentes et interrogeables. C'est en réalité ce qui rend les blockchains meilleures que les bases de données classiques : tout le monde peut exécuter un nœud et vérifier que les modifications apportées à la base de données sont correctement calculées. Mais nous pouvons contourner cette contrainte en exploitant la cryptographie, plus précisément la technologie d'amélioration de la confidentialité (PET), qui permet de dissimuler des informations tout en veillant à ce que les mises à jour du grand livre soient conformes aux règles.

Comment fonctionnent les dark pools?

Il n'y a pas une seule façon de construire un dark pool onchain. Cependant, tous les dark pools crypto partagent la caractéristique commune : ils utilisent différents mécanismes cryptographiques pour masquer les informations sur les transactions onchain et améliorer la qualité de l'exécution pour les utilisateurs.

La computation multipartite (MPC), les preuves à divulgation nulle, le chiffrement seuil, le chiffrement entièrement homomorphique (FHE) et les environnements d'exécution de confiance (TEEs) sont quelques primitives disponibles pour les concepteurs de mécanismes travaillant sur des dark pools crypto-natives. L'objectif dans chaque cas est de maintenir des garanties de confidentialité des échanges sans augmenter les prémisses de confiance ou rendre le système susceptible de manipulation.

Renégat, Tristero, et Railgunsont des exemples de dark pools onchain dans l'écosystème Ethereum. Nous passerons brièvement en revue chacun de ces protocoles pour donner un aperçu de la façon dont les dark pools onchain fonctionnent en pratique. Cet article se concentrera sur Renegade, en explorant sa conception et l'approche du protocole pour protéger les informations sur les transactions effectuées par les participants du marché.

Renegade: Accélération de la DeFi privée avec une cryptographie de pointe

Renegade est un dark pool décentralisé et préservant la confidentialité, conçu pour remédier aux failles critiques du paysage de trading de la finance décentralisée (DeFi) existant. En exploitant des techniques cryptographiques avancées telles que les preuves de connaissance nulle (ZKP) et les calculs multipartites (MPC), Renegade permet aux utilisateurs de placer, d'apparier et de régler des commandes en toute sécurité sans révéler leurs soldes, intentions de trading ou stratégies à des tiers. Contrairement aux DEX traditionnels, qui exposent les données du carnet de commandes à un examen public, Renegade chiffre toutes les informations de portefeuille et de commande, garantissant que les transactions se déroulent de manière privée et sont résistantes à la manipulation.

Au cœur de Renegade, les utilisateurs peuvent réaliser des échanges sans confiance, sur chaîne, avec la même précision et la même qualité d'exécution que les exchanges centralisés, tout en préservant les garanties de confidentialité nécessaires pour se protéger contre les pratiques d'anticipation, de dégradation des devis et d'autres pratiques d'exploitation. En introduisant un arbre de merkle mondial unique pour la gestion de l'état, Renegade conserve les avantages de la transparence de la blockchain, tels que la vérifiabilité et l'immutabilité, tout en protégeant les détails sensibles des échanges des regards indiscrets.

Aborder les problèmes des systèmes DeFi actuels

La conception des échanges décentralisés (DEXes) aujourd'hui, qu'ils soient basés sur des Automated Market Makers (AMMs) ou des Central Limit Order Books (CLOBs), introduit des failles critiques qui impactent tous les participants, des utilisateurs réguliers aux traders institutionnels. Ces problèmes surviennent car les transactions et les ordres sont diffusés en texte clair sur des blockchains transparentes. Alors que la transparence est fondamentale pour la vérification sans confiance, elle expose également les traders à des pratiques nocives telles que le front-running, le quote fading et le profilage des adresses.

Pour les petits traders comme pour les gros investisseurs, ces vulnérabilités se traduisent par une mauvaise exécution des transactions, des pertes financières et une confiance réduite dans la finance décentralisée. Renegade élimine ces problèmes en introduisant des techniques cryptographiques qui préservent la confidentialité sans compromettre l'intégrité des systèmes décentralisés.

Valeur Maximale Extractible (MEV)

Profit total moyen MEV (ensemble de données de 30 jours) selon EigenPhi

Chaque fois que les commandes et les transactions sont visibles dans le mempool, elles deviennent susceptibles d'être manipulées par les producteurs de blocs (dans la couche 1) ou les séquenceurs (dans la couche 2). Ces acteurs peuvent réorganiser, devancer ou retarder les transactions à des fins lucratives. Par exemple, observer une grande commande d'achat ou de vente permet aux acteurs malveillants d'exécuter leurs transactions avec des frais de gaz plus élevés en premier (devancement) ou d'exploiter immédiatement les opportunités suivant l'exécution (retard). Cette forme de MEV affecte toutes les conceptions de DEX, qu'elles utilisent une architecture AMM ou CLOB.

Transparence des échanges

La transparence des carnets de commandes basés sur la blockchain expose les traders aux risques avant et après la négociation :

• Risques pré-négociation : Dans les systèmes de carnet d'ordres ouverts, les ordres publiquement visibles signalent l'intention des traders, permettant aux adversaires d'ajuster leurs stratégies en réponse. Cela peut conduire à des tactiques de manipulation telles que le retrait de devis, où les fournisseurs de liquidité retirent leurs ordres pour exploiter les transactions entrantes, provoquant un glissement et une dégradation de la qualité d'exécution.
• Risques post-négociation : une fois qu'une transaction est exécutée, ses détails, y compris les stratégies et les modèles de négociation, sont enregistrés de manière permanente sur la chaîne de blocs. Les acteurs malveillants ou les concurrents peuvent analyser ces données historiques pour prédire et exploiter les transactions futures. Ce manque de confidentialité post-négociation rend les traders, en particulier les institutions, vulnérables à l'exploitation.

En combinant ces éléments en une catégorie plus large, Renegade traite de l'ensemble du cycle de vie des problèmes de transparence des échanges avec des solutions cryptographiques qui garantissent la confidentialité avant la négociation et le règlement sécurisé après la négociation.

Profilage basé sur l'adresse

Dans les systèmes blockchain transparents, chaque transaction expose l'adresse de la partie initiatrice. Les adversaires peuvent analyser ces données pour créer des profils détaillés, en liant le comportement de trading à des portefeuilles spécifiques. Ce profilage permet des pratiques discriminatoires, telles que l'offre de prix plus bas ou le ciblage sélectif de certains utilisateurs. Bien que les identités blockchain soient pseudonymes, des analyses sophistiquées peuvent corréler les adresses avec des entités réelles ou des schémas de comportement, aggravant ainsi ces vulnérabilités.

La conception axée sur la confidentialité de Renegade garantit que les identités et les stratégies des utilisateurs restent protégées tout au long du processus de négociation, protégeant ainsi les participants de détail et institutionnels.

Au cœur de ces problèmes se trouve la transparence inévitable des blockchains. Bien que la transparence garantisse une vérification sans confiance et une immuabilité - des qualités essentielles pour les systèmes décentralisés - elle expose également des détails sensibles sur l'activité des utilisateurs. Chaque transaction, mise à jour de solde ou transaction en attente devient une information publique que des acteurs adverses peuvent analyser, manipuler ou exploiter à des fins lucratives. Cela crée un système où les utilisateurs sont confrontés à des défis tels que l'extraction de MEV, la manipulation des échanges et le profilage basé sur les adresses, qui dégradent la qualité d'exécution et érodent la confiance dans les marchés décentralisés.

Pour résoudre ces problèmes, Renegade remplace la transparence par la confidentialité contrôlée grâce à l'utilisation combinée des preuves de connaissances nulles (ZKPs) et du calcul multipartite (MPC). Les ZKPs garantissent que les transactions sont valides, que les soldes sont suffisants et que les règles du protocole sont respectées sans jamais révéler le contenu du portefeuille ou les détails de la transaction. En même temps, le MPC permet une correspondance d'ordres sécurisée, où plusieurs parties collaborent pour trouver des correspondances de transactions sans exposer les entrées ou divulguer des informations sensibles.

Ensemble, ces techniques forment un système fluide où les transactions restent privées, l'exécution est vérifiable et les détails de l'ordre sont cachés tout au long du cycle de vie. Cela élimine les vulnérabilités inhérentes aux blockchains transparentes tout en préservant la décentralisation et la validation sans confiance.

Avec une compréhension claire des problèmes que Renegade résout et de son approche en matière de confidentialité, plongeons dans le fonctionnement du système pour offrir des transactions sécurisées, privées et équitables.

Comment Renegade fonctionne-t-il sous le capot ?

Renegade réinvente le trading décentralisé en intégrant des techniques cryptographiques avancées qui redéfinissent les limites de la transparence, de la confidentialité et de l'équité dans DeFi. En répondant aux limitations des échanges décentralisés conventionnels, Renegade introduit une approche innovante qui combine des technologies préservant la confidentialité avec un trading sans confiance sur la chaîne.

Cette section offre un aperçu plus détaillé des composants architecturaux uniques qui alimentent Renegade. Nous explorerons:

• Arbre d'engagement et conception de portefeuille: Comment les portefeuilles des utilisateurs restent entièrement hors chaîne et privés, sécurisés par des engagements cryptographiques et gérés grâce à une hiérarchie de clés sophistiquée.
• Relayers et super relayers: Le rôle des relayers dans la facilitation de l'appariement et de l'exécution sécurisés des transactions, ainsi que leur intégration avec les permissions de portefeuille déléguées.
• Moteur de correspondance MPC : le mécanisme révolutionnaire de calcul multipartite à deux parties de Renegade qui garantit une correspondance commerciale privée et sans confiance.
• Collaborative SNARKs : Comment les règlements atomiques sont réalisés grâce à l'intégration transparente de preuves de connaissances nulles avec le calcul multipartite.
• Performance et évolutivité : Une discussion sur les compromis impliqués dans les choix de conception de Renegade et sur la façon dont son architecture équilibre la confidentialité, la décentralisation et l'efficacité.

En exploitant ces innovations, Renegade résout non seulement les défauts critiques des modèles DEX existants, mais jette également les bases d'un environnement de trading décentralisé plus sécurisé, privé et équitable.

Les portefeuilles de Renegade et l'arbre d'engagement

Renegade introduit un modèle de gestion d'état qui privilégie la confidentialité et la vérifiabilité. Au cœur du système se trouve un arbre d'engagement, un arbre de Merkle global en ajoutant uniquement qui stocke les représentations cryptographiques (engagements) des portefeuilles d'utilisateurs. Cette conception garantit que le contenu du portefeuille reste entièrement privé tout en maintenant les garanties sans confiance des systèmes décentralisés.

Contrairement aux échanges décentralisés traditionnels (DEX) où les données du portefeuille sont visibles sur la chaîne, Renegade conserve toutes les informations du portefeuille hors chaîne, permettant aux utilisateurs de gérer en toute sécurité leurs soldes, leurs ordres et leur historique de transactions sans exposer de détails sensibles. Sur la chaîne, ces portefeuilles sont représentés uniquement en cachant et en liant les engagements, des hachages cryptographiques qui obscurcissent le contenu du portefeuille tout en garantissant qu'ils ne peuvent pas être manipulés ou réutilisés de manière inappropriée.

Une analogie : Portefeuilles en tant que mini-rollups

Pour mieux comprendre l'architecture de Renegade, nous pouvons établir un parallèle avec les rollups Ethereum. Dans un rollup, les transactions sont exécutées hors chaîne, où les changements d'état se produisent de manière privée, et seul le state root, une représentation cryptographique de l'état cumulatif du rollup, est périodiquement soumis à Ethereum. En plus de ce state root, une preuve de connaissance nulle (PCN) est fournie pour valider que la transition d'état respecte les règles du protocole rollup sans révéler de détails sur les transactions.

Les portefeuilles Renegade fonctionnent de manière frappante de manière similaire :

• Exécution hors chaîne : Toutes les opérations de portefeuille, telles que le placement d'ordres, la mise à jour des soldes et l'exécution des transactions, se déroulent hors chaîne. Ces mises à jour sont reflétées dans l'état privé du portefeuille, inaccessible aux observateurs externes, y compris Ethereum.
• Engagement on-chain : Après la mise à jour de l'état du portefeuille, son nouvel engagement est ajouté à l'arbre des engagements. Cet engagement sert de résumé cryptographique des nouveaux soldes, ordres et modifications apportées lors du processus de mise à jour. La mise à jour est accompagnée d'un ZKP, garantissant que la transition de l'ancien état du portefeuille vers le nouveau est valide.

Cette similitude met en évidence la façon dont les portefeuilles Renegade fonctionnent comme des mini-rollups. Ils traitent de manière indépendante les changements d'état hors chaîne tout en s'appuyant sur l'arbre d'engagement pour synchroniser leur état avec le système plus large. Importamment, ce processus est spécifiquement conçu pour améliorer la confidentialité, plutôt que la scalabilité, en gardant les données du portefeuille opaques et illisibles pour tous les observateurs externes.

Schéma de commit-reveal pour les mises à jour de portefeuille

Chaque opération sur un portefeuille dans Renegade suit un schéma d'engagement-révélation, assurant la confidentialité et la correction tout au long du processus de mise à jour. Ce mécanisme permet aux utilisateurs de modifier leurs portefeuilles tout en maintenant l'intégrité du système.

1. Révéler l'ancien portefeuille : L'utilisateur soumet une preuve de Merkle montrant que son engagement de portefeuille précédent existe en tant que feuille dans l'arbre d'engagement. Il est crucial de noter que ce processus de révélation ne divulgue aucun détail sur le contenu du portefeuille, préservant ainsi les garanties de confidentialité préalables à la transaction de Renegade. Le système n'apprend que l'engagement du portefeuille est valide et inclus dans l'arbre.
2. Calcul des nullificateurs : Pour empêcher la réutilisation d'anciens états de portefeuille, Renegade exige le calcul de deux nullificateurs pour chaque portefeuille : un nullificateur de dépense de portefeuille et un nullificateur de correspondance de portefeuille. Ces nullificateurs sont dérivés de l'engagement du vieux portefeuille et d'une valeur de hasard privée, assurant l'unicité.

Les nullificateurs sont ensuite soumis avec l'engagement du nouveau portefeuille pour garantir que l'ancien portefeuille ne peut pas être réutilisé.

1. S'engager pour le nouveau portefeuille : L'utilisateur génère un nouvel état de portefeuille reflétant les mises à jour souhaitées, telles que le placement d'ordres, les ajustements de solde ou les règlements de transactions, et calcule son engagement cryptographique. Une preuve de connaissance nulle est soumise pour prouver ce qui suit :
   • L'ancien engagement de portefeuille existe dans l'arbre d'engagement.
   • Les annulateurs sont correctement calculés et uniques.
   • La transition de l'ancien état du portefeuille au nouveau respecte les règles du protocole (par exemple, pas d'augmentation de solde non autorisée).
   • L'utilisateur possède les clés secrètes nécessaires pour autoriser la mise à jour.

Une fois que la preuve est vérifiée et que les annulateurs sont confirmés comme non utilisés, le contrat intelligent marque les annulateurs du vieux portefeuille comme "dépensés" et insère le nouvel engagement dans l'arbre d'engagement.

(Source: Documentation Renegade)

L'architecture basée sur l'engagement de Renegade garantit que les données sensibles de trading restent sécurisées en tout temps. La nature cachée et liée des engagements de portefeuille garantit qu'aucun observateur externe ne peut déduire le contenu du portefeuille, même avec accès à l'arbre des engagements. De plus, l'aléatoire inclus dans le calcul des engagements de portefeuille empêche les adversaires de créer des tables arc-en-ciel pour identifier des états de portefeuille communs, tels que des portefeuilles avec un solde nul ou des ordres.

En combinant ces mécanismes cryptographiques avec des preuves à divulgation nulle, Renegade réalise une conception axée sur la confidentialité où les opérations de portefeuille sont vérifiables mais invisibles aux parties externes. Cela garantit que le protocole maintient la confidentialité avant l'échange, protégeant les utilisateurs contre les stratégies adverses telles que le frontrunning et la manipulation des devises.

Hiérarchie de clés et système de relais

Renegade s'appuie sur des relayers pour faciliter des opérations critiques telles que la correspondance des ordres et le règlement, permettant aux utilisateurs de trader efficacement sans compromettre la sécurité. Pour ce faire, le protocole met en œuvre une hiérarchie de clés robuste, un cadre cryptographique qui sépare les permissions de contrôle et de visualisation, garantissant aux utilisateurs la garde de leurs actifs tout en déléguant des tâches spécifiques aux relayers. Ce système sécurise non seulement les informations sensibles du portefeuille, mais simplifie également les interactions avec les relayers, rendant le trading privé et décentralisé plus pratique et convivial.

Comment fonctionne la hiérarchie des clés

Bien que la conception actuelle de la hiérarchie des clés de Renegade ait évolué par rapport à sa description initiale dans le livre blanc, les principes fondamentaux restent cohérents. Lorsqu'un portefeuille est créé pour la première fois et engagé dans l'arbre d'engagement, il comprend cinq secrets distincts qui définissent collectivement sa fonctionnalité. Ces secrets sont :

• Paire de clés racine : La paire de clés racine est une paire de clés ECDSA (courbe secp256k1), identique à une clé privée Ethereum standard. Elle est la clé la plus autoritaire et confère une pleine garde sur le portefeuille. Toutes les opérations qui modifient l'état du portefeuille - telles que les dépôts, les retraits, la passation d'ordres ou les annulations - nécessitent une signature de la clé secrète racine. Pour garantir une sécurité maximale, la clé racine est strictement conservée côté client et n'est jamais partagée avec une partie externe, y compris les relais.
• Match scalar: Le match scalaire est une valeur scalaire secrète définie sur la courbe bn254 et sert de mécanisme par lequel les relayers sont autorisés à soumettre des correspondances pour le règlement au contrat intelligent ou à la couche de base. Contrairement aux paires de clés asymétriques traditionnelles, le match scalaire est une seule valeur secrète que les relayers utilisent pour générer des preuves à divulgation nulle (ZKPs), prouvant leur connaissance de l'image préimage scalaire sous le hachage Poseidon. Cela garantit que les relayers ne peuvent régler que les correspondances explicitement autorisées par la configuration du portefeuille. De plus, le match scalaire est associé à des frais prédéfinis dans le portefeuille, ce qui permet aux utilisateurs de spécifier les frais exacts que les relayers peuvent appliquer pour leurs services.
• Clé API symétrique : La clé API symétrique est un outil hors protocole utilisé pour authentifier les interactions entre l'utilisateur et le relais. Il permet aux relais de diffuser en continu des mises à jour en temps réel, telles que les modifications de portefeuille ou les statuts de commande, à l'utilisateur sans compromettre la sécurité du portefeuille ou son intégrité cryptographique. Bien qu'il ne soit pas directement lié aux opérations de portefeuille, cette clé facilite la communication transparente et améliore l'expérience de trading globale.
• Blinder seed et share seed : Le blinder seed et le share seed sont des composants essentiels qui permettent aux relayers de décrypter et de traiter en toute sécurité les informations de portefeuille. Ces graines fonctionnent comme des clés de visualisation, accordant aux relayers la capacité d'accéder à l'état privé du portefeuille. Cependant, en tant que graines, elles sont dynamiquement hashées en valeurs qui changent à chaque transaction. Cela garantit que les valeurs de blinder et de share sont spécifiques à l'opération en cours, empêchant toute réutilisation ou accès non intentionnel.

La graine du brouilleur est responsable de l'indexation du portefeuille sur la chaîne en créant une chaîne de hachage cryptographique qui relie les états du portefeuille. Cela garantit que la présence du portefeuille dans l'arbre d'engagement reste prouvable sans exposer son contenu.

La graine de partage est utilisée pour construire des "partages secrets" de données de portefeuille, permettant au relais de collaborer avec le moteur de correspondance MPC pendant le processus de correspondance des commandes. Cette intégration permet aux relais d'effectuer leurs fonctions en toute sécurité et sans révéler de détails sensibles sur le portefeuille au réseau plus large.

Comment les relais fonctionnent-ils dans renegade

Les relayers dans Renegade jouent un rôle d'intermédiaires critiques qui permettent au protocole de maintenir sa nature de préservation de la confidentialité et sa décentralisation tout en offrant une expérience de trading fluide. Agissant à la fois comme facilitateurs et enableurs, les relayers sont habilités par la hiérarchie des clés à effectuer des opérations spécifiques au nom de l'utilisateur sans compromettre la garde du portefeuille ou la confidentialité. En exploitant les secrets intégrés dans le portefeuille, les relayers peuvent décrypter les informations du portefeuille, identifier les ordres en attente et soumettre des correspondances au contrat intelligent pour le règlement, tout en maintenant des garanties cryptographiques strictes.

La relation entre les relayeurs et la hiérarchie des clés repose sur un modèle de délégation clair. Les utilisateurs ne partagent que les secrets nécessaires, tels que le scalaire de correspondance, la graine d’œillère et la graine de partage, avec le relayeur. Ces secrets permettent au relayeur de visualiser et de traiter les données du portefeuille en toute sécurité. Le scalaire de correspondance permet aux relayeurs d’autoriser et de régler les correspondances en prouvant la connaissance de sa préimage de hachage Poséidon par le biais de preuves à divulgation nulle de connaissance (ZKP). La graine d’aveugle et la graine de partage, quant à elles, garantissent que les relayeurs peuvent accéder aux données du portefeuille sans les exposer à des observateurs externes ou obtenir un contrôle non autorisé. Cette séparation des pouvoirs garantit que les relayeurs disposent des outils nécessaires pour effectuer les tâches qui leur sont déléguées sans compromettre le contrôle ou la sécurité globale de l’utilisateur.

Un avantage clé de ce système est qu'il permet une délégation granulaire. Les relayers sont limités aux rôles explicitement autorisés par les secrets partagés. Par exemple, bien que les relayers puissent consulter les détails du portefeuille et faire correspondre les ordres en attente, ils ne peuvent pas modifier, retirer ou annuler les ordres, car la paire de clés racine, la clé de garde ultime, reste avec l'utilisateur. Cette conception garantit que les utilisateurs conservent la pleine propriété de leurs portefeuilles tout en externalisant des tâches spécifiques pour plus d'efficacité.

Les relayers apportent également une grande commodité au processus de trading en gérant la complexité informatique de la mise en correspondance des ordres avec le moteur de mise en correspondance MPC et en assurant la validité de ces correspondances grâce aux SNARKs collaboratifs. Ce mécanisme permet aux relayers de décharger une grande partie de la charge technique des utilisateurs tout en maintenant les garanties de confidentialité rigoureuses de Renegade avant et après la négociation. En gérant de manière sécurisée ces opérations, les relayers protègent non seulement les détails sensibles du portefeuille lors de la mise en correspondance des ordres et du règlement, mais atténuent également bon nombre des défis UX généralement associés aux systèmes de préservation de la confidentialité. Leur capacité à fournir des mises à jour en temps réel via la clé d'API symétrique améliore encore l'expérience utilisateur, garantissant que les utilisateurs restent informés de leurs échanges et de l'état de leur portefeuille sans compromettre la sécurité.

En pratique, ce système crée un environnement de trading hautement flexible et sécurisé. Les utilisateurs peuvent déléguer leurs portefeuilles à des relayers pour des périodes prolongées, leur accordant un accès persistant pour correspondre aux ordres sans avoir à partager de nouvelles clés à plusieurs reprises. En même temps, les utilisateurs peuvent révoquer l'accès du relayer à tout moment en créant un nouveau portefeuille et en transférant leurs actifs, réinitialisant ainsi la délégation. Ce mécanisme équilibre la commodité à long terme avec l'adaptabilité à court terme, répondant à la fois aux traders occasionnels et aux participants plus soucieux de la sécurité.

En intégrant des relayers dans son architecture, Renegade parvient à une combinaison rare de décentralisation, de confidentialité et d'utilisabilité. Les relayers agissent comme des intermédiaires de confiance sans exiger de confiance explicite, grâce aux garanties cryptographiques imposées par la hiérarchie des clés. Cela permet à Renegade de mettre à l'échelle ses opérations tout en maintenant les plus hauts niveaux de sécurité et d'autonomie des utilisateurs.

En bref, l'architecture en arbre d'engagement de Renegade et la hiérarchie des clés fournissent un cadre fondamental pour équilibrer la confidentialité et la vérifiabilité dans le trading décentralisé. En veillant à ce que les portefeuilles des utilisateurs restent entièrement hors chaîne et ne soient représentés en chaîne que sous forme d'engagements cryptographiques, Renegade élimine la visibilité des données sensibles de trading.

Cette conception permet non seulement d'éviter les pratiques de frontrunning, de quote fading et autres comportements d'exploitation, mais permet également aux utilisateurs de conserver la pleine propriété de leurs fonds grâce à la paire de clés racine. Le schéma commit-reveal, associé à l'utilisation de ZKPs, garantit que les mises à jour du portefeuille et les transitions d'état sont sécurisées, inviolables et totalement opaques aux observateurs externes. Cela garantit un environnement de trading où la vérification sans confiance et la confidentialité renforcée coexistent harmonieusement.

Le système de relais, intégré à la hiérarchie des clés, élève encore davantage l'expérience utilisateur et l'efficacité opérationnelle de Renegade. Les relais simplifient le processus de trading en gérant les tâches intensives en calcul de la correspondance des ordres et de règlement, en utilisant le moteur de correspondance MPC et la preuve SNARK pour maintenir la confidentialité et assurer la correction. Dans le même temps, leur capacité à fournir des mises à jour en temps réel via la clé API symétrique comble le fossé entre des garanties de confidentialité robustes et une expérience utilisateur fluide.

En séparant les autorisations d'affichage et de correspondance, la hiérarchie des clés garantit que les utilisateurs conservent un contrôle ultime sur leurs portefeuilles tandis que les relayers opèrent dans des rôles strictement définis. Ce système crée un équilibre unique où les utilisateurs bénéficient des propriétés de préservation de la confidentialité des techniques cryptographiques avancées sans rencontrer les obstacles d'utilisation généralement associés à de tels systèmes.

Comment les commandes sont assorties dans Renegade

Dans Renegade, le processus de mise en correspondance des ordres combine les actions des utilisateurs, la facilitation du relais et les protocoles cryptographiques de pointe pour créer une expérience de trading fluide et privée. Cette section suit le parcours d'un seul ordre, de sa création par l'utilisateur à son règlement final, expliquant le rôle des relais, le fonctionnement du moteur de mise en correspondance du MPC et les garanties de sécurité fournies par les SNARK collaboratifs. En explorant ces étapes, nous découvrirons comment Renegade veille à ce que les transactions restent privées, atomiques et entièrement vérifiables sans sacrifier la convivialité ou la confiance.

Avec cela, commençons par examiner la première étape: comment un utilisateur crée une commande et comment cette action prépare la scène pour le reste du processus de correspondance.

L'utilisateur crée une commande

Le parcours de correspondance des commandes dans Renegade commence par l'interaction de l'utilisateur avec l'interface pour créer une commande. Cela implique de spécifier des paramètres clés tels que la paire de négociation (par exemple, WETH/USDC) et la quantité qu'ils souhaitent échanger. Contrairement aux systèmes traditionnels, Renegade ne prend pas en charge les ordres limités, car Renegade n'est pas un carnet d'ordres limité centralisé (CLOB) et vise à éviter une complexité inutile. Au lieu de cela, chaque commande est ancrée au point médian, ce qui signifie que la transaction s'exécute au point médian de l'écart prévalant sur les principales plateformes d'échange telles que Binance, Coinbase, OKX et Kraken. Une fois le prix déterminé à l'aide de données provenant de plusieurs lieux, les utilisateurs confirment les détails de leur commande et le logiciel de portefeuille met à jour en toute transparence l'état pour refléter la nouvelle commande tout en respectant l'architecture de préservation de la confidentialité de Renegade.

L’état du portefeuille mis à jour tient compte de tous les soldes réservés nécessaires à l’exécution de la transaction, ainsi que des frais de relais. Ce nouvel état est crypté à l’aide d’un système d’engagement de dissimulation et de liaison, garantissant que le contenu du portefeuille reste privé et incompréhensible pour les observateurs externes. Pour maintenir l’intégrité du système, l’état précédent du portefeuille est annulé en toute sécurité, ce qui empêche toute possibilité de réutilisation ou de double dépense.

Le logiciel de portefeuille soumet ensuite l'engagement mis à jour à l'arbre d'engagement dans le cadre du schéma d'engagement-révélation de Renegade, ainsi qu'une preuve de non-divulgation (ZKP) qui valide l'ensemble de la transition. Cette preuve garantit que la mise à jour du portefeuille respecte les règles du protocole, notamment en ce qui concerne les soldes suffisants et les transitions d'état correctes, sans révéler de détails sensibles sur l'ordre ou le contenu du portefeuille. Une fois que la transition est vérifiée, l'ancien portefeuille est marqué comme dépensé et le nouvel engagement est ajouté en toute sécurité à l'arbre d'engagement.

Du point de vue de l'utilisateur, tout ce processus est transparent. Une fois la commande passée avec succès, l'état du portefeuille mis à jour, y compris les soldes restants et les commandes actives, est affiché en temps réel. Il est important de noter que l'intention de trading de l'utilisateur et les détails du portefeuille restent complètement privés, ce qui préserve les garanties de confidentialité préalables à la transaction de Renegade.

Maintenant que l’ordre est validé dans le système, le relayeur peut commencer à le traiter pour les correspondances potentielles, passant ainsi à l’étape suivante du processus de trading sécurisé et privé.

Le relayer traite la commande

Une fois que l'utilisateur passe une commande, le relais devient une partie essentielle du processus, facilitant les interactions sécurisées et privées entre le portefeuille de l'utilisateur et le système plus large de Renegade. Armé des secrets délégués - le scalaire de correspondance, la graine de brouilleur et la graine de partage - le relais décrypte le portefeuille de l'utilisateur pour accéder aux détails de la commande nouvellement créée. Cette délégation fait du relais l'intermédiaire critique, reliant de manière transparente le portefeuille privé de l'utilisateur et l'écosystème commercial plus large, garantissant que la commande est assortie efficacement et en pleine conformité avec les garanties de confidentialité et de sécurité du protocole.

La première tâche du relayer est de décrypter le portefeuille en utilisant la graine aveuglante et la graine partagée, qui sont dynamiquement hachées pour chaque transaction. Cela garantit que ces valeurs sont uniques à l'opération spécifique, renforçant ainsi la confidentialité et la sécurité. Une fois décrypté, le relayer obtient un accès en lecture seule à l'état privé du portefeuille, y compris l'ordre nouvellement créé, les soldes et toutes les autres commandes en attente. Cependant, le relayer ne peut pas modifier ou interférer avec le contenu du portefeuille, car la paire de clés racine reste uniquement sous le contrôle de l'utilisateur.

Après avoir accédé à l'état du portefeuille, le relayer construit un tuple de poignée de main pour communiquer en toute sécurité l'ordre au réseau Renegade. Ce tuple contient:

• Engagements cryptographiques aux détails de la commande (par exemple, paire de jetons, montant, prix).
• Un prédicat à connaissance nulle, qui prouve cryptographiquement que l'ordre est valide selon les règles du protocole sans exposer de détails sensibles tels que les soldes du portefeuille ou les spécificités de l'ordre.
• Métadonnées supplémentaires requises pour les vérifications de compatibilité, telles que les frais et les préférences de règlement.

Le tuple de poignée de main est ensuite diffusé à d'autres relais dans le réseau pair à pair (P2P), signalant la disponibilité de l'ordre tout en veillant à ce que sa confidentialité reste intacte. À mesure que la poignée de main se propage, d'autres relais surveillent les tuples entrants pour identifier les ordres qui pourraient éventuellement correspondre à ceux gérés par leurs portefeuilles. Le relais responsable de l'ordre de l'utilisateur fait de même, recherchant en permanence des contreparties répondant aux critères spécifiés par l'utilisateur à l'aide des engagements cryptographiques et des métadonnées de compatibilité.

(Source: documentation Renegade)

Lorsqu'une correspondance potentielle est identifiée, les relais responsables des deux commandes entament une communication directe pour initier la prochaine phase : la correspondance sécurisée des commandes à l'aide du moteur de correspondance MPC. Cela garantit une transition fluide de la création de la commande à la correspondance sécurisée, tout en maintenant les garanties de confidentialité essentielles de Renegade.

Correspondance des commandes

Le processus de correspondance des commandes dans Renegade met en valeur une application innovante de DeFi.Calcul en Partie Multiples (MPC), spécialement conçu pour permettre des échanges sécurisés, privés et décentralisés. Contrairement aux implémentations traditionnelles du MPC, qui impliquent souvent la contribution de plusieurs participants pour une computation collective, le MPC de Renegade est conçu pour une configuration à deux parties. Dans ce cas, deux relayeurs, agissant chacun au nom de leurs utilisateurs respectifs, collaborent pour évaluer si leurs ordres peuvent être assortis. Cette adaptation unique du MPC garantit que aucun relayeur n'apprend de détails sensibles sur l'ordre de l'autre, tels que les types de jetons, les soldes ou les prix, tout en permettant un appariement précis et sans confiance.

(Source: Documentation de Renegade)

Le moteur de correspondance MPC commence par traiter les entrées cryptées des deux relais. Ces entrées comprennent des détails critiques tels que les paires de jetons, les montants, les prix et les états de portefeuille associés des commandes. Tout au long de ce processus, toutes les informations restent cryptées et sont représentées sous forme de parts secrètes dans le protocole MPC. Le calcul vérifie si les commandes sont alignées sur des paramètres clés, tels que la compatibilité des paires de jetons, la suffisance des soldes et les conditions de tarification. Si les commandes sont jugées incompatibles, le processus se termine sans divulguer aucune information sur la correspondance tentée, préservant la confidentialité de la transaction des deux parties.

Si le moteur MPC détermine que les ordres sont compatibles, il génère un tuple de correspondance, une représentation cryptographique de la correspondance. Ce tuple inclut des détails essentiels tels que les jetons à échanger, les montants impliqués et la direction de l'échange pour chaque participant.

Cependant, conformément à l'approche axée sur la confidentialité de Renegade, ce tuple n'est pas immédiatement ouvert. Au lieu de cela, il reste chiffré, garantissant qu'aucun des relayers ne peut accéder prématurément à son contenu ou déduire des détails sur l'ordre de la contrepartie. En différant l'exposition de ces informations, et en raison des hypothèses cryptographiques robustes du MPC Matching Engine, Renegade élimine le risque de divulgation de données sensibles pendant le processus de mise en correspondance, même en cas de relayer malveillant.

(Source: Documentation Renegade)

La principale exception est le relayer que vous choisissez avant de soumettre votre commande; comme ils sont délégués à votre clé de visualisation, un relayer malhonnête pourrait accéder à toutes vos commandes passées et futures. Néanmoins, le fait que ceci soit la seule hypothèse de confiance au sein de Renegade et que vous puissiez librement exécuter votre propre relayer rend cette préoccupation largement négligeable.

Pour valider le tuple de correspondance, les relais construisent collaborativement une preuve SNARK collaborative, qui confirme cryptographiquement que la correspondance est valide selon les règles du protocole. Cette preuve garantit que:

• Les commandes ont été correctement assorties en fonction de leurs entrées chiffrées.
• Le tuple de correspondance reflète avec précision les états de portefeuille et les commandes fournis pendant le processus MPC.
• Aucun des relayers n'a manipulé le tuple de correspondance ou soumis des données invalides au moteur MPC.

Les preuves SNARK collaboratives jouent un rôle critique dans la garantie de l'intégrité du processus de mise en correspondance. En reliant les sorties chiffrées du moteur MPC aux engagements stockés dans l'arbre d'engagements, elles fournissent un mécanisme de validation sans confiance qui garantit que la correspondance est conforme aux règles du protocole de Renegade. Ce n'est qu'après vérification de la preuve des valeurs chiffrées dans le tuple de correspondance, telles que les montants à échanger, qu'elles deviennent accessibles. Cette approche progressive protège la confidentialité commerciale des deux parties tout au long du processus de correspondance et de validation.

Une fois que la preuve collaborative de SNARK est vérifiée et que le tuple de correspondance chiffré est ouvert, le système passe à la phase de règlement. À ce stade, les ordres correspondants sont entièrement validés et prêts pour le règlement, avec tous les détails de la transaction encapsulés et vérifiés de manière sécurisée. Cette intégration transparente de MPC et de SNARK collaboratif garantit que le processus de correspondance de Renegade n'est pas seulement privé et sécurisé, mais aussi sans confiance et infalsifiable, établissant ainsi une nouvelle norme pour le trading décentralisé.

Finalisation de l'échange

Après que le tuple de match et la preuve collaborative SNARK ont été validés, le processus passe à la phase de finalisation, où les résultats de l'échange correspondant sont enregistrés en toute sécurité et préparés pour le règlement. À cette étape, toutes les validations cryptographiques nécessaires ont été effectuées, garantissant l'intégrité de l'échange tout en préservant la confidentialité des deux parties impliquées.

Pour finaliser le match, le portefeuille de chaque trader génère un enregistrement de la transaction, résumant les jetons échangés, dans quelles quantités et dans quelle direction. Ces enregistrements servent de placeholders sécurisés pour les résultats du match et sont directement liés aux engagements cryptographiques qui représentent les états de portefeuille mis à jour. Importamment, ces enregistrements sont générés de manière privée pour chaque trader et comprennent des mesures de sécurité cryptographiques pour empêcher tout accès ou manipulation non autorisés.

Après avoir vérifié les enregistrements de transactions chiffrées et les preuves, le contrat intelligent de Renegade met à jour l'arbre d'engagement et marque les commandes comme "obstruées" - empêchant toute action ultérieure jusqu'au règlement. Ces enregistrements chiffrés persistent dans l'arbre d'engagement pour référence lors du règlement. Cette phase démontre l'architecture de confidentialité et de sécurité de Renegade : les détails des transactions chiffrées combinés aux preuves cryptographiques permettent des échanges privés et sans confiance tout en assurant la vérifiabilité tout au long du processus de règlement.

Performance et évolutivité

Cette section aborde deux défis fondamentaux qui découlent des choix innovants de conception de Renegade€️

• Coûts de calcul de MPC et SNARKs : Les compromis en termes de latence et d'exigences en ressources introduits par ces techniques cryptographiques avancées.
• Scalabilité du réseau de relais : Comment l'infrastructure pair-à-pair de Renegade gère les volumes élevés de transactions et s'adapte aux besoins variables des utilisateurs.

Explorons chacun d'entre eux en détail.

Coûts de calcul de MPC et SNARKs

L'architecture de Renegade repose fortement sur le moteur de correspondance MPC et les preuves SNARK collaboratives pour offrir une confidentialité et une sécurité inégalées. Cependant, ces techniques cryptographiques avancées nécessitent des calculs substantiels. Le processus MPC exige que les relais effectuent des calculs chiffrés sur des entrées partagées secrètes, ce qui implique plusieurs étapes de communication et de calcul sécurisés pour évaluer la compatibilité des ordres. Cela entraîne une surcharge significative par rapport aux systèmes de correspondance traditionnels, en particulier lors du traitement de transactions complexes ou à fort volume.

De même, la génération de preuves SNARK collaboratives est une tâche intensive en ressources. Bien que les SNARK soient conçus pour être efficaces pour la vérification on-chain, leur création implique des opérations cryptographiques étendues, notamment lors de la preuve d'énoncés complexes tels que la validité des ordres et les transitions d'état du portefeuille. Ce coût computationnel s'ajoute au temps et aux ressources nécessaires pour effectuer un échange, ce qui le rend moins adapté aux scénarios nécessitant une négociation à haute fréquence ou instantanée.

En résumé, ces deux opérations représentent l'un des plus grands fardeaux computationnels pour les relais chargés de faire correspondre les ordres des utilisateurs. Bien que ce coût soit un compromis nécessaire pour atteindre les garanties de confidentialité et de sécurité solides qui définissent Renegade, il reste un élément clé à prendre en compte pour la scalabilité et l'expérience utilisateur.

Scalabilité du réseau de relais

La conception de Renegade minimise la confiance dans les relais, ne comptant sur eux que pour la vivacité nécessaire pour faire correspondre les transactions. Au-delà de cela, les relais n'ont aucune autorité de garde ou de prise de décision, car toutes les actions sont validées cryptographiquement par des preuves à divulgation nulle (ZKP). Cette conception sans confiance signifie que le renforcement des relais sur le plan informatique - par exemple, en augmentant leur puissance de traitement pour gérer davantage de transactions - n'introduit pas de risques importants. En même temps, l'architecture réseau de Renegade est entièrement sans permission, permettant à une diversité de relais, de tailles et de capacités informatiques variées, de coexister au sein du même écosystème sans causer de problèmes systémiques.

Cette flexibilité est l'un des points forts de Renegade. Les plus petits relayers peuvent fonctionner efficacement aux côtés des plus grands et plus puissants, garantissant un réseau robuste et décentralisé. La dépendance du protocole aux garanties cryptographiques garantit que tous les relayers, quelle que soit leur taille ou leur échelle, doivent respecter les mêmes règles strictes de validation, préservant ainsi l'équité et l'intégrité du système.

Les super relayers, d'autre part, offrent un rôle spécialisé au sein du réseau, conçu pour répondre aux besoins des utilisateurs avancés et des participants institutionnels. Contrairement aux relayers standard, les super relayers fonctionnent avec un accès clé racine délégué, leur accordant un contrôle total sur le portefeuille d'un utilisateur. Cela signifie qu'ils ne sont pas seulement fiables pour faire correspondre les transactions, mais aussi pour gérer l'ensemble du cycle de vie du portefeuille, y compris les placements d'ordres, les annulations et les ajustements de solde. En déléguant la clé racine, les utilisateurs bénéficient d'améliorations significatives en termes de vitesse et de performances, car le super relayer peut contourner les étapes de vérification on-chain pour certaines opérations.

Cependant, la délégation de la clé racine introduit un niveau élevé de confiance, ce qui rend les super relayers adaptés principalement aux entités qui exploitent leur propre infrastructure de relayer à des fins personnelles, telles que les institutions ou les traders individuels sophistiqués. Ces utilisateurs peuvent exploiter les super relayers pour optimiser leurs systèmes de trading, bénéficiant d'une exécution d'ordre quasi-instantanée et de coûts réduits tout en conservant une surveillance directe de l'infrastructure.

(Source: documentation Renegade)

Le réseau de relais de Renegade, avec son mélange de relais standard et super, est un exemple de système évolutif et adaptable. Il atteint cette évolutivité sans sacrifier la décentralisation ou la sécurité, en veillant à ce que le réseau puisse gérer diverses exigences des utilisateurs et volumes de transactions tout en conservant ses principes fondamentaux d’absence de confiance et d’autorisation.

Conclusion

Dans cet article, nous avons présenté le concept de dark pools, mettant en évidence leur rôle dans la finance traditionnelle et leur importance croissante dans la finance décentralisée. En examinant Renegade, nous avons démontré comment des innovations cryptographiques telles que les preuves de connaissance nulle et le calcul multipartite peuvent résoudre des problèmes critiques tels que le frontrunning, le quote fading et l'extraction de MEV, ouvrant la voie à des échanges décentralisés sécurisés et privés.

Avançant, la discussion sur les dark pools s'étendra pour inclure d'autres protocoles remarquables tels que Tristero et Railgun. Ces deux projets offrent des approches uniques pour améliorer la confidentialité des échanges et la qualité de l'exécution, chacun utilisant des méthodologies différentes pour atteindre leurs objectifs.

Dans les prochains articles, nous approfondirons les conceptions de ces protocoles, en explorant leurs avantages, leurs caractéristiques distinctes et comment ils se comparent les uns aux autres et à Renegade. Cette exploration plus large mettra en lumière les solutions diverses qui façonnent l'avenir de la finance décentralisée préservant la vie privée.

Avertissement :

1. Cet article est réimprimé à partir de [ 2077research]. Tous les droits d'auteur appartiennent à l'auteur original [Emmanuel Awosika et Koray Akpinar]. S'il y a des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. L'équipe de traduction de Gate Learn effectue des traductions de l'article dans d'autres langues. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.