💻 computer science

Privacy-Preserving Compliance on Public Ledgers via Selective Disclosure Authorization Schemes

Cet article introduit les schémas d'autorisation de divulgation sélective (Selective Disclosure Authorization Schemes - SDAS) et leur instanciation sur Ethereum, ZK-Compliance, afin de permettre une conformité réglementaire granulaire et révocable sur les registres publics en liant des preuves à connaissance nulle à des expéditeurs on-chain spécifiques, atténuant ainsi les risques de front-running et de réutilisation de preuves tout en préservant la confidentialité des données.

Auteurs originaux : Supriya Khadka, Sanchari Das

Publié 2026-06-23

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Supriya Khadka, Sanchari Das

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez un registre public (comme une blockchain) comme un immense mur de verre transparent où tout le monde peut voir chaque transaction. C'est excellent pour l'honnêteté, mais c'est terrible pour la vie privée. Si vous devez prouver que vous avez plus de 18 ans pour entrer dans un club numérique, la méthode actuelle vous oblige à crier votre date de naissance réelle au monde entier. Soit vous révélez votre secret, soit vous ne pouvez pas entrer.

Ce document propose une nouvelle façon de résoudre ce problème en utilisant un « tour de magie » appelé Preuves à Divulgation Nulle de Connaissance (ZKP - Zero-Knowledge Proofs), combiné à une règle de sécurité stricte pour empêcher les voleurs de voler votre tour.

Voici la décomposition de leur solution, la ZK-Compliance, utilisant des analogies simples :

1. Le Problème : Le « Mur de Verre » et le « Voleur »

Le Piège de la Transparence : Dans une blockchain normale, si vous voulez prouver que vous êtes éligible (par exemple, « J'ai plus de 18 ans »), vous devez généralement publier vos données réelles sur le mur. Une fois qu'elles y sont, elles sont permanentes et visibles par tous.
La Fenêtre du Voleur : Même si vous utilisez un « tour de magie » (un ZKP) pour prouver que vous avez plus de 18 ans sans montrer votre date de naissance, il y a un délai. Vous générez la preuve sur votre ordinateur, mais elle doit voyager à travers une salle d'attente publique (le « mempool ») avant d'être enregistrée.
L'Attaque : Un voleur debout dans cette salle d'attente peut voir votre preuve valide, la saisir et courir à la porte du club avant vous, en prétendant que c'est lui qui a généré la preuve. C'est ce qu'on appelle le « front-running ».

2. La Solution : Le « Bracelet » qui ne convient qu'à vous

Les auteurs ont créé un système appelé SDAS (Selective Disclosure Authorization Scheme). Considérez cela comme un système de bracelets intelligents pour le club numérique.

Le Tour de Magie (La Preuve) : Au lieu de montrer votre acte de naissance, vous utilisez un programme informatique spécial (un « circuit ») pour générer un reçu numérique. Ce reçu prouve : « Oui, cette personne a plus de 18 ans », mais il ne contient aucune information sur qui est cette personne ou quand elle est née.
La Colle de Sécurité (Liaison de l'Expéditeur) : C'est l'innovation principale du papier. Le système prend ce reçu numérique et le « colle » à l'adresse de votre portefeuille numérique spécifique (votre identifiant unique).
- L'Analogie : Imaginez que le reçu est un ticket. Dans l'ancien système, n'importe qui pouvait ramasser un ticket tombé et l'utiliser. Dans ce nouveau système, le ticket est imprimé avec un hologramme qui dit : « Ce ticket ne fonctionne que s'il est tenu par Alice ».
- Si un voleur essaie de saisir votre ticket et de l'utiliser avec son propre identifiant, l'hologramme ne correspond pas, et le videur du club (le contrat intelligent) rejette immédiatement la tentative.

3. Comment cela fonctionne en la vie réelle (Le cycle « Accorder, Vérifier, Révoquer »)

Le papier a testé cela sur une version de test d'Ethereum (Sepolia) et a créé un processus en trois étapes :

Accorder (Le Spectacle de Magie) : Vous allez sur votre navigateur, et un petit programme (s'exécutant en moins de 200 millisecondes — plus vite qu'un clin d'œil) crée votre preuve. Il vérifie votre année de naissance par rapport à la limite d'âge, ajoute un « sel » secret (comme une épice aléatoire pour empêcher les suppositions) et lie la preuve à votre portefeuille. Vous envoyez cela au club.
Vérifier (Le Contrôle du Videur) : Le contrat intelligent du club vérifie deux choses :
- La mathématique de la preuve est-elle correcte ? (Avez-vous vraiment prouvé que vous avez plus de 18 ans ?)
- Crucialement : La preuve correspond-elle à la personne qui la détient ? (L'adresse du portefeuille sur la preuve est-elle la même que celle qui envoie la transaction ?)
- Si les deux correspondent, vous entrez. Si un voleur tente d'utiliser votre preuve, la vérification échoue car la « colle » ne correspond pas à son portefeuille.
Révoquer (La Coupe) : Si vous voulez quitter le club ou empêcher la dApp d'avoir accès, vous pouvez appuyer sur un bouton pour « couper » votre bracelet. Le système supprime votre enregistrement d'accès. Le club sait que vous êtes parti, mais il ne connaît toujours pas votre date de naissance.

4. Les Résultats : Rapide et Peu Coûteux

Les auteurs ont construit un prototype et l'ont testé. Voici ce qu'ils ont trouvé :

Vitesse : Générer la preuve sur un ordinateur portable standard prend moins de 200 millisecondes. C'est assez rapide pour un site web normal.
Coût : Vérifier la preuve sur la blockchain coûte environ 240 000 unités de « gas » (la monnaie utilisée pour payer les transactions blockchain). Bien que ce ne soit pas gratuit, c'est un coût fixe et prévisible qui prouve que le système est pratique.
Sécurité : Lors de leurs tests, lorsqu'ils ont tenté de simuler un voleur volant une preuve et l'utilisant depuis un autre portefeuille, le système a bloqué la transaction avec succès à chaque fois.

Résumé

Ce papier introduit une façon de prouver que vous respectez les règles (comme l'âge légal) sur une blockchain publique et transparente sans révéler vos secrets. L'innovation clé est de lier la preuve à la personne spécifique qui l'envoie, de sorte que même si un voleur dérobe la preuve pendant qu'elle attend en ligne, il ne peut pas l'utiliser car le « verrou » de la preuve ne s'adapte qu'à la clé du propriétaire d'origine.

Les auteurs appellent cela la ZK-Compliance, et ils démontrent que cela fonctionne rapidement et de manière sécurisée, transformant un « piège de transparence » en un système de sécurité préservant la vie privée.

Résumé Technique : Conformité préservant la confidentialité sur les registres publics via des schémas d'autorisation de divulgation sélective

Énoncé du problème
Les registres distribués publics, tels qu'Ethereum, imposent l'intégrité par une transparence radicale, ce qui entre en conflit avec les principes de minimisation des données requis pour la conformité réglementaire. Bien que les preuves à divulgation nulle de connaissance (ZKP) permettent théoriquement aux utilisateurs de prouver des affirmations (par exemple, l'âge ou la résidence) sans révéler les données sous-jacentes, les constructions existantes font face à des contraintes adverses critiques dans les environnements de contrats intelligents. Plus précisément, la nature asynchrone des transactions blockchain crée une vulnérabilité : les preuves générées hors-chaîne sont soumises à un mempool public avant leur inclusion. Ce délai permet à des adversaires d'observer des preuves valides et de les « front-runner » ou de les rejouer dans différents contextes de transaction (par exemple, à partir d'une adresse d'expéditeur différente ou vers un contrat différent). Les ZKP standards garantissent la connaissance du témoin (witness), mais ne lient pas intrinsèquement la preuve à l'expéditeur on-chain spécifique, créant un « piège de transparence » où la sur-divulgation ou la réutilisation de preuves compromet la confidentialité et l'intégrité de l'autorisation.

Méthodologie : Schémas d'Autorisation de Divulgation Sélective (SDAS)
Pour combler ces lacunes, les auteurs formalisent les Schémas d'Autorisation de Divulgation Sélective (SDAS), un primitif cryptographique conçu pour des contrôles de conformité granulaires et révocables qui ne révèlent pas les témoins sous-jacents. Le cadre traite l'autorisation non pas comme une présentation de preuve sans état, mais comme une transition d'état vérifiable liée à un contexte d'exécution spécifique.

Modèle Formel : Le modèle SDAS définit un tuple de contexte d'exécution $\Gamma = (\chi_{addr}, \chi_{chain}, \chi_{contract})$ , correspondant aux variables de l'Ethereum Virtual Machine msg.sender, block.chainid, et address(this). Une preuve d'autorisation valide doit attester d'une relation $R(w, \Gamma)$ , garantissant que la preuve est cryptographiquement liée à cet espace de coordonnées.
Définitions de Sécurité : Le document introduit deux propriétés de sécurité fondamentales :
- Déliaison d'Attribut Liée au Registre (Ledger-Bound Attribute Unlinkability) : Garantit qu'un enregistrement d'autorisation on-chain ne révèle aucune information sur le témoin sous-jacent spécifique (par exemple, l'année de naissance), distinguant la liaison transactionnelle (l'adresse) de la liaison d'attribut.
- Liaison de l'Expéditeur Sensible au Contexte (Context-Aware Sender Binding) : Garantit qu'une preuve générée pour un contexte spécifique ne peut pas être réutilisée dans un autre contexte ou par un autre expéditeur.
Prototype de Conformité ZK : Les auteurs instaurent le SDAS sous la forme de ZK-Compliance, un système basé sur Ethereum implémentant un cycle de vie « Accorder, Vérifier, Révoquer » contrôlé par l'utilisateur.
- Conception du Circuit : Le système utilise un circuit Circom à 14 contraintes (AgeCheck) basé sur le schéma Groth16 sur la courbe BN128. Le circuit prend des entrées publiques (année actuelle, seuil d'âge, adresse demandante) et des témoins privés (année de naissance, sel aléatoire). Crucialement, il contraint l'entrée de l'adresse publique ( $x_{addr}$ ) de telle sorte que le circuit consomme l'adresse de l'expéditeur, rendant la preuve invalide si elle est soumise par un msg.sender différent.
- Flux d'Exécution : Le client génère la preuve localement en utilisant SnarkJS, lie l'entrée publique à l'adresse du portefeuille, et soumet une transaction signée. Le vérificateur on-chain vérifie d'abord si l'adresse liée correspond au msg.sender avant d'effectuer la vérification cryptographique, échouant immédiatement en cas de discordance.

Contributions Clés

Formalisation du SDAS : Le document introduit une nouvelle architecture d'autorisation qui sépare la validité de l'attribut de l'autorisation d'état on-chain, modélisant l'autorisation comme une transition d'état vérifiable.
Liaison Sensible au Contexte : Les auteurs définissent et implémentent la Liaison de l'Expéditeur Sensible au Contexte, un mécanisme qui ancre les preuves à divulgation nulle de connaissance à l'exécutant msg.sender pour neutraliser les attaques de front-running de mempool et de réutilisation de preuves.
Instanciation Pratique : Le travail présente ZK-Compliance, un prototype Ethereum natif pour navigateur qui opérationnalise le cycle de vie « Accorder, Vérifier, Révoquer » sans dépendre de dépositaires d'identité persistants.

Résultats Expérimentaux
Les auteurs ont évalué ZK-Compliance sur le réseau de test Sepolia :

Performance Côté Client : La génération de preuve (génération de témoin + construction de preuve) s'est exécutée en moins de 200 ms (précisément 184 ms) sur un MacBook Air (M2, 16 Go de RAM) de classe grand public via WebAssembly.
Coût On-Chain : La transaction de vérification a coûté 240 512 gas, couvrant l'ancrage de l'expéditeur, la vérification de couplage BN128 et le stockage de l'enregistrement d'accès.
Validation de Sécurité : Les simulations ont confirmé que lorsqu'un portefeuille malveillant tentait de réutiliser une preuve capturée depuis une adresse différente, le contrat rejetait la transaction en raison de la discordance de l'expéditeur, empênant ainsi avec succès le transfert d'accès non autorisé.

Signification et Revendications
Le document affirme que ZK-Compliance démontre la faisabilité d'une autorisation de divulgation sélective liée à l'expéditeur sur les registres publics. En traitant l'autorisation comme une transition d'état liée au contexte plutôt que comme une preuve sans état, le système réduit la dépendance vis-à-vis des référentiels d'identité centralisés tout en préservant une stricte confidentialité des attributs. Les auteurs soutiennent que cette approche offre une voie pratique pour la conformité réglementaire (par exemple, la vérification de l'âge) qui soit auditable, limitée dans le temps et révocable, sans exposer de données utilisateur sensibles au registre public et sans être vulnérable aux attaques de réutilisation de preuves basées sur le mempool.

Limites
Les auteurs notent que le prototype actuel se concentre principalement sur la liaison de l'expéditeur ; la liaison cross-chain et cross-contract (ancrage à block.chainid et address(this)) restent des extensions pour des travaux futurs. De plus, le mécanisme de révocation actuel supprime l'état mais n'implémente pas encore de nullificateurs d'état (par exemple, en utilisant des hachages Poseidon) pour empêcher la réactivation de l'accès révoqué via des preuves obsolètes, une fonctionnalité nécessaire pour un déploiement en production.

1. Le Problème : Le « Mur de Verre » et le « Voleur »

2. La Solution : Le « Bracelet » qui ne convient qu'à vous

3. Comment cela fonctionne en la vie réelle (Le cycle « Accorder, Vérifier, Révoquer »)

4. Les Résultats : Rapide et Peu Coûteux

Résumé

Articles similaires