Loading...
Cet article est reproduit depuis Proof Street, une publication indépendante couvrant le calcul préservant la confidentialité : ZK, FHE, MPC, TEEs et l’identité décentralisée. Publié à l’origine sous le titre « Jusqu’où Zcash est allé en matière de divulgation sélective, et ce qu’il reste à faire » le 7 septembre 2026. Reproduit avec l’autorisation de l’auteur dans le cadre de la Zcash Community Grant #339. Par Stephen Webber.
Dans Zcash, une clé de visualisation permet au détenteur d’un compte de révéler l’historique de transactions blindées à une partie de son choix. Les clés sont actives et contrôlées par l’utilisateur. Les développeurs et défenseurs des politiques publiques travaillent encore à les adapter aux processus de conformité qui pourraient les utiliser.
Le 17 août, le comité des Zcash Community Grants s’est réuni pour examiner une proposition appelée Shielded Compliance Bridge. Deborah Olaboye, contributrice open source dont les travaux incluent le dépôt execution-specs d’Ethereum, avait créé une preuve de concept qui ingère une clé de visualisation complète unifiée, analyse des blocs compacts à l’aide d’un indexeur de testnet et transporte une « référence de conformité » dans un champ mémo Zcash reliant un transfert blindé à un enregistrement hors chaîne de la Travel Rule. Elle a demandé une subvention pour la finaliser, mais le comité l’a refusée.
Le raisonnement était que les intégrations de conformité sont façonnées par l’exchange ou l’institution spécifique qui les utilisera, qu’il n’existe pas de normes communes sur lesquelles construire et que, sans partenaire demandant l’outil, son adoption était peu probable. La même réunion a refusé d’autres propositions pour des raisons similaires, l’une concernant une machine virtuelle de « divulgation sélective programmable », et une autre concernant un cadre d’architecture de confidentialité et de confiance, qui incluait une cartographie des questions juridiques américaines.
Bien sûr, ces décisions ne signifient pas que personne ne souhaite cela. Considérées à la lumière du reste de l’année, elles indiquent le contraire. Binance a formulé une demande au niveau du protocole en 2024 et a obtenu une ZIP dans l’année. Gemini effectue des retraits blindés sous supervision réglementaire depuis 2020. L’écosystème a mis en place une organisation politique à Washington en juin et une structure d’intégration institutionnelle en août. Ce que le comité a dit, en substance, c’est que le besoin n’a pas encore été consigné sous la forme d’une exigence sur laquelle quiconque puisse construire.
Une adresse blindée Zcash est contrôlée par une clé de dépense. Des clés de visualisation en sont dérivées et peuvent lire les données de transaction sans pouvoir déplacer les fonds. La clé de visualisation complète voit les transactions entrantes et sortantes du compte, la clé de visualisation entrante ne voit que les fonds reçus, et la clé de visualisation sortante permet à un expéditeur de reconstruire ce qu’il a envoyé. Depuis ZIP 316, celles-ci sont regroupées dans des clés de visualisation unifiées, une complète et une entrante, limitées à un compte, où un compte correspond à une position dans l’arbre de clés du wallet sous ZIP 32. Une clé de visualisation complète unifiée regroupe les composants par pool pour chaque pool blindé utilisé par le compte, et elle contient également la clé publique étendue transparente du compte ; en partager une expose donc la chaîne transparente ainsi que l’historique blindé.
En ce sens, une clé de visualisation est rétroactive. Elle déchiffre l’intégralité de l’historique du compte depuis sa création, et ne peut être retirée une fois partagée, sauf à déplacer les fonds vers un nouveau compte. Il n’existe ni clé de visualisation par transaction ni clé limitée dans le temps. Josh Swihart, directeur général de ZODL, l’entreprise créée cette année par l’ancienne équipe d’ingénierie ECC du protocole, l’a confirmé, ajoutant que la divulgation de paiement par transaction n’est « implémentée nulle part ».
zcashd, le nœud de référence original, proposait deux méthodes RPC, z_getpaymentdisclosure et z_validatepaymentdisclosure, qui permettent à un expéditeur de prouver un paiement unique à un tiers. La documentation RPC les indique comme expérimentales, désactivées à moins que l’opérateur n’ait défini un indicateur de fonctionnalités expérimentales, et implémentant une « divulgation de paiement ZIP en cours de développement ». Ce ZIP, 303, est désormais marqué comme retiré, et son successeur, ZIP 311, reste un brouillon sans implémentation associée. Les méthodes ne couvraient que le pool Sprout, le pool blindé originel de 2016, et n’ont jamais été étendues à Sapling ou Orchard, c’est-à-dire aux pools qui portent chaque transaction blindée moderne. zcashd a lui-même atteint sa fin de vie le 18 juillet 2026, un arrêt planifié avant la mise à niveau Ironwood. Ni Zebra, le nœud de consensus de Zcash Foundation, ni Zallet, le wallet successeur, ne répertorie de méthode de divulgation. Pour les pools qui comptent, la divulgation par transaction reste une intention de conception.
Cette intention reste d’actualité, mais est plus éloignée qu’elle ne le semblait en juillet. ZIP 231, les lots de mémos, est le brouillon qui lui ferait de la place : Swihart a décrit les lots de mémos comme la future base d’une adresse de réponse authentifiée pouvant faire office de preuve de paiement, et le brouillon dépendant, adresses de réponse authentifiées, nécessite des preuves trop volumineuses pour le champ mémo actuel. Les lots de mémos constituent un changement de format de transaction, et les cinq organisations coordonnant le NU7 vote des détenteurs de coins ont convenu en août que les changements de format sont hors du périmètre de NU7 et relèvent de la mise à niveau suivante. Le vote lui-même, qui se déroule du 25 août au 14 septembre, soumettait aux détenteurs l’émission, la politique de frais, l’espacement des blocs et l’abandon de Sprout ; la divulgation ne figurait pas sur le bulletin. L’ancienne voie, ZIP 311, ne requiert aucun changement de consensus mais demeure un brouillon sans implémentation ni couverture Orchard.
Ainsi, ce qui est disponible aujourd’hui, ce sont des clés de visualisation limitées au compte, complètes ou entrantes uniquement, rétroactives, irrévocables et partagées à l’initiative du détenteur du compte, tandis que la divulgation au niveau des transactions figure sur la feuille de route.
Les mécanismes de divulgation, dans Zcash ou ailleurs, peuvent être situés selon les dimensions suivantes : ce qui est révélé (portée) ; à qui (bénéficiaire) ; le moment où l’autorisation prend effet et jusqu’où elle remonte (temporalité) ; si elle peut être retirée (révocabilité) ; et qui l’initie, la personne concernée ou une autorité (initiation).
Les régimes de conformité constituent des exigences portant sur ces dimensions, et les architectures y adoptent des positions. Les clés de visualisation de Zcash sont, par conception, à portée large, accordées à un bénéficiaire choisi par le détenteur, entièrement rétroactives, irrévocables et initiées par l’utilisateur. Le côté des exigences, tel qu’il est appliqué par les exchanges et les superviseurs, tend à être limité à une relation ou à une période, accordé à une institution nommée ou à son fournisseur d’analytique, continu à partir de l’onboarding, révocable lorsque la relation prend fin et initié par l’institution comme condition du service.
Ces deux réalités sont qualifiées de divulgation sélective. Dans le monde des justificatifs, la divulgation sélective désigne la présentation d’un sous-ensemble d’attributs d’un justificatif signé sans révéler le reste, ce que SD-JWT, ISO mdoc et les signatures BBS+ sont conçus pour faire. L’unité de divulgation est un attribut, le moment est celui de la présentation, et le détenteur décide pour chaque interaction.
Dans le monde des paiements blindés, l’expression désigne la révélation de données de transaction à une partie choisie, où l’unité est l’historique d’un compte et le moment est celui où la clé est remise.
Swihart a déclaré que la seule demande de conformité au niveau du protocole jamais reçue par l’équipe d’ingénierie venait de Binance, qui, en janvier 2024, exigeait une garantie de provenance transparente pour les dépôts. La réponse de l’équipe fut ZIP 320, des adresses à source transparente uniquement, et le texte ZIP consigne bien cette origine « comme exigé par Binance ». Une adresse TEX est un passage transparent éphémère qui garantit que l’exchange reçoit des fonds provenant d’une source transparente. Elle fournit à l’exchange une voie de retour sans lui donner accès à l’historique de l’expéditeur. La seule adaptation du protocole à un exchange divulgue exactement ce que l’exchange a demandé et rien de plus.
Depuis la mise à niveau Sapling, selon Swihart, aucune raison technique n’empêche un exchange de prendre en charge les transactions blindées, car la génération des preuves est rapide, les clients des exchanges sont déjà identifiés lors de l’onboarding et une diligence renforcée existe pour les cas qui en ont besoin. Dans cette optique, l’écart entre les mécanismes et le processus de conformité n’est pas réellement une primitive manquante, mais en fait une conversation manquante.
Divij Pandya travaille à l’autre extrémité de cette conversation. Il est directeur exécutif de Pretty Good Policy pour Zcash, l’organisation politique de Washington créée en juin dans la continuité d’une initiative antérieure menée par ECC, et le projet de son organisation consiste à faire reconnaître la divulgation par clé de visualisation comme un mécanisme de conformité acceptable dans un document qu’un responsable de conformité peut citer. À sa connaissance, a-t-il indiqué, aucun régulateur ne s’est encore penché sur les clés de visualisation comme instrument. Le périmètre de PGPZ est naturellement la reconnaissance plutôt que les directives destinées aux développeurs. Un outil ne peut être spécifié par rapport à une exigence tant qu’une autorité n’a pas statué sur l’instrument ; la reconnaissance est donc l’étape en amont. Les déclarations de l’organisation sont signées par Paul Brigner en tant que fondateur de PGPZ et directeur de la politique et de la réglementation de ZODL ; les efforts de politique et d’ingénierie partagent donc un responsable ainsi qu’une thèse.
Une déclaration du 21 juillet versée au dossier d’une sous-commission de la Chambre sur la supervision de FinCEN décrit Zcash comme disposant de « capacités de divulgation sélective, permettant aux utilisateurs de partager volontairement les détails de transactions au moyen de clés de visualisation avec des auditeurs, des autorités fiscales ou des responsables de conformité », et fait référence à des preuves à divulgation nulle de connaissance « associées à des clés de visualisation sélective » pour prouver des faits spécifiés. Une lettre de commentaires dans le dossier de FinCEN, FINCEN-2026-0101-0050, soutient, selon Pandya, que les clés de visualisation et la divulgation sélective devraient être des mécanismes de conformité acceptables. La question ouverte qu’ils soumettent au régulateur porte sur la granularité : savoir si une divulgation à portée de compte couvrant tout l’historique suffit pour des « informations ciblées sur les transactions », ou si la réponse attend ZIP 231.
En attendant que cela soit résolu, les équipes de conformité font face à une contrainte qu’un contributeur pseudonyme d’un forum, strahncryptography, a décrite lors de la discussion de la proposition d’Olaboye : elles suivent la règle à la lettre et n’adopteront pas une voie non reconnue sans attestation d’un régulateur ou d’un cabinet juridique, quelle que soit la solidité de la cryptographie. Toute conception de divulgation qui attache une référence à une transaction ne prouve que le dernier saut, et ce dernier saut pourrait être le déposant lui-même. Une clé de visualisation présente la même limite. Elle révèle les transactions du détenteur du compte, non l’origine des fonds des contreparties, qui est la question posée par un filtrage des sanctions.
Les clés de visualisation satisfont aux exigences partout où celles-ci demandent à la personne concernée de prouver ce qui s’est passé, comme la provenance d’un dépôt que le déposant choisit d’expliquer, un audit volontaire, une déclaration fiscale ou la preuve qu’un paiement spécifique a été effectué. Ce sont des divulgations ponctuelles, rétroactives et initiées par l’utilisateur. Elles ne satisfont pas aux exigences lorsque celles-ci imposent une surveillance continue depuis l’onboarding, un filtrage des sanctions concernant des contreparties que le détenteur du compte ne contrôle pas, une portée limitée à une période ou une relation, ou une révocation lors de l’offboarding.
Gemini accepte les retraits vers des adresses blindées depuis septembre 2020, lorsqu’un porte-parole l’a attribué à des conversations continues avec les régulateurs ; cette prise en charge a été étendue au pool Orchard en novembre 2025, puis au pool post-Ironwood deux jours après son activation en juillet 2026. Gemini accepte les dépôts envoyés depuis des adresses blindées vers une garde transparente. La liste des adresses de retrait de Kraken ne prend en charge que les adresses transparentes ZEC, Coinbase est également limité au transparent, et Binance exige TEX. Ce qu’aucun grand exchange réglementé ne propose encore, c’est une garde blindée, une adresse de dépôt blindée ou un processus dans lequel serait intégrée la clé de visualisation d’un client.
L’ingestion est en cours de développement un niveau plus bas. Parmi les propositions du cycle de subventions rétroactives dirigé par les détenteurs de coins examinées en septembre figurent ZecBooks, un outil de comptabilité Mac qui importe une clé en lecture seule, classe les notes et exporte un paquet ciblé de lignes pour un comptable sans accorder un accès durable au wallet ; ZecLedger, un outil en lecture seule de calcul de base de coût et de rapprochement conçu autour d’une clé de visualisation complète unifiée, testé avec un wallet mainnet ; et seer-sync, un moteur de synchronisation de chaîne qui prend une clé de visualisation afin qu’un processeur de paiements ou un système comptable puisse observer l’activité blindée sans détenir de clés de dépense. Aucun n’est un processus d’exchange, et aucun n’a l’attention d’un régulateur. Chacun constitue la moitié orientée comptable du même problème, construit par une ou deux personnes sans partenaire demandeur, et l’export ciblé de ZecBooks est une divulgation sélective opérant à l’interface où elle est le plus souvent nécessaire en premier : entre un utilisateur blindé et la personne qui tient ses comptes.
Les développeurs de Zcash travaillent sur un problème partagé par toutes les architectures de confidentialité.
Dans la conception EVM confidentielle de Zama, une liste de contrôle d’accès détermine quelles adresses peuvent demander le déchiffrement d’un texte chiffré, et un réseau à seuil d’opérateurs de gestion de clés effectue le déchiffrement sur demande. Cela déplace l’axe du bénéficiaire d’une clé remise par l’utilisateur à une autorisation consignée par un contrat, et rend l’initiation programmable, puisqu’un contrat peut accorder à un auditeur des droits de déchiffrement comme condition d’utilisation. Cela ne rend pas la divulgation révocable au sens où l’entend un responsable de conformité, car un texte chiffré déjà déchiffré reste déchiffré, et cela substitue l’honnêteté des opérateurs à la garde de clé de l’utilisateur comme base de confiance. Les clés d’auditeur au niveau des actifs, du type de celles présentes dans l’extension de transfert confidentiel de Solana et dans la conception ERC chiffrée d’Avalanche, fixent un bénéficiaire au niveau du token, en ce que l’émetteur ou un auditeur désigné peut lire les soldes et les transferts de cet actif.
Inco a publié un cadre pour la visualisation prédéfinie, où l’accès est fixé dans le matériel de clé au moment de la transaction, par opposition à l’accès de visualisation programmable, où les droits de visualisation constituent un état de contrat pouvant être accordé, limité et retiré ultérieurement.
Qu’est-ce qui sépare une clé de visualisation d’un processus de conformité ?
Une clé de visualisation divulgue l’historique propre au détenteur du compte. Le filtrage des sanctions et la surveillance continue interrogent les contreparties, l’origine des fonds de l’autre côté de chaque transaction, et c’est précisément l’information qu’un pool blindé existe pour dissimuler. Personne n’a encore montré de conception qui réponde à une question sur une contrepartie sans registre transparent ni tiers de confiance.
Si les lots de mémos sont intégrés dans la mise à niveau suivant NU7 et que le brouillon d’adresse de réponse suit, les « informations ciblées sur les transactions » dans les déclarations de PGPZ deviendront littérales. Cela se situe à au moins deux mises à niveau de distance, et la réponse réglementaire arrivera selon le calendrier d’un régulateur.
La demande est facile à constater au nombre de personnes qui construisent dans cette direction. Ce qui manque est une exigence établie pour la divulgation préservant la confidentialité. Zcash est l’écosystème où cette décision est négociée ouvertement, par des ingénieurs, des défenseurs, des développeurs, un exchange et un comité de subventions qui semblent s’accorder sur la destination et débattent de l’ordre des étapes. Des développeurs indépendants y travaillent aussi, ayant commencé par la couche comptable sans attendre que l’exigence soit écrite.
Divulgation : cet article a été soutenu par une Zcash Community Grant. ZCG n’a pas relu ni approuvé cet article avant sa publication.
Pages associées : Clés de visualisation · Confidentialité comparée