Qu'entend-on par identité au sein du protocole Concordium ? De quelle manière la preuve à divulgation nulle de connaissance permet-elle de vérifier et de préserver la confidentialité ?

L’identité intégrée au niveau du protocole est la clé pour comprendre la singularité de Concordium (CCD) par rapport aux autres blockchains publiques. Contrairement à la majorité des blockchains, qui assimilent l’« adresse » à l’« identité » et confient la gestion du KYC à des plateformes centralisées, Concordium relie directement, au sein du protocole, chaque compte à une entité vérifiée. Ainsi, toutes les transactions, inscriptions d’Agent et contrôles d’attributs reposent sur une base commune de responsabilité.

Une question fréquente revient : si la conformité est nécessaire, pourquoi ne pas enregistrer les résultats KYC directement on-chain ? Concordium explique que la chaîne requiert des autorisations vérifiables et des conclusions sur les attributs, pas la divulgation permanente de données sensibles. Les Zero-Knowledge Proofs (ZKP) constituent la solution à cette exigence.

Quels problèmes résout l’identité au niveau du protocole ? En quoi diffère-t-elle de l’« anonymat d’adresse » ?

Le modèle classique des blockchains publiques repose sur la pseudonymie : les adresses sont traçables, mais non rattachées à des entités responsables. Cela suffit pour les transferts simples, mais pour la signature d’Agents, l’accès à des services sous condition ou le PayFi d’entreprise, les contreparties doivent savoir « qui est responsable » et « si les critères de conformité sont remplis », sans avoir accès à toutes les données personnelles.

Avec Concordium, chaque compte est associé à une personne physique ou morale validée par un Identity Issuer, cette liaison étant imposée au niveau des règles réseau. Ce n’est pas une option ajoutée via DApp. Cela permet au processus d’enregistrement et de vérification de l’Agent Registry de relier chaque Agent à une partie autorisée et validée.

Comment les comptes Concordium sont-ils rattachés à des personnes ou entités réelles ?

La liaison s’effectue en deux temps : vérification off-chain, puis référence on-chain. L’utilisateur transmet ses justificatifs à un Identity Issuer reconnu par Concordium ; après validation KYC ou KYB, l’émetteur accorde un objet d’identité lié au compte. Sur la chaîne, seules la référence d’identité et la structure cryptographique sont visibles — jamais de documents en clair.

Cet objet confère au compte une « origine vérifiée » : toute opération signée par le compte (création d’Agent, transaction, présentation de preuve d’attribut) est reliée à une entité validée par l’émetteur. Les règles de révocation, de mise à jour et d’expiration sont définies par le protocole et la politique de l’émetteur, selon la documentation réseau.

Cette approche diffère de l’ouverture d’un compte CEX suivie d’un retrait on-chain : le KYC du CEX reste interne et l’adresse on-chain demeure anonyme. Concordium vise à ce que chaque compte porte, dès sa création, une chaîne de responsabilité vérifiable.

Comment fonctionnent les Zero-Knowledge Proofs ? Quels attributs peuvent-ils prouver ?

Les Zero-Knowledge Proofs permettent à un utilisateur (« prover ») de démontrer à un vérificateur qu’une affirmation est vraie, sans révéler d’autres informations sensibles. Sur Concordium, il s’agit souvent d’attributs tels que : être majeur, résider dans un pays donné, être investisseur qualifié ou respecter un plafond d’autorisation.

Le processus comprend quatre étapes : l’Identity Issuer vérifie les justificatifs hors chaîne et inscrit les droits dans l’objet d’identité ; l’utilisateur génère localement un ZKP selon le besoin ; le vérificateur (contrat, app ou Agent) contrôle la validité de la preuve ; le résultat est un oui/non ou un seuil, sans jamais exposer le certificat d’origine sur la chaîne.

Le produit Verify and Access encapsule ces contrôles d’attributs dans des interfaces pour applications, permettant aux Agents ou frontaux d’obtenir des signaux d’autorisation avant d’accéder à des services restreints. Dans la comparaison Concordium vs Worldcoin, World ID vise « l’humain unique », alors que le ZKP de Concordium sert à vérifier la conformité ou l’éligibilité d’un compte.

Pour les entreprises, l’onboarding peut se limiter à un « compte vérifié + preuve d’attribut » sans créer un lac de données KYC. Pour les architectures d’Agents, des contrôles peuvent être insérés avant les appels d’outils, empêchant les Agents non vérifiés d’accéder aux API restreintes. Le cycle de vie de l’objet d’identité inclut mises à jour et révocation : en cas de changement de statut ou de politique, les justificatifs doivent être renouvelés ou invalidés, assurant une responsabilité évolutive.

Figure 1. Flux de preuve d’attribut à divulgation nulle de connaissance sur Concordium : de l’objet d’identité au résultat de vérification, aucune information personnelle d’origine n’est exposée sur la chaîne.

En quoi l’identité au niveau du protocole diffère-t-elle du KYC on-chain traditionnel ?

Le « KYC on-chain » est souvent assimilé, à tort, à l’enregistrement de noms ou numéros d’identification sur la blockchain. Concordium évite cela : seules la liaison d’identité et la capacité de vérification sont conservées, jamais les données personnelles. Comparatif :

Pour les écosystèmes RegTech et Agents, la différence est majeure : la validation repose sur des preuves cryptographiques et l’endossement de l’émetteur, pas sur la copie d’un formulaire centralisé. Les cas PayFi, stablecoin ou fonds tokenisés exigent souvent de vérifier l’éligibilité ou la juridiction sans exposer tout le profil — le couple identité protocolisée + ZKP est conçu pour une vérification minimale mais fiable.

Côté développeur, les applications ne manipulent pas directement de données KYC brutes : elles appellent Verify and Access ou des interfaces de preuve côté portefeuille pour obtenir une autorisation booléenne ou énumérée, puis décident d’autoriser ou non la transaction, l’appel d’Agent ou l’accès au contenu. Cela réduit la charge de conformité pour les frontaux et Smart Contracts, mais impose une logique claire : quelles actions requièrent quelles preuves.

Quels sont les avantages et limites de l’identité au niveau du protocole ?

Avantages : la conformité est contrôlée au niveau du protocole, ce qui réduit les intégrations répétées d’identité dans les applications ; le ZKP dissocie la preuve de conformité de l’exposition des données ; les comptes vérifiés servent de racine d’autorisation à l’Agent Registry. Pour l’entreprise, les audits se concentrent sur les comptes et les événements de preuve, évitant la distribution de données KYC brutes.

Limites : la qualité dépend de la couverture et des standards des Identity Issuers, avec des attributs différents selon les juridictions. La génération de ZKP repose sur le portefeuille local et le statut des justificatifs, ce qui complexifie l’utilisation par rapport à une adresse anonyme. En cas d’expiration des émetteurs ou justificatifs, les preuves doivent être renouvelées. L’identité au niveau du protocole ne résout pas à elle seule la fraude hors chaîne : elle vise la preuve et la responsabilité sur les interactions on-chain.

Enfin, elle ne dispense pas des audits off-chain : les régulateurs ou partenaires peuvent exiger des justificatifs auprès des émetteurs, mais ces documents n’ont pas à être publics sur la blockchain pour chaque interaction. Les projets doivent expliquer clairement leur fonctionnement pour éviter la confusion entre ZKP et « anonymat total ».

Résumé

L’identité au niveau du protocole sur Concordium relie chaque compte à une entité vérifiée, tandis que les Zero-Knowledge Proofs permettent de prouver des attributs sans exposer les données d’origine. Maîtriser ce modèle est indispensable pour explorer l’Agent Registry, Verify and Access et les usages PayFi.

FAQ

Qu’est-ce que l’identité au niveau du protocole Concordium ?

C’est le rattachement d’un compte Concordium à une personne physique ou morale validée par un Identity Issuer lors de la création. La chaîne conserve des objets d’identité et des références cryptographiques, jamais de données personnelles en clair. Cela garantit l’origine responsable des autorisations et permet la preuve d’attribut par ZKP.

Comment Concordium vérifie-t-il l’identité ?

Deux niveaux : off-chain, l’Identity Issuer réalise le KYC/KYB et émet l’objet d’identité ; on-chain ou via Verify and Access, les Zero-Knowledge Proofs générés par l’utilisateur sont vérifiés. Les vérificateurs reçoivent la conclusion sur l’attribut, jamais le certificat d’origine.

Comment les Zero-Knowledge Proofs protègent-ils la vie privée ?

Ils permettent de prouver qu’une condition est remplie, sans révéler les données sensibles requises pour la démonstration. Exemple : prouver la majorité sans divulguer la date de naissance. Concordium utilise ce mécanisme pour limiter l’exposition des PII on-chain en contexte de conformité.

Quel est le lien entre l’identité au niveau du protocole et les Agents ?

L’Agent Registry relie les Agents à des comptes Concordium vérifiés. L’identité protocolisée forme la racine de la chaîne de responsabilité : toute vérification d’Agent remonte à une partie autorisée validée par l’Identity Issuer. Sans cette couche, impossible de relier de façon fiable un Agent on-chain à une partie responsable réelle.

Quelles sont les limites de l’identité au niveau du protocole ?

Elles tiennent à la couverture des Identity Issuers, aux différences réglementaires locales, à la gestion des justificatifs et à la courbe d’apprentissage pour les portefeuilles ZKP. Cette identité gère la responsabilité et la preuve d’attribut on-chain, mais ne remplace pas les contrôles de risque ou les processus anti-fraude hors chaîne.