jakiro
Source: Communauté deglian
introduire
Un point de douleur majeur face aux utilisateurs de WEB3 Encryption est le manque de confidentialité.Toutes les transactions sont visibles sur les registres publics et sont de plus en plus associés à un nom ENT clairement visible, ce qui rend les utilisateurs moins motivés lors de la réalisation de certaines activités ou les conduisent à effectuer une manière qui augmente l’expérience des utilisateurs.Un exemple consiste simplement à transférer des fonds des portefeuilles chauds aux portefeuilles froids ou vice versa.Les utilisateurs peuvent ne pas vouloir qu’un portefeuille soit connecté à un autre, car ils peuvent ne pas vouloir voir leur équilibre de portefeuille froid.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, vos activités sociales (SBT, preuve, activités sur divers DAPP, etc.) seront également visibles.Pour cette raison, Vitalik appelle la vie privée ce que Ethereum a besoin pour passerL’une des trois principales transformations technologiques, afin d’être utile aux utilisateurs ordinaires.
En utilisant des solutions de confidentialité existantes comme Tornado Cash, l’expérience n’est pas idéale pour plusieurs raisons.Tout d’abord: les utilisateurs s’inquièteront raisonnablement que leur adresse sera mis sur liste noire sur des échanges centralisés ou d’autres plates-formes.Deuxièmement, l’expérience utilisateur interactive avec des services tels que Tornado Cash n’est pas conviviale et ne convient en fait qu’aux utilisateurs hautement qualifiés.
Les adresses secrètes fournissent aux utilisateurs une confidentialité similaire à ce qu’ils tiennent pour acquise dans un compte bancaire privé et sont implémentées de manière facile à comprendre.En outre, l’innovation autour des adresses cachées signifie que nous pouvons le faire d’une manière qui est conforme aux réglementations anti-blanchiment dans plusieurs juridictions.
Besoins de confidentialité des utilisateurs
Bien que les recherches sur les attitudes de confidentialité envers la confidentialité par les utilisateurs Web et Web3 ne soient pas étendues, les études suivantes ont été trouvées par le biais de recherches sur le Web, et les résultats sont à peu près cohérents, ce qui indique un besoin clair de confidentialité des transactions.
-
Une enquête menée en 2022, publiée par Simin Ghesmati et al.Confidentialité perçue par l’utilisateur dans la blockchainDans le journal, il est indiqué queLa moitié des répondants ont déclaré que la confidentialité des transactions était très importante pour eux”
-
Une autre étude intéressante est venue de 2022, publiée dansFrontièresLe titre estAttitudes politiques, économiques et gouvernementales des utilisateurs de la blockchain, Cette étude est plus complète et un total de 3 710 utilisateurs de cryptographie ont été étudiés.Les résultats montrent qu’environ un quart des répondants ont déclaré que leur vie privée était «La caractéristique la plus importante de la blockchain et des crypto-monnaies».
-
En termes d’attitude globale envers la vie privée,ConsensysUne publicationWeb3 et Crypto Global Survey 2023, dans lequel une enquête en ligne auprès de 15 158 personnes de 15 pays a couvert divers sujets liés au Web, pas seulement le cryptage.L’enquête a révélé que 83% des répondants pensaient que la confidentialité des données était importante, tandis que seulement 45% ont déclaré qu’ils faisaient confiance à l’utilisation actuelle de leurs données et de leurs informations personnelles par les services Internet.
-
Un régime de rémunération des services financiers britanniquesenquête, libéré en avril 2023, soulignant que 9% des répondants seront «Un désir d’anonymat / confidentialité«Comme raison pour laquelle ils investissent dans les crypto-monnaies.
-
Fluidkey
-
Ombre
-
Labyrinthe
-
Fer à chenilles
-
ERC-5564: accord d’adresse secrète
-
ERC-6538: Enregistrement d’adresse métallique cachée
-
Lorsque le destinataire va dépenser les fonds, l’objet qu’il transfère les fonds verra que les fonds proviennent de l’expéditeur d’origine (c’est-à-dire qu’ils peuvent voir l’adresse où les fonds sont transférés et qui ont envoyé les fonds à cette adresse auparavant).Cela signifie que les chaînes de transfert restent intactes et traçables, mais elles ne sont pas liées aux destinataires impliqués (à moins que le destinataire ne fasse quelque chose comme envoyer des fonds à une adresse non cachée à laquelle ils sont connus).Notez que cela ne fonctionne qu’avec les implémentations ERC-5564 et non avec Railgun ou Labyrinth.
-
Un autre effet secondaire du problème ci-dessus est que pour maintenir une confidentialité optimale, les utilisateurs peuvent avoir besoin de conserver leurs fonds dans l’adresse secrète à laquelle ils ont été envoyés à l’origine jusqu’à ce qu’ils aient vraiment besoin d’eux, plutôt que de les fusionner sous une seule adresse.Cela représente les frais généraux supplémentaires des adresses de se souvenir et de dépenser par la suite des fonds pour ces adresses, car le montant que vous souhaitez transférer doit être tiré du portefeuille de fonds pour plusieurs autres adresses.
-
Afin de transférer des fonds de cette adresse, le destinataire doit fournir un peu d’ETH à l’adresse pour payer le gaz, ce qui peut dé-anonymiser le destinataire.Il s’agit d’un problème connu avec les adresses cachées et l’une des raisons pour lesquelles de nombreuses implémentations soutiennent l’EIP-4337 et les payeurs.
-
Un inconvénient du schéma d’adresse caché est que le récepteur doit surveiller la blockchain pour obtenirannonceEt vérifiez chaque annonce pour déterminer s’ils ont reçu les fonds.Il s’agit évidemment d’une surcharge irréaliste pour la plupart des utilisateurs, en particulier lors de la réception de fonds de plusieurs réseaux.Pour rendre ce processus plus efficace, la norme spécifie une « balise de vue », un hachage tronqué dérivé d’un secret partagé qui peut être utilisé pour éliminer rapidement les transactions qui ne sont évidemment pas destinées à leur être envoyées.En utilisant la balise de vue, les performances sur le bureau ne sont pas si mal, mais elle peut être plus visible sur les appareils mobiles.Le seul moment où la baisse des performances est vraiment évidente est si le portefeuille se rétablit, auquel cas le portefeuille doit scanner chaque adresse depuis le déploiement du contrat sur chaîne, ce qui prend beaucoup de temps.
-
Pour résoudre ce problème, les utilisateurs peuvent choisir de partager une clé de visualisation privée avec un tiers de confiance.Ce service tiers peut surveiller une variété de réseaux et informer les utilisateurs lorsqu’ils reçoivent des fonds.Bien sûr, cela apporte un compromis: alors que des tiers ne peuvent pas réellement dépenser des fonds d’utilisateurs (ils n’ont pas de clé de dépenses privées), ils peuvent voir tous les fonds envoyés à un destinataire spécifique, ce qui signifie que les utilisateurs ont besoin faire confiance à leur vie privée.FluidKey le fait par défaut.
-
Le protocole d’adresse secrète standard, à savoir ERC-5564, est conçu pour faciliter le transfert de protection de la vie privée, cependant, les cas d’utilisation non financiers (tels que l’appel des fonctions de contrat intelligent arbitraire) nécessitent plus d’ingénierie, souvent spécifique à la mise en œuvre.
-
Confidentialité de bout en bout terminée (seul l’expéditeur et le récepteur Voir les informations de paiement)
-
Confidentialité à l’avant.Les fonds reçus par le biais de transactions de dissimulation ne permettent pas à un deuxième destinataire de voir la source des fonds
-
Suivez les normes ERC-5564 et ERC-6538
-
Implémente une architecture modulaire évolutive qui permet l’intégration avec des DAPP tiers
-
La mise en œuvre fournit-elle un SDK que les développeurs peuvent utiliser pour intégrer?
-
La solution est-elle restée en conformité avec une sorte de support de désanonymisation?
-
La conception soutient-elle l’obscurcissement de la quantité / valeur transférée?
-
actif: L’identifiant de l’actif représenté par cette note (ETH, WBTC, MATIC, etc.). -
valeur: La valeur ou le montant représenté par les billets. -
feuille de feuille: Cette note sera insérée dans l’indice du nœud foliaire de l’arbre prometteur Merkel. -
aveuglant: Un facteur de protection aléatoire. -
rootaddress: L’adresse racine de l’utilisateur avec autorisation de dépenses. -
révocateur: Le point de clé publique de l’adorce sélectionné. -
Vont-ils fournir un support de plaidoyer pour une seule implémentation, ou vont-ils construire et maintenir une sorte d’agrégateur complet sur plusieurs protocoles?Ce dernier peut être coûteux en termes de développement et de maintenance.
-
Y aura-t-il des considérations réglementaires et devons-nous prendre position sur la portée et le mécanisme de la déanonymat sélectif (comme le cas du labyrinthe)?
-
Les adresses cachées nécessitent un composant sur chaîne, via un contrat d’enregistrement (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 cachées rendent l’intégration existante avec des détecteurs de blocs tels que Etherscan plus complexes.Par exemple, la vue sur le bouton du détecteur ne fonctionnera pas pour cacher des adresses de méta car le portefeuille affiche des soldes agrégés.Ce problème peut également exister dans le transfert.Ces cas marginaux doivent être soigneusement pris en considération.
-
Selon l’implémentation sous-jacente, les utilisateurs ne peuvent utiliser efficacement les adresses cachées avec un ensemble spécifique de DAPP, c’est-à-dire ces DAPP pris en charge par le protocole sous-jacent.L’architecture d’adresse de cachette modulaire rendra cela possible.Cependant, tous les DAPP ne seront pas pris en charge et les utilisateurs doivent être informés d’une manière ou d’une autre.Ceci est relativement facile lors de l’utilisation de l’EIP-5506, mais il existe toujours des cas de complexité et de bord qui peuvent pénétrer dans l’expérience utilisateur de votre portefeuille.
Adoption des accords de transaction secrète
Fer à chenillesLes données d’utilisation sont impressionnantes et l’utilisation du protocole semble avoir augmenté régulièrement au fil du temps, atteignant plus de 70 millions de dollars de valeur verrouillée totale (TVL) et 2 milliards de dollars en volume de négociation en novembre 2024.
TVL (USD) Railgun sur Ethereum Main Network – Source: Railgun – Defillama
OmbreLe nombre d’utilisateurs a également augmenté régulièrement (le nombre de personnes qui ont enregistré des adresses secrètes à leur ENS), approchant près de 77 000 en novembre 2024:
Umbra Nombre cumulatif de personnes inscrites (interchaine) – Source: Dune.com
Si nous regardons le protocole de confidentialité le plus connu (et maintenant malheureusement notoire) dans Ethereum, Tornado Cash, nous pouvons voir que malgré l’adresse du contrat incluse techniquement dans la liste SDN de l’OFAC, elle est toujours utilisée en grande quantité.
La figure suivante montre le TVL de Tornado Cash au fil du temps.Nous pouvons observer que depuis le sommet vers octobre 2021, la première baisse majeure de TVL a coïncidé avec la vente globale sur le marché de la cryptographie, et la deuxième baisse majeure s’est produite en août 2022, qui a coïncidé avec la liste de trésorerie de l’OFAC sur la liste des SDN sur la liste des SDN , le troisième déclin significatif correspond à la redégnation de l’OFAC en novembre 2022.Cependant, malgré les sanctions, l’utilisation de trésorerie de tornade n’a cessé de croître depuis lors, TVL approchant 600 millions de dollars.Il s’agit d’un fort témoignage de la nécessité de la confidentialité des transactions de base dans Ethereum.
TVL (USD) Tornado Cash on Ethereum Main Network – Source: Tornado Cash – Defillama
La situation actuelle des adresses cachées
Cette étude a identifié 4 solutions principales actuellement produites sur la chaîne EVM, qui sont:
Fluidkey et Umbra sont basés sur les normes Ethereum, qui sont:
Labyrinthe et Railgun sont basés surProtocole Zerocash(zcashÉgalement basé sur cela), le protocole utilise un pool de protection où les utilisateurs déposent des fonds.ZeroCash utilise le concept de « notes », qui est essentiellement une représentation cryptée de la valeur, capable d’atteindre des transactions privées.Chaque note comprend une valeur cachée, une clé de propriétaire et un numéro unique (un invalidateur), qui utilise ZK-Snarks pour vérifier la propriété sans les détails révélatrices, transférant ainsi la valeur dans la note.Lorsqu’une facture est dépensée, son invalidateur se révèle empêcher les doubles dépenses, tout en créant de nouvelles factures pour le récepteur, formant un système UTXO dans le pool de protection.
À un niveau élevé, le principe de base d’une adresse cachée est qu’un tiers peut envoyer des fonds à une adresse qui n’a jamais existé, et le destinataire prévu peut trouver et contrôler l’adresse (c’est-à-dire que les fonds peuvent être dépensés par la suite).
La norme ERC-5564 spécifie un mécanisme dans lequel le récepteur peut publier une adresse de méta cachée à partir de laquelle une nouvelle adresse Ethereum peut être dérivée.Quiconque souhaite envoyer des fonds au destinataire peut générer une nouvelle adresse à partir de l’adresse de l’élément caché et permettre au destinataire de se renseigner sur les fonds sans aucune communication directe.Toutes les adresses cachées sont implémentées en fonction de cette prémisse de base.
Comment fonctionne l’adresse secrète
L’adresse secrète de l’élément est essentiellement une connexion entre deux clés publiques compressées, appelées la « clé de spence » et la « clé de vue » respectivement.L’adresse Meta secrète utilise le format d’adresse spécifique à la chaîne EIP-3770 et ajoute le préfixe « ST: ».Voici un exemple d’une adresse cachée:
ST: ETH: 0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714e EC3507
Pour simplifier, cette adresse secrète peut être associée à une adresse Ethereum normale (et donc à ENS), ce qui facilite l’envoi de fonds au propriétaire de l’adresse secrète.Pour envoyer des fonds, l’expéditeur analyse l’adresse ci-dessus et utilise la norme EIP-5564 pour créer une clé publique temporaire à partir de laquelle l’adresse secrète est dérivée.L’expéditeur envoie les fonds à une nouvelle adresse cachée, généralement via un contrat Singleton où le récepteur de toutes les adresses cachées écoute les événements.Le contrat émet un événement «annonce» auquel le destinataire peut souscrire.Chaque fois qu’un événement d’annonce est publié, le destinataire vérifie la clé publique temporaire de l’annonce, le combine avec sa clé privée pour déterminer s’il a la possibilité de dépenser les fonds envoyés à l’adresse cachée.Si c’est le cas, le portefeuille / client qu’il utilise se souviendra de l’adresse cachée et des fonds correspondants et l’ajoutera à l’équilibre affiché de l’utilisateur.Pour dépenser réellement ces fonds, ils peuvent signer la transaction à l’aide d’une clé de dépenses privée.
Le graphique suivant décrit l’ensemble du processus plus clairement:
N’oubliez pas que ce processus est complètement non interactif, ce qui signifie qu’il n’y a pas de communication directe entre l’expéditeur et le récepteur, ce qui signifie qu’il n’y a en fait aucun lien entre l’expéditeur et le récepteur qu’un tiers peut observer.
Cependant, pour que cela fonctionne correctement, le récepteur doit informer l’expéditeur de son adresse secrète.Une façon de le faire est d’utiliserEIP-6538 Formulaire d’enregistrement d’adresse d’élément caché.Il s’agit d’un contrat Singleton qui permet aux utilisateurs d’enregistrer une adresse de méta secrète à une adresse Ethereum normale, que l’expéditeur peut rechercher.Cela permet à l’expéditeur d’analyser l’adresse normale de l’ESS, puis de rechercher les adresses Meta cachées pertinentes du registre.
Le schéma rompt le lien entre l’expéditeur et le récepteur, leur permettant tous les deux d’éviter le monde entier de connaître leurs affaires.Cependant, il y a certaines choses à noter:
Matrice de comparaison
Nous pouvons comparer les quatre implémentations d’adresses cachées discutées dans cet article de diverses manières.Toutes les implémentations ont des différences et des compromis subtiles, mais le point le plus important est peut-être le fuzzing de la traçabilité et de la valeur.
Alors que Fluidkey et Umbra permettent de transférer des fonds à des adresses Ethereum standard tout en détruisant tout lien vers l’identité du destinataire, ils conservent toujours la traçabilité des transactions, ce qui signifie que l’expéditeur sera contre toute personne qui vérifie l’historique des transactions de l’adresse secrète, elle est visible .Cela signifie que si vous recevez des fonds à une adresse cachée, la personne à qui vous décidez d’envoyer ces fonds verra d’où elle vient.De plus, la valeur réelle du transfert est également visible.Railgun et Labyrinth masquent l’expéditeur et la valeur de l’expéditeur, mais au prix de cela, tout se passe dans un seul contrat plutôt que comme une transaction normale à une adresse Ethereum normale.
La figure ci-dessous montre la comparaison mutuelle des protocoles dont nous avons discuté dans cet article sur ces deux dimensions comparatives importantes.
Pour explorer ces différences plus en détail, voici la matrice de comparaison des quatre principaux protocoles d’adresses cachés sur six dimensions principales:
La section suivante capture d’autres nuances et différences plus en détail.Chaque implémentation a des nuances intéressantes, qui peuvent ou non affecter votre cas d’utilisation.
Par exemple: dans Fluidkey: toutes les transactions sont directement transférées à l’adresse cachée de la chaîne, tandis que Umbra **: ** Seul ETH est transféré à l’adresse cachée de la chaîne, et les jetons sont transférés au contrat central. Labyrinth, toutes les transactions sont toutes transférées au contrat de base, plutôt que directement à l’adresse cachée de la chaîne.
Discussion approfondie sur la mise en œuvre des adresses cachées
Fluidkey
Fluidkeyest une implémentation de ERC-5564 qui permet aux utilisateurs d’envoyer, de recevoir, d’échanger et de pont les jetons ETH et ERC-20.Au moment de la rédaction du moment de la rédaction, Fluidkey a été déployé sur la base, l’optimisme, l’arbitrum, le polygone, la gnose et les plteurs d’ethereum.
Les utilisateurs interagissent avec FLUIDKEY via leur interface utilisateur Web.Lorsqu’ils se connectent pour la première fois avec leur portefeuille, ils signent un message de génération de clés à partir duquel ils déduisent leurs clés de visualisation et de dépenses.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.
Fluidkey a plusieurs manières différentes de celles des autres implémentations.L’une des différences est que les utilisateurs partagent leur clé de visualisation privée avec FluidKey (en fait uneBip-32dériver nœud).Cela permet à FluidKey de générer des adresses cachées pour les utilisateurs et d’informer les utilisateurs lorsqu’ils reçoivent le paiement de ces adresses.Cependant, cela signifie également que Fluidkey a la capacité de visualiser les transactions et les soldes de gain des utilisateurs, ce qui est un compromis.Cependant, FluidKey reste complètement auto-messier.
Un autre aspect intéressant de la conception de Fluidkey est qu’il déploie un compte de contrat intelligent pour chaque nouvelle adresse cachée.Cela ne se produit que lorsque les fonds financés par des adresses auto-résolus sont utilisés.Le compte intelligent est un compte sécurisé 1/1 qui permet des opérations telles que le parrainage du gaz, ce qui facilite la gestion de diverses adresses cachées.Pour plus d’informations à ce sujet, veuillez consulter leurExplication technique.
Bien que Fluidkey conserve la visibilité sur les comptes d’utilisateurs, cela peut potentiellement être un avantage en conformité, bien que le cadre exact de la façon dont Fluidkey gère les demandes potentielles de l’application des lois n’a pas été divulguée.Ils sont situés en Suisse et malgré les lois locales, les lois sur la protection des données sont très claires et puissantes – il doit y avoir des raisons très claires de partager des données, et l’affaire sera examinée par la Cour (Voir cet articleDécouvrez un bon aperçu des lois suisses sur la vie privée).
Les utilisateurs peuvent également exporter pleinement leurs transactions ou partager leurs clés de visualisation avec des tiers, tels que les comptables, ce qui est particulièrement utile pour les entreprises.Il convient de noter que, selon la spécification ERC-5564, le partage de clés publics est « tout ou rien », ce qui signifie qu’il ne peut pas divulguer les transactions uniques orphelines seules.En outre, comme toutes les implémentations ERC-5564, la traçabilité n’est pas rompue – juste la corrélation avec l’utilisateur – ce qui signifie que l’historique des transactions de chaque adresse cachée est accessible au public pour ceux qui ont la clé de visualisation.Une fonctionnalité moins connue de Fluidkey est la possibilité de faire tourner les touches de vue, qui permettra aux utilisateurs d’utiliser une nouvelle clé de vue par mois et de partager l’accès à la vue pour un mois spécifique avec des tiers uniquement.
Un avantage de la méthode FluidKey est que l’adresse cachée elle-même n’est pas générée par l’expéditeur, mais est générée par pseudo-aléatoire par Fluidkey à chaque fois qu’il interroge ENS.C’est plus rapide car les utilisateurs n’ont pas à parcourir l’événement d’annonce pour identifier les transactions qu’ils sont destinataires.Cela signifie également que l’expéditeur n’a pas besoin d’un portefeuille d’adresses cachés pour générer une adresse cachée pour le destinataire – ils ont juste besoin d’envoyer des fonds comme d’autres adresses.Cela signifie également qu’aucun contrat d’enregistrement n’est impliqué, ce qui est unique et un avantage majeur de la conception de Fluidkey.
Il convient de mentionner que Fluidkey est déterminé à être complètement entretenu, et ils ont ouvert leur bibliothèque de kits de compte cachés et, peu probable, Fluidkey disparaît du jour au lendemain, il y a plusieurs récupérations de développement indépendantes. être verrouillé ou coincé.
Abstraction d’adressage
En utilisant des comptes de contrat intelligents, Fluidkey peut gérer automatiquement abstraitement les adresses cachées individuelles.Cela signifie que si vous souhaitez transférer un montant spécifique de votre solde dans chaque adresse cachée à un destinataire spécifique, Fluidkey peut automatiquement calculer la combinaison d’adresses utilisée pour transférer des fonds, gérer tous les frais de gaz et les déploiements de contrat, qui se déroulent tous en arrière-plan .FluidKey permet également aux utilisateurs de passer unÉtiquetteLa fonction cool de l’adresse à combiner permet aux utilisateurs de marquer l’adresse en différentes catégories.
Analyse ENS
FluidKey exige que les utilisateurs créent un nom ENS exclusif à FluidKey.Ces noms statiques se présentent sous deux formes: username.fkey.id et username.fkey.eth, l’un est l’URL de l’interface Web qui envoie des fonds à quelqu’un, et l’autre est le nom ENS standard qui peut être utilisé avec le portefeuille.
Utilisation des paramètres ENSEns Offchain Resolver(également connu sous le nomERC-3668: lecture CCIP) Pour retourner l’adresse cachée.Chaque fois que le résolveur hors ligne est interrogé, il génère et renvoie une nouvelle adresse cachée pour le nom ENS correspondant.Il s’agit d’une excellente fonctionnalité car elle permet à l’utilisateur d’avoir un seul nom ENS lisible par l’homme tout en conservant l’intimité de l’adresse cachée, car l’adresse cachée générée ne peut pas être retracée au nom ENS.
coût
Fluidkey est libre à utiliser et il n’y a pas de charge.Lorsque vous souhaitez dépenser de l’argent, chaque adresse avec des fonds doit déployer des frais de contrat en toute sécurité.Cependant, bien qu’il soit relativement coûteux sur le MainNet, cela est en fait trivial sur L2, généralement moins de 1 cent, même si plusieurs adresses cachées sont combinées en un seul transfert.
Ils peuvent également faire du parrainage de gaz par le biais de déploiements sûrs – ils calculent les frais de gaz et le déduisent du solde de l’utilisateur, même s’il s’agit d’un jeton – dans ce cas, le transfert déploie des jetons sûrs et transfère les jetons au nom de l’utilisateur.
Embra Cash
OmbreOuiScopeliftImplémenté EIP-5564 + EIP6538.Lorsque les utilisateurs se connectent à l’application Umbra, ils passent par une phase de configuration où ils signent un message à partir desquels ils tirent des dépenses et affichent les clés et les adresses de méta cachant correspondantes.Ils enregistrent ensuite cette adresse de méta cachée au registre sur chaîne de leur adresse de portefeuille principale.C’est la différence entre la mise en œuvre et FluidKey.
L’implémentation par Umbra de l’ERC-5564 est la plus proche de la spécification car ils ne peuvent pas accéder à la clé de l’utilisateur.Bien que cela signifie que Umbra (ou quelqu’un d’autre) ne peut pas voir les fonds de l’utilisateur, cela signifie que pour recevoir des fonds, l’expéditeur doit avoir un portefeuille compatible ERC-5564 (ou une application Umbra) pour générer son adresse occulte.
Quand quelqu’un veutenvoyerLorsque des fonds sont donnés aux utilisateurs, ils utilisent généralement l’application Umbra pour la terminer.Fondamentalement, l’application Umbra recherche la méta-address cachée enregistrée sur l’adresse ENS Nom / Wallet et génère une adresse cachée.Les destinataires peuvent se connecter à l’application Umbra et rechercher tous les fonds envoyés à leur adresse cachée depuis la dernière connexion.Grâce à un cache intelligent, cela semble ne prendre que 10-15 secondes pour les analyses hebdomadaires, bien que les utilisateurs puissent également choisir de spécifier une plage de blocs pour réduire le scan.Umbra V2 comprendra l’utilisation des balises de vue, qui accélérera davantage le processus.
Répartition
L’un des problèmes avec l’adresse cachée que nous avons mentionnée précédemment est que pour que le destinataire dépense les fonds envoyés à l’adresse cachée, l’adresse doit avoir ETH ou d’autres jetons de gaz nécessaires pour payer les frais de transaction.Sur la plupart des réseaux, ce n’est généralement pas un problème si l’adresse cachée reçoit initialement ETH.Cependant, si un jeton ERC-20 ou NFT est reçu par une adresse cachée, l’acte de fournir du gaz à l’adresse avec ETH peut associer cette adresse à d’autres adresses de l’utilisateur, perdant ainsi la confidentialité.
Pour contourner ce problème, Umbra a utilisé unRépartitionstructure.Lorsqu’un actif non eth est envoyé à un utilisateur Umbra, il est en fait envoyé à un contrat spécial, plutôt que directement à une adresse cachée.Les utilisateurs peuvent dépenser des fonds envoyés à leur adresse cachée en envoyant des métatransactions (de l’application Umbra) aux transitaires d’Umbra, qui transfèrent des fonds du contrat intelligent au nom de l’utilisateur.Le transmission déduira certains jetons pour couvrir le coût des frais de gaz et ne prend initialement que un certain nombre de jetons.
coût
Les contrats UMBRA facturent également de petits frais lors du transfert de fonds sur des réseaux avec des frais de transaction faibles pour limiter le spam.La raison en est que le spam augmente le coût des transactions de numérisation pour identifier les transactions connexes, ceci est donc considéré comme un compromis acceptable.
Réseaux pris en charge
Umbra est actuellement déployé sur le Mainnet Ethereum, ainsi que l’optimisme, le polygone, la chaîne de gnose et l’arbitrum.
Le contrat d’enregistrement UMBRA a des conceptions intéressantes.La méthode de déploiement utilise des déploieurs Create2 et Standard Create2, 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é, le client peut s’assurer qu’il s’agit du bon contrat.Les clients peuvent être configurés pour ajouter des réseaux et n’importe qui peut se déployer sur n’importe quel réseau.Ils ont normalisé le bytecode et le contrat n’a pas de propriétaire, ce qui permet à quiconque de déployer des contrats d’enregistrement et d’annonce sans autorisation sur aucune chaîne.
Umbra v2
Scopelift est actuellement en développementLa 2e édition d’Umbra, Cette version introduit une nouvelle architecture modulaire qui permet aux extensions de contrat de base de prendre en charge de nouvelles normes de jeton ou des cas d’utilisation non-paiement.Avec cette nouvelle architecture, les développeurs tiers peuvent créer des modules pour tout type de normes de jeton, telles que ERC-1155, ERC-7621, les payeurs compatibles ERC-4337, ou tout ce que vous pouvez penser.Actuellement, le contrat Umbra Core prend en charge deux scénarios, l’un pour ETH et l’autre pour ERC-20.V2 prendra en charge de nombreux scénarios différents.
Labyrinthe
Labyrintheest un protocole qui n’est pas basé sur l’EIP-5564 + EIP6538, mais utilise une preuve de connaissance zéro pour ajouter l’anonymat et la confidentialité aux transactions.Le livre blanc de Labyrinth le décrit comme le middleware « ZKFI »: « ZKFI fournit une solution d’emballage qui agit comme un middleware de confidentialité avec une conformité intégrée».
Les principaux contrats intelligents utilisés par Labyrinth incluent un pool multi-transaction et multi-assembres qui permet aux utilisateurs d’échanger plusieurs actifs dans une seule transaction.Pour dépenser des actifs, les utilisateurs scannent le réseau et obtiennent des données de notes cryptées, décryptent les notes et filtrez les actifs qu’ils souhaitent dépenser.L’utilisateur crée ensuite un ZKP qui inclut les clés de signature pour la transaction et les notes associées aux transactions qu’ils souhaitent dépenser.
Une partie du contrat de base de Labyrinth comprend un contrat de conversion qui interface avec des contrats de proxy modulaires qui se proxent essentiellement des contrats externes.Ainsi, par exemple: si l’utilisateur souhaite interagir avec uniswap à l’aide de Labyrinth, l’utilisateur établira une transaction qui invoquera l’opération d’échange sur le pool uniswap en utilisant le contrat de conversion via le contrat de proxy de l’UNISWAP.
Le protocole ZKFI de Labyrinth utilise des «notes» pour suivre les soldes et les transferts.Un projet de loi est essentiellement une structure de données qui décrit un certain nombre d’actifs et leur adresse à laquelle ils appartiennent.Le client stocke les informations nécessaires pour reconstruire les notes et utilise ces informations pour dépenser des actifs.L’engagement envers les notes (hachage de l’ID d’actif, propriétaire et valeur) est stocké dans l’arbre Merkel sur la chaîne.En fait, Labyrinth utilise deux arbres Merkel, un pour le billet et un pour l’adresse racine.
La structure des données de note contient les éléments suivants:
Vous remarquerez que la structure de données ci-dessus ne contient pas d’actifspropriétaireToute référence à cela est étrange car les promesses enregistrées dans l’arbre Merkel de notes sont l’identifiant d’actif, la valeur etpropriétairehachage de.En fait, le propriétaire est calculé à partir de l’adresse racine, du révocateur et du facteur de protection aléatoire, donc pour les observateurs externes, le propriétaire est en fait une nouvelle adresse générée par chaque nouvelle transaction.
Piscine de protection
En ce qui concerne le labyrinthe, il est particulièrement intéressant qu’il soit légèrement différent du protocole traditionnel basé sur des adresses cachées, et le pool d’actifs est en fait un pool de protection qui utilise les notes pour créer un pool UTXO blindé, fournissant ainsi un ancien pour les transactions. .Rappelons que dans l’implémentation EIP-5564, l’objet de transfert d’utilisateur pourra afficher la source de ces fonds.En d’autres termes, Alice paie Bob avec une adresse secrète, et Bob le paie à Charlie, afin que Charlie puisse maintenant voir Bob recevoir les fonds d’Alice au départ, et ainsi de suite.Ce n’est pas le cas avec la piscine de protection de Labyrinth.
Pour comprendre comment fonctionne ce pool de protection, nous devons voir comment les fonds sont transférés dans le protocole:
Le solde de l’utilisateur dans le pool de protection est la somme des notes des actifs correspondants.Pour dépenser ces notes, les utilisateurs doivent révéler le « logo non valide » de ces notes.Un logo non valide est uniquement lié à une note, et une fois la note dépensée, le logo non valide est marqué pour empêcher la double consommation et créer une nouvelle note basée sur la note dépensée.Plusieurs notes pour le même actif peuvent être fusionnées et plusieurs nouvelles notes peuvent être créées.Un identifiant non valide est un hachage de (?,?,?), Où?
Les destinataires des transferts de transactions secrètes identifient le transfert de la même manière que l’EIP-5564, car ils écoutent les événements envoyés à partir du contrat principal et déterminent l’adresse secrète à partir de laquelle ils pourront envoyer des fonds et enregistrer ces adresses localement.La vitesse d’identification des fonds entrants a également été améliorée en tirant parti des balises de vue et en cache et en notes synchrones de manière asynchrone tout au long du cycle de vie de l’application.
Des recherches sont actuellement en cours pour accélérer le processus de découverte de la réception de fonds et jetez un œil à cette proposition d’Aztec:Demande de propositions: Protocole de découverte de notes – Aztèque.
En termes de dépenses d’argent, les utilisateurs doivent également générer une preuve ZK, ce qui est différent de l’implémentation ERC-6654 qui est essentiellement une adresse Ethereum normale.La génération de preuve nécessite un portefeuille compatible avec des performances relativement bonnes, et il faut environ 20 secondes sur les appareils Android de milieu de gamme.
Packers et convertisseurs
Labyrinth fournit de bonnes fonctionnalités qui peuvent résoudre certains points de douleur dans les transactions secrètes.Les transactions envoyées au contrat de base Labyrinth sont envoyées sous forme d’opérations utilisateur via le packager ERC-4337.Ce paramètre permet les frais de billets sans avoir besoin d’ETH ou de jetons de gaz transactionnels, car les utilisateurs peuvent utiliser les payeurs ERC-4337 pour payer du gaz pour eux, ajoutant une couche supplémentaire de confidentialité.La seule exception est le dépôt initial, qui n’est pas soumis en tant qu’action utilisateur.Un autre avantage de l’utilisation des payeurs ERC-4337 est la possibilité de payer du gaz par le biais des actifs transférés, même s’ils sont des jetons ERC-20, donc Labyrinth expose une API Oracle de prix de gaz.
Une autre très bonne caractéristique du labyrinthe est son architecture modulaire qui permetConvertisseurLes contrats servent d’agents pour des demandes décentralisées tierces.Cela permet non seulement aux utilisateurs de transférer des fonds à l’aide de transactions cachées, mais aussi d’interagir avec des applications décentralisées tierces (telles que les DEX telles que UNISWAP, Aave, Lido, etc.).Ces agentsConvertisseur« Le contrat implémente essentiellement une fonction qui reçoit une certaine quantité d’actifs et d’écoute certains actifs. La logique de base existe dans un contrat tiers.
Solutions de conformité
Labyrinthe assure la conformité et la conformité réglementaire à travers un cadre appelé déanonymisation sélective (SEDE).
Rappelons que la structure de données de la note contient un champ appelé « Undoer ».Le révocateur est l’adresse d’une entité spécifique qui peut initier le processus de désanonymisation.L’utilisateur doit sélectionner au moins un révocateur dans la liste prédéfinie.Le révocateur n’est pas uniquement responsable de l’identification d’activités potentielles illégales ou inappropriées, mais peut répondre aux demandes des organismes chargés de l’application des lois.
Le révocateur n’a pas la possibilité de désanoniser directement les transactions, mais ils sont responsables de l’initiation des demandes de désanonymisation.Ces demandes sont publiées publiquement auprès de The Guardian, un comité de fond qui surveille la vie privée et la conformité.Le Guardian doit voter pour décider d’autoriser l’autorisation des transactions de désanonymisation.Si le Guardian peut atteindre le quorum et voter pour celui-ci, le révocateur peut décrypter les données de transaction, reliant ainsi la transaction pertinente avec la transaction précédente jusqu’à ce que la chaîne de transaction soit complètement désanonyme.
Ce système crée une série de chèques et de contrepoids parce que les Gardiens ne peuvent pas décider de révéler les données de transaction, et même s’ils se terminent, ils ne peuvent rien faire sans le révocateur, et le révocateur ne peut le faire avec la majorité des votes du Guardian. .
Fer à chenilles
Fer à chenillesIl s’agit d’un système de confidentialité de transaction secrète déployé sur Ethereum, Binance Smart Chain, Polygon et Arbitrum.Le protocole est similaire à certains moyens au labyrinthe car il est basé surnotes, ces notes sont stockées comme des promesses dans l’arbre Merkel, formant un ensemble UTXO, c’est-à-dire en créant de nouvelles notes pour que d’autres destinataires dépensent.Cela signifie que seul le propriétaire de la note peut calculer son identité non valide, qui est souvent générée en fonction du hachage de la clé de dépenses et de l’indice de la note dans l’arbre Merkel.
Les adresses de méta cachées dans RailGun utilisent le préfixe de « 0ZK », similaire à EIP-5564, qui est une combinaison de clés de visualisation publique et de clés de dépenses publiques.Cependant, RailGun utilise la clé ED25519 sur la courbe babyjubjub au lieu d’ECDSA et SECP256K1.Tout comme EIP-5564, les utilisateurs scannent tous les événements émis dans le contrat RailGun et utilisent leur clé de vue pour déterminer quels événements représentent les transferts à leur portefeuille.
Railgun utilise unDiffuseurRéseau, ces diffuseurs sont en fait des relais qui reçoivent les métatransactions de l’utilisateur et diffusent les transactions réelles à la blockchain correspondante pour payer des frais de gaz au nom de l’utilisateur.Les transactions des utilisateurs aux radiodiffuseurs sont cryptées et utiliséesAccord WakuEffectuer une communication pour protéger l’anonymat des utilisateurs finaux.
Railgun adopte une architecture modulaire qui lui permet d’interagir avec des contrats intelligents externes, fournissant des fonctionnalités au-delà des transferts simples.Ça passeAdaptrelayLe contrat y parvient, qui protège et déprotecte les jetons avant et après avoir interagi avec un contrat externe, par exemple, un jeton non protégé A, échange le jeton B sur un AMM et protège le jeton B au propriétaire d’origine.
Dans la version 3, RailGun prévoit de tirer parti de l’EIP-4337 et prend en charge les métatransactions traditionnelles.Ils espèrent permettre aux solveurs indépendants de participer en tant que diffuseurs en maintenant un pool de mémoire EIP-4337 dédié pour RailGun.Ils travaillent actuellement avec Umbra sur cette question et identifient les cas Edge et comment les résoudre, consultez la section Railgun V3 ci-dessous pour plus de détails.
coût
L’accord Railgun facture des frais de 0,25% pour les dépôts et les retraits.Ces frais seront envoyés à l’entrepôt DAO, qui sera payé au fil du temps aux parties prenantes des jetons de gouvernance ferroviaire.En plus des frais de dépôt et de retrait de 0,25%, les radiodiffuseurs facturent généralement leurs propres frais, qui représentent généralement environ 10% des frais de gaz pour les transactions réelles en chaîne.
Gouvernance
Railgun a un système de gouvernance qui permet la soumission de toute forme de proposition, et toute modification des contrats de base, y compris les contrats fiscaux et de gouvernance, doit être effectué avec une proposition DAO.Inhabituellement, différents cas de Railgun ont leur propre gouvernance.Par exemple, Railgun a ses propres systèmes de gouvernance indépendants et jetons sur Ethereum, Polygon et Binance Chain.
SDK et livre de cuisine
RailGun fournit un SDK complet et bien documenté que les développeurs de Wallet ou DAPP peuvent utiliser pour construire des fonctionnalités d’adresse cachée par le support de RailGun.Railgun a également unlivre de cuisine, fournit une « recette » qui permet aux développeurs DAPP de fournir des modules pour RailGun, permettant aux utilisateurs d’interagir avec leurs DAPP à l’aide de RailGun.Par exemple, un développeur pourrait rédiger une recette pour Dex afin que les utilisateurs avec des soldes de jetons dans Railgun puissent échanger des jetons en privé.
Railgun v3
La prochaine itération de Railgun réduira les coûts de transaction de 50% à 60%.D’autres modifications de la version 3 sont la prise en charge des utilisateurs d’EIP-4337, implémentées via un pool de mémoire dédié.De plus, V3 prendra en charge les architectures basées sur l’intention qui permettent aux solutionnistes de rivaliser pour la meilleure exécution, bien que les détails restent très élevés en ce qui concerne l’écriture.Ils travaillent actuellement avecVoletEn travaillant ensemble, prévoit d’utiliser des crochets avant et arrière pour permettre aux résolveurs d’accéder aux fonds.
Railgun Connect
Le changement le plus intéressant de la proposition est sans doute le changement le plus intéressant est un outil appelé RailGun Connect, qui est similaire à WalletConnect, permettant à des adresses 0zk d’être connectées à la plupart des fins frontales pour un usage privé sans ces DAPP fournissant explicitement l’intégration avec RailGun via des modules personnalisés.
Railgun Connect est une extension de navigateur qui utilise réellement l’état du hardhat localement pour reproduire l’état de la chaîne et injecter son propre fournisseur Web3 dans le DAPP, avec un point de terminaison RPC avec une chaîne de version HardHat locale.Cela vous permet d’interagir avec un contrat DAPP comme d’habitude, d’enregistrer les transactions, puis de le lfier et de créer une preuve de snark et de l’envoyer au contrat Railgun sur la chaîne réelle.Bien que cette description soit un peu plus simple, elle transmet l’idée globale.Cela vous permet d’interagir avec presque tous les DAPP (il peut y avoir des cas de bord pour les DAPP qui nécessitent un traitement hors lien supplémentaire).Il convient de noter que l’état de la chaîne de sauvegarde locale est une opération consommatrice de ressources, mais une fois terminé, vous pouvez utiliser l’adresse cachée de Railgun pour interagir avec le DAPP sans aucune différence par rapport à l’utilisation d’un portefeuille normal.
en conclusion
Il existe des propositions intéressantes pour établir des adresses cachées dans le protocole Ethereum.Par exemple,ImprégnerLe concept d’un « wrapper » ERC-20 est utilisé, qui résume un contrat ERC-20 normal et crypte tous les équilibres.Les transferts et les approbations sont tous deux effectués à l’état chiffré via un cryptage entièrement homomorphe.Inco repose sur des précompilateurs qui n’existent actuellement que sur son propre réseau, mais qui peuvent passer à Ethereum à l’avenir.
Il y a une autre proposition appeléeEIP-7503: trous de ver de la connaissance zéro, qui est basé sur une conception appelée « preuve de brûlure », bien que cette proposition ne semble pas avoir reçu beaucoup d’attention, probablement parce qu’elle nécessite une mise à jour de l’EVM, sans cette mise à jour, elle ne peut être mise en œuvre qu’au niveau du jeton, Utilisez une conception ERC-20 qui prend en charge spécifiquement EIP-7503 (ou si un L2 décide d’ajouter la prise en charge de son opcode EVM).
AztèqueProbablement la technologie de confidentialité la plus complexe pour le moment, mais elle oblige les utilisateurs à combler les fonds vers Aztec à utiliser, ce qui peut ne pas être acceptable pour la plupart des utilisateurs.Cependant, si la demande des utilisateurs d’Ethereum pour la confidentialité des transactions de base augmente, Aztec peut avoir une proposition de valeur unique pour devenir un L2 très précieux à mesure que les DAPP et les utilisateurs migrent vers une plate-forme qui fournit la confidentialité par défaut.
même,IntmaxIl s’agit d’un Ethereum L2 axé sur la confidentialité (basé sur la conception du plasma), qui a également un aspect réglementaire de conformité, vérifiant la légitimité des fonds individuels via ZKP en fonction de la LMA et imposant des restrictions aux montants de transaction.Intmax a des restrictions à fournir des transferts de confidentialité aux transferts d’argent, tandis que les opérations de contrat intelligent EVM n’ont pas de confidentialité.Cependant, contrairement à Aztec, les contrats intelligents peuvent être écrits en solidité, que certains développeurs peuvent préférer (selon le cas d’utilisation).
Support de portefeuille
Alors que nous constatons une augmentation de l’adoption de protocoles d’adresses cachés, qui est un signal positif, il y a encore de nombreux défis.Le défi le plus important est qu’ils ne sont pas entièrement soutenus dans les portefeuilles Ethereum traditionnels (du moins pas encore).Les portefeuilles grand public peuvent avoir besoin de faire plusieurs choix lors de la support des adresses cachées.Ces options incluent:
Il y a une place à l’amélioration de la prévention de la confidentialité et de l’hygiène des utilisateurs médiocres, veuillez vous référer à cet article:Analyse d’anonymat du schéma d’adresse furtive Umbra sur Ethereum», L’auteur a réussi à dénommer 48,5% des transactions de furtivité sur le maintien du maintien Ethereum. L’adresse d’envoi initiale, croyant à tort que la traçabilité a été brisée. être adressé.
Dans l’ensemble, je suis assez optimiste quant aux adresses invisibles et à la confidentialité dans Ethereum.Je pense que nous avons fait des progrès assez impressionnants et trouvé des défis très correctifs.Je crois que les portefeuilles grand public trouveront des moyens de fournir un support d’adresse invisible afin que les utilisateurs puissent facilement utiliser ces adresses et profiter du niveau normal de confidentialité que les utilisateurs attendent et méritent.
Grâce à toutes les équipes qui ont investi leur temps et leur dur labeur dans la recherche et la construction d’infrastructures d’adresse invisible, y compris les quatre protocoles que j’ai mentionnés dans ce post.Leurs efforts et leur ténacité auront un impact énorme sur Ethereum!
