*Faire suivre le titre original：Rapport de recherche d'Eureka Partners : Singularity : Privacy Transactions on a Transparent Blockchain

Introduction

En 1969, la méthode de négociation sur les marchés financiers était toujours basée sur les salles de marché traditionnelles. À cette époque, la technologie informatique n'était pas encore arrivée à maturité et les traders se contentaient de crier des ordres à haute voix, une méthode inefficace et peu confidentielle, qui empêchait les investisseurs institutionnels d'effectuer des transactions importantes sans provoquer de fluctuations du marché. Instinet, fondée par Jerome Pustilnik, a vu le jour en réponse à ce défi. Instinet a permis aux investisseurs de passer des ordres de manière anonyme via une plateforme de trading électronique, chargée de faire correspondre les ordres des acheteurs et des vendeurs et d'exécuter les transactions. Ce modèle a non seulement amélioré l'efficacité des transactions, mais a également garanti la confidentialité des transactions, en prévenant efficacement l'impact sur le marché et les fuites d'informations.

Aujourd'hui, les avancées technologiques ont donné naissance à la technologie blockchain, une innovation révolutionnaire qui a apporté une transparence et une sécurité sans précédent aux transactions financières. Cependant, le caractère public et l'immuabilité de la blockchain, tout en apportant de nombreux avantages au marché, présentent également de nouveaux défis pour les grands opérateurs. Dans le registre public de la blockchain, chaque transaction est visible par tous les participants, ce qui rend difficile l'anonymat des grands traders. Les plateformes d'échange traditionnelles ne peuvent pas protéger totalement la vie privée des traders, et la divulgation publique d'ordres importants peut entraîner des fluctuations de cours, affectant ainsi l'efficacité des transactions et les coûts. En outre, l'incertitude réglementaire et l'opacité des marchés présentent également des risques supplémentaires pour les investisseurs.

Ce rapport explorera les dark pools de la blockchain en tant que solution innovante qui introduit des technologies avancées de protection de la vie privée et des mécanismes de négociation automatisés afin de fournir un environnement plus sûr et plus efficace pour les transactions importantes en cryptomonnaies. Il expliquera également comment Singularity, grâce à ses solutions innovantes utilisant des technologies telles que le FHE (cryptage entièrement homomorphique) et le ZKP (Zero-Knowledge Proof), offre aux grands investisseurs une plateforme de trading décentralisée privée et conforme.

Qu'est-ce que Dark Pools ?

Les dark pools sur les marchés financiers traditionnels font référence à des plateformes de trading privées qui ne divulguent pas publiquement d'informations commerciales, ce qui permet aux investisseurs d'effectuer des transactions importantes sans dévoiler leurs intentions de trading. L'émergence du dark pool trading aux États-Unis est étroitement liée à la demande croissante de transferts d'actions à grande échelle en raison de la fréquence croissante des fusions et acquisitions sur le marché des valeurs mobilières. Avec le développement des marchés financiers, l'importance des dark pools dans divers domaines tels que les actions, les obligations et les changes prend de plus en plus d'importance, en particulier à une époque où le trading à haute fréquence et algorithmique domine. Les statistiques montrent que les transactions du dark pool représentent 30 à 50 % du marché boursier, devenant ainsi un élément important de la liquidité du marché.

Sur le marché des cryptomonnaies, alors que le nombre de grands investisseurs augmente, la demande de transactions de gros volumes continue d'augmenter. Ces commandes importantes ont un impact significatif sur le marché, provoquant parfois des bouleversements sur le marché. Pour éviter de tels risques, de nombreux traders se tournent vers le marché OTC ou même vers les groupes Telegram pour leurs transactions. Selon les données de la bourse Kraken en 2020, le volume mondial des transactions de gré à gré a été multiplié par 20 depuis 2018, avec un volume de transactions quotidien moyen d'environ 300 milliards de dollars, soit près de 70 % du volume total des transactions sur le marché des crypto-monnaies. Cependant, le marché de gré à gré est également confronté à des problèmes de liquidité insuffisante et d'absence de réglementation. Pour relever ces défis, des dark pools ont été introduits comme solution, dans le but de créer un environnement commercial plus stable et plus privé.

Les points clés à propos de Dark Pool sont les suivants :

• Vie privée et confidentialité : les dark pools permettent aux traders d'effectuer des transactions de manière anonyme, protégeant ainsi leur identité et la taille de leurs ordres sur le marché public jusqu'à ce que la transaction soit exécutée.

• Impact réduit sur le marché : les dark pools permettent aux grands investisseurs institutionnels d'exécuter des ordres importants sans provoquer de fluctuations importantes des cours sur le marché public, minimisant ainsi l'impact et les dérapages du marché.

• Non-divulgation des stratégies de trading : les transactions du dark pool contribuent à empêcher que les stratégies des traders ne soient connues du marché public, en les empêchant d'être exploitées par le MEV (Miner Extractable Value), l'arbitrage de copy trading et l'arbitrage statistique.

• Liquidité et amélioration des prix : Les dark pools fournissent des liquidités supplémentaires au marché en mettant en relation des acheteurs et des vendeurs qui ne trouvent peut-être pas de contrepartie sur les bourses traditionnelles, ce qui peut proposer des améliorations de prix, en particulier pour les transactions de gros volumes.

• Supervision réglementaire : les dark pools sont réglementés, les organismes de régulation surveillant les activités des dark pools afin d'empêcher tout accès déloyal, tout délit d'initié ou toute manipulation de marché. Cependant, pour de nombreux dark pools, le style de gestion centralisée présente toujours des risques en termes de sécurité, de fiabilité et d'utilisation abusive de données privées. Dans le passé, il y a eu plusieurs cas où des dark pools centralisés ont été sanctionnés pour violation des principes de confiance.

Technologies de confidentialité de base

Les dark pools sont une branche de la protection de la vie privée. Grâce aux technologies améliorant la confidentialité (PET) suivantes, telles que Zero-Knowledge Proofs (ZKP), le calcul multipartite (MPC) et le cryptage entièrement homomorphique (FHE), les dark pools injectent de la confidentialité dans leur infrastructure.

Zero-Knowledge Proof (ZKP)

La technologie Zero-Knowledge Proof (ZKP) permet à un prouveur de prouver l'exactitude d'une déclaration à un vérificateur sans révéler aucune information de fond. Cette technologie est particulièrement cruciale pour les solutions de mise à l'échelle de couche 2 d'Ethereum, telles que ZK Rollup, qui permet de vérifier la validité des transactions en compressant les données des transactions en preuves ZK compactes et en les soumettant au réseau principal. Ces preuves occupent non seulement un espace de stockage minimal, mais protègent également la confidentialité des informations relatives aux transactions, incarnant ainsi les avantages naturels d'un mécanisme fiable. L'application de la technologie ZKP ne se limite pas à la mise à l'échelle mais inclut également l'informatique de confidentialité, ses principales implémentations étant zkSnarks, zkStarks et Bulletproofs. Ensemble, ces technologies contribuent à améliorer la protection de la confidentialité des cryptomonnaies et l'efficacité des transactions.

Présentation des preuves de connaissance nulle

Calcul multipartite (MPC)

Le calcul multipartite (MPC) est une technologie qui permet à plusieurs parties de calculer une fonction ensemble sans révéler leurs entrées individuelles. Dans le domaine de la confidentialité, MPC propose une méthode pour protéger les données sensibles, en permettant aux parties d'effectuer des analyses de données, des tâches de calcul ou de prendre des décisions sans divulguer de données personnelles. Le principal avantage du MPC réside dans sa capacité à protéger la vie privée. Grâce à l'informatique distribuée et aux technologies de cryptage, les participants peuvent garantir la confidentialité de leurs données tout au long du processus de calcul.

Présentation du calcul multipartite sécurisé

▪ Chiffrement entièrement homomorphe (FHE)

Le cryptage entièrement homomorphique (FHE) est une technologie cryptographique qui permet de calculer directement des données cryptées sans avoir à les déchiffrer au préalable. Cela signifie que des opérations telles que l'addition, la soustraction et la multiplication peuvent être effectuées sur des données alors qu'elles restent cryptées, et que les résultats des calculs, une fois déchiffrés, sont cohérents avec ceux obtenus en effectuant les mêmes opérations sur les données d'origine. La valeur fondamentale de FHE réside dans le fait de fournir un outil puissant de protection de la vie privée, permettant aux données de rester confidentielles pendant leur traitement, améliorant ainsi de manière significative la sécurité des données.

Trouver un équilibre entre lutte contre la censure et conformité

Les bourses décentralisées (DEX) opérant sur des blockchains publiques, telles qu'Uniswap et Curve, sont sensibles à la valeur extractible maximale (MEV) en raison de la nature publique et transparente de leurs registres. Cette transparence signifie que les détails des commandes sont visibles par tous, ce qui permet aux chercheurs et aux constructeurs d'optimiser leurs profits en réorganisant les ordres de transaction, ce qui peut avoir un impact négatif sur les autres utilisateurs dans une certaine mesure.

Les dark pools, en tant que plateforme de négociation financière, ont pour principaux avantages de protéger la vie privée et de lutter contre la censure. Dans les dark pools, les détails des commandes sont généralement tenus secrets pour les tiers, car chaque commande génère des preuves à connaissance nulle (ZKP), ce qui réduit la divulgation publique des informations sur les transactions. Cette architecture est particulièrement intéressante pour les grands détenteurs et les investisseurs institutionnels, car elle protège leurs stratégies de trading contre l'exploitation par des concurrents ou des manipulateurs de marché. De plus, les caractéristiques des dark pools contribuent également à résister au MEV, car l'ordre et les détails des transactions ne sont pas publics, ce qui réduit les risques de réarrangement.

Cependant, ces avantages peuvent diminuer lorsque les transactions doivent faire l'objet de marchés publics ou utiliser des séquenceurs partagés, car ces opérations peuvent exposer des informations sur les transactions, offrant ainsi des opportunités de capture MEV. Néanmoins, pour les grands détenteurs et les investisseurs institutionnels qui recherchent une protection contre la censure et la confidentialité, en particulier lorsque leurs activités commerciales exigent un niveau élevé de confidentialité, les dark pools restent une option intéressante.

L'émergence d'outils de protection de la vie privée tels que Tornado Cash offre la possibilité de mener des activités financières anonymes en chaîne, mais ces outils ont également été utilisés par des criminels pour des activités illégales telles que le blanchiment d'argent. L'adresse du contrat intelligent de Tornado Cash a été répertoriée par l'Office of Foreign Assets Control (OFAC) pour cause de non-conformité. L'OFAC tient à jour une liste de ressortissants spécialement désignés (SDN) pour sanctionner les personnes et les entités non conformes. Les protocoles non conformes aux réglementations de l'OFAC ont de fortes chances que leurs transactions soient exclues des blocs en chaîne. Au 23 février 2024, 45 % des blocages nécessitaient une révision de la liste de l'OFAC. Ce problème de lutte contre la censure touche non seulement les producteurs de blocs, mais aussi les validateurs et les relayeurs, qui peuvent ignorer certaines transactions ou certains blocs de manière sélective.

Proportion de blocs revus par les listes de l'OFAC

Tornado Cash ayant été bannie pour non-conformité, un vide de marché en matière de solutions de confidentialité conformes est apparu. Pour combler ce vide, les prochains projets de dark pool doivent protéger la vie privée tout en évitant des risques réglementaires similaires. Une méthode efficace consiste à intégrer des processus KYB/KYC vérifiés au projet, afin de garantir la légalité des activités des utilisateurs et d'éviter les risques réglementaires potentiels. Les réglementations légales sont souvent à la traîne par rapport aux avancées technologiques, ce qui rend les projets de confidentialité facilement exploitables à des fins illégales. Il est crucial d'adopter et de respecter activement les réglementations pour garantir la sécurité et la légalité du projet.

Paysage de la compétition & Analyse de projets

Entre 2010 et 2022, le nombre de projets de dark pool était limité, et ces projets n'ont pas été largement reconnus par le grand public. Cependant, grâce à l'avancement des technologies renforçant la confidentialité, telles que Zero-Knowledge Proofs (ZKP) et Multi-Party Computation (MPC), le domaine du dark pool a accueilli une série de solutions technologiques innovantes. Le développement de ces technologies a refait connaître les dark pools au grand jour en 2023. Néanmoins, en raison de la complexité de la technologie, le nombre de projets dans la course au dark pool est encore relativement faible. Voici quelques projets qui ont atteint une certaine maturité.

1. Renegade, créé en 2022, est un dark pool décentralisé basé sur l'architecture MPC-ZKP, conçu pour fournir des services de transactions importants aux investisseurs institutionnels. Renegade effectue le rapprochement des commandes via un réseau peer-to-peer et la technologie de calcul multipartite (MPC) et utilise zk-SNARKS pour garantir l'anonymat des informations sur les transactions pour les personnes extérieures pendant le processus de vérification de la correspondance des commandes. En outre, il utilise un mécanisme d'exécution intermédiaire pour garantir que toutes les transactions sont réglées directement au cours médian agrégé en temps réel des bourses centralisées afin d'éviter tout dérapage. Sa fonction d'échange croisé anonyme par défaut, associée à des indicateurs d'intérêt, permet une découverte complète des cours et optimise la liquidité.

2. Penumbra est une plateforme de trading décentralisée intégrée à l'écosystème Cosmos. Elle propose un environnement de trading semblable à un dark pool qui permet aux utilisateurs de négocier tout en préservant leur confidentialité. Grâce à un mécanisme de délégation privée, Penumbra combine la protection de la vie privée et le mécanisme de consensus Proof-of-Stake (PoS), en proposant des dérivés de jalonnement, un jalonnement fiscalement avantageux et une gouvernance en chaîne avec vote privé. Penumbra se connecte à l'écosystème Cosmos via la communication inter-blockchain (IBC), faisant office de dark pool à l'échelle de l'écosystème qui permet des transactions privées sur n'importe quel actif compatible IBC. Les utilisateurs peuvent également utiliser ZSwap, une plateforme d'échange privée décentralisée qui propose des enchères par lots et des liquidités concentrées, comme Uniswap-V3, pour échanger ces actifs.

3. Panther est une plateforme DeFi inter-chaînes qui intègre une technologie à connaissance nulle, dans le but de fournir une solution à la fois conforme à la réglementation et protégeant la vie privée des utilisateurs. Les utilisateurs peuvent déposer des actifs numériques dans les pools blindés multi-actifs (MASP) de Panther et recevoir des actifs sur une base individuelle. Grâce au module Zswap, Panther se connecte à d'autres protocoles DeFi, agrégeant les devis pour les sélectionner par les utilisateurs. Lors des transactions, Zswap crée un contrat d'entiercement crypté, permettant aux utilisateurs d'échanger des actifs sans divulguer les détails des transactions. Cette conception permet aux actifs de coexister dans différents pools, tout en préservant l'hétérogénéité des données et en compliquant le suivi et la désanonymisation des utilisateurs. Les pools blindés de Panther exploitent les technologies ZK SNARK et ZKP pour garantir la confidentialité et la conformité des transactions.

4. Railgun est un système de confidentialité doté d'une architecture ZKP-MPC conçu pour Ethereum, BSC, Polygon et Arbitrum. Il utilise la technologie de cryptage à connaissance nulle (ZK) et la technologie MPC pour une cérémonie de configuration fiable. Il permet aux utilisateurs d'exécuter des contrats intelligents et des opérations DeFi en toute sécurité tout en préservant la confidentialité des transactions. Lorsque les utilisateurs émettent des ordres de transaction via Railgun, un contrat intelligent Adapt Module traite automatiquement la protection de la confidentialité du solde privé, valide la commande, puis relaie pour trouver le meilleur taux de change en termes de liquidité DEX agrégée, pour enfin reprotéger les actifs des transactions afin de garantir l'anonymat de l'activité et des adresses des utilisateurs. Ce processus ne s'applique pas seulement aux échanges d'actifs, mais peut également être étendu à d'autres types de transactions DeFi.

Interprétation technique de la singularité :

Comment mettre en œuvre des transactions privées

Comprendre le concept de transactions privées

Pour comprendre le concept de transactions privées, il est essentiel de prendre en compte à la fois les parties impliquées dans la transaction et les spécificités de celle-ci, en faisant la différence entre deux types de confidentialité : l'anonymat et la dissimulation.

Une transaction standard inclut les éléments suivants :

• Parties à la transaction : Cela inclut l'expéditeur (trader A) et le destinataire (trader B) de la transaction.

• Détails de la transaction : Cela inclut le montant de la transaction, le nombre de sous-transactions, le hachage de la transaction et d'autres détails spécifiques.

Les transactions privées peuvent être classées en deux types en fonction du niveau de visibilité des informations pour les tiers :

• Transactions anonymes : Dans les transactions anonymes, les adresses de l'expéditeur et du destinataire sont inconnues des tiers. Cela signifie que pendant le processus de transaction, à l'exception des deux parties impliquées dans la transaction, personne d'autre ne peut identifier les participants en question. Par exemple, Tornado Cash est un protocole de confidentialité qui garantit l'anonymat en masquant les chemins de transaction.

• Transactions dissimulées : Dans les transactions masquées, bien que les adresses de l'expéditeur et du destinataire soient visibles, les détails spécifiques de la transaction ne sont pas connus. Cela signifie que le montant de la transaction, le nombre de sous-transactions, le hachage de la transaction et d'autres informations détaillées sont cachés aux tiers. Ce type de confidentialité peut être atteint grâce à des technologies telles que Zero-Knowledge Proofs (ZKP). Par exemple, Zcash est une cryptomonnaie confidentielle qui utilise la technologie zk-SNARKS pour dissimuler les détails des transactions.

Interprétation globale de l'architecture de la singularité

Présentation de l'architecture Singularity

Si l'on considère la structure générale, elle peut être divisée en 5 modules environ :

1. Singularité

Il s'agit du contrat intelligent avec lequel les utilisateurs interagissent principalement, utilisé pour exprimer et exécuter la logique du circuit ZK. Les fonctionnalités de ces contrats intelligents incluent le masquage du solde et des enregistrements de transactions des jetons ETH/ERC20 pour garantir l'anonymat et la dissimulation du contenu des transactions. Il fait office de pool de liquidités qui regroupe tous les actifs de tous les types de traders. Son nom vient de sa caractéristique unique, à savoir que, pour tous les observateurs, toutes les transactions protocolaires semblent provenir de ce contrat intelligent. Ce design offre aux utilisateurs une confidentialité multidimensionnelle.

Dans le protocole Singularity, les ZK Notes constituent l'unité de base des transactions. Elles contiennent des informations critiques sur les transactions, notamment le type d'actif, le montant et un identifiant crypté lié au propriétaire. La conception de ces billets vise à fournir un haut niveau de protection de la vie privée, en garantissant que l'identité des traders et les informations sur les actifs sont protégées efficacement.

Chaque note contient les informations clés suivantes :

• Type d'actif : indique le type d'actif impliqué dans la transaction, par exemple le type de jeton d'une crypto-monnaie ou d'autres actifs numériques.

• Montant : indique la quantité d'actifs contenus dans le billet, utilisée pour déterminer la valeur de la transaction.

• Rho : Une valeur de champ générée de manière aléatoire utilisée pour améliorer la confidentialité des transactions, en empêchant les observateurs externes de suivre et d'analyser les transactions.

• Clé publique Schnorr : utilisée pour la signature cryptographique et la vérification de l'identité des transactions, afin de garantir que seuls les utilisateurs autorisés peuvent effectuer des opérations de transaction valides.

Outre les informations ci-dessus, chaque note génère également un facteur d'annulation correspondant. La génération des nullificateurs utilise des techniques de hachage cryptographique, qui prennent la valeur aléatoire et la clé publique de la note comme entrées et les traitent pour produire le Nullifier correspondant. Ce design vise à renforcer la sécurité des transactions, en veillant à ce que seuls les utilisateurs autorisés légitimes puissent utiliser et utiliser le Note de manière efficace.

Ajout et stockage de notes

Dans le protocole Singularity, toutes les notes sont associées à un arbre Merkle accessible uniquement en tant qu'appendice, et la racine du nouvel arbre Merkle est enregistrée de façon permanente. Le but de ce design est de garantir l'intégrité et la sécurité des transactions, en empêchant la falsification et la corruption des données.

Pour illustrer par un exemple simple :

Supposons qu'Alice utilise le protocole Singularity. À un moment donné, elle effectue une transaction en déposant 1 ETH dans le contrat Singularity. Cette transaction sera enregistrée sous forme de note et attachée à l'arbre Merkle actuel. En ce moment, la racine de l'arbre Merkle est calculée à partir de cette seule note.

Par la suite, Bob effectue également une transaction en déposant 0,5 ETH dans le cadre du contrat Singularity. Cette transaction sera également enregistrée sous forme de note et ajoutée à l'arbre Merkle actuel. La racine de l'arbre Merkle est mise à jour au fur et à mesure que de nouvelles notes sont ajoutées.

Remarque : Si un nombre impair de notes est généré pour la racine de l'arbre Merkel, les deux notes individuelles seront dupliquées et leur hachage calculé.

Au fur et à mesure que de plus en plus d'utilisateurs effectuent des transactions, chaque nouvelle note est ajoutée à l'arbre Merkel par ordre chronologique. Ainsi, l'historique des transactions de chaque utilisateur est conservé dans la même structure de données, et l'intégrité de l'ensemble de l'historique des transactions peut être vérifiée efficacement en calculant le hachage racine de l'arbre de Merkel. Comme l'arbre de Merkel ne fonctionne qu'en ajout, il est impossible de modifier ou de supprimer les notes qui y ont été ajoutées, garantissant ainsi la sécurité et l'immuabilité des données de transaction.

Vérification des transactions des notes

Lorsque les traders effectuent des transactions, ils doivent indiquer le facteur d'annulation correspondant et fournir des preuves connexes sous forme de preuve à connaissance nulle afin de vérifier que l'annuleur est associé à la note correspondante et de prouver l'existence de la note dans l'arbre de Merkel. Les contrats intelligents vérifieront le caractère unique de l'annulateur et la validité des preuves afin de garantir la légalité et la sécurité de la transaction.

Par exemple :

Supposons qu'Alice possède un billet contenant 1 ETH qu'elle a déposé dans le cadre du contrat Singularity et que l'annulateur de ce billet soit « AAA123 ». Maintenant, Alice veut utiliser ces fonds pour une transaction. Elle doit donc fournir « AAA123 » comme facteur d'annulation et prouver les deux points suivants par une preuve à connaissance nulle :

1. Prouvez que « AAA123 » est associé au billet dépensé, c'est-à-dire que les fonds de cette transaction proviennent bien de ce billet.

2. Prouvez l'existence du billet dans l'arbre de Merkel, c'est-à-dire qu'il a déjà été déposé dans le cadre du contrat Singularity et qu'il n'a pas été falsifié.

Le contrat intelligent vérifiera le Nullifier et les preuves fournies par Alice afin de garantir l'unicité de l'annuleur et la validité des preuves. Ce n'est qu'une fois la vérification terminée que le contrat exécutera la transaction et transférera les fonds au destinataire souhaité par Alice. Ainsi, le contrat intelligent garantit la légalité et la sécurité de la transaction, en empêchant toute activité malveillante ou frauduleuse.

Voici l'implémentation en pseudocode de la logique ci-dessus :

//Pseudocode
solidité du pragma ^0.8.0 ;
contract SingularityContract {
 mappage (address = > mapping (bytes32 = > bool)) private InvalidValues ;
 mappage (bytes32 = > bool) privé MerkleTree ;
 //Opération de dépôt, dépôt de fonds dans le cadre du contrat Singularity
 dépôt de fonction (bytes32 NoteHash, bytes32 InvalidValue) public payable {
       require(msg.value > 0, "Deposit amount must be greater than 0");
       // Add the Note to the Merkel tree
       merkleTree[noteHash] = true
       // Store the nullifier
       invalidValues[msg.sender][noteHash] = true;
   }
   //Opération de dépenses liées aux transactions, vérification de l'annuleur et des preuves, exécution de la transaction
 fonction spend (bytes32 NoteHash, bytes32 InvalidValue, bytes memory proof) public {
       // Verify that the provided nullifier matches the stored one
       require(invalidValues[msg.sender][noteHash], "Invalid value does not match");
       // Verify the existence of the Note in the Merkel tree
       require(merkleTree[noteHash], "Note does not exist in the Merkle tree");
       // Verify the zero-knowledge proof
       require(_verifyProof(noteHash, invalidValue, proof), "Proof verification failed");
       // Execute the transaction, transferring funds to the recipient
       // The specific transfer operation is omitted here
   }
   //Fonction de vérification de preuve de connaissance nulle
 function _VerifyProof (bytes32 NoteHash, bytes32 InvalidValue, bytes memory proof) La vue privée renvoie (bool) {
       // In practice, specific zero-knowledge proof verification is required
       // The specific verification process is omitted here
       // If the proof is successfully verified, return true, otherwise return false
       return true;
   }
}

1. Réserver

Book utilise la technologie de cryptage entièrement homomorphique (FHE) pour créer un carnet d'ordres hors ligne totalement privé, offrant ainsi aux traders un environnement de trading sécurisé et fiable. Au sein du système Book, un groupe spécial de nœuds FHE, appelés Bookies, joue un rôle essentiel en gérant collectivement le carnet de commandes. Le processus de jumelage inclut :

Les nœuds API chiffrent les commandes pour garantir la confidentialité du contenu des commandes. Ensuite, les bookmakers utilisent le protocole FHE pour effectuer des calculs de correspondance des commandes, tout en préservant la confidentialité des informations relatives aux commandes. Les résultats de l'appariement des commandes sont publiés, mais le contenu original de la commande reste confidentiel afin de protéger le droit à la vie privée des traders. Les traders correspondants peuvent communiquer et régler directement grâce à la fonction Swap du contrat Singularity, tandis que les traders qui ne parviennent pas à un règlement seront passibles de sanctions en matière de réputation.

Pour garantir le fonctionnement stable du système Book, un mécanisme d'incitation basé sur la règle de la majorité est adopté, et les bookmakers sont tenus de miser des jetons :

• Les bookmakers utilisent un mécanisme de règle majoritaire pour résoudre d'éventuels désaccords en matière de correspondance cryptée des commandes, afin de prévenir les activités malveillantes.

• Le jalonnement de jetons vise à se prémunir contre les attaques de Sybil tout en incitant les bookmakers à s'acquitter de leurs tâches et à garantir le bon fonctionnement du système.

Dans le système Book, la gestion de l'identité et de la réputation est essentielle, avec des innovations telles que :

• Chaque identité anonyme correspond à une réputation qui reflète sa probabilité de règlement historique, tout en préservant la confidentialité de l'identité.

• Les traders peuvent définir des seuils de réputation pour filtrer les contreparties correspondant aux commandes, afin de garantir la sécurité et la fiabilité des transactions.

• Les traders qui ne parviennent pas à un règlement seront pénalisés en termes de réputation, ce qui affectera également la réputation de leurs homologues commerciaux.

Supposons par exemple qu'Alice veuille acheter 1 ETH,

• Soumission des commandes : Alice passe une commande pour acheter 1 ETH au prix spécifié de 2 000 dollars USDT.

• Correspondance des commandes : le système Book trouve un vendeur, Bob, prêt à vendre 1 ETH à 2 000 dollars USDT.

• Confirmation de la transaction : Alice et Bob confirment que leurs commandes ont été passées avec succès.

• Règlement de la transaction : Alice paie 2 000 dollars USDT à Bob et reçoit 1 ETH. Le système Singularity met à jour le solde de leurs comptes.

• Gestion de la réputation : si Bob ne termine pas la transaction à temps ou présente d'autres comportements négatifs, sa réputation risque d'être entachée, ce qui amène le système à restreindre sa correspondance avec d'autres traders. Si la note de réputation de Bob est de 5, cela signifie que c'est un trader fiable. Cependant, s'il ne termine pas la transaction à temps ou s'il adopte d'autres comportements négatifs, tels que l'annulation de commandes à plusieurs reprises ou une manipulation malveillante du marché, sa réputation pourrait en être affectée. Cela pourrait entraîner une baisse d'un point de sa note de réputation à 4, limitant ainsi encore son futur seuil de participation au trading.

1. Automatisation

Automation est un AMM-DEX intégré au protocole, Book agissant en tant que fournisseur de liquidités alternatif. Comme les traders peuvent effectuer des transactions via Singularity pour déposer des fonds et que Singularity est anonyme, les dépôts dans Automation le sont également. Cela signifie que l'identité des traders n'est pas révélée, protégeant ainsi leur vie privée.

Les traders peuvent retirer des fonds auprès d'Automation à tout moment et les transférer vers le contrat Singularity. Cette flexibilité permet aux traders de gérer librement leurs fonds et de les retirer en cas de besoin. De même, comme le contrat Singularity lui-même est anonyme, le processus de retrait préserve également l'anonymat des traders.

Pour les commandes qui ne peuvent être associées à aucune commande dans Book, Automation proposera un appariement afin d'augmenter la liquidité. Cela garantit que même si les ordres ne sont pas immédiatement correspondants, les ordres des traders peuvent toujours être traités et leurs transactions peuvent se poursuivre. En fournissant des liquidités supplémentaires, Automation améliore l'efficacité globale et l'expérience de trading du protocole.

1. Relayeuse

Dans Singularity, le Relayer joue un rôle crucial, puisqu'il est chargé de soumettre les méta-transactions pour le compte des utilisateurs et de payer les frais de gaz pour les transactions des utilisateurs. Ce design est motivé par le désir de protéger l'anonymat des utilisateurs. Comme les frais de gaz doivent être payés sur la blockchain de base généralement publique, si les utilisateurs devaient payer leurs propres frais de gaz, leur identité pourrait être révélée.

Les relais s'acquittent de cette tâche en soumettant des méta-transactions. Les méta-transactions sont vérifiables et calculables en mode natif, ce qui empêche les relais de falsifier ou d'altérer le contenu des transactions, garantissant ainsi la sécurité et l'intégrité des transactions. De plus, pour empêcher les comportements malveillants de la part des relais, le système est conçu avec un réseau de relais fiable. Cela signifie que n'importe qui peut gérer un Relayer sans avoir à fournir de garantie.

Les transactions soumises par les utilisateurs et les frais associés sont publics et seront versés à Relayers pour les indemniser pour les frais de gaz qu'ils couvrent. Cette conception fait du réseau Relayer un système rationnel, dans lequel l'entreprise accepte et soumet toutes les transactions rentables. Même s'il existe des relais malveillants, la présence d'au moins un relais honnête garantit l'exhaustivité du système. Bien entendu, les traders ont la possibilité de gérer leur propre relais et de remplacer les frais de gaz, mais au détriment de la confidentialité.

1. API

L'API sert de nœud d'interface permettant aux utilisateurs d'interagir avec le protocole. Grâce à l'API, les utilisateurs peuvent générer et soumettre des preuves du contrat Singularity, gérer les commandes sur le Book, écouter le Book pour trouver des correspondances et négocier des règlements sur le contrat Singularity. De plus, l'API permet aux utilisateurs d'interagir avec les relais.

Transactions de confidentialité

Sur la base de la structure susmentionnée, les transactions de confidentialité mentionnées plus haut peuvent être mises en œuvre :

• Transactions anonymes (automatisation)

Lorsque vous effectuez des transactions avec Automation, étant donné que les traders doivent effectuer une opération de dépôt, le montant d'argent promis à chaque fois sera dévoilé, tout comme chaque dépôt sur Singularity ne peut éviter d'être entendu par des tiers qui écoutent les détails de la transaction. Par conséquent, effectuer des transactions par le biais de l'automatisation sacrifiera la dissimulation de la transaction.

Il convient de noter que lorsque le livre ne peut pas correspondre à un trader, même si son ordre peut être inclus dans le pool de négociation automatisé pour l'appariement (ce qui semble révéler l'adresse du trader), l'anonymat du trader est toujours garanti, car l'entité qui transfère ses liquidités est Singularity.

• Transactions anonymes et dissimulées (règlement par singularité)

Lors du règlement de transactions par le biais de Singularity, quelle que soit la manière dont la découverte du prix de la transaction et l'appariement des intentions sont effectués, le règlement final de la transaction peut toujours garantir son anonymat et sa dissimulation. Cela est dû au fait que le contrat Singularity est responsable du règlement des fonds et du transfert final des fonds, garantissant ainsi une visibilité au grand jour tout en opérant dans le noir.

Dark Pool Trading : la mise en œuvre de Singularity

Le processus de négociation de Singularity

Un dark pool, destiné aux grandes institutions et aux traders professionnels, fournit une plateforme de trading sans affecter les cours du marché. Il répond principalement à deux types de besoins commerciaux : le transfert et le swap. Dans ce qui suit, nous expliquerons comment Singularity met en œuvre ces deux types de transactions en fonction du contenu décrit dans le schéma ci-dessus. Il est important de noter que les nœuds API et les nœuds de trading font partie du même nœud dans le schéma ; pour plus de clarté, ils sont décrits comme deux types de nœuds différents ici.

1. Transactions de transfert

Les transactions de transfert ont lieu principalement entre deux nœuds Trader. Nous définissons le nœud Trader récepteur comme Trader A et le nœud Trader expéditeur comme Trader B. Le processus spécifique pour une transaction entre le trader A et le trader B est le suivant :

1) Lorsqu'il effectue une transaction, le trader B doit déposer des fonds dans le cadre du contrat Singularity. Le trader B chiffre cette transaction de dépôt en appelant une API, générant ainsi un ZK Proof, également appelé ZK Note, et le fournit au contrat Singularity pour vérifier que le trader B a déposé les fonds.

2) Après avoir déposé les fonds, le trader B lance une transaction de transfert en appelant une API pour envoyer une note ZK au contrat Singularity.

3) À la réception de la note du trader B, le contrat Singularity identifie le trader A correspondant sur la base des informations fournies dans la note. À ce stade, le trader A peut extraire le montant de la transaction de transfert du contrat Singularity.

Au cours de ce processus, nous observons que l'interaction entre les nœuds et le contrat s'effectue via ZK Notes. Les notes utilisent le modèle UTXO pour le transfert, qui garantit intrinsèquement un certain degré de confidentialité et d'anonymat par rapport au modèle de compte. Cette méthode garantit que les détails d'une transaction ne sont connus que de son initiateur, tandis qu'en externe, il semble qu'une adresse ait interagi avec le contrat Singularity. Cependant, les informations de base sur les transactions, telles que l'adresse du destinataire ou le montant de la transaction, ne peuvent pas être saisies.

1. Transactions d'échange

Par rapport aux transactions de transfert, les transactions de swap sont un peu plus complexes en raison de la nécessité de trouver une contrepartie commerciale. Ici, nous définissons le nœud Trader qui souhaite participer à une transaction de Swap comme Trader C et le nœud Trader du partenaire commercial finalement trouvé comme Trader D. Le processus de transaction spécifique entre le trader C et le trader D est le suivant :

1) Comme pour la première étape de la transaction de transfert, le trader C doit déposer des fonds dans le contrat Singularity, et simultanément, le trader C initiera une transaction d'ordre vers le nœud Book en appelant une API.

2) Agissant en tant que nœud du carnet d'ordres hors chaîne, le nœud Book tente de faire correspondre les différentes transactions d'ordres dans un environnement de cryptage entièrement homomorphique (FHE) sans connaître les détails spécifiques des transactions de commande.

a. Une fois la correspondance réussie, le nœud Book avertira les deux nœuds Trader correspondants pour qu'ils poursuivent la transaction.

b. Si l'appariement échoue, le Book déposera les fonds liés à cette transaction dans l'automatisation de la chaîne en tant que liquidité réservée. Cela revient à déposer de l'argent de rechange dans un service d'épargne comme Yu'e Bao. S'il y a toujours des transactions qui ne correspondent pas plus tard, ils donneront la priorité aux transactions depuis l'Automation. Ce n'est que lorsque les fonds d'Automation seront insuffisants pour terminer la transaction que celle-ci interagira avec des DEX externes tels qu'Uniswap dans le cadre du contrat Singularity.

Après avoir trouvé l'homologue commercial et négocié les détails du Swap, les traders signeront les détails de la transaction d'un commun accord. Ensuite, chaque partie peut utiliser ces signatures pour créer une preuve à connaissance nulle, permettant ainsi à la transaction de changer le propriétaire de Notes sans que les deux parties ne soient en ligne. Il est important de noter que pour protéger la confidentialité des transactions, les transactions Swap sont toujours effectuées dans le cadre du contrat Singularity.

Nous pouvons donc constater que Singularity utilise principalement les technologies ZK (Zero Knowledge) et FHE dans le processus de transaction afin de garantir la confidentialité et l'anonymat. L'utilisation de la technologie ZK garantit que les détails de chaque transaction ne sont connus que de l'initiateur, tout en permettant aux autres traders ou au contrat Singularity de les vérifier rapidement ; la technologie FHE permet au nœud Book de calculer des transactions identiques pendant le processus de rapprochement sans avoir besoin de connaître les détails spécifiques des transactions, et préserve également la confidentialité des informations originales sur les transactions lorsqu'il informe les deux parties, ce qui signifie que les parties ne savent que avec qui elles négocient, mais pas le type d'actif et le montant spécifiques du commerce.

Résumé et évaluation

Le marché OTC représente près de 70 % du volume des transactions du marché des cryptomonnaies, ce qui met en évidence la forte demande de transactions confidentielles dans le secteur du Web3. Cependant, le secteur du négoce de confidentialité est toujours confronté à de nombreux défis, tels que le respect des exigences réglementaires des organismes gouvernementaux, la réalisation de transactions sans révéler d'informations spécifiques sur les utilisateurs et les transactions, et la prévention des actions malveillantes de la part des parties commerciales. Les dark pools décentralisés tels que Singularity constituent une solution innovante qui peut offrir aux utilisateurs des niveaux plus élevés de protection de la vie privée et de résistance à la censure grâce à l'utilisation de technologies de confidentialité et de contrats intelligents, réduisant ainsi le recours à des entités centralisées. Ces plateformes prennent en charge les transactions importantes de manière anonyme et peuvent s'intégrer aux services de conformité afin de créer un environnement commercial à la fois décentralisé et conforme à la réglementation.

Points clés à prendre en compte pour le secteur du dark pool :

1. Architecture technique : Zero-Knowledge Proofs (ZKP) et le calcul multipartite (MPC) sont essentiels au secteur des dark pools, car ils permettent de vérifier la validité des transactions sans révéler les détails des transactions. De nombreux protocoles actuels reposent largement ou entièrement sur le MPC, ce qui présente deux inconvénients principaux : une faible efficacité informatique et une complexité du protocole. Les protocoles MPC nécessitent de prouver et de vérifier les ZKP dans le cadre d'un framework MPC, qui demande beaucoup de temps de calcul. De plus, MPC a souvent besoin de connexions réseau stables, ce qui est difficile à atteindre dans un réseau mondial décentralisé. Ces facteurs rendent les protocoles entièrement basés sur le MPC peu pratiques pour les applications à grande échelle, telles que les moteurs de correspondance des commandes.

2. Anonymat et protection de la vie privée : la réglementation est un sujet incontournable dans le secteur de la confidentialité. Garantir l'anonymat total des transactions et des fonds tout en garantissant une protection suffisante de la vie privée est une tâche difficile. C'est particulièrement important pour les utilisateurs qui souhaitent négocier avec un capital conforme. Les projets Dark Pool doivent intégrer de toute urgence les processus KYB/KYC, adopter la réglementation de manière proactive et garantir que les données KYC/KYB des utilisateurs ne sont pas divulguées afin de préserver la légalité de la plateforme et la confiance des utilisateurs.

3. Liquidité & Sécurité des fonds : La liquidité est un facteur essentiel dans les opérations de dark pool. Il est vital de garantir un volume de transactions et une sécurité des fonds suffisants pour faire correspondre efficacement les ordres et renforcer l'anonymat des traders et leur volonté de participer. Dans les dark pools, l'anonymat des fonds augmente en fonction de la taille du pool, ce qui complique le suivi de certains déposants. Dans les scénarios de pénurie de liquidités, les modèles de carnets d'ordres de nombreux protocoles ont des limites lorsqu'il s'agit de faire correspondre les transactions entre les utilisateurs, car ils ne fournissent pas toujours suffisamment de liquidités pour toutes les commandes. Outre les carnets d'ordres, des mécanismes de négociation AMM innovants et l'intégration d'un plus grand nombre d'applications DeFi issues de différents écosystèmes de chaînes de blocs pourraient être des moyens efficaces d'augmenter les liquidités.

4. Évolutivité : il est essentiel de garantir une bonne évolutivité pour répondre à un nombre croissant d'utilisateurs et à des volumes de transactions croissants pour les dark pools. Les dark pools risquent de perdre s'ils font face à une augmentation du nombre de vinyles sans égaler les commandes. Par conséquent, les dark pools devraient tenir compte de leurs niveaux de règlement, de leur conception technique et de la feuille de route de leur écosystème lors de la phase de conception afin de répondre à l'augmentation des demandes de transactions, en particulier dans le cadre de cadres réglementaires de plus en plus complets.

Le dark pool trading, qui a une certaine histoire dans les secteurs traditionnels et qui n'a pas encore été réfuté en tant que solution, continue de bénéficier d'une demande de marché et d'un potentiel de développement importants. Le trading traditionnel sur le dark pool est confronté à des risques de confiance face aux traders centralisés, tandis que des projets décentralisés tels que Singularity adoptent de manière innovante un modèle « dark pool + pool transparent pour les transactions obscures », remédiant ainsi aux problèmes liés à la centralisation, au manque de confidentialité et à la faible résistance à la censure.

Contrairement aux précédents projets de trading confidentiels, Singularity propose des fonctionnalités de trading relatives à la confidentialité des actifs ainsi que des fonctionnalités de négociation d'actifs DeFi. Le marché actuel regorge d'agrégateurs de trading, mais peu d'entre eux possèdent des caractéristiques ou un design distinctifs qui améliorent la fidélité des utilisateurs. Singularity, qui sert de couche de confidentialité pour les pools transparents, répond d'abord aux problèmes commerciaux des institutions et des baleines, en préservant l'asymétrie de l'information. Par rapport aux solutions de trading actuelles en matière de confidentialité, la conception d'un dark pool (couche de confidentialité) incarne naturellement le principe qui consiste à « garder l'argent en poche », car la confidentialité est perdue si les fonds des traders entrent et sortent fréquemment de la plateforme, ce qui équivaut à une divulgation personnelle. La plupart des fonds préfèrent donc rester dans le dark pool pendant un certain temps avant de se retirer, afin de contribuer à la croissance stable de la TVL du projet et de renforcer la sécurité des utilisateurs.

Sur la base des normes susmentionnées pour les dark pools décentralisés, Singularity se distingue des solutions de dark pool actuelles pour plusieurs raisons :

• Anonymat et protection de la vie privée : Pour garantir l'anonymat, l'approche conventionnelle est Zero-Knowledge Proofs (ZKP). Il est donc essentiel de trouver les bons partenaires. Actuellement, Singularity délègue les processus KYC & KYB hors chaîne à ComplyCube (KYC) et Shufti Pro (KYC & KYB), Keyring construisant les preuves correspondantes, et les oracles les introduisant finalement sur la blockchain. Comparé à d'autres projets, Singularity est plus conforme aux exigences de conformité actuelles, évitant ainsi de futurs risques réglementaires similaires à ceux auxquels Tornado Cash est confronté.

• Sécurité des fonds : il n'est pas possible de comparer directement la sécurité des contrats. Cependant, étant donné que Singularity permet aux pools transparents d'agir comme des dark pools, cela peut empêcher les utilisateurs et les institutions de transférer des fonds, exposant ainsi leur capital à des risques liés à la sécurité des contrats à long terme. Comme indiqué précédemment, les virements de fonds fréquents effectués par des institutions/utilisateurs peuvent également exposer des adresses, ce qui nécessite un équilibre entre confidentialité des adresses et sécurité des fonds.

• Liquidité : Contrairement aux projets qui reposent uniquement sur des modèles de carnets d'ordres/AMM, Singularity introduit à la fois des carnets d'ordres et des AMM afin de maximiser l'efficacité des liquidités. Cependant, l'application elle-même peut montrer que la différence de liquidité due aux modèles de négociation n'est peut-être pas significative, en fonction des capacités de développement commercial du projet et de sa conformité, la décision finale revenant en grande partie aux utilisateurs du marché.

• Évolutivité : En termes de compatibilité des écosystèmes, la compatibilité de Singularity avec l'écosystème EVM est une question courante. Si vous n'envisagez pas de créer sa propre chaîne, l'efficacité de son règlement des transactions reste très limitée par sa couche de règlement. Dans les cas extrêmes, ces couches peuvent ne pas être en mesure de gérer les transactions à haute fréquence. Par conséquent, à moyen et long terme, les projets qui étendent la direction de l'écosystème de la chaîne d'applications seront plus évolutifs. Techniquement, Singularity opte pour le FHE+ZKP, qui est plus efficace que les solutions MPC-ZKP en raison de l'efficacité informatique élevée requise par MPC-ZKP. L'approche technologique choisie par Singularity semble donc répondre aux besoins des transactions. Du point de vue de l'expansion de l'écosystème, l'approche « pool transparent en tant que pool sombre » peut s'étendre à des scénarios non transactionnels et à d'autres contextes DeFi, offrant des possibilités imaginatives comparables à celles proposées par Uniswap V4 avec des hooks.

Tout en reconnaissant les compétences de base de Singularity, il est également important d'être consciente des risques potentiels auxquels le projet pourrait être confronté à l'avenir :

• Perte de la fonction de découverte des cours du marché : En raison de l'anonymat et du volume important de transactions dans le dark pool, les cours des actifs sur le marché peuvent ne pas refléter exactement les fluctuations au sein du dark pool. Cela se traduit par une perte de visibilité effective des cours, car les autres acteurs du marché n'ont pas accès aux informations sur les transactions du dark pool. L'exception est si les utilisateurs utilisent des DEX classiques pour découvrir les prix sur Singularity, où les prix peuvent refléter l'offre et la demande réelles du marché.

• Risque réglementaire gouvernemental : les transactions dans le dark pool, potentiellement utilisées pour échapper à la réglementation et aux normes, pourraient inciter les agences gouvernementales à mettre en œuvre des mesures réglementaires plus strictes. Cela pourrait inclure une surveillance et une réglementation renforcées des transactions dans le dark pool ou des sanctions pour les personnes et entités participant à de telles transactions. Ces mesures pourraient avoir un impact sur le développement et le fonctionnement du projet Singularity et augmenter les risques juridiques.

• Contrôle et sécurité des fonds : Les fonds étant conservés à long terme dans le cadre de contrats Singularity, comme dans un coffre-fort, il peut y avoir des risques contractuels dans des situations extrêmes. Cependant, comme Singularity n'implique pas de communication multi-chaînes et ne repose pas sur des relais de transactions, sa sécurité est au moins supérieure à celle des ponts inter-chaînes.

• Risques KYC/KYB : La forte dépendance à l'égard d'un nombre limité de partenaires pour les contrôles de qualification des utilisateurs peut entraîner des points de défaillance uniques.

En résumé, Eureka Partners considère le volet confidentialité comme un investissement stratégique important. Pour les institutions d'investissement et les autres parties prenantes, Singularity représente le dark pool trading ; cependant, pour les régulateurs, cela s'apparente plutôt à un « pool gris ». Nous prévoyons que les transactions de gré à gré et institutionnelles adopteront progressivement des méthodes de négociation réglementées en matière de confidentialité dans le dark pool. Nous pensons que le développement technologique actuel du Web3 fait des « progrès itératifs ». À la suite de la réglementation stricte de Tornado Cash, un vide visible de la demande en matière de confidentialité est apparu. Historiquement, la mise en œuvre des règles est souvent à la traîne par rapport aux avancées technologiques et aux révolutions. Lorsque la technologie fait face à des défis, nous devons nous adapter au changement et ne gâcher aucune crise. Nous avons hâte de voir Singularity devenir le prochain leader de la section ZK sur la confidentialité réglementée du dark pool.

« Ne gâchez jamais une bonne crise. » - Winston Churchill

Avertissement：

1. Cet article est reproduit par Eureka Partners, Forward the Original Title« Eureka Partners Research Report : Singularity - Privacy Transactions on Transparent Blockchains ». Tous les droits d'auteur appartiennent à l'auteur original [Oliver, Andy, Howe]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.