Combien de fois avez-vous lu qu’un protocole était privé sans jamais savoir de qui, exactement, il vous protégeait ? La question paraît naïve. Elle est pourtant devenue le cœur d’un chantier que L2BEAT vient d’ouvrir au grand public. Après avoir forcé les rollups Ethereum à documenter leurs clés d’urgence et leurs délais de sortie, la plateforme applique la même exigence aux outils de confidentialité. Plus de note unique. Plus de classement par volume. Une grille face à cinq profils d’adversaires, du passant qui lit un explorateur de blocs jusqu’à l’acteur capable de contraindre un opérateur ou d’attendre l’arrivée d’un ordinateur quantique.
Pourquoi L2BEAT Change La Manière De Parler De Privacy
Le réflexe du marché a longtemps été simple : plus un pool est gros, plus il serait discret. Cette intuition n’est pas absurde. Un ensemble d’anonymat large dilue mieux une sortie qu’un bassin quasi vide. Elle reste toutefois insuffisante. Un mixer peut brouiller le lien entre un dépôt et un retrait pour quiconque se contente de lire la chaîne, tout en livrant l’adresse IP de l’utilisateur au relais qui pousse la transaction. La confidentialité n’est pas un interrupteur. C’est une série de compromis, souvent invisibles tant qu’on ne les nomme pas.
L2BEAT s’est construite une réputation en refusant les classements faciles. Ses rosaces de risque et son échelle en trois paliers, du Stage 0 au Stage 2, ont poussé Arbitrum, Optimism et leurs rivaux à publier ce qu’ils préféraient parfois laisser dans le flou. Désormais, la même méthode s’étend à un domaine plus opaque : les solutions qui promettent de cacher un lien, un montant ou un destinataire. La plateforme ne décerne pas de médaille. Elle décrit ce qu’un utilisateur prudent peut encore cacher, et contre qui.
Chaque protocole dit qu’il est privé. La seule question utile est : privé vis-à-vis de qui ?
L2BEAT
Une méthode héritée des Stages des rollups
Sur les layer-2, L2BEAT n’a jamais vendu un score magique. Elle a décomposé les hypothèses de confiance : disponibilité des données, fenêtre de sortie, défaillance du séquenceur, validation d’état. Cette décomposition a eu un effet concret. Plusieurs équipes ont réduit leurs pouvoirs d’administration, publié des preuves de fraude et allongé les délais de mise à jour pour gagner un palier. Le tableau de bord est devenu un levier social autant qu’un outil d’analyse.
Le même levier est désormais tendu vers les protocoles de confidentialité. Les équipes sont invitées à contester leurs notations, à documenter leurs cérémonies de génération de paramètres, à préciser qui détient une clé de vue, qui peut censurer une liste de preuves d’innocence, qui opère le frontend. L’enjeu n’est pas cosmétique. Un utilisateur qui croit disparaître dans un pool alors qu’un opérateur voit encore ses métadonnées prend un risque qu’il n’a pas consenti à prendre.
Ce que la confidentialité onchain peut vraiment cacher
Sur une chaîne publique comme Ethereum, presque tout est visible par défaut. Un protocole de privacy ne peut, au mieux, que couper certains liens. L2BEAT distingue plusieurs promesses, qui ne se valent pas. La confidentialité du lien vise à masquer le rapport entre deux adresses publiques. La confidentialité des montants cache les valeurs et les soldes, pas forcément le graphe. La confidentialité du destinataire s’appuie souvent sur des adresses furtives. Un système peut exceller sur l’une et échouer sur l’autre.
Cette typologie évite une confusion fréquente. Un jeton confidentiel qui masque les soldes tout en laissant le graphe de transactions totalement public n’offre pas la même protection qu’un grand livre blindé. Un service d’adresses furtives protège surtout le receveur, pas nécessairement l’historique du payeur. Ranger ces objets dans une même vitrine, sans dire ce qu’ils promettent, revient à comparer une serrure, un rideau et un coffre-fort.
Ce que L2BEAT cherche à rendre lisible
- Quelle promesse le protocole formule réellement.
- Contre quel adversaire cette promesse tient encore.
- Où un utilisateur prudent peut encore limiter la fuite.
- Quelles hypothèses de confiance restent non négociables.
Les cinq adversaires, du plus banal au mieux armé
La grille ne distribue pas des bons points. Elle pose cinq regards. Le premier est l’observateur public : n’importe qui lit un explorateur, consulte un dépôt, un retrait, un horodatage. Beaucoup de mixeurs tiennent encore face à lui, à condition que l’ensemble d’anonymat ne soit pas ridicule. Le deuxième est l’analyste de chaîne. Il scrappe tout, applique des heuristiques de clustering, croise les timings, observe les montants ronds, les motifs de frais, les habitudes de regroupement.
Le troisième est l’observateur réseau. Ce n’est plus seulement la chaîne. C’est le nœud RPC, le relais, le frontend, parfois le fournisseur d’accès. Il voit passer des métadonnées que le contrat intelligent ne montre pas. Le quatrième est l’initié privilégié : équipe du protocole, gouvernance, opérateur d’une TEE, détenteur d’une clé de vue, participant d’un trusted setup qui n’aurait pas détruit le hasard toxique. Le cinquième est l’adversaire du futur, capable d’archiver aujourd’hui ce qu’un ordinateur quantique saura ouvrir demain, ou un État capable de contraindre un hébergeur.
Ces profils ne sont pas des caricatures. Ils correspondent à des capacités déjà observées. Des RPC ont un jour filtré des adresses associées à des sanctions. Des listes de preuves d’innocence peuvent refuser d’inclure un dépôt. Une cérémonie Groth16 mal conduite laisse une hypothèse de confiance permanente. Un front-end fermé peut journaliser ce que le circuit ZK, lui, ne révèle pas.
Pourquoi aucun protocole ne coche toutes les cases
Le constat de L2BEAT est net : aucun des systèmes suivis ne protège contre les cinq regards à la fois. Ce n’est pas un échec moral. C’est la nature du problème. Renforcer la résistance au réseau coûte de l’expérience utilisateur. Ouvrir une porte de conformité rassure un régulateur et affaiblit la protection contre l’initié. Ajouter une TEE améliore parfois le confort institutionnel et introduit une confiance matérielle difficile à auditer.
Selon les publications de la plateforme, seuls quelques protocoles historiques de type pool, notamment Tornado Cash et Railgun, apparaissent verts face à la plupart des adversaires qui existent aujourd’hui. Le point de rupture le plus fréquent n’est pas l’explorateur de blocs. C’est l’initié privilégié. Clés de mise à jour, listes de conformité, code d’enclave non publié, services de découverte de notes qui reçoivent une clé de vue : voilà où beaucoup de projets basculent au jaune ou au rouge.
Tornado Cash, Railgun et le poids de l’ensemble d’anonymat
Le tableau de bord privacy de L2BEAT ne se limite pas à des pastilles de couleur. Il affiche aussi des métriques que le marché a trop longtemps ignorées : nombre de dépôts, volume sur trente jours, taille effective de l’ensemble d’anonymat, reproductibilité du setup, délai de sortie. Tornado Cash reste, en valeur verrouillée, le géant des pools suivis, avec des centaines de millions de dollars et des centaines de milliers de dépôts historiques. Railgun se distingue par autre chose : un grand livre blindé capable de transferts internes et d’interactions DeFi, pas seulement d’un aller-retour dépôt-retrait.
Cette différence de design change le type de vie privée obtenue. Un pool à montants fixes facilite le mélange mais rigidifie l’usage. Un système à montants libres améliore l’utilité et complique parfois l’analyse, à condition que la foule soit réelle. L2BEAT insiste sur ce point : un TVL élevé avec quatre retraits en un mois offre une foule de papier. L’effective crowd, cette foule réellement plausible pour une action donnée, compte davantage qu’un stock dormant.
Railgun ajoute une tension propre. Le protocole peut s’appuyer sur des preuves d’innocence pour éviter qu’un bassin entier soit traité comme contaminé. Cette porte de sortie sociale a un prix. Le fournisseur de liste peut refuser d’inscrire un bouclier. L’utilisateur prudent doit alors savoir s’il peut encore sortir par ses propres moyens, et dans quel délai la gouvernance peut modifier les contrats. Sur Railgun, L2BEAT rappelle un délai de sept jours avant qu’une mise à jour ne prenne effet. Sept jours, ce n’est pas une éternité. C’est déjà plus qu’une clé d’admin instantanée.
Privacy Pools et la philosophie de l’association
Les systèmes bâtis sur des ensembles d’association, Privacy Pools en tête, assument un arbitrage différent. Ils ne prétendent pas que toute origine est indiscernable. Ils permettent, en principe, de prouver qu’un fonds n’appartient pas à un ensemble interdit, tout en restant mélangé dans un ensemble autorisé. Pour un utilisateur honnête qui veut interagir avec un échange prudent, cette propriété a une valeur. Pour un utilisateur qui veut une rupture totale d’historique, elle est une concession.
L2BEAT ne tranche pas le débat moral. Elle le rend lisible. Laisser une porte ouverte à la vérification d’origine, c’est accepter qu’un certain adversaire, ou une certaine contrepartie, puisse obtenir davantage d’information qu’avec un pool totalement opaque. C’est aussi refuser que l’ensemble du bassin soit collectivement suspect. Dans un climat où les prestataires européens se préparent à des règles plus strictes sur les comptes anonymes, cet arbitrage n’est plus théorique.
Zcash, le pool blindé et le détour par d’autres chaînes
Zcash occupe une place à part. Son pool blindé résiste souvent très bien à l’analyse onchain classique. La même architecture peut être plus vulnérable à une surveillance réseau ciblée, ou à un adversaire futur capable de récupérer une clé de vue à partir d’une courbe aujourd’hui considérée comme sûre. Lorsque L2BEAT décrit un trajet Ethereum vers ZEC blindé puis retour via des intents sur une autre chaîne, elle insiste sur un point souvent oublié : presque tout ce qui se passe hors du pool reste public. L’expéditeur Ethereum, l’actif, le montant, l’adresse de payout peuvent rester visibles. Le pool ne casse que le lien entre deux jambes spécifiques.
Cette précision évite un mythe tenace. Passer par une monnaie de confidentialité n’efface pas automatiquement le graphe de part et d’autre du pont. Si les deux extrémités sont transparentes, l’adversaire qui observe les deux chaînes et les horodatages dispose déjà d’une matière précieuse. La privacy n’est pas un tampon appliqué à un voyage. C’est la partie du voyage réellement occultée.
Adresses furtives, Fluidkey et la privacy du destinataire
Tous les projets suivis ne sont pas des pools. Umbra, Cloaked ou Fluidkey relèvent davantage de la confidentialité du destinataire. L’idée est ancienne et toujours utile : générer une adresse fraîche que seul le receveur peut dépenser, éventuellement via un compte Smart que l’on déploie au moment voulu. Fluidkey, ajouté récemment au tableau, conserve les clés de dépense côté client et s’appuie sur des Safe furtifs, tout en exposant un frontend fermé. L2BEAT note ce genre de détails parce qu’ils comptent. Un client de récupération publié n’efface pas le fait qu’une interface propriétaire peut observer des habitudes.
La privacy du destinataire répond à un besoin quotidien : recevoir un paiement sans publier une adresse réutilisée. Elle ne transforme pas pour autant un historique de dépense en secret. Un utilisateur qui mélange adresses furtives et réutilisation de fonds sur des places KYC reconstitue lui-même le puzzle. L2BEAT le répète dans ses guides de bonnes pratiques : la confidentialité onchain n’est pas un réglage passif. C’est une hygiène.
Montants confidentiels, FHE et le cas Zama
Une autre famille de protocoles cache les montants plutôt que le graphe. Les jetons confidentiels fondés sur le chiffrement entièrement homomorphe illustrent ce choix. On peut interagir, parfois composer avec de la DeFi, tout en laissant visibles les contreparties. Pour un trésorier d’entreprise, masquer un solde a du sens. Pour quelqu’un qui veut disparaître d’un graphe d’analyse, c’est une autre promesse, plus étroite.
L2BEAT classe ces objets à part, et c’est heureux. Confondre un jeton à montants chiffrés avec un pool qui rompt le lien entre deux adresses, c’est garantir les malentendus. Le marché aime les récits unifiés. La cryptographie, elle, produit des propriétés distinctes. Un tableau honnête doit les séparer, quitte à frustrer ceux qui voulaient une note unique sur dix.
TEE, Privacy Boost et la tentation du confort institutionnel
Certains protocoles récents misent sur un environnement d’exécution de confiance. Privacy Boost, pool blindé de jetons sur OP Mainnet pensé pour un usage plus institutionnel, illustre le compromis. Les transferts privés peuvent être traités hors chaîne dans une enclave. Des preuves ZK garantissent ensuite la validité onchain. L’utilisateur gagne parfois en fluidité. Il perd en hypothèses pures : il doit faire confiance au matériel, et parfois à un code d’enclave qui n’est pas publié.
L2BEAT souligne aussi l’existence possible d’interfaces d’audit. Un mécanisme qui permet à un auditeur autorisé de lever rétroactivement le voile, même si les requêtes sont journalisées, change le profil d’adversaire. Ce n’est plus seulement un observateur passif. C’est un initié dont le pouvoir a été conçu dès le départ. Pour un fonds régulé, cette porte peut être une condition d’existence. Pour un utilisateur qui voulait une privacy inconditionnelle, c’est un interrupteur qu’il ne contrôle pas.
La privacy cryptographique n’empêche pas qu’un interrupteur existe. La question est de savoir qui peut l’actionner.
Débat en cours dans l’écosystème Aztec
Aztec, Kohaku et le rêve d’une privacy native sur Ethereum
Le calendrier n’est pas anodin. Vitalik Buterin a réaffirmé, dans la feuille de route d’Ethereum vers 2029, la volonté d’une confidentialité plus native. Aztec a ouvert un testnet public après de longues années de travail sur les preuves à divulgation nulle de connaissance, puis progressé vers un mainnet encore limité. L’argument du projet est précis : l’état privé reste chiffré pour l’utilisateur, les preuves sont produites côté client, et l’interrupteur de divulgation sélective reste dans sa main plutôt que dans celle d’un opérateur.
Kohaku, côté portefeuille et boîte à outils, s’inscrit dans la même poussée culturelle : rendre la privacy utilisable sans exiger que chacun devienne un chercheur en circuits. Cette montée en maturité explique pourquoi un tableau comme celui de L2BEAT arrive maintenant. Tant que les outils étaient rares, ésotériques ou juridiquement toxiques, comparer leurs garanties relevait du cercle restreint. Dès qu’Aztec, Railgun, Privacy Pools et une série de projets plus jeunes se disputent les mêmes utilisateurs, le besoin d’un langage commun devient politique autant que technique.
Le trusted setup, cette cérémonie que personne n’aime expliquer
Plusieurs pools majeurs s’appuient encore sur des zk-SNARK de type Groth16. Ces systèmes exigent une cérémonie unique pour générer les paramètres de preuve. Cette cérémonie produit un hasard que l’on appelle parfois déchet toxique. S’il n’est pas détruit, un acteur malveillant pourrait théoriquement forger des preuves. L2BEAT documente le nombre de participants, le caractère reproductible ou non du setup, et traite cette hypothèse comme ce qu’elle est : une confiance initiale, pas un détail de documentation.
Le public a tendance à surinterpréter ces cérémonies dans les deux sens. Certains les voient comme une preuve de sérieux. D’autres comme une tache originelle indélébile. La lecture utile est plus sèche. Plus la cérémonie est large, ouverte et bien documentée, plus le risque de collusion baisse. Elle ne disparaît jamais tout à fait. Les systèmes qui s’affranchissent de ce rituel, ou qui le rendent universellement vérifiable, changent donc de catégorie de confiance. C’est exactement le type de distinction qu’un classement par TVL est incapable de faire.
Découverte des notes : la fuite que le circuit ne voit pas
Un apport discret mais décisif de L2BEAT concerne la découverte des notes. Dans la plupart des protocoles, on ne possède pas un solde au sens bancaire. On possède des engagements dans un arbre de Merkle. Encore faut-il retrouver les siens. Si l’interface exige une seed et scanne tous les événements, si un service tiers reçoit une clé de vue, si les requêtes RPC révèlent quelles notes vous intéressent, la preuve ZK la plus élégante ne sauve plus grand-chose.
Tornado Cash, dans son modèle classique, laisse l’utilisateur conserver localement la note créée au dépôt. Railgun peut synchroniser un portefeuille par balayage sans que le RPC apprenne, à lui seul, quelles notes vous appartiennent. D’autres architectures livrent davantage au prestataire de découverte. L2BEAT a raison d’en faire une section dédiée. C’est souvent là que la privacy meurt en silence, loin des livres blancs.
Hygiène minimale rappelée par L2BEAT
- Séparer strictement les portefeuilles de dépôt et de retrait.
- Laisser du temps au bassin pour grandir entre deux actions.
- Éviter de réutiliser la même connexion réseau et le même navigateur.
- Préférer une pile logicielle ouverte et un RPC choisi, pas subi.
- Utiliser un relais pour ne pas payer le gaz depuis l’adresse qui se dévoile.
Le réseau, ce point faible que le contrat ne corrige pas
Un séquenceur de layer-2, un relais, un frontend hébergé, un fournisseur RPC : tous peuvent corréler une adresse et une IP. Cette corrélation ressemble, dans sa logique, à ce qu’une plateforme centralisée fait déjà. La différence est rhétorique. L’utilisateur d’un pool croit souvent avoir quitté ce monde. Il n’a parfois fait que déplacer le journal.
Les précédents existent. Après certaines sanctions, des infrastructures ont filtré des requêtes. Un observateur réseau n’a pas besoin de casser un circuit. Il lui suffit d’être sur le chemin. D’où l’insistance de L2BEAT sur Tor, les VPN de confiance, et l’interdiction pratique de consulter un portefeuille isolé depuis la même session que son identité principale. Ces conseils paraissent triviaux. Ils expliquent pourtant une grande partie des deanonymisations réelles, bien plus que les attaques de cryptographes de salon.
Pression juridique : la privacy n’est plus une coquetterie
Le contexte réglementaire donne à cette grille une actualité brutale. En Europe, le cadre anti-blanchiment doit interdire aux prestataires de services sur actifs numériques de tenir des comptes anonymes et de traiter certaines cryptomonnaies de confidentialité à compter de juillet 2027. Aux États-Unis, le retrait de Tornado Cash de la liste de l’OFAC au printemps 2025 n’a pas dissipé toute menace pénale autour des auteurs de code, comme l’a rappelé le dossier visant Roman Storm.
Dans ce climat, savoir précisément contre quel adversaire un protocole protège cesse d’être un caprice de chercheur. Un utilisateur peut vouloir se cacher d’un analyste commercial sans chercher à échapper à un juge. Une entreprise peut vouloir masquer un solde à ses concurrents tout en acceptant un audit. Un militant peut juger insuffisant tout système qui laisse une clé de vue à une gouvernance. Ces besoins ne sont pas interchangeables. Un label unique les écrase.
Le marché a déjà voté, de manière imparfaite
Les flux récents vers le pool blindé de Zcash, les à-coups de cours du ZEC, la croissance relative d’un secteur privacy parfois décorrélé de Bitcoin, tout cela dit une demande. Elle ne dit pas que les utilisateurs ont choisi le bon outil. Elle dit qu’ils cherchent un abri, souvent après avoir constaté que la pseudonymie d’Ethereum ne protège plus grand-chose face aux heuristiques modernes.
L2BEAT arrive donc au bon moment, et avec le bon défaut. Son tableau est incomplet, contestable, dépendant des informations que les équipes acceptent de livrer. C’est précisément pour cela qu’il peut fonctionner. Comme pour les rollups, la lumière vaut plus que la perfection. Une équipe qui conteste une pastille rouge sur Discord est déjà une équipe contrainte de parler clair.
Ce que cette grille change pour l’utilisateur de tous les jours
Le premier bénéfice est pédagogique. On arrête de demander si un protocole est sûr comme on demanderait si une voiture est rapide. On demande pour quel trajet, contre quel vent, avec quelle charge. Le second bénéfice est comparatif. Un nouvel arrivant peut voir qu’un TVL plus faible n’est pas forcément une privacy plus faible, et qu’un design institutionnel n’est pas forcément une privacy plus forte.
Le troisième bénéfice est politique, au sens large. En rendant visibles les pouvoirs d’administration, les listes de conformité et les trusted setups, L2BEAT empêche les équipes de vendre une mystique. La privacy redevient un ensemble de propriétés vérifiables, donc critiquables. C’est inconfortable pour le marketing. C’est sain pour l’écosystème.
Limites du tableau et pièges d’interprétation
Une pastille verte n’absout pas l’utilisateur imprudent. Une pastille rouge n’interdit pas un usage ciblé. Un protocole peut être excellent contre l’observateur public et médiocre contre le réseau. Un autre peut être honnête sur ses limites institutionnelles et donc plus prévisible. Le danger serait de transformer la grille en classements de cours de récréation.
Autre limite : la foule réelle change tous les jours. Un bassin profond aujourd’hui peut s’assécher demain. Une heuristique nouvelle peut relier des motifs que le circuit ne considère pas. Un adversaire étatique n’a pas besoin de casser une preuve s’il peut assigner l’hébergeur du frontend. L2BEAT le sait et accompagne souvent chaque notation d’un conseil d’usage. Ces conseils valent autant que la couleur.
Vers une privacy lisible, donc responsable
La grande leçon de cette nouvelle section n’est pas que la confidentialité crypto a échoué. C’est qu’elle est devenue assez mature pour supporter une critique fine. Les rollups ont appris à vivre sous le regard des Stages. Les protocoles de privacy vont apprendre à vivre sous le regard des adversaires. Certains rogneront leurs pouvoirs. D’autres assumeront clairement qu’ils vendent un compromis de conformité. Les utilisateurs, enfin, pourront choisir autre chose qu’un slogan.
Il restera des angles morts. L’ordinateur quantique n’est pas encore là, mais les archives, elles, s’écrivent maintenant. Les États n’ont pas besoin d’attendre une rupture cryptographique pour corréler du trafic. Les équipes n’ont pas besoin d’être malveillantes pour détenir trop de pouvoir. En nommant ces cinq regards, L2BEAT n’a pas refermé le débat. Elle l’a rendu enfin praticable. Et dans un écosystème qui confond trop souvent le mot privé avec le mot magique, c’est déjà un progrès rare.
Ce qu’il faudra surveiller ensuite
Trois signaux mériteront l’attention dans les mois qui viennent. Premier signal : la manière dont les équipes réagissent. Si elles publient leurs hypothèses, ouvrent leurs frontends, réduisent leurs clés, la grille aura joué son rôle disciplinaire. Deuxième signal : l’évolution des foules. Un outil excellent dans le vide cryptographique ne protège personne. Troisième signal : le droit. Les règles européennes de 2027 et la jurisprudence américaine décideront quels designs restent utilisables par le grand public, et lesquels basculent vers des niches.
En attendant, la discipline la plus utile n’est pas de mémoriser onze noms de protocoles. C’est d’adopter le réflexe L2BEAT : refuser le label, exiger l’adversaire, lire la limite écrite en bas de page. La chaîne publique n’oubliera pas vos erreurs d’hygiène. Les tableaux, au moins, peuvent empêcher celles qui naissent d’une brochure trop confiante.

