Privacy on-chain : ce que Monero et Zcash peuvent apprendre à Ethereum

Zcash

Lancée en 2016 comme fork de Bitcoin Core, Zcash est une blockchain proposant une approche hybride. Concrètement, comme sur la grande majorité des blockchains publiques, les transactions y sont entièrement transparentes par défaut.

Néanmoins, les utilisateurs ont la possibilité de dissimuler leurs activités on-chain en utilisant des adresses “shieldées”. Cette anonymisation des transactions repose sur un système de pools qui fonctionnent elles-mêmes grâce aux zk-SNARKs.

Adresses transparentes ou shielded

En pratique, Zcash repose sur la coexistence de deux types d’adresses :

• Les adresses transparentes (t-addr), identiques à celles de Bitcoin, avec expéditeur, destinataire et montant visibles ;
• Les adresses shieldées (z-addr), où toutes les informations sont chiffrées et invisibles pour un observateur externe.

La confidentialité sur Zcash est donc optionnelle, et il est possible d’utiliser le réseau sans jamais recourir aux fonctionnalités de privacy via les adresses z-addr.

Pools

Les adresses shieldées sont organisées en différentes pools (Sprout, Sapling et Orchard), qui correspondent aux évolutions successives du protocole. Ces itérations ont notamment permis de réduire progressivement le coût et la complexité de création des transactions.

Lorsqu’un utilisateur dépose des ZEC dans une pool, on dit que ces derniers sont “shieldés“. Ils peuvent alors être transférés à d’autres adresses au sein de cette même pool de manière totalement anonyme. Chaque pool constitue cependant un environnement isolé, ce qui signifie que l’”anonymity set” est limité au volume de ZEC qu’elle contient.

Pour vous donner une perspective de l’évolution de la privacy sur Zcash, au début de 2025, seulement 12 % des ZEC se trouvaient dans des pools. Ce nombre a grandement augmenté pour aujourd’hui atteindre 30,4 %, dont 87,3 % se situent dans la pool Orchard, c’est-à-dire la dernière itération du protocole.

zk-SNARKs

Au sein des pools de confidentialité de Zcash, toutes les informations relatives aux transactions sont chiffrées. L’utilisation des zk-SNARKs permet de prouver leur validité, notamment la cohérence des montants et l’absence de double dépense, sans en révéler le contenu.

Parallèlement, le protocole repose sur le concept de “notes”, lesquelles encodent un montant ainsi qu’une clé de propriété. Ces notes sont ensuite stockées sous forme chiffrée dans un arbre de Merkle dont la racine est publique. Dans les faits, lorsqu’un utilisateur souhaite dépenser une note, il génère une preuve zk-SNARK attestant que cette note existe bien dans l’arbre et qu’il en est le propriétaire légitime, sans toutefois révéler laquelle.

En parallèle, un “nullifier“ est également publié. Ce dernier correspond à un hash de la note, et il est automatiquement comparé à l’ensemble des nullifiers déjà existants. S’il apparaît pour la première fois, cela prouve que la note n’a jamais été dépensée auparavant. Ce mécanisme permet ainsi de résoudre la problématique de double dépense sans jamais exposer d’information sur la transaction.

Limites du modèle de Zcash

Malgré un anonymat théoriquement parfait au sein d’une même pool, Zcash présente plusieurs limites :

• La première pool, Sprout, reposait sur un protocole de confiance impliquant six participants. En cas de collusion, ceux-ci auraient pu créer des ZEC ex-nihilo sans que cela ne soit détectable. La pool Sapling a étendu ce processus à 90 participants, réduisant fortement ce risque. La dernière pool en date, Orchard, a supprimé ce besoin, mais il reste aujourd’hui malgré tout impossible de prouver formellement le nombre exact de ZEC présents dans chaque pool.
• La privacy étant opt-in, l’anonymity set est limité aux utilisateurs ayant choisi de shield leurs fonds, ce qui peut paradoxalement rendre ces transactions plus suspectes ;
• Les passages entre adresses transparentes (t-addr) et shieldées (z-addr) restent visibles, ce qui peut permettre de tracer certains flux, notamment lorsque les montants sont identiques ;
• Malgré les améliorations successives, le calcul des zk-SNARKs reste relativement lourd, ce qui peut dégrader l’expérience utilisateur, en particulier sur mobile.

---

Monero

À la différence de Zcash, Monero repose sur une obfuscation obligatoire des transactions. Concrètement, ce procédé consiste à noyer les informations de l’envoyeur parmi de nombreuses autres transactions potentielles tout en masquant le montant transféré ainsi que l’adresse de destination.

Il s’agit donc d’une privacy probabiliste dont le niveau peut varier selon l’usage qui en en fait, mais où toutes les transactions participent effectivement à l’anonymity set.

Le mécanisme de privacy de Monero repose sur le triptyque suivant : les Stealth Adresses, les Ring Signatures et ringCT.

Stealth Adresses

Lorsqu’un utilisateur de Monero envoie des XMR, il génère une stealth adress, c’est-à-dire une adresse à usage unique dérivée de la clé publique du destinataire. Cette adresse ne sera jamais réutilisée par la suite, et il est impossible pour un observateur extérieur de la relier à la clé publique du receveur.

Pour identifier les transactions qui lui sont destinées, le destinataire doit “scanner” la blockchain à l’aide de sa clé privée. S’il est capable de déchiffrer une transaction, alors les fonds lui appartiennent. Les autres transactions demeurent impossible à déchiffrer pour lui.

Ring Signature

Lors de la signature d’une transaction, l’output réel est mélangé avec quinze autres outputs servant de leurres, formant un cercle de signataires potentiels. Ces leurres correspondent à des outputs réels présents sur la blockchain.

Concrètement, les signatures de cercle permettent de prouver que la transaction provient de l’un des membres du groupe, sans toutefois pouvoir identifier lequel. C’est précisément cela qui confère à Monero son caractère de privacy probabiliste.

Le choix des leurres constitue un paramètre déterminant : S’ils sont mal sélectionnés, la probabilité d’identifier le véritable expéditeur peut augmenter de manière significative. À ce propos, une étude récente a d’ailleurs montré qu’en utilisant certains algorithmes, les chances de retrouver le bon output pouvaient être ramenées à environ 1 sur 4,2 en moyenne, ce qui souligne certaines limites du modèle.

RingCT

Bien qu’elles permettent de dissimuler l’adresse de l’expéditeur mais pas les montants, les Ring Signatures pourraient être utilisées pour identifier l’output d’une transaction donnée. C’est là que RingCT, le 3e pilier du triptyque de Monero, vient compléter le dispositif de Monero.

Introduit en 2017, RingCT permet de dissimuler le montant des transactions sur Monero via ce que l’on appelle les engagements de Pedersen. Ces derniers permettent de prouver que les inputs et outputs d’une transaction sont équilibrés et qu’aucun XMR n’a été créé ou détruit, et ce sans révéler les valeurs sous-jacentes lors du processus.

Limites du modèle de Monero

• Un mauvais choix des leurres peut augmenter la probabilité d’identifier l’expéditeur réel dans le cas où plusieurs Stealth Adresses seraient consolidées au sein d’une même transaction. Dans ce cas de figure, puisque chaque output dispose de son propre cercle, cette transaction révélerait qu’un output appartient à la même personne dans différents cercles. Ce point est en partie adressé par la mise à jour FCMP++, prévue en 2026, qui vise à étendre les cercles à l’ensemble des outputs de la blockchain ;
• L’identification des transactions nécessite de scanner la blockchain, ce qui reste plus lourd que sur Zcash, et ce malgré l’introduction des view tags en 2022.

---

Zcash ou Monero ?

En définitive, ces deux modèles reposent sur des approches radicalement différentes. Zcash offre cune confidentialité théoriquement parfaite grâce aux zk-SNARKs, mais qui dépend fortement de l’adoption des pools. Dans les faits, aujourd’hui, seuls 30 % des ZEC sont shieldés, ce qui limite nettement l’anonymity set.

Monero propose au contraire une privacy généralisée, où chaque transaction participe à la sécurité de l’ensemble, au prix d’un anonymat probabiliste plutôt qu’absolu. Néanmoins, le fait que l’ensemble du réseau participe au procédé atténue fortement les limites identifiées.

Dans le cadre d’une blockchain dédiée aux paiements anonymes, l’approche de Monero semble aujourd’hui la plus adaptée. Mais cette logique est-elle transposable à Ethereum ?

---

Quelle solution pour Ethereum ?

Aujourd’hui, deux propositions s’opposent avec des sous-jacents assez similaires à Monero et Zcash, l’ERC-5564 et Strawmap.

ERC-5564

Publiée en août 2022, l’ERC-5564 propose d’introduire des adresses furtives (stealth adresses) similaires à celles de Monero. En pratique, via ce standard, lorsqu’un utilisateur envoie des fonds, une adresse unique est générée à partir de la clé privée du destinataire.

Pour éviter de devoir scanner l’ensemble de la blockchain, ces transactions sont enregistrées dans un smart contract dédié. Le standard intègre également les view tags pour faciliter la vérification de la propriété des transactions.

Limites du modèle

• Contrairement à Monero, aucune donnée n’est masquée : expéditeur, destinataire et montant restent visibles ;
• Les adresses furtives étant regroupées dans un contrat unique, leur identification est triviale, ce qui réduit fortement l’anonymity set ;
• Ces adresses ne disposent pas de gas par défaut, ce qui pose des problèmes d’utilisation. Une solution pourrait être d’ajouter nativement le gas nécessaire dans le total du montant envoyé dans la transaction. Une autre alternative pourrait consister à appuyer la transaction avec un paymaster reposant sur les zkSnarks, ce qui permettrait théoriquement de payer le gas d’une stealth adress sans avoir à dévoiler l’adresse initiale ;
• Puisque toutes les informations sont publiques, la consolidation des fonds ou leur dépense permettrait de révéler le véritable propriétaire de ces adresses furtives.

L’ERC-5564 propose une implémentation très partielle de la privacy appliquée sur Monero. Cela a pour conséquence une solution inadaptée qui crée, en réalité, plus de problèmes qu’elle n’en résout.

La principale raison de cet échec est que les techniques d’obfuscation probabiliste ne sont efficaces que si elles sont appliquées à l’ensemble des transactions et à l’ensemble de leurs données. Pour une blockchain comme Ethereum, dont la privacy n’est aujourd’hui pas l’objectif principal, cela a peu de chances de véritablement fonctionner.

Strawmap

Dévoilée au mois de février 2026, la Strawmap est un document publié par l’Ethereum Foundation visant à exposer les 5 “North Stars” qui guideront l’évolution d’Ethereum d’ici à horizon 2029. Ce papier, qui n’est pas figé dans le temps et susceptible d’évoluer, place la privacy comme l’un de ces 5 piliers de développement.

Pour atteindre cet objectif, le procédé envisagé reposerait davantage sur un modèle similaire à Zcash qu’à celui de Monero. En pratique, les ETH pourraient être shieldés dans une pool dans laquelle les détails des transactions seraient dissimulés via l’usage de preuve cryptographiques.

Cependant, là où le modèle diffère de celui de Zcash, c’est qu’il aurait recours à des preuves STARKs (récursives) plutôt que SNARKs. Ces dernières, bien que plus lourdes à calculer, présentent l’avantage d’être théoriquement résistantes à l’informatique quantique, et c’est pourquoi elles constituent l’approche privilégiée par l’Ethereum Foundation.

Sur l’aspect privacy, cela constitue un facteur différenciant qui permettrait d’éviter d’avoir à développer de nouvelles pools dans les premières années du protocole.

Limites du modèle

• Les preuves STARKs étant plus lourdes que les preuves SNARKs, l’expérience utilisateur s’en retrouverait dégradée dans une certaine mesure. La Strawmap envisage néanmoins d’intégrer des precompiles (des bouts de codes standardisés) pour réduire le coût en gas et en puissance de calcul pour la vérification on-chain de ces preuves ;
• Le caractère opt-in risque de limiter l’adoption, et donc le nombre d’ETH déposés dans la pool, et par extension l’anonymity set ;
• Seuls les transferts d’ETH sont envisagés, sans support des stablecoins à ce stade ;
• Les entrées et sorties de pool restent traçables, tout comme sur Zcash.

Ce dernier point révèle un problème plus large : la privacy n’est pas une simple porte qu’il suffit de garder. C’est plutôt un long couloir tortueux : de la réception de fonds à leur envoi, il existe plusieurs intermédiaires (wallet, RPC, fournisseurs d’accès Internet, etc.) qui peuvent extraire des informations avant même que la blockchain ne prenne connaissance de la transaction.

---

Conclusion

Même si son implémentation reste encore à préciser, la Strawmap constitue aujourd’hui l’approche la plus solide pour introduire de la confidentialité sur Ethereum. À ce stade, une obfuscation généralisée comme sur le modèle de Monero apparaît difficilement compatible avec la diversité des usages du réseau.

Mais malgré cette cryptographie en théorie parfaite, le véritable défi sera de rendre ces transferts faciles à utiliser et peu coûteux au risque de voir une adoption minime qui limitera mécaniquement l’intérêt de la fonctionnalité. Cela nécessitera aussi le développement de technologies annexes pour assurer que la privacy soit suffisante, de l’émission d’une transaction à son inclusion dans un bloc.

Enfin, le durcissement des règles de compliance à la fois pour les utilisateurs particuliers sur les plateformes centralisées et pour les investisseurs institutionnels sera un frein de plus à considérer pour l’adoption de cette privacy sur Ethereum.