Où le zero knowledge est réellement utilisé : zkLogin, coprocessors et contrôles d’identité

2026-08-24

Un système zero knowledge est plus facile à comprendre quand chaque preuve correspond à une affirmation précise. Une preuve peut cacher un champ d’identité, certifier un calcul effectué hors chaîne ou montrer qu’une règle d’identité est satisfaite sans publier le document sous-jacent. Elle ne rend pas automatiquement chaque composant trustless et ne transforme pas un login en identité universelle. Cet article suit la frontière entre preuve ZK, zkLogin, coprocessor ZK et contrôle d’identité.

Ce qu’une preuve zero knowledge cache réellement

Une preuve zero knowledge permet à un prover de convaincre un verifier qu’une affirmation est vraie tout en gardant certaines données witness privées. L’affirmation peut concerner un jeton signé, le résultat d’un programme ou une credential qui satisfait une règle. La preuve n’est pas l’affirmation : elle démontre une relation définie entre des entrées publiques et privées par un circuit ou un programme précis.

La confidentialité est donc sélective. Le verifier peut voir un résultat booléen, un commitment public, un identifiant de réseau, un identifiant de programme ou un horodatage sans voir l’entrée privée. Une preuve de seuil d’âge peut cacher une date de naissance, mais elle ne prouve pas que l’émetteur de la credential est fiable ni que la politique choisie est correcte.

La bonne question n’est pas seulement de savoir si un produit utilise ZK. Il faut demander ce qui est public, ce qui est privé, qui produit le witness, quelles clés ou configurations sont supposées fiables et qui vérifie le résultat. Un système peut avoir une preuve solide tout en dépendant d’un fournisseur OAuth, d’un salt service, d’un indexer, d’un émetteur de credentials ou d’une application qui applique une règle faible.

Comment zkLogin lie un login web à une adresse

Pour comprendre zk login explained, il faut commencer par le lien d’identité plutôt que par le mot wallet. Sui zkLogin utilise un login OpenID Connect pour obtenir un JSON Web Token signé. L’application crée aussi une paire de clés éphémère. Le nonce du jeton est construit à partir de la clé publique éphémère, d’un aléa et d’une epoch d’expiration, ce qui lie la session de transaction au flux de login.

La documentation Sui distingue un salt service et un proving service. Le salt, l’issuer, l’audience de l’application et le subject claim participent à la dérivation du seed d’adresse. Tant que le salt reste privé, l’identifiant OAuth peut être dissocié de l’adresse on-chain. Le proving service reçoit le jeton et les entrées nécessaires, puis produit une preuve Groth16 qui vérifie la signature du fournisseur, le nonce, le claim et la dérivation de l’adresse.

L’adresse et la clé de session n’ont pas la même durée de vie. L’adresse peut rester stable lorsque l’issuer, l’audience, le subject et le salt ne changent pas, tandis que la clé éphémère expire à l’epoch prévue. Un nouveau login peut produire une nouvelle clé et une nouvelle preuve pour la même adresse. Les validateurs vérifient la preuve et la signature éphémère avant d’exécuter la transaction. Il s’agit d’un flux propre au protocole, pas d’une promesse que tout social login crée une identité auto-souveraine.

La limite de confiance est visible dans les détails. Le fournisseur OAuth authentifie le compte et signe le jeton. L’application contrôle le frontend et la clé éphémère. Le salt service et le proving service peuvent voir des éléments sensibles selon leur conception. Sui indique que ces services peuvent relier identité et salt dans leur propre vue, même si le JWT n’est pas publié on-chain. Le résultat dépend donc des hypothèses et de la protection du salt et de la clé de session.

Ce qu’un ZK coprocessor calcule

L’expression zk coprocessor explained doit être traitée comme une question d’architecture. Un coprocessor déplace une tâche lourde en données ou en calcul hors de la chaîne applicative, puis renvoie un résultat accompagné d’une preuve indiquant que les entrées authentifiées et le calcul déclaré ont été utilisés. Dans un modèle ZK pur, un contrat verifier peut contrôler la preuve sans refaire tout le calcul.

Flux d’une preuve ZK entre une entrée privée et un résultat d’application vérifiable

La documentation Brevis présente trois étapes : accès aux données, calcul applicatif et utilisation du résultat. L’application demande des données historiques, un prover hors chaîne exécute une logique, puis le résultat et la preuve sont vérifiés on-chain. Ce schéma peut soutenir un seuil d’activité, une règle d’appartenance, un calcul de récompense ou un indicateur de risque. La preuve certifie la relation encodée, pas automatiquement la qualité de la source de données.

Ce modèle diffère d’une simple réponse d’indexer. Une réponse non prouvée oblige à faire confiance à la partie qui a choisi les données et effectué le calcul. Un coprocessor ZK peut réduire cette confiance en reliant le résultat à des données de chaîne authentifiées et à un circuit. En contrepartie, le circuit, les commitments, le système de preuve, le verifier et le processus de mise à jour doivent être audités.

Un coprocessor n’est pas une fonction unique et immuable. Brevis distingue un mode pure ZK d’un modèle coChain ou optimiste, avec des hypothèses différentes sur la latence, le coût et les challenges. RISC Zero décrit plus généralement le calcul vérifiable : la sortie d’un programme est accompagnée d’un receipt vérifiable sans relancer le programme ni voir les entrées privées. Chaque déploiement doit toutefois préciser son statement, l’authentification des entrées et sa politique d’échec.

Où s’arrête la preuve d’un contrôle d’identité

Un contrôle d’identité peut être formulé comme une affirmation sur une credential, pas comme une preuve magique sur une personne. Le verifier peut demander si un issuer a signé la credential, si elle est valide, si le subject dépasse un seuil d’âge ou si un identifiant figure dans une liste de révocation. Un circuit ZK peut cacher les champs inutiles et ne révéler que le résultat minimal demandé par l’application.

L’expression zero knowledge identity verification doit donc être décomposée en rôles issuer, holder et verifier. Le modèle W3C Verifiable Credentials décrit des claims émis par un issuer, détenus par un subject ou holder et présentés à un verifier avec des mécanismes d’authenticité et d’intégrité. Les DID W3C décrivent des identifiants et des méthodes de vérification, mais un format DID ou credential ne garantit pas à lui seul la vérité d’une personne, d’une organisation ou d’un document.

Prenons un contrôle d’âge. Une preuve peut montrer qu’une date de naissance signée est antérieure à une date limite sans révéler cette date. Elle ne décide pas si l’issuer a correctement vérifié le document, si la credential appartient au holder actuel, si la politique est légale dans une juridiction donnée ou si la credential a été révoquée. Ce sont des questions d’issuer, de liaison, de politique et de cycle de vie.

La même limite vaut pour sanctions, résidence, accréditation et unicité de compte. Un circuit peut encoder un prédicat où l’issuer appartient à un ensemble approuvé et où le claim satisfait la règle. Il ne répare pas un registre faible, une credential volée, un wallet compromis, une source erronée ou un flux de révocation incomplet. True signifie que le prédicat encodé a été vérifié sur les entrées fournies, pas que tous les faits réels derrière ces entrées sont vrais.

La confidentialité est un choix de conception, pas une sortie de preuve

ZK peut réduire la divulgation, mais la confidentialité dépend de tout le flux. Le verifier peut encore observer une adresse publique, le moment, le réseau, l’audience de l’application, la fréquence des preuves ou le fait qu’une politique a été tentée. Des présentations répétées peuvent être corrélées si l’application réutilise des identifiants ou des commitments publics. Les métadonnées peuvent révéler plus que le witness caché par le circuit.

zkLogin rend ce point visible avec le salt et les claims OpenID. Le salt aide à dissocier l’identifiant OAuth de l’adresse on-chain, mais sa perte peut empêcher de retrouver l’adresse et son exposition peut rendre le subject corrélable. Le fournisseur OAuth, le frontend, le salt service, le proving service et les validateurs voient des parties différentes du flux. Une revue de confidentialité doit cartographier ces vues.

Pour les coprocessors, la confidentialité dépend aussi du lieu où les données brutes et le witness sont traités. Un verifier on-chain peut vérifier le résultat sans voir les entrées privées, alors que le prover hors chaîne ou le fournisseur de données a pu les voir. Si la confidentialité doit aussi être maintenue vis-à-vis du prover, un verifier ZK public ne suffit pas toujours ; il peut falloir du private proving, une exécution sécurisée ou du calcul chiffré.

Le principe de divulgation minimale reste utile : prouver seulement le prédicat nécessaire, utiliser une audience ou un domain separator propre à la finalité, faire tourner les éléments de session selon le protocole et documenter la conservation et les risques de corrélation. Ces contrôles ne suppriment pas la confiance, mais rendent les chemins restants examinables.

Ce que le modèle de confiance doit nommer

Commencez par l’énoncé et les entrées publiques. Notez exactement ce que le verifier accepte, quelles données sont engagées, comment l’état de la chaîne ou la credential est authentifiée et quelle version de logiciel ou de circuit a produit la preuve. Si un contrat consomme le résultat, identifiez le code du verifier, le pouvoir de mise à jour, la voie d’urgence et le traitement des données périmées.

Nommez ensuite les acteurs. Pour zkLogin : fournisseur OpenID, application, détenteur de la clé éphémère, salt service, proving service et validateurs Sui. Pour un coprocessor : source de données, indexer ou light client, prover, verifier et mécanisme de challenge ou de staking. Pour un contrôle d’identité : issuer, holder, wallet ou couche de présentation, verifier et service de révocation. Un acteur absent du schéma est déjà un signal de risque.

Séparez correction, disponibilité et récupération. Une preuve valide peut arriver trop tard. Un fournisseur peut changer ses clés, un salt service être indisponible et une credential expirer. Une réorganisation de chaîne ou une règle de finalité peut modifier l’ensemble d’entrées. Une voie optimiste peut dépendre d’un challenge honnête dans une fenêtre donnée. Ce sont des propriétés opérationnelles, pas des problèmes que la preuve mathématique règle seule.

Enfin, vérifiez les hypothèses de setup et de mise à jour. Sui documente une cérémonie de référence commune Groth16 pour zkLogin. D’autres systèmes peuvent utiliser un système transparent, un receipt de zkVM, un setup de confiance, un comité ou une couche de staking. Demandez qui peut changer le circuit, le verifier, le registre des issuers, la liste des fournisseurs, la source de données ou la politique. Une preuve correcte selon la politique d’hier peut être inadéquate aujourd’hui.

Comment lire une affirmation d’identité ZK

Quand une documentation dit qu’une fonction est privée, traduisez cette promesse en quatre questions : privée pour qui, visible pour qui, pendant combien de temps et avec quelle possibilité de corrélation. Quand elle dit trustless, demandez quel acteur est retiré et qui reste fiable pour les entrées, les clés, la disponibilité, la récupération et la gouvernance. Quand elle dit vérifiable, demandez quelle relation de calcul ou de credential est réellement couverte.

Pour cette séquence, vérifiez cinq éléments. Examinez d’abord le statement et le witness. Suivez ensuite la liaison entre jeton du fournisseur ou credential et adresse de l’application ou présentation. Identifiez le calcul hors chaîne et sa source de données authentifiée. Listez les hypothèses d’issuer, de politique, de révocation et de holder. Testez enfin les fuites de métadonnées, la réutilisation et la visibilité des services.

Cette méthode sépare trois idées. zkLogin peut lier une clé de transaction éphémère à des claims d’un flux OpenID tout en cachant certains champs à la chaîne. Un coprocessor ZK peut rendre vérifiable un calcul hors chaîne par rapport à des données déclarées. Un contrôle d’identité peut prouver qu’un prédicat de credential défini a été satisfait. Aucun de ces énoncés ne prouve à lui seul l’honnêteté de l’utilisateur, la fiabilité de l’issuer ou l’actualité des données.

Le zero knowledge est réellement utilisé dans une relation soigneusement délimitée entre entrées, calcul et vérification. Le résultat utile n’est pas une promesse d’identité invisible, mais une affirmation plus petite et auditable, avec des hypothèses de confidentialité et de confiance explicites. Ces hypothèses doivent être conservées avec la version du protocole, la date des sources et la politique afin qu’un changement ultérieur soit détecté.

Articles associés

Autres articles Bitbase sur ce sujet :

- Preuve de personnalité et résistance aux attaques Sybil

- Transactions privées, shielded addresses et view keys

- Comment l’éligibilité à un airdrop est décidée : instantanés, points et filtres Sybil

Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en août 2026 ; référez-vous aux informations officielles les plus récentes.