Le moment HTTPS de la confidentialité d’Ethereum : passer d’un outil défensif à une infrastructure par défaut

Cette édition de l'événement Ethereum Privacy Stack est organisée conjointement par l'équipe Privacy & Scaling Explorations (PSE), Web3Privacy Now et des membres clés de la Ethereum Foundation (EF). Il s'agit de l'un des événements verticaux les plus prestigieux de Devconnect ARG 2025. L'événement réunit Vitalik Buterin, le fondateur de Tor, des chercheurs principaux de l'EF, des fondateurs de protocoles de confidentialité (Railgun, 0xbow, Aztec, etc.) ainsi que des experts juridiques de premier plan. Son objectif principal est de redéfinir la cartographie de l'écosystème de la confidentialité sur Ethereum à un moment charnière où la pression réglementaire s'accroît et où la technologie arrive à maturité, de combler les îlots technologiques et de définir la feuille de route de la confidentialité pour les 3 à 5 prochaines années.

Organisé lors de Devconnect Buenos Aires 2025, Ethereum Privacy Stack est le rassemblement le plus important de l'année sur la confidentialité dans l'écosystème Ethereum.

Le consensus le plus marquant de cet événement est l'établissement du concept de « confidentialité holistique » : la confidentialité ne se limite plus à l'empilement d'outils on-chain tels que les preuves à connaissance nulle (ZK) ou les mixers, mais constitue une boucle complète qui traverse la couche de transmission réseau (Tor), la couche de lecture RPC, la couche de stockage des données jusqu'au front-end d'interaction utilisateur.

Comme l'ont souligné Vitalik Buterin et Roger Dingledine, fondateur du projet Tor, si le réseau sous-jacent divulgue l'IP, l'anonymat de la couche applicative n'a plus aucun sens. La communauté est désormais d'accord sur le fait qu'Ethereum doit suivre la « théorie du tonneau » et réparer le maillon le plus faible de la fuite de métadonnées afin de devenir un véritable « grand livre mondial » résistant à la censure.

Analyse des tendances : vers la « confidentialité par défaut » et la bataille de l'expérience utilisateur

Les participants estiment généralement que la confidentialité dans le Web3 traverse un moment clé similaire à la transition du Web2 de HTTP vers HTTPS. La technologie de confidentialité ne devrait plus être le privilège des « geeks » ou des « hackers », ni porter le fardeau moral de « cacher des crimes ». À travers la comparaison de Railgun, du portefeuille Kohaku et de l'expérience historique du Web2, les intervenants soulignent que l'étape suivante consiste à « stigmatiser les comportements non confidentiels », c'est-à-dire faire en sorte que les transferts publics et transparents soient perçus comme un comportement anormal, comparable à courir nu sur Internet.

D'ici 2026, l'objectif de la communauté Ethereum est de réduire le coût des transferts confidentiels à un niveau acceptable (par exemple, seulement deux fois celui d'un transfert ordinaire) et d'offrir une expérience sans friction en un clic, afin de servir non seulement les particuliers, mais aussi d'ouvrir la porte aux institutions financières traditionnelles qui ne peuvent pas entrer faute de protection des secrets commerciaux.

Controverse centrale : le spectre de la conformité et le risque de « guerre civile » au niveau L1

Bien que la feuille de route technologique devienne plus claire, la tension idéologique demeure. Le principal point de discorde est la lutte entre « confidentialité conforme » et « confidentialité sans permission ». D'un côté, Privacy Pools prône la séparation proactive des fonds illicites via des « preuves de dissociation » pour obtenir la tolérance des régulateurs et l'adoption institutionnelle ; de l'autre, certains défendent l'esprit cypherpunk pur, estimant que toute concession à la conformité mènera inévitablement à la censure.

De plus, Andy Guzman de PSE a averti d'une possible « guerre civile » imminente : la question de savoir si les fonctionnalités de confidentialité doivent être intégrées au cœur du protocole Ethereum (L1). L'intégration à L1 apporterait une liquidité unifiée et une protection par défaut, mais pourrait aussi entraîner d'énormes risques réglementaires et une complexité accrue du protocole. Ce choix déterminera la nature politique future d'Ethereum.

L'éveil de l'infrastructure : le matériel comme dernier rempart contre la censure

Au-delà des discussions logicielles, l'événement a exceptionnellement approfondi les couches physiques et réseau. De « faire tourner son propre nœud » à la « décentralisation des environnements d'exécution de confiance (TEE) », la communauté a pris conscience que si le matériel est truffé de portes dérobées, tout chiffrement logiciel devient inutile. La résistance à la censure est redéfinie comme une infrastructure publique semblable à une « issue de secours » : elle semble inutile en temps de paix, mais devient vitale en temps de crise. Qu'il s'agisse de construire des VPN décentralisés (comme Nym, HOPR) ou d'utiliser ZK-TLS pour une « interopérabilité de guérilla », l'objectif est de bâtir un système robuste même en cas de conflits géopolitiques extrêmes.

Auto-sauvetage juridique et culturel

Face au sort des développeurs de Tornado Cash, l'événement a été imprégné d'un sentiment d'urgence de « sauvetage ». Juristes et développeurs appellent unanimement à la création de fonds de défense juridique puissants et de groupes de lobbying politique. Tous ont compris que protéger la confidentialité ne se limite pas à écrire du code, mais relève d'une bataille pour le contrôle du récit : il faut transformer l'image du développeur de « complice potentiel de terroristes » en « défenseur de la liberté à l'ère numérique ». Si l'industrie ne s'unit pas pour protéger les contributeurs open source, le progrès technologique s'arrêtera faute de volontaires pour coder.

Voici un résumé détaillé des 16 conférences et panels de l'événement.

1. Onionizing Ethereum (L'oignonisation d'Ethereum)

Intervenants : Vitalik Buterin (Ethereum Foundation), Roger Dingledine (Tor Project)

Ce dialogue marque un tournant conceptuel majeur dans la vision de la confidentialité sur Ethereum. Vitalik a indiqué que la Ethereum Foundation promeut un plan visant à intégrer profondément Tor et les Onion Services dans toute la stack technique d'Ethereum. Cela représente un changement de paradigme : passer d'une focalisation sur la confidentialité des transactions (comme les preuves ZK) à une vision plus globale de la « confidentialité holistique ». Cette vision englobe la confidentialité à l'écriture (envoi de transactions) et à la lecture (lecture de données RPC), afin d'empêcher la fuite d'adresse IP et de schémas d'accès lors de la diffusion de transactions ou de la consultation de données on-chain.

Roger Dingledine a partagé l'état du réseau Tor en tant qu'infrastructure sous-jacente de Bitcoin, notant qu'environ trois quarts des nœuds Bitcoin se connectent via des adresses onion. Il a souligné que l'anonymat applicatif ne suffit pas : si la couche de transport réseau divulgue l'adresse IP, la protection de la confidentialité applicative devient illusoire. L'objectif d'Ethereum est donc d'introduire non seulement la confidentialité au niveau des smart contracts, mais aussi d'intégrer mixnets et onion routing dans la couche réseau P2P, afin de défendre contre les attaques DoS ciblant les validateurs (Proposer) et d'améliorer la résistance à la censure.

Vitalik a ensuite expliqué les deux sens du terme « censure » : la censure des transactions au niveau applicatif et la censure de l'accès au niveau réseau. Il a insisté sur le fait qu'Ethereum vise à être un registre accessible mondialement, permettant aux utilisateurs et validateurs de se connecter via les transports modulaires de Tor (comme Snowflake) même en cas de blocage par des firewalls nationaux. Cette technologie permet de déguiser le trafic en flux vidéo WebRTC ordinaire, contournant ainsi la censure. Il ne s'agit pas seulement de confidentialité, mais aussi de la résilience et de la décentralisation géographique d'Ethereum en tant que « grand livre mondial ».

Pour l'avenir, les deux intervenants ont discuté de la possibilité pour les validateurs Ethereum (Stakers) de faire tourner simultanément des relais Tor. Comme le trafic destiné à des Onion Services spécifiques n'a pas besoin de relais de sortie, les validateurs peuvent facilement opérer des relais non-sortie, ne fournissant que de la bande passante sans risque juridique. Si cette initiative aboutit, elle renforcera considérablement la résistance à la censure et la confidentialité d'Ethereum dans les prochaines années, tout en améliorant l'expérience utilisateur et la résilience du réseau.

2. Ethereum is for DefiPunk (Ethereum appartient à DefiPunk)

Intervenante : Hsiao-Wei Wang (Ethereum Foundation)

Le cœur de la présentation de Hsiao-Wei portait sur la nouvelle politique financière de la Ethereum Foundation (EF) et introduisait le concept de « DefiPunk », visant à réinjecter l'esprit cypherpunk dans l'écosystème DeFi. Elle a souligné que la DeFi ne doit pas se limiter à la recherche du rendement, mais doit aussi incarner la résistance à la censure, l'open source et la protection de la confidentialité. L'EF décide de l'allocation de ses fonds non seulement en fonction du retour financier, mais aussi pour refléter les valeurs fondamentales d'Ethereum, en soutenant les projets qui favorisent la santé à long terme du réseau, plutôt que ceux qui poursuivent uniquement des APY élevés ou des raccourcis centralisés.

Pour guider cette stratégie, elle a détaillé les six attributs clés de DefiPunk : sécurité, open source, autosuffisance financière, minimisation de la confiance, support des outils cryptographiques et confidentialité. En particulier, pour l'open source, l'EF privilégie les projets sous licence FLOSS afin d'encourager une véritable transparence et collaboration, plutôt que la protection commerciale du code source.

En termes de critères, DefiPunk insiste sur le fait que les protocoles doivent être sans permission (Permissionless Access), accessibles à tous les utilisateurs, et garantir la souveraineté des utilisateurs sur leurs actifs, sans dépendance à une garde tierce. Elle a aussi souligné que la confidentialité ne doit pas être un luxe dans la DeFi, mais un droit fondamental. L'EF encourage les projets à utiliser des front-ends distribués, des interfaces indépendantes ou même des outils en ligne de commande pour éviter les risques de censure liés aux front-ends centralisés.

Enfin, Hsiao-Wei a appelé la communauté et les développeurs à incarner ces valeurs. Le rôle de l'EF n'est pas seulement de fournir des fonds, mais aussi de soutenir cette philosophie. Elle encourage les utilisateurs à penser comme de véritables « DefiPunks » lors du choix d'un protocole DeFi : examiner le code, vérifier la transparence de la gouvernance, s'assurer de l'immuabilité des smart contracts. Ce discours remet en question l'état actuel de la DeFi et appelle à un retour aux origines de la finance décentralisée : offrir des services financiers non censurables aux opprimés et aux non-bancarisés.

3. Privacy-Aware Mechanisms for Public Goods Funding (Mécanismes de financement des biens publics sensibles à la confidentialité)

Participants : Camila Rioja (Plexos), Thomas Humphreys (EF), Tanisha Katara, Beth McCarthy, José Ignacio Trajtenberg

Cette table ronde s'est concentrée sur l'équilibre entre transparence et confidentialité dans le financement des biens publics. Les intervenants ont d'abord partagé des cas d'application réels, tels que le projet d'aide humanitaire Xcapit avec l'UNICEF et l'utilisation de la blockchain pour gérer la monnaie communautaire au Brésil. Dans ces contextes d'aide humanitaire et de populations vulnérables, la confidentialité est cruciale pour la sécurité des bénéficiaires, au-delà de la simple protection des données.

Le cœur de la discussion portait sur le compromis entre « transparence » et « confidentialité ». Pour les résultats du financement, la transparence est nécessaire pour garantir que les fonds sont correctement alloués et ont un impact ; mais au niveau de la participation, notamment lors du vote et de la vérification d'identité, la confidentialité est essentielle. Si le vote est totalement public, cela crée des marchés de corruption et une pression sociale, faussant les résultats de la gouvernance. L'introduction de primitives ZK permet de vérifier l'éligibilité et les résultats du vote sans révéler les bulletins, assurant ainsi une gouvernance résistante à la collusion.

Les intervenants ont également discuté de l'adaptation des outils techniques aux exigences des différentes juridictions. Par exemple, dans certains pays, la collecte de certaines données est légale, mais dans d'autres (comme l'Allemagne), cela peut violer le RGPD. Par conséquent, les outils mondiaux de financement des biens publics ne doivent pas chercher à satisfaire toutes les exigences de conformité, mais plutôt construire une infrastructure flexible et privacy-first, adaptable par les communautés locales selon leurs besoins.

Enfin, la discussion a porté sur les orientations technologiques futures, notamment les marchés prédictifs confidentiels et les mécanismes de financement des biens publics auto-soutenables. Les intervenants s'accordent à dire que la technologie doit résoudre non seulement les problèmes d'efficacité, mais aussi revenir à une conception centrée sur l'humain. Grâce aux preuves d'identité ZK et aux outils de vote confidentiel, il est possible de protéger les données des utilisateurs tout en prévenant les attaques Sybil, établissant ainsi une gouvernance communautaire plus juste et plus sûre.

4. Who pays for privacy? The real cost of building aligned apps (Qui paie pour la confidentialité ? Le vrai coût de la construction d'applications alignées)

Intervenant : Lefteris Karapetsas (Rotki)

Lefteris a commencé par une remarque incisive sur l'état de l'industrie : « Si le produit est gratuit, c'est que vous êtes le produit. »

Il explique que les applications Internet actuelles offrent des services gratuits en échange d'une « taxe sur les données », c'est-à-dire la collecte et la vente des données des utilisateurs. Pour rompre ce modèle, il propose le concept d'« applications alignées », qui servent réellement les intérêts des utilisateurs, respectent la souveraineté des données, privilégient le local et n'utilisent pas de trackers. Cependant, construire de telles applications implique d'énormes défis d'ingénierie et des coûts élevés.

En prenant l'exemple de Rotki (un outil de suivi de portefeuille axé sur le local), il détaille les coûts cachés du développement d'applications de confidentialité. Contrairement aux produits SaaS, les applications locales ne peuvent pas facilement effectuer des tests A/B ou collecter des logs d'erreurs ; les développeurs doivent packager des binaires pour plusieurs OS, gérer les migrations de bases de données locales et payer des certificats de signature de code coûteux. Cela réduit l'efficacité du développement et empêche la monétisation des données utilisateurs, rendant le modèle économique plus difficile.

Lefteris déconseille fortement aux développeurs de compter sur les dons ou les subventions, car c'est une impasse. Il affirme que les applications de confidentialité doivent avoir un modèle économique clair et facturer directement les utilisateurs. Non seulement pour soutenir le développement, mais aussi pour éduquer les utilisateurs : la confidentialité a un coût explicite. Grâce au modèle Freemium, au support entreprise ou à des fonctionnalités payantes (comme l'analyse avancée des données), les développeurs peuvent obtenir des revenus récurrents prévisibles.

En conclusion, il appelle à un nouveau contrat entre utilisateurs et développeurs. Les utilisateurs doivent comprendre que payer, c'est soutenir non seulement les fonctionnalités actuelles, mais aussi un futur sans surveillance ni abus. Il encourage les développeurs à fixer des prix avec confiance, à ne pas sous-évaluer leur travail et à maintenir la transparence financière pour gagner la confiance de la communauté. Construire des « applications alignées » est en soi un acte punk, une rébellion contre le monopole du cloud et la surveillance des données.

5. Ethereum Privacy Ecosystem mapping (Cartographie de l'écosystème de la confidentialité sur Ethereum)

Participants : Mykola Siusko, Antonio Seveso, cyp, Alavi, Kassandra.eth

Ce panel visait à clarifier l'écosystème complexe et fragmenté de la confidentialité sur Ethereum. Les intervenants s'accordent à dire que l'essentiel n'est pas de lister tous les protocoles de confidentialité, mais de comprendre leurs relations. L'écosystème actuel se divise en plusieurs domaines verticaux : confidentialité on-chain (adresses furtives, pools de confidentialité), confidentialité au niveau réseau (mixnets), et surtout la couche de connexion la plus critique : l'expérience utilisateur (UX). L'UX est vue comme le pont reliant ces composants techniques dispersés, déterminant l'adoption massive des technologies de confidentialité.

La discussion a abordé la relation subtile entre « conformité » et « confidentialité ». Les intervenants ont remis en question la construction d'outils de confidentialité uniquement pour se défendre contre la régulation. Selon eux, la confidentialité ne doit pas être définie uniquement comme une technologie défensive (contre la surveillance), mais comme un effort communautaire collaboratif, un outil permettant de nouvelles capacités pour les utilisateurs et la communauté. Trop insister sur le récit « défensif » peut limiter l'imagination des produits.

Concernant la régulation et la conformité, les intervenants ont exprimé une opinion forte : il est irréaliste, voire naïf, de vouloir construire un produit mondial conforme à toutes les juridictions. Plutôt que d'intégrer la conformité au niveau du protocole (ce qui implique souvent des portes dérobées), il vaut mieux construire une infrastructure de confidentialité générique et donner aux utilisateurs le droit de divulguer sélectivement des informations au niveau applicatif (View Keys). Cela protège les utilisateurs d'une surveillance totale tout en permettant de prouver la conformité si nécessaire.

Enfin, les intervenants ont souligné l'importance de briser l'« écho technologique » et ont appelé à des liens plus étroits avec les organisations de confidentialité hors crypto (Tor, EFF, Signal). La future cartographie de l'écosystème ne doit pas se limiter à l'empilement technique, mais inclure l'aide juridique, les hackathons, l'éducation et le plaidoyer. Normaliser, socialiser et même rendre la confidentialité amusante est la clé du développement futur de l'écosystème.

6. Ethereum Institutional Privacy now (La confidentialité institutionnelle sur Ethereum aujourd'hui)

Participants : Oskar Thorin, Zach Obront, Amzah Moelah, Eugenio Reggianini, Francois

Oskar Thorin a d'abord présenté le groupe de travail sur la confidentialité institutionnelle de l'EF (IPTF) et sa mission : aider les institutions financières traditionnelles à migrer vers Ethereum tout en répondant à leurs besoins de confidentialité. La tendance actuelle est que les institutions ne refusent plus la blockchain à cause de la régulation, mais parce qu'elles manquent de confidentialité. Même si seulement 1 % des fonds financiers traditionnels entraient sur Ethereum, l'impact sur l'écosystème de la confidentialité serait immense.

Lors du panel, des représentants d'ABN Amro (banque néerlandaise) et d'Etherealize ont partagé les véritables difficultés des institutions. Elles ne refusent pas la liquidité mondiale des blockchains publiques, mais ne peuvent accepter que leurs stratégies de trading, positions ou données clients soient totalement publiques. Contrairement aux particuliers, les institutions ont besoin non seulement de confidentialité, mais aussi de « contrôle » : savoir précisément qui peut voir quelles données et quand. Ce contrôle doit être adapté à chaque flux métier, comme l'émission d'obligations, le règlement de prêts ou les transactions de marché secondaire, chaque cas ayant des exigences de transparence différentes.

Francois de Polygon Miden a présenté leur solution basée sur un modèle hybride compte + UTXO : les utilisateurs maintiennent un état privé localement et ne prouvent la validité des transactions au réseau public que lorsque c'est nécessaire. La discussion a également abordé l'utilisation des preuves ZK pour les rapports de conformité, permettant de prouver la solvabilité ou la conformité d'une institution sans révéler les données sous-jacentes.

Les intervenants s'accordent à dire que l'avenir n'est pas dans la création de blockchains privées isolées, mais dans la construction d'une couche de confidentialité sur la blockchain publique Ethereum. En dissociant l'authentification (KYC/KYB), l'exécution des stratégies et les rapports de conformité, les institutions peuvent bénéficier de la sécurité et de la liquidité d'Ethereum tout en protégeant leurs secrets commerciaux. La maturité de cette architecture sera le point de bascule pour l'adoption institutionnelle massive d'Ethereum vers 2026.

7. Privacy Without Terrorists (La confidentialité sans terroristes)

Intervenant : Ameen Suleimani (0xbow)

Ameen a ouvert son intervention par une fable sur la pollution d'un lac en Patagonie, métaphore vivante du dilemme de Tornado Cash : lorsque quelques personnes (terroristes/hackers) polluent une ressource publique (le pool de confidentialité), tout le monde (utilisateurs ordinaires) est puni. Il a retracé l'histoire de Tornado Cash, soulignant que les développeurs ne devraient pas être tenus responsables des actes illégaux des utilisateurs, mais a aussi posé une question aiguë : en utilisant un mixer, les utilisateurs ordinaires offrent en réalité une couverture aux hackers. La communauté doit donc construire un système protégeant la confidentialité des utilisateurs légitimes sans favoriser les criminels.

C'est le cœur du concept de Privacy Pools. Contrairement à Tornado Cash, Privacy Pools permet aux utilisateurs, via des preuves ZK, de se « dissocier » publiquement des fonds illicites (par exemple, ceux des hackers nord-coréens). Lors du retrait, l'utilisateur peut prouver que ses fonds proviennent d'un ensemble de dépôts légitimes, sans révéler la source exacte. Cela satisfait aux exigences anti-blanchiment tout en préservant la confidentialité on-chain.

Ameen a détaillé le mécanisme de gestion de 0xbow. Le système introduit des contrôles KYT (Know Your Transaction) : les dépôts doivent être approuvés. Si 0xbow détecte une origine illicite, le dépôt est retiré de l'ensemble conforme, mais les fonds ne peuvent pas être gelés. Il a particulièrement insisté sur le mécanisme « Rage Quit » : même si un dépôt est ultérieurement jugé non conforme ou si 0xbow cesse d'opérer, le smart contract garantit que l'utilisateur peut toujours récupérer son capital. Cela réalise un modèle de confidentialité « non-custodial mais avec permission ».

Enfin, Ameen a présenté la feuille de route de Privacy Pools V2, prévue pour EthCC (Paris). V2 prendra en charge les transferts d'adresses furtives (Shielded Transfers), permettant des paiements P2P au sein du pool, sans devoir retirer vers une nouvelle adresse comme en V1. V2 échange une partie de la fongibilité contre la récupérabilité, visant à construire une infrastructure de confidentialité pour les « bons utilisateurs » et à éviter que les développeurs ne soient emprisonnés pour avoir écrit du code.

8. Is censorship resilience truly necessary? (La résistance à la censure est-elle vraiment nécessaire ?)

Intervenant : Mashbean (Matters.lab)

Mashbean a posé une question dérangeante : si la résistance à la censure est si importante, pourquoi les produits qui en font leur cœur peinent-ils à survivre ? S'appuyant sur cinq ans d'expérience avec Matters.news (plateforme de publication décentralisée), il a révélé le décalage entre « besoin de marché » et « besoin de survie ». Les groupes marginaux (dissidents, journalistes) ont un besoin moral fort de résistance à la censure, mais ce marché est petit et peu solvable. La plupart des utilisateurs ordinaires ne se soucient que de la qualité du contenu, pas de la résistance à la censure de la plateforme.

Il a exploré en profondeur le « paradoxe du pot de miel (Honeypot Paradox) » : une plateforme résistante à la censure attire naturellement les contenus les plus sensibles, concentrant ainsi les risques. Cela attire non seulement la censure des gouvernements autoritaires, mais aussi une avalanche de spams et d'escroqueries. Ironiquement, pour lutter contre le spam, la plateforme doit introduire une forme de modération, ce qui crée une tension avec l'objectif initial de résistance à la censure. Parfois, les attaques de spam ont même déclenché des systèmes anti-fraude automatiques dans des pays démocratiques, entraînant le blocage de la plateforme et créant une nouvelle forme de « censure conjointe transfrontalière ».

Face à ces difficultés, Mashbean propose des solutions contre-intuitives. D'abord, ne pas construire une grande plateforme unique, mais des modules (stockage, identité, paiement) réutilisables par de petites communautés, évitant ainsi de devenir une cible évidente. Ensuite, il faut « manger sa propre nourriture pour chien » (Eat your own dogfood), c'est-à-dire que les développeurs doivent eux-mêmes adopter une OpSec et des paiements privés robustes, car ils sont aussi des cibles à haut risque.

En conclusion, la technologie de résistance à la censure ne doit pas être vue comme un produit commercial ordinaire, mais comme une infrastructure publique, telle qu'une « issue de secours » ou une « ceinture de sécurité ». On ne se demande pas quelle est la taille du marché des issues de secours, mais en cas d'incendie, elles sauvent des vies. Le financement de ces projets doit donc être hybride (fonds publics, dons, propriété communautaire), et leur succès se mesure non pas en revenus, mais au nombre de personnes pouvant s'exprimer et survivre sous pression.

9. Guerilla Interoperability (Interopérabilité de guérilla)

Intervenant : Andreas Tsamados (Fileverse)

Le discours d'Andreas était combatif, comparant l'Internet Web2 actuel à une ville remplie d'« architectures hostiles », où les géants contrôlent les utilisateurs via des jardins clos, DRM et verrouillage des données. Pour contrer cette « Enshittification » (dégradation des plateformes), il propose le concept de « guérilla de l'interopérabilité » : une résistance tactique menée par les utilisateurs, utilisant des moyens techniques pour forcer l'interopérabilité sans l'autorisation des plateformes dominantes, afin de reprendre la souveraineté sur les données.

Il a détaillé l'arsenal technique pour y parvenir, notamment ZK-TLS (Zero-Knowledge Transport Layer Security). Cette technologie permet aux utilisateurs de générer des preuves cryptographiques de leurs interactions avec des sites Web2 (banques, réseaux sociaux), rendant possible l'importation sans permission des données Web2 dans le Web3. Les développeurs peuvent ainsi construire des applications qui s'appuient sur les plateformes monopolistiques existantes, les « vampirisent » et les surpassent, sans attendre l'ouverture d'API.

Andreas prône une culture de « révolution optimiste », refusant le fatalisme de l'Internet actuel. Il a présenté les outils ddocs.new et dsheets.new de Fileverse, alternatives décentralisées à Google Workspace, chiffrées de bout en bout et permettant d'inviter des collaborateurs via ENS, avec stockage sur IPFS.

Le message central : n'attendez pas que les géants changent, utilisez des comptes programmables, du stockage décentralisé et la technologie ZK pour construire de force des alternatives. Ce mouvement pour le « droit à la réparation numérique » invite les développeurs à exploiter l'infrastructure des systèmes fermés existants pour offrir plus de confidentialité et de souveraineté aux utilisateurs, jusqu'à ce que les géants soient contraints d'accepter cette nouvelle norme.

10. Building infrastructural resilience (Construire la résilience de l'infrastructure)

Participants : Sebastian Burgel, ml_sudo, Pol Lanski, Kyle Den Hartog

Ce panel s'est concentré sur les couches physiques et matérielles. Les intervenants ont souligné que si le matériel sous-jacent n'est pas digne de confiance, la confidentialité logicielle est bâtie sur du sable. Les puces actuelles (comme Intel SGX) sacrifient souvent la sécurité pour la performance et sont vulnérables aux attaques par canaux auxiliaires. ml_sudo a présenté l'initiative Trustless TEE, visant à construire des puces matérielles totalement open source, transparentes et vérifiables de la conception à la fabrication, pour répondre aux menaces géopolitiques croissantes.

Pol Lanski (Dappnode) a insisté sur l'importance de l'auto-hébergement à domicile. Selon lui, même si l'expérience utilisateur n'est pas encore optimale, l'objectif doit rester que « chacun fasse tourner son propre nœud ». Ce n'est pas seulement pour la décentralisation, mais aussi comme acte de désobéissance civile : lorsque la loi (comme Chat Control) tente de surveiller toutes les communications, faire tourner ses propres relais et serveurs rend la loi inapplicable.

Sebastian (HOPR) a avancé une idée intéressante : « Les nerds protègent les réseaux ». Même si l'on souhaite que tout le monde participe, ce sont les quelques passionnés prêts à bricoler le matériel et à faire tourner des nœuds qui forment la première ligne de défense du réseau. L'écosystème doit donc valoriser et soutenir cette culture geek, tout en abaissant les barrières matérielles pour élargir la participation.

La discussion est revenue à la question du « pourquoi ». À l'ère de la prolifération des deepfakes et de la connectivité généralisée, seule une infrastructure matérielle et logicielle sans confiance permet de préserver l'« humanité » dans le monde numérique : être sûr d'interagir avec de vraies personnes, que ses données ne sont pas volées. Cette résilience de l'infrastructure est notre dernier rempart contre le totalitarisme numérique.

11. Kohaku wallet on Ethereum (Le portefeuille Kohaku sur Ethereum)

Intervenant : Nicolas Consigny (EF)

Nicolas a présenté un nouveau projet mené par la Ethereum Foundation : Kohaku. Il s'agit d'un ensemble de primitives axées sur la confidentialité et la sécurité, comprenant un SDK et une extension de portefeuille de référence (fork d'Ambire). Kohaku n'a pas vocation à être un portefeuille concurrent, mais à fournir des composants open source de haute qualité, comme un « buffet » pour les développeurs de portefeuilles, afin d'élever le standard de confidentialité de tout l'écosystème.

Le point fort de Kohaku est de simplifier considérablement l'utilisation des protocoles de confidentialité. Il intègre Railgun, Privacy Pools, etc., permettant à l'utilisateur de basculer en un clic dans l'interface pour envoyer des actifs vers un pool de confidentialité, sans configuration complexe. Kohaku introduit aussi un système de connexion « un compte par dApp », évitant que la même adresse soit liée à plusieurs applications et réduisant ainsi la fuite de métadonnées.

Sur le plan de la sécurité matérielle, Kohaku a réalisé plusieurs percées majeures. L'équipe a collaboré avec ZKnox pour permettre la signature directe de transactions ZK Railgun sur hardware wallet, répondant aux besoins des utilisateurs avancés en « cold storage + confidentialité ». Ils ont aussi présenté une couche applicative matérielle universelle, permettant d'exécuter la même logique de signature confidentielle sur Keystone, Keycard et même du matériel DIY à bas coût.

La démonstration de Nicolas illustre l'approche pragmatique de l'EF en matière de confidentialité : ne pas chercher à changer le monde du jour au lendemain, mais construire des SDK sûrs et faciles à utiliser (comme OpenLV), permettant aux portefeuilles existants d'intégrer facilement le support Tor et les transactions confidentielles. Kohaku prévoit de lancer son testnet public lors de l'EthCC de l'an prochain, marquant une nouvelle étape de standardisation et de modularisation de la confidentialité applicative sur Ethereum.

12. Private voting in DAOs (Vote confidentiel dans les DAO)

Participants : Joshua Davila, Lasha Antadze, Anthony Leuts, Jordi Pinyana, John Guilding

Cette discussion a exploré en profondeur la nécessité du vote confidentiel dans les DAO et la gouvernance réelle. Anthony (Aragon) a souligné sans détour que l'absence de confidentialité fausse la gouvernance : sous la pression du vote transparent, 99 % des propositions obtiennent 99 % de votes favorables, car personne ne veut être le « trouble-fête » ou subir des représailles. Le vote confidentiel protège non seulement les électeurs, mais permet aussi d'obtenir une opinion authentique, brisant ce « faux consensus » toxique.

Les représentants de Rarimo et Vocdoni ont partagé leur expérience du vote confidentiel dans des environnements à haut risque (sous des régimes oppressifs). Dans ces contextes, participer au vote peut mener à l'emprisonnement, rendant la confidentialité de l'identité vitale. Techniquement, le défi est de lier identité réelle (passeport, biométrie) et confidentialité on-chain, tout en empêchant les attaques Sybil (multi-vote) et en garantissant l'anonymat des bulletins.

John (MACI) a insisté sur l'importance de l'anti-collusion. Le vote confidentiel ne consiste pas seulement à anonymiser, mais à rendre impossible la preuve du vote à un tiers, pour éviter la corruption. Si un électeur peut prouver à un acheteur de vote qu'il a voté pour A, un marché de la corruption se forme. MACI (Minimum Anti-Collusion Infrastructure) vise à résoudre ce problème. Il a cité le succès du round privé de Gitcoin, prouvant que la technologie (vote quadratique + identité ZK) est presque prête pour la production.

Les intervenants estiment que 2026 sera l'année clé de la maturité des protocoles de vote confidentiel et de leur intégration dans les outils DAO mainstream (Snapshot, Tally). Malgré la maturité technique, le principal obstacle reste culturel : la communauté crypto assimile « transparence » à « justice » et considère même la corruption comme un mécanisme DeFi normal. Changer ce récit et faire comprendre que la confidentialité est la base de la démocratie est la prochaine tâche politique.

13. From Tornado Cash to future developers protection (De Tornado Cash à la protection future des développeurs)

Participants : Marina Markezic, Fatemeh Fannisadeh, Ayanfeoluwa Olajide, Joan Arús

Ce panel, empreint d'urgence et d'appel à l'action, a vu Joan Arús raconter la création de Sentinel Alliance, une coalition de victimes de logiciels espions (comme Pegasus). Il a relaté comment les équipes d'Aragon et Vocdoni ont été surveillées par des gouvernements via des logiciels espions pour avoir développé des technologies de vote résistantes à la censure. La menace est passée de la « poursuite des crimes passés » à la « surveillance préventive », visant le potentiel d'usage du code open source.

Les juristes ont analysé l'aggravation des risques légaux. Les lois antiterroristes sont désormais si larges que toute tentative de « perturber la structure politique ou économique » peut être qualifiée de terrorisme. Cela signifie que les développeurs de DeFi ou d'outils de confidentialité peuvent être accusés de terrorisme sans le savoir. Fatemeh a averti qu'il ne faut pas compter uniquement sur la bureaucratie pour obtenir justice, mais mettre en place des mécanismes de défense proactifs.

Marina (EUCI) a apporté une note d'espoir en partageant les avancées de l'UE sur la révision du RGPD : grâce au lobbying, les régulateurs commencent à reconnaître la spécificité de la blockchain et pourraient admettre que les technologies de renforcement de la confidentialité sont un moyen de conformité RGPD, et non un obstacle. Cela prouve l'efficacité du plaidoyer politique.

Enfin, le panel a lancé un appel fort :l'industrie crypto, qui dispose de plusieurs milliards de dollars, doit cesser de consacrer ses fonds uniquement à des événements et investir dans des fonds de défense juridique et du lobbying politique. Sans cadre légal pour protéger les développeurs, sans unité contre la criminalisation du développement open source, le prochain à aller en prison pourrait être n'importe lequel d'entre nous. Ce n'est pas seulement une question de conformité, mais une lutte existentielle pour la liberté.

14. Protocol-level privacy: Lessons from web2 (Confidentialité au niveau protocole : leçons du Web2)

Intervenant : Polymutex (Walletbeat)

Polymutex a retracé l'histoire de la transition du Web2 de HTTP à HTTPS pour offrir un cadre de référence précieux à la généralisation de la confidentialité dans le Web3. Il rappelle qu'Internet était à ses débuts aussi dépourvu de confidentialité que la blockchain aujourd'hui, pour des raisons similaires : technologie de chiffrement immature, incertitude réglementaire (le chiffrement était considéré comme une arme), coût élevé en performance (latence de handshake).

Il résume les quatre étapes clés de la généralisation de HTTPS : 1. Rendre la confidentialité possible (standardisation, SSL/TLS) ; 2. Rendre la confidentialité légale (gagner le droit au chiffrement en justice) ; 3. Rendre la confidentialité bon marché (instructions matérielles accélérées) ; 4. Rendre la confidentialité par défaut et normale. L'apparition de Let's Encrypt a été un tournant, rendant l'obtention de certificats simple et gratuite. Enfin, les navigateurs ont commencé à marquer les sites HTTP comme « non sécurisés », stigmatisant ainsi les comportements non confidentiels.

Transposé au Web3, nous sommes actuellement à l'étape de la « possibilité » (standards de protocoles de confidentialité) ; l'étape du « bon marché » progresse grâce à l'accélération matérielle ZK et aux précompilés ; mais les étapes « légale » (affaire Tornado Cash) et « simplicité » (intégration dans les portefeuilles) restent de grands défis. Surtout, le Web3 manque d'un « Oh Shit Moment » à la Snowden pour éveiller la conscience collective à la confidentialité.

Polymutex conclut que nous devons utiliser des outils (comme WalletBeat) pour surveiller le comportement confidentiel des portefeuilles (fuites RPC) et promouvoir la confidentialité par défaut. Plus important encore, la communauté doitstigmatiser les comportements non confidentiels : comme les navigateurs avertissent aujourd'hui que HTTP n'est pas sûr, les portefeuilles devraient avertir « ceci est une transaction publique, vos finances seront surveillées ». Ce n'est qu'en considérant l'absence de confidentialité comme une anomalie que la confidentialité deviendra la norme.

15. Privacy on Ethereum now: key challenges (La confidentialité sur Ethereum aujourd'hui : défis clés)

Intervenants : Alan Scott, Max Hampshire

Alan et Max ont discuté de façon décontractée des véritables difficultés rencontrées dans la construction de protocoles de confidentialité. Le premier défi est le problème du récit. L'utilisation d'outils de confidentialité (comme Railgun) est souvent associée à des activités illégales : « Pourquoi veux-tu cacher ? As-tu peur de la police ? » Cette stigmatisation rebute les utilisateurs ordinaires. Il faut changer le récit de « cacher un crime » à « protéger sa sécurité financière quotidienne » (comme ne pas vouloir que tout le monde voie son relevé Visa).

La friction d'intégration technique est un autre obstacle majeur. Alan note que le SDK de Railgun compte des centaines de milliers de lignes de code, ce qui rend son intégration difficile et risquée pour des protocoles DeFi mainstream comme Aave. C'est pourquoi les protocoles DeFi préfèrent que la couche de confidentialité s'adapte à eux, et non l'inverse. De plus, les portefeuilles existants (forks de Rabby, etc.) sont souvent truffés de trackers, ce qui va à l'encontre des objectifs des protocoles de confidentialité.

Sur la confidentialité réseau, Max souligne que c'est un jeu du chat et de la souris. Les techniques de deanonymisation (analyse de trafic) et d'anonymisation (mixnets) évoluent sans cesse. La confidentialité applicative seule ne suffit pas : si l'ISP ou le nœud RPC voit votre IP et vos schémas d'accès, la confidentialité on-chain est compromise. Il faut donc une intégration étroite entre l'infrastructure réseau (Nym) et les protocoles applicatifs.

Enfin, ils discutent de l'élargissement du set d'anonymat. Si seuls les whales utilisent les outils de confidentialité, leur efficacité est limitée. L'objectif est que les utilisateurs ordinaires utilisent la confidentialité sans s'en rendre compte (Plug and Play), même simplement pour éviter d'être copiés ou pour protéger leur alpha. Ce n'est que lorsque les « bons utilisateurs » et les transactions ordinaires sont suffisamment nombreux que le réseau de confidentialité offre une vraie protection.

16. Ethereum Privacy Roadmap (Feuille de route de la confidentialité sur Ethereum)

Intervenant : Andy Guzman (PSE)

Andy Guzman a conclu la journée par une synthèse macro et des perspectives. Il a présenté le modèle de classification simplifié de PSE pour la stack de confidentialité : lectures privées (Private Reads), écritures privées (Private Writes) et portabilité des données (Private Porting). S'appuyant sur la loi du minimum, il rappelle que la robustesse d'un système de confidentialité dépend de son maillon le plus faible. Si la confidentialité ZK est parfaite on-chain mais que l'IP fuit au niveau RPC, tout le système échoue.

Pour la feuille de route, Andy prédit audacieusement : d'ici novembre 2026 (prochain Devcon), le problème des transferts privés sur Ethereum sera résolu. Il note que plus de 35 équipes explorent environ 13 pistes technologiques différentes (adresses furtives, pools de confidentialité, etc.), garantissant qu'une solution gagnante émergera. Les solutions futures offriront un coût faible (seulement deux fois celui d'un transfert ordinaire), une faible latence et une expérience en un clic.

Il soulève aussi une question potentiellement controversée : la confidentialité doit-elle rester au niveau applicatif ou être intégrée au cœur du protocole (L1) ? Cela pourrait provoquer une « guerre civile » à l'avenir. Intégrer la confidentialité à L1 unifierait la liquidité et offrirait une confidentialité par défaut, mais augmenterait les risques réglementaires et la complexité du protocole. Il appelle la communauté à un débat public sur ce sujet.

Enfin, sur la conformité, Andy a présenté un spectre allant de la « confidentialité sans permission (Cypherpunk) » à la « confidentialité conforme (Practical) ». Il estime que, bien que l'esprit cypherpunk pur mérite d'être poursuivi, l'adoption institutionnelle et gouvernementale nécessite aussi des solutions responsables comme Privacy Pools. L'avenir de la confidentialité sur Ethereum ne doit pas être monolithique, mais un écosystème diversifié répondant à différents besoins. PSE continuera à combler les lacunes techniques pour faire d'Ethereum un réseau véritablement privacy-first.