Introduction

Un point majeur de friction pour les utilisateurs de crypto web3 est le manque de confidentialité. Le fait que toutes les transactions soient visibles sur un grand livre public, et de plus en plus : associées à un seul nom ENS lisible, constitue un obstacle pour les utilisateurs à effectuer certaines activités, ou les pousse à effectuer ces activités de manière à ce que cela entraîne une augmentation de la friction de l'expérience utilisateur. Un exemple est simplement le transfert de fonds d'un portefeuille chaud à un portefeuille froid ou vice versa. Les utilisateurs peuvent ne pas vouloir lier un portefeuille à un autre, car ils ne veulent peut-être pas que leur solde de portefeuille froid soit visible. Actuellement, les adresses Ethereum ne fonctionnent pas comme des comptes bancaires privés, car tout le monde peut voir votre portefeuille, et de plus en plus, votre activité sociale (SBTs, attestations, activités sur diverses dapps, etc.). C'est pour ces raisons que Vitalik a cité la confidentialité comme l'une des raisonstrois transitions techniques majeuresque Ethereum doit subir pour être utile aux utilisateurs moyens.

Utiliser des solutions de confidentialité existantes, telles que Tornado Cash, est une expérience quelque peu suboptimale pour plusieurs raisons. Premièrement, les utilisateurs seront légitimement préoccupés par le fait que leur adresse puisse être black-listée sur des bourses centralisées ou d'autres plateformes. Deuxièmement, l'expérience utilisateur lors de l'interaction avec des services tels que Tornado Cash n'est pas très conviviale et convient vraiment uniquement aux utilisateurs très compétents.

Les adresses furtives offrent un moyen de garantir à l'utilisateur la confidentialité dont il bénéficie avec les comptes bancaires privés, et ce, de manière facile à comprendre. De plus, les innovations autour des adresses furtives signifient que nous pouvons potentiellement le faire d'une manière qui reste conforme aux réglementations de lutte contre le blanchiment d'argent dans de nombreuses juridictions.

Demande des utilisateurs pour la confidentialité

Bien que la recherche sur les attitudes à l'égard de la vie privée chez les utilisateurs du web et du web3 ne soit pas largement disponible, la recherche ci-dessous a été découverte lors de recherches à travers le web, et les résultats s'alignent largement et démontrent qu'il y a clairement une appétence pour la vie privée des transactions.

1. Une enquête qui a été menée en 2022 et publiée par Simin Ghesmati et al. dans un article intitulé: Confidentialité perçue par l'utilisateur dans la blockchain, a déclaré que « la moitié des interviewés ont précisé que la confidentialité des transactions est très importante pour eux ». Bien que cette recherche soit plus liée à Bitcoin qu'à Ethereum, il est probable qu'il existe des attitudes similaires chez les utilisateurs d'Ethereum également. Cependant, la taille de l'échantillon pour cette recherche était assez petite (14 participants).
2. Un autre article intéressant de recherche de 2022, publié dans Frontières, intitulé Attitudes politiques, économiques et de gouvernance des utilisateurs de la blockchain, est plus complet, avec 3 710 utilisateurs de crypto-monnaie interrogés. Les résultats ont montré qu'environ un quart des répondants ont indiqué que la confidentialité était «la caractéristique la plus importante de la blockchain et des crypto-monnaies».

1. En termes d'attitudes envers la vie privée en général, Consensysresearch publiée intituléeEnquête mondiale sur Web3 et la cryptomonnaie en 2023, dans lequel ils ont interrogé 15 158 personnes en ligne dans 15 pays sur divers sujets concernant le web, et pas seulement les crypto-monnaies. L'enquête a révélé que 83 % des répondants estiment que la confidentialité des données est importante, tandis que seulement 45 % des répondants ont déclaré faire confiance à la façon dont les services Internet actuels utilisent leurs données et leurs informations personnelles.
2. Un enquête menée par le régime d'indemnisation des services financiers du Royaume-Uni, publié en avril 2023, a souligné que 9% des personnes interrogées ont cité le « désir d'anonymat/vie privée » comme raison d'investir dans les cryptomonnaies.

Adoption de protocoles de transaction furtifs

Railguna des chiffres impressionnants, avec l'utilisation du protocole qui semble croître régulièrement avec le temps, atteignant un pic de plus de 70 millions de dollars TVL et 2 milliards de dollars de volume en novembre 2024.

TVL (USD) Railgun sur Ethereum principal — source: Railgun — DefiLlama

Umbraa également vu une augmentation constante du nombre de personnes utilisant leur protocole (des personnes enregistrant une adresse furtive à leur ENS), avec près de 77K en novembre 2024 :

Inscrits cumulatifs Umbra (Cross Chain) — source : dune.com

Si nous examinons le protocole de confidentialité le plus largement connu (et malheureusement célèbre) dans Ethereum, qui est Tornado Cash, nous pouvons voir qu'il continue de connaître une utilisation significative, malgré le fait que les adresses de contrat sont techniquement sur la liste SDN de l'OFAC.

Le graphique ci-dessous montre la TVL de Tornado Cash au fil du temps. Nous pouvons observer que la première chute majeure de la TVL depuis son pic autour d'octobre 2021 a coïncidé avec une vente plus large sur les marchés de la cryptographie, la deuxième chute majeure en août 2022 correspondant à l'inscription de Tornado Cash sur la liste SDN de l'OFAC, et la troisième chute majeure correspondant à la réinscription de l'OFAC en novembre 2022. Depuis lors, cependant, Tornado Cash connaît une croissance régulière, malgré les sanctions, atteignant près de 600 millions de dollars de TVL. Cela constitue une preuve assez solide qu'il existe une demande pour la confidentialité des transactions de base sur Ethereum.

TVL (USD) Tornado Cash sur Ethereum principal - source : Tornado Cash — DefiLlama

Le paysage des adresses furtives

Cette recherche a identifié 4 solutions principales pour les chaînes EVM en production à ce jour, ce sont:

• Fluidkey
• Umbra
• Labyrinthe
• Railgun

Both Fluidkey and Umbra are based on Ethereum standards, which are:

• ERC-5564: Protocole d'adresse furtive
• ERC-6538: Registre de métadresses Stealth

Labyrinthe et Railgun sont basés sur leprotocole zerocash (qui zcashest également basé sur), qui utilise un pool protégé dans lequel les utilisateurs déposent des fonds. Zerocash utilise le concept de "notes", qui sont essentiellement des représentations cryptographiques de valeur qui permettent des transactions privées. Chaque note inclut une valeur cachée, une clé propriétaire et un numéro unique (un nullifier), avec zk-SNARKs utilisés pour vérifier la propriété sans révéler les détails, et donc transférer la valeur dans les notes. Lorsqu'une note est dépensée, son nullifier est révélé pour éviter les doubles dépenses, tandis que de nouvelles notes sont créées pour le(s) destinataire(s), formant un système UTXO à l'intérieur du pool protégé.

À un niveau élevé, les adresses furtives fonctionnent sur le principe de base selon lequel un tiers peut envoyer des fonds à une adresse qui n'a jamais existé auparavant, mais que le destinataire prévu peut découvrir et contrôler (c'est-à-dire qu'il peut ensuite dépenser ces fonds).

La norme erc-5564 spécifie un mécanisme permettant à un destinataire de publier une adresse furtive méta, à partir de laquelle de nouvelles adresses Ethereum peuvent être dérivées. Toute personne souhaitant envoyer des fonds au destinataire peut générer de nouvelles adresses à partir de l'adresse furtive méta et permettre au destinataire de prendre connaissance de ces fonds sans qu'aucune communication directe n'ait jamais lieu. Toutes les implémentations d'adresses furtives fonctionnent sur cette base fondamentale.

Comment fonctionnent les adresses furtives

Une méta-adresse furtive est essentiellement la concaténation de 2 clés publiques compressées, appelées "clé de dépense" et "clé de visualisation". La méta-adresse furtive utilise le format d'adresse spécifique à la chaîne EIP-3770, avec l'ajout du préfixe "st:". Voici un exemple d'adresse furtive:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Pour simplifier, cette adresse furtive peut être associée à une adresse Ethereum normale (et donc ENS), ce qui facilite l’envoi de fonds au propriétaire de l’adresse furtive. Pour envoyer des fonds, un expéditeur résoudrait l’adresse ci-dessus et, à l’aide de la norme EIP-5564, créerait une clé publique éphémère, à partir de laquelle il dériverait ensuite l’adresse furtive. L’expéditeur envoie des fonds à la nouvelle adresse furtive, généralement via un contrat singleton que tous les destinataires d’adresses furtives écoutent pour les événements. Ce contrat émet un événement « Annonce » auquel les destinataires s’abonnent. Chaque fois qu’un événement d’annonce est émis, les destinataires vérifient la clé publique éphémère dans l’annonce, la combinent avec leur clé privée d’affichage et déterminent s’ils ont la possibilité de dépenser les fonds envoyés à l’adresse furtive. Si c’est le cas, le portefeuille / client qu’ils utilisent se souviendra de l’adresse furtive et des fonds respectifs, les ajoutant au solde affiché de l’utilisateur. Pour dépenser les fonds, ils peuvent signer une transaction à l’aide de la clé de dépense privée.

Le diagramme suivant décrit le processus de bout en bout, espérons-le un peu plus clairement:

Rappelez-vous que ce processus se déroule entièrement de manière non interactive, ce qui signifie que l'expéditeur et le destinataire n'ont jamais de communication directe, ce qui signifie qu'il n'y a effectivement aucun lien entre l'expéditeur et le destinataire que toute tierce partie peut observer.

Cependant, pour que cela fonctionne en premier lieu, le destinataire doit rendre son adresse furtive connue du ou des expéditeurs. Une façon de faire est d'utiliser le Registre d'adresse méta furtive EIP-6538. Ceci est un contrat singleton qui permet aux utilisateurs d'enregistrer une adresse méta furtive à une adresse Ethereum normale, que les expéditeurs peuvent ensuite rechercher. Cela permet aux expéditeurs de résoudre l'adresse normale à partir de ENS, puis de rechercher l'adresse méta furtive associée du registre.

Ce schéma rompt le lien entre l'expéditeur et le destinataire, leur offrant à tous les deux une confidentialité vis-à-vis du monde entier qui connaît leurs affaires. Il y a quelques réserves :

• Lorsque le destinataire dépense les fonds, la personne à qui il transfère ces fonds verra qu'ils proviennent de l'expéditeur d'origine (c'est-à-dire qu'elle peut voir l'adresse à partir de laquelle les fonds ont été transférés et qui a précédemment envoyé des fonds à cette adresse). Cela signifie que la chaîne de transferts reste intacte et traçable, mais qu'elle n'est simplement pas associée au destinataire en question (à moins que le destinataire ne fasse quelque chose comme envoyer les fonds à l'une de ses adresses non furtives connues). Notez que cela ne s'applique qu'aux implémentations erc-5564, pas à Railgun ou Labyrinth.
• Un autre effet secondaire du problème ci-dessus est qu’afin de maintenir une confidentialité optimale, un utilisateur devra probablement laisser les fonds dans les adresses furtives où ils ont été initialement envoyés jusqu'à ce qu'il en ait réellement besoin, plutôt que de les consolider sous une seule adresse. Cela représente une charge supplémentaire pour se souvenir des adresses, et par la suite pour dépenser les fonds à ces adresses, car le montant que vous souhaitez transférer devra provenir de la combinaison de fonds provenant de diverses autres adresses.
• Pour transférer des fonds à partir de cette adresse, le destinataire devra financer l'adresse avec un peu d'ETH afin de payer le gaz, ce qui pourrait potentiellement déanonymiser le destinataire. Il s'agit d'un problème connu avec les adresses furtives, et une raison pour laquelle un certain nombre de mises en œuvre ont mis en place le support pour eip-4337 et un paymaster.
• Un inconvénient du schéma d'adresse furtive est que les destinataires doivent surveiller la blockchain pour les événements d'annonce et vérifier chaque annonce pour déterminer s'ils ont reçu des fonds. Cela représente évidemment une surcharge impraticable pour la plupart des utilisateurs, en particulier lorsqu'il s'agit de recevoir des fonds sur plusieurs réseaux. Pour rendre ce processus plus efficace, la norme spécifie une « balise de vue », qui est un hachage tronqué dérivé du secret partagé et peut être utilisé pour rapidement rejeter les transactions qui ne leur sont certainement pas destinées. Grâce à l'utilisation des balises de vue, les performances ne sont pas si mauvaises sur ordinateur, cependant elles peuvent être un peu plus perceptibles sur les appareils mobiles. La seule fois où l'impact sur les performances est vraiment perceptible, c'est lorsqu'un portefeuille est restauré, auquel cas le portefeuille devra analyser chaque adresse depuis le déploiement du contrat sur la chaîne, ce qui prend du temps.
• Pour contourner cela, les utilisateurs peuvent partager facultativement la clé de visualisation privée avec un tiers de confiance. Ce service tiers peut surveiller différents réseaux et avertir les utilisateurs lorsqu'ils ont reçu des fonds. Bien sûr, cela implique un compromis : bien que le tiers ne puisse pas réellement dépenser les fonds des utilisateurs (il ne dispose pas de la clé de dépense privée pour le faire), il peut voir tous les fonds envoyés à un destinataire donné, ce qui signifie que l'utilisateur doit leur faire confiance en matière de confidentialité. Fluidkey le fait par défaut.
• Le protocole d'adresse furtive standard, c'est-à-dire ERC-5564, est conçu pour faciliter les transferts préservant la confidentialité, cependant, les cas d'utilisation non financiers tels que l'appel de fonctions arbitraires de contrat intelligent nécessitent un peu plus d'ingénierie et sont généralement spécifiques à la mise en œuvre.

Matrice de comparaison

Il existe diverses façons de comparer les quatre implémentations des adresses furtives explorées dans ce post. Toutes les implémentations présentent des différences subtiles et des compromis, mais les points les plus importants à souligner concernent probablement la traçabilité et l'obscurcissement de la valeur.

Bien que Fluidkey et Umbra permettent tous deux de transférer des fonds vers une adresse Ethereum standard tout en rompant tout lien avec l'identité du destinataire, ils préservent néanmoins la traçabilité de la transaction, ce qui signifie que l'expéditeur est visible par toute personne examinant l'historique des transactions de l'adresse masquée. Cela signifie que si vous recevez des fonds à une adresse masquée, la personne à qui vous décidez d'envoyer ces fonds verra d'où ils proviennent. De plus, la valeur réelle transférée est également visible. Railgun et Labyrinth masquent l'expéditeur ainsi que la valeur envoyée, mais avec le compromis que tout cela se produit à l'intérieur d'un seul contrat, et non sous la forme d'une transaction normale vers une adresse Ethereum normale.

La figure ci-dessous montre comment les protocoles que nous examinons dans ce message se comparent les uns aux autres sur ces deux dimensions importantes de comparaison.

Pour explorer les différences un peu plus en détail, voici une matrice comparative des quatre principaux protocoles d'adresse furtive selon six dimensions principales :

1. Confidentialité complète de bout en bout (seul l'expéditeur et le destinataire voient le paiement)
2. Secret de l'avenir. L'envoi de fonds reçus via des transactions furtives n'empêche pas le deuxième destinataire de voir d'où proviennent les fonds.
3. Suit les normes erc-5564 et erc-6538
4. Implémente une architecture modulaire extensible qui permet l'intégration avec des dapps tierces parties
5. L'implémentation offre-t-elle un SDK que les développeurs peuvent utiliser pour intégrer ?
6. La solution fournit-elle un niveau de conformité grâce à un certain type de support de dé-anonymisation ?
7. Le design prend-il en charge l'obfuscation du montant / de la valeur transférée ?

| Protocole | Confidentialité de bout en bout | Secret de transmission | Norme ouverte | Architecture modulaire | SDK | Support de dé-anonymisation | Montants masqués |

|—————-|——————-|————————-|————————|———————————|———|—————————————|————————|

| Umbra | ✅ | ⛔️ | ✅ | ⛔️ | ⛔️ | ⛔️ | ⛔️ |

| Fluidkey | ⛔️ | ⛔️ | ✅ | ✅ | bientôt | ✅ | ⛔️ |

| Labyrinthe | ✅ | ✅ | ⛔️ | ✅ | ✅ | ✅ | ✅ |

| Railgun | ✅ | ✅ | ⛔️ | ✅ | ✅ | volontaire | ✅ |

Certaines des autres nuances et différences sont capturées plus en détail dans la section suivante. Chaque implémentation a des différences subtiles intéressantes qui peuvent ou non faire une différence en fonction de votre cas d'utilisation.

Par exemple : dans Fluidkey : tous les transferts vont directement aux adresses furtives on-chain, avec Umbra : seul l'ETH va aux adresses furtives on-chain, tandis que les jetons vont au contrat central, et avec Railgun et Labyrinth, toutes les transactions vont aux contrats principaux, pas directement aux adresses furtives on-chain.

Plongée profonde sur les implémentations d'adresses furtives

Fluidkey

Fluidkey est une implémentation de erc-5564 qui permet aux utilisateurs d'envoyer, de recevoir, d'échanger et de relier des ETH et des jetons erc-20. Au moment de la rédaction, Fluidkey est déployé sur Base, Optimism, Arbitrum, Polygon, Gnosis et Ethereum mainnet.

Les utilisateurs interagissent avec Fluidkey via leur interface web. Lorsqu'ils se connectent pour la première fois à l'aide de leur portefeuille, ils signent un message de génération de clé à partir duquel dérivent leurs clés de visualisation et de dépense. Ces mêmes clés sont régénérées de la même manière à chaque fois que l'utilisateur entre dans l'application.

Il existe quelques façons dont Fluidkey diffère des autres implémentations. Une façon dont Fluidkey diffère des autres implémentations d'adresses furtives est que les utilisateurs partagent leur clé de visualisation privée avec Fluidkey (en fait une BIP-32nœud dérivé de la clé pour être tatillon). Cela permet à Fluidkey de générer des adresses furtives pour l'utilisateur et de notifier l'utilisateur lorsqu'il reçoit des paiements à ces adresses. Cela signifie cependant que Fluidkey est en mesure de visualiser les transactions entrantes et les soldes d'un utilisateur, ce qui est le compromis. Cependant, il reste entièrement auto-custodial.

Un autre aspect intéressant de la conception de Fluidkey est qu'elle déploie un compte de contrat intelligent à chaque nouvelle adresse furtive. Cela se produit de manière contrefactuelle uniquement lorsque des fonds d'une adresse furtive sont dépensés. Le compte intelligent est un compte Safe 1/1, et permet des choses comme le parrainage de gaz, ce qui facilite la gestion des différentes adresses furtives ensemble. Il existe des détails complets à ce sujet dans leur Guide technique.

Bien que Fluidkey ait le compromis de conserver une visibilité sur les comptes d’un utilisateur, cela peut en fait potentiellement être un avantage en matière de conformité, bien que le cadre exact de la façon dont Fluidkey traitera des choses comme les demandes potentielles des forces de l’ordre à l’avenir ne soit pas encore disponible publiquement. Cependant, ils sont basés en Suisse et, bien qu’ils doivent se conformer aux lois locales, les lois sur la protection des données sont très claires et très strictes - il doit y avoir un cas très clair pour partager les données et devrait également être examiné par un tribunal (voir ce postpour une excellente vue d'ensemble des lois sur la confidentialité en Suisse).

Les utilisateurs sont également totalement libres d’exporter leurs transactions ou de partager leurs clés de visualisation avec des tiers (par exemple, leur comptable), ce qui peut être extrêmement utile, en particulier pour les entreprises. Il convient toutefois de garder à l’esprit qu’avec la spécification erc-5564, le partage de la clé publique est « tout ou rien », ce qui signifie qu’elle ne peut pas révéler des transactions individuelles isolées par elles-mêmes. De plus, comme pour toutes les implémentations de l’erc-5564, la traçabilité n’est pas rompue, mais seulement la possibilité de se connecter à l’utilisateur, ce qui signifie que l’historique des transactions de chaque adresse furtive est exposé à celui qui possède la clé de visualisation. Une fonctionnalité peu connue de Fluidkey qui permet d’atténuer ces compromis est la possibilité de faire pivoter les clés d’affichage, ce qui permettrait à un utilisateur d’utiliser une nouvelle clé d’affichage chaque mois et de ne partager l’accès à l’affichage que pour des mois spécifiques avec un tiers.

Un avantage intéressant de l'approche de Fluidkey est que l'adresse furtive elle-même n'est pas générée par l'expéditeur, elle est générée de manière pseudo-aléatoire à chaque fois que l'ENS est interrogé par Fluidkey. Cela est beaucoup plus rapide car les utilisateurs n'ont pas à parcourir les événements d'annonce pour identifier les transactions dans lesquelles ils sont les destinataires. Cela signifie également que l'expéditeur n'a pas besoin d'un portefeuille d'adresse furtive pour générer une adresse furtive pour le destinataire - il envoie simplement des fonds à une adresse comme il le ferait pour toute autre adresse, et c'est tout. Cela signifie également qu'il n'y a pas de contrat d'enregistrement impliqué, ce qui est propre à la conception de Fluidkey et constitue un avantage majeur.

Il convient de dire que Fluidkey s'engage à être entièrement autonome et ils ont rendu leur bibliothèque Stealth Account Kit open source. De plus, en cas de disparition soudaine de Fluidkey, il existe plusieurs interfaces de récupération développées indépendamment, ce qui signifie que les fonds ne seront jamais bloqués ou perdus.

Abstraction d'adresse

En utilisant des comptes de contrats intelligents de manière contrefactuelle, Fluidkey peut automatiquement abstraire la gestion des adresses furtives individuelles. Cela signifie que si vous souhaitez transférer un montant spécifique à un certain destinataire à partir de vos soldes sur différentes adresses furtives, Fluidkey peut automatiquement déterminer quelle combinaison d'adresses utiliser pour sourcer les fonds pour le transfert, en gérant tous les frais de gaz et les déploiements de contrats, tout cela en coulisses. Fluidkey permet également aux utilisateurs d'exercer un certain contrôle sur les adresses combinées en utilisant une fonctionnalité intéressante appelée étiquettes, qui permet à l'utilisateur de marquer les adresses en différentes catégories.

Résolution ENS

Fluidkey exige que les utilisateurs créent des noms ENS spécifiques à Fluidkey. Ces noms statiques prennent 2 formes : username.fkey.id et username.fkey.eth, l'un étant une URL vers une interface web pour envoyer des fonds à quelqu'un, et l'autre un nom ENS standard qui peut être utilisé avec des portefeuilles.

La configuration ENS utilise un Résolveur hors chaîne ENS(aka erc-3668: Lecture CCIP) pour renvoyer des adresses furtives. Chaque fois que le résolveur hors chaîne est interrogé, il génère et renvoie une nouvelle adresse furtive pour le nom ENS correspondant. C'est une fonctionnalité intéressante car elle permet à un utilisateur d'avoir un seul nom ENS lisible par les humains tout en conservant la confidentialité des adresses furtives, car les adresses furtives générées ne peuvent pas être liées rétrospectivement au nom ENS.

Coût

Fluidkey est gratuit et ne facture aucun frais. Il y a le coût du déploiement d'un contrat Safe à chaque adresse qui possède des fonds lorsque vous souhaitez dépenser ces fonds. Cependant, bien que relativement cher sur mainnet, sur L2s, c'est vraiment négligeable, généralement moins d'un centime, même lors de la combinaison de plusieurs adresses furtives dans un seul transfert.

Ils peuvent également parrainer le gaz via les déploiements Safe - ils calculent le coût du gaz et le déduisent du solde des utilisateurs, même s'il s'agit d'un jeton - dans ce cas, un relais déploie le coffre-fort et transfère le jeton au nom de l'utilisateur.

Umbra Cash

Umbra est une implémentation de eip-5564 + eip6538 de ScopeliftLorsqu'un utilisateur se connecte à l'application Umbra, il passe par une phase de configuration, au cours de laquelle il signe un message, à partir duquel les clés de dépense et de visualisation, ainsi que l'adresse métastable furtive respective, sont dérivées. Ils enregistrent ensuite cette adresse métastable furtive à leur adresse de portefeuille principale dans un registre on-chain. C'est là que l'implémentation diffère de Fluidkey.

L'implémentation d'Umbra de erc-5564 est la plus proche de la spécification, en ce sens qu'ils n'ont pas accès aux clés de l'utilisateur. Cela signifie que Umbra (ou quiconque d'autre) ne peut pas voir les fonds des utilisateurs, mais cela signifie également que pour recevoir des fonds, l'expéditeur doit avoir un portefeuille compatible erc-5564 (ou l'application Umbra) pour générer leur méta-adresse furtive.

Quand quelqu'un veut envoyerLorsqu'un utilisateur souhaite envoyer des fonds à un autre utilisateur, il utilise normalement l'application Umbra. Essentiellement, l'application Umbra recherchera l'adresse méta-furtive enregistrée sous un nom ENS / une adresse de portefeuille et générera une adresse furtive. Les destinataires peuvent se connecter à l'application Umbra et rechercher les fonds qui leur ont été envoyés à des adresses furtives leur appartenant depuis la dernière fois qu'ils se sont connectés. Grâce à un cache intelligent, cela ne prend apparemment que 10 à 15 secondes pour une analyse hebdomadaire, bien que les utilisateurs puissent également optionnellement spécifier une plage de blocs pour affiner l'analyse. Umbra v2 inclura l'utilisation de viewtags, ce qui accélérera encore plus le processus.

Relayer

Un problème avec les adresses furtives que nous avons déjà mentionné est que, pour que le destinataire puisse dépenser les fonds envoyés à une adresse furtive, cette adresse devra disposer d'ETH ou d'un autre jeton de gaz requis pour payer les frais de transaction. Sur la plupart des réseaux, si l'adresse furtive a reçu de l'ETH en premier lieu, cela ne pose généralement pas de problème. Cependant, si l'adresse furtive a reçu un jeton erc-20 ou un NFT, alors le fait de financer l'adresse avec de l'ETH pour payer le gaz peut lier l'adresse à d'autres adresses de l'utilisateur, ce qui supprime leur confidentialité.

Pour contourner cela, Umbra utilise une construction impliquant un relais. Lorsque tout actif qui n'est pas ETH est envoyé à un utilisateur Umbra, il est en fait envoyé à un contrat spécial au lieu d'être envoyé directement à l'adresse furtive. Les utilisateurs peuvent dépenser les fonds envoyés à leurs adresses furtives en envoyant une méta-transaction (depuis l'application Umbra) au relais d'Umbra, qui transférera les fonds hors du contrat intelligent au nom de l'utilisateur. Le relais déduira certains jetons afin de couvrir les frais de gaz, et seuls un certain nombre de jetons sont pris en charge initialement.

Coût

Le contrat Umbra applique également des frais minimes lors du transfert de fonds sur des réseaux à faibles frais de transaction, afin de dissuader les spams. La logique est que les spams augmenteraient le coût de l'analyse des transactions pour identifier celles qui sont pertinentes, et c'est pourquoi cela est considéré comme un compromis acceptable.

Réseaux pris en charge

Umbra est actuellement déployé sur le réseau principal d'Ethereum, ainsi que sur Optimism, Polygon, Gnosis Chain et Arbitrum.

Le contrat d'enregistrement de l'Ombra a une conception intéressante. La méthode de déploiement utilise create2 et le déploiement standard create2 deployer, et l'adresse du contrat intelligent est la même sur n'importe quel réseau. Cela signifie que si le contrat existe sur un réseau donné, alors le client peut être sûr que c'est le bon contrat. Le client peut être configuré pour ajouter des réseaux, et n'importe qui peut déployer sur n'importe quel réseau. Ils ont canonisé le bytecode et le contrat n'a pas de propriétaire, ce qui permet un déploiement sans autorisation de contrats d'enregistrement et d'annonce sur n'importe quelle chaîne par n'importe qui.

Umbra v2

Scopelift est actuellement en développementversion 2 d’Umbra, qui introduit une nouvelle architecture modulaire qui permet d'étendre les contrats de base pour prendre en charge de nouvelles normes de jetons ou des cas d'utilisation autres que les paiements. Grâce à cette nouvelle architecture, les développeurs tiers peuvent créer des modules pour n'importe quel type de norme de jeton, par exemple erc-1155, erc-7621, prise en charge des paymasters erc-4337, ou tout autre chose à laquelle vous pouvez penser. Actuellement, le contrat principal d'Umbra prend en charge deux scénarios, un pour ETH et un pour erc-20. La version 2 prendra en charge de nombreux scénarios différents.

Labyrinthe

Labyrintheest un protocole qui n'est pas basé sur eip-5564 + eip6538, mais utilise plutôt des preuves à connaissance nulle pour ajouter l'anonymat et la confidentialité aux transactions. Le livre blanc de Labyrinth le décrit comme un middleware "zkFi" : "zkFi offre une solution intégrée qui agit comme un middleware de confidentialité avec conformité intégrée". La conformité intégrée fait référence à la "dé-anonymisation sélective" de Labyrinth, qui est une solution sophistiquée permettant de dé-anonymiser certaines transactions pour des acteurs autorisés spécifiques, c'est-à-dire des autorités légales comme Interpol, etc., tout en maintenant la transparence et l'ouverture.

Les contrats intelligents principaux utilisés par Labyrinth comprennent un pool multi-transactionnel et multi-actifs qui permet à l'utilisateur de transiger plusieurs actifs dans une seule transaction. Afin de dépenser des actifs, un utilisateur balaye le réseau et récupère les données des notes chiffrées, déchiffre les notes et filtre les actifs qu'il souhaite dépenser. Ensuite, l'utilisateur crée un ZKP qui inclut les transactions et une signature de la clé de signature associée aux notes qu'il souhaite dépenser des transactions.

Une partie des contrats principaux de Labrynth comprend un contrat de convertisseur, qui interagit avec des contrats de proxy modulaires, qui sont essentiellement des mandataires pour des contrats externes. Par exemple : si un utilisateur souhaite utiliser Labyrinth pour interagir avec Uniswap, l'utilisateur créerait une transaction qui utiliserait le contrat de convertisseur pour appeler une opération d'échange sur un pool Uniswap via le contrat de proxy d'Uniswap.

Le protocole zkFi de Labyrinth utilise des "notes" pour suivre les soldes et les transferts. Une note est essentiellement une structure de données qui décrit une certaine quantité d'un actif et à quelle adresse elle appartient. Un client stocke les informations nécessaires pour recréer une note, et utilise cela pour dépenser des actifs. Un engagement envers la note (un hachage de l'identifiant de l'actif, du propriétaire et de la valeur) est stocké dans un arbre de Merkle on-chain. En fait, Labyrinth utilise deux arbres de Merkle, un pour les notes, et un pour les adresses racines.

La structure de données de la note contient ce qui suit :

• assetId: Identifiant de l'actif (ETH, WBTC, MATIC, etc.) que cette note représente la valeur de.
• valeur: Valeur ou montant représenté par la note.
• leafIndex : L'indice de feuille de l'arbre de Merkle d'engagement où cette note sera insérée.
• aveuglant: Un facteur d'aveuglement aléatoire.
• rootAddress: L'adresse racine d'un utilisateur ayant l'autorité de le dépenser.
• révoquer: Le point de clé publique du révocateur choisi.

Vous remarquerez que la structure de données ci-dessus ne contient aucune référence au propriétaire des actifs, ce qui est étrange, car l’engagement enregistré dans l’arborescence de Merkle des notes est un hachage de l’ID de l’actif, de la valeur et du propriétaire. En fait, le propriétaire est calculé à partir de l’adresse racine, du révoquant et d’un facteur d’aveuglement aléatoire, et donc pour les observateurs externes, le propriétaire est en fait une adresse nouvellement créée pour chaque nouvelle transaction.

Pool protégé

Ce qui est vraiment intéressant à propos de Labyrinth, qui est également légèrement différent des protocoles basés sur des adresses furtives classiques, c’est que le pool d’actifs est en fait un pool blindé, qui utilise le concept de notes pour créer une sorte de pool UTXO blindé qui permet la confidentialité des transactions. Rappelons qu’avec les implémentations d’eip-5564, l’entité à laquelle un utilisateur transfère des fonds sera en mesure de voir d’où proviennent ces fonds. En d’autres termes, Alice paie Bob en utilisant une adresse furtive, Bob paie Charlie, donc maintenant Charlie peut voir que Bob a initialement reçu les fonds d’Alice, et ainsi de suite. Ce n’est pas le cas avec la piscine blindée de Labyrinth.

Pour comprendre le fonctionnement de ce pool protégé, nous devons examiner comment les fonds sont transférés à l'intérieur du protocole :

Les soldes d'un utilisateur dans le pool protégé sont la somme des notes des actifs respectifs. Pour dépenser ces notes, l'utilisateur doit révéler les "nullifiers" de ces notes. Un nullifier est unique à une note, et une fois que cette note est dépensée, le nullifier est marqué pour éviter les doubles dépenses, et une nouvelle note est créée à partir de cette note dépensée. Plusieurs notes du même actif peuvent être combinées, et plusieurs nouvelles notes peuvent être créées. Le nullifier est simplement le hash de (𝑙,𝑐,𝛿), où 𝑙 est l'index de l'engagement de la note dans l'arbre de Merkle des notes, et 𝑐 est l'engagement, et 𝛿 est un élément aléatoire également appelé facteur de masquage.

Un bénéficiaire d'un transfert de transaction furtive identifie le transfert de la même manière que l'eip-5564, dans la mesure où ils écoutent les événements émis par les contrats principaux, et déterminent à partir de quelles adresses furtives ils pourront envoyer des fonds, les enregistrant localement. L'identification des fonds entrants est également accélérée en utilisant des balises de vue et en mettant en cache localement et en synchronisant de manière asynchrone les notes pendant la durée de vie de l'application.

Des recherches sont en cours pour rendre le processus de découverte des fonds reçus plus rapide, prenez par exemple cette proposition d'Aztec :Demande de propositions: Protocole de découverte de notes - Aztec.

Pour dépenser les fonds, l'utilisateur doit également générer une preuve zk, contrairement aux implémentations erc-6654, qui sont essentiellement des adresses Ethereum normales. Générer une preuve nécessite un portefeuille compatible, avec des performances relativement bonnes, prenant environ 20 secondes sur un appareil Android de gamme moyenne.

Bundler et Converter

Labyrinth propose plusieurs fonctionnalités intéressantes qui résolvent certains problèmes liés aux transactions invisibles. Les transactions envoyées aux contrats principaux de Labyrinth sont envoyées sous forme d'opérations utilisateur via des bundlers erc-4337. Cette configuration permet de dépenser des notes sans ETH ni jetons de gaz pour les transactions, car l'utilisateur peut exploiter le paymaster erc-4337 pour payer les frais de gaz en son nom, ce qui ajoute un autre niveau de confidentialité. La seule exception est le dépôt initial qui n'est pas soumis en tant qu'opération utilisateur. L'utilisation de paymaster er-4337 permet également de payer les frais de gaz via les actifs transférés, même s'ils sont des jetons erc-20, et pour cela Labyrinth expose une API d'oracle de prix du gaz.

Une autre fonctionnalité très intéressante que Labyrinth possède est une architecture modulaire qui permet aux contrats convertisseurs d'agir en tant que mandataires pour des applications tierces. Cela permet aux utilisateurs non seulement de transférer des fonds à l'aide de transactions furtives, mais aussi d'interagir avec des applications tierces telles que des DEX (par exemple, Uniswap, Aave, Lido, etc.). Ces contrats mandataires « convertisseurs » implémentent essentiellement une fonction qui prend en compte une certaine quantité d'un actif, et une certaine quantité d'actif en sort, la logique sous-jacente résidant dans un contrat tiers.

Solution de conformité

Labyrinth assure la conformité et le respect des réglementations grâce à un cadre appelé Selective De-Anonymization (SeDe).

Rappelez-vous que la structure de données d'une note contient un champ appelé "révoqueur". Le révoqueur est l'adresse d'une entité spécifique qui peut initier le processus de dé-anonymisation. Un utilisateur doit choisir au moins un révoqueur dans une liste prédéfinie. Le révoqueur n'est pas uniquement responsable d'identifier une activité potentiellement illicite ou illégale, mais peut répondre aux demandes des agences de maintien de l'ordre.

Les révocateurs n'ont pas la capacité unilatérale de dé-anonymiser les transactions directement, mais ils sont responsables de l'initiation des demandes de dé-anonymisation. Ces demandes sont publiées publiquement aux gardiens, qui sont un comité d'entités chargées de la confidentialité et de la conformité. Les gardiens doivent répondre à la demande en votant pour accorder ou non l'autorisation de dé-anonymiser la ou les transactions. Si les gardiens peuvent atteindre un quorum et voter en faveur, alors le révocateur peut décrypter les données de transaction, ce qui leur permet de relier la transaction en question aux transactions précédentes jusqu'à ce que la chaîne de transaction ait été entièrement dé-anonymisée.

Ce système crée une série de contrôles et de balances, dans la mesure où les gardiens ne peuvent pas décider unilatéralement de révéler les données de transaction, et même s'ils collaborent, ils ne peuvent rien faire sans le révocateur, et le révocateur seul ne peut rien faire sans un vote majoritaire des gardiens.

Railgun

RAILGUNest un système de confidentialité des transactions furtives déployé sur Ethereum, BSC, Polygon et Arbitrum. Le protocole est en quelque sorte similaire à Labyrinthe dans la mesure où il est basé sur des notes, qui sont stockées dans un arbre de Merkle sous forme d'engagements, et forment un ensemble UTXO, c'est-à-dire que les notes peuvent être dépensées en créant de nouvelles notes pour d'autres destinataires. Pour dépenser une note, un nullifier est ajouté à l'état pour cette note, empêchant les dépenses doubles. Seul le propriétaire d'une note peut calculer son nullifier, qui est basé sur le hachage de la clé de dépense et l'index des notes sur l'arbre de Merkle, ce qui signifie que seul le propriétaire de la note peut la dépenser (et ne peut la dépenser qu'une seule fois).

Les adresses méta furtives dans Railgun utilisent le préfixe "0zk", et comme eip-5564, elles sont une concaténation de la clé de visualisation publique et de la clé de dépenses publiques. Cependant, Railgun utilise des clés Ed25519 sur la courbe BabyJubJub au lieu de ECDSA & secp256k1. De la même manière que eip-5564, les utilisateurs parcourent tous les événements émis par les contrats Railgun et utilisent leur clé de visualisation pour déterminer quels événements représentent des transferts vers leur portefeuille.

Railgun utilise un réseau de diffuseurs, qui sont essentiellement des relais qui acceptent des méta-transactions des utilisateurs et diffusent la transaction réelle à la blockchain respective, payant les frais de gaz au nom de l'utilisateur. Les interactions directes avec les contrats Railgun proviennent de ce réseau de diffuseurs, protégeant l'anonymat des utilisateurs finaux. Les transactions envoyées par les utilisateurs aux diffuseurs sont cryptées avec la clé publique spécifique d'un diffuseur et communiquées en utilisant le protocole Waku.

Railgun possède une architecture modulaire qui lui permet d'interagir avec des contrats intelligents externes, permettant ainsi des fonctionnalités au-delà des simples transferts. Il le fait via le contrat AdaptRelay, qui protège et désactive les jetons avant et après l'interaction avec un contrat externe, par exemple désactiver le jeton A, échanger contre le jeton B sur un AMM, puis protéger le jeton B pour le propriétaire d'origine.

Avec la version 3, Railgun prévoit d'utiliser eip-4337 ainsi que de prendre en charge les méta-transactions héritées. Ils espèrent qu'en maintenant un pool de mémoire dédié aux utilisateurs eip-4337 pour Railgun, les solveurs indépendants pourront participer en tant que diffuseurs. Ils collaborent actuellement avec Umbra sur cette recherche, en identifiant les cas particuliers et en proposant des solutions. Voir la section Railgun v3 ci-dessous pour plus de détails.

Frais

Le protocole Railgun prélève des frais de 0,25% pour les dépôts et les retraits. Ces frais sont envoyés au trésor DAO, et ces frais sont versés au fil du temps aux détenteurs du jeton de gouvernance RAIL. En plus des frais de dépôt et de retrait de 0,25%, les diffuseurs appliquent généralement leurs propres frais, et ceux-ci représentent généralement environ 10% du montant des frais de gaz pour la transaction réelle sur la chaîne.

Gouvernance

Railgun dispose d'un système de gouvernance qui permet de soumettre n'importe quelle forme de proposition, et aucun changement ne peut avoir lieu sur l'un des contrats principaux (y compris les contrats de trésorerie et de gouvernance) sans proposition de DAO. De manière inhabituelle, des instances séparées de Railgun ont leur propre gouvernance. Par exemple, Railgun sur Ethereum, Polygon et Binance Chain ont leurs propres systèmes de gouvernance et jetons distincts.

SDK et Cookbook

Railgun propose un SDK complet et bien documenté que les développeurs de portefeuilles ou de dapps peuvent utiliser pour intégrer la fonctionnalité d'adresse furtive via le support de Railgun. Railgun est également maintenu par la communauté.livre de cuisineavec des “recettes” qui permettent aux développeurs de dapp de fournir des modules pour Railgun qui permettent aux utilisateurs d'interagir avec leur dapp en utilisant Railgun. Par exemple, un développeur peut écrire une recette pour un DEX qui permet aux utilisateurs avec des soldes de jetons dans Railgun d'échanger des jetons de manière privée.

RailGun v3

La prochaine itération de Railgun rendra les transactions environ 50% à 60% moins chères. Les autres changements dans la version 3 consistent en un passage au support des userops eip-4337 via un mempool dédié. De plus, la version 3 fournira une prise en charge d'une architecture basée sur les intentions, qui permettra aux solveurs de rivaliser pour la meilleure exécution, bien que les détails soient très généraux au moment de l'écriture. Ils travaillent actuellement avec gate.CowSwapà ce sujet et prévoir d'utiliser des hooks avant et après pour permettre aux solveurs d'accéder aux fonds.

Railgun Connect

Probablement le changement le plus intéressant proposé est quelque chose appelé Railgun Connect, qui est décrit comme un outil similaire à WalletConnect, en ce qu'il permet aux adresses 0zk de se connecter à la plupart des interfaces utilisateur pour un usage privé, sans nécessiter que ces dapps fournissent spécifiquement une intégration explicite avec Railgun via des modules personnalisés.

Railgun Connect est une extension de navigateur, et ce qu’il fait, c’est en fait forker l’état de la chaîne localement à l’aide de HardHat sous le capot, et injecter son propre fournisseur web3 dans la dapp, avec un point de terminaison RPC de la version HardHat locale de la chaîne. Cela vous permet ensuite d’effectuer les interactions avec les contrats dapps comme vous le feriez normalement, d’enregistrer les transactions, puis de les regrouper et de créer une preuve de snark, et de l’envoyer aux contrats Railgun réels sur la chaîne réelle. Bien que cette description soit un peu trop simpliste, elle transmet l’idée générale. Cela vous permet d’interagir avec pratiquement n’importe quelle dapp (avec quelques cas limites pour les dapps qui effectuent un traitement hors chaîne supplémentaire). La mise en garde est que la sauvegarde de l’état de la chaîne localement est une opération lourde, mais une fois faite, cela signifie que vous pouvez interagir avec les dapps en utilisant les adresses furtives de Railgun sans voir de différence avec l’utilisation d’un portefeuille normal.

Conclusion

Il existe quelques propositions intéressantes pour consacrer des adresses furtives dans le protocole Ethereum. Par exemple, Inco Utilise l’idée d’un « wrapper » ERC-20, qui encapsule un contrat ERC-20 normal, et crypte tous les soldes. Les transferts et les approbations sont tous effectués sur l’état crypté via un cryptage entièrement homomorphe. Inco s’appuie sur des précompilations qui n’existent actuellement que sur son propre réseau, mais qui pourraient un jour arriver à Ethereum.

Il y a aussi une autre proposition appeléeEIP-7503: Zero-Knowledge Wormholesqui est basé sur une conception appelée « proof-of-burn », bien que cela ne semble pas susciter beaucoup d'intérêt, probablement parce qu'il nécessite une mise à jour de l'EVM, sans laquelle il ne peut vraiment être mis en œuvre qu'au niveau du jeton, en utilisant une conception erc-20 qui prend en charge spécifiquement l'eip-7503 (ou si un L2 décide d'ajouter des supports à leurs opcodes EVM).

Aztecest peut-être la technologie de confidentialité la plus sophistiquée qui existe, mais elle nécessite que les utilisateurs transfèrent des fonds à Aztec pour pouvoir l'utiliser, ce qui peut être ou non une mauvaise expérience utilisateur pour la plupart des utilisateurs. Cependant, si la demande de confidentialité des transactions de base augmente parmi les utilisateurs d'Ethereum, alors Aztec pourrait avoir une proposition de valeur unique qui en fait une L2 très précieuse à mesure que les dapps et les utilisateurs migrent vers une plateforme qui leur offre la confidentialité par défaut.

De même, Intmax (en anglais seulement)Il s'agit d'un Ethereum L2 (basé sur une conception Plasma) axé sur la confidentialité, et ayant également un aspect conforme à la réglementation en vérifiant la légitimité des fonds individuels grâce à des preuves AML basées sur ZKP et en imposant des limites sur les montants de transaction. Intmax est limité en termes de confidentialité des transferts, tandis que les opérations de contrat intelligent EVM ne le sont pas. Cependant, contrairement à Aztec, les contrats intelligents peuvent être rédigés en Solidity, ce que certains développeurs peuvent préférer (selon le cas d'utilisation).

Support de portefeuille

Bien que nous observions une adoption accrue des protocoles d'adresse furtive, ce qui est prometteur, il reste un certain nombre de défis. Le défi le plus important est qu'ils ne sont pas entièrement pris en charge dans les portefeuilles Ethereum grand public (du moins pas encore). Les portefeuilles grand public ont probablement plusieurs choix à faire s'ils vont fournir un support pour les adresses furtives. Certains de ces choix comprennent :

• Fourniront-ils un soutien orienté pour une seule implémentation, ou construiront-ils et maintiendront-ils une sorte d'agrégateur complet à travers plusieurs protocoles? Il est probable que ce dernier soit excessivement coûteux en termes de développement et de maintenance.
• Y aura-t-il des considérations réglementaires, et devront-elles prendre position sur l'étendue et le mécanisme de la dé-anonymisation sélective (c'est-à-dire comme celle de Labyrinth) ?
• Les adresses furtives nécessitent un composant on-chain vis-à-vis du contrat de registre (sauf Fluidkey), ce qui signifie que chaque réseau EVM doit être explicitement pris en charge par le portefeuille (bien que la conception d'Umbra facilite le déploiement sans autorisation du registre).
• Les adresses furtives compliquent les intégrations existantes avec les explorateurs de blocs (par exemple Etherscan). Par exemple, le bouton « Afficher sur l’explorateur » ne fonctionnera pas pour une méta-adresse furtive, où le portefeuille affiche le solde agrégé. Ce problème peut également se poser pour les transferts. Les différents cas limites comme celui-ci devront être pris en compte.
• Selon la mise en œuvre sous-jacente, un utilisateur ne pourra utiliser l'adresse furtive efficacement qu'avec un ensemble spécifique de dapps, à savoir ceux qui sont pris en charge par le protocole sous-jacent. Cela sera possible avec des architectures d'adresse furtive modulaires. Cependant, toutes les dapps ne seront pas prises en charge, et cela devra être communiqué à l'utilisateur d'une manière ou d'une autre. C'est un peu plus facile avec eip-5506, mais cela présente encore des complications et des cas particuliers, et cela peut souvent se refléter dans l'expérience utilisateur du portefeuille.

Il existe également des possibilités d'amélioration pour prévenir les mauvaises pratiques de confidentialité des utilisateurs, voir ce document :Analyse de l'anonymat du schéma d'adresse furtive Umbra sur Ethereum" pour la façon dont les auteurs ont réussi à dé-anonymiser 48,5 % des transactions furtives sur Ethereum mainnet. Les heuristiques qu'ils ont utilisées pour ce faire n'avaient rien à voir avec les protocoles, mais plutôt avec l'hygiène de la vie privée, par exemple lorsqu'un utilisateur envoie des fonds dans une adresse furtive qu'il contrôle, puis envoie ces fonds de retour à l'adresse à partir de laquelle il les a envoyés initialement, pensant à tort que la traçabilité est rompue. Dans l'ensemble, les auteurs ont identifié 6 heuristiques différentes qui peuvent être utilisées pour dé-anonymiser les transactions d'adresse furtive, principalement basées sur le non-respect des meilleures pratiques. Cependant, il s'agit de problèmes critiques d'UX qui doivent être résolus.

Dans l’ensemble, je suis assez optimiste sur les adresses furtives et la confidentialité dans Ethereum en général. Je pense que nous avons fait des progrès assez impressionnants et découvert des défis qui sont très faciles à résoudre. Je suis convaincu que les portefeuilles grand public trouveront comment fournir le niveau de prise en charge des adresses furtives qui permettent aux utilisateurs de les utiliser avec un minimum de friction et de réflexion, offrant le niveau normal de confidentialité que les utilisateurs attendent et méritent.

Un grand merci à toutes les équipes qui ont consacré du temps et beaucoup de travail à la recherche et à la construction d'une infrastructure d'adresses furtives, y compris les quatre protocoles dont j'ai parlé dans ce message. Leur travail acharné et leur ténacité feront une énorme différence pour Ethereum !

Clause de non-responsabilité :

1. Cet article est repris à partir de [Moyen]. Tous les droits d'auteur appartiennent à l'auteur original [Simon Brown]. S'il y a des objections à cette reproduction, veuillez contacter le Gate Learnl'équipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent aucun conseil en matière d'investissement.
3. L'équipe 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.