Comment fonctionne zkPass ? 3P-TLS + ZK hybride pour créer un Oracle Machine à connaissance nulle.

zkPass est un protocole d'oracle qui permet la vérification des données Internet privées sur la blockchain. zkPass est construit sur zkTLS, qui est composé de 3P-TLS et de technologies ZK hybrides, et fournit des outils et des applications pour un partage de données sécurisé et vérifiable, garantissant la confidentialité et l'intégrité des données provenant de n'importe quel site HTTPS, sans nécessiter d'API OAuth.

zkPass comment ça fonctionne ? Architecture globale et concepts clés

Comment fonctionne zkPass ? Pour comprendre son architecture, il est nécessaire de connaître trois rôles clés : P (Preuveur/Individu), V (Vérificateur/Commercial/Nœud zkPass), S (Serveur TLS/Source de données). Dans le processus de validation des données traditionnel, le preuveur soumet des informations au vérificateur, qui extrait ces données et collabore avec la Source de données pour effectuer des vérifications de validation. Ce modèle présente trois problèmes majeurs : le preuveur risque de divulguer trop d'informations personnelles ; bien que la source de données soit fiable, elle ne peut pas fournir de services de validation personnalisés ; le vérificateur détient toutes les données personnelles des clients, ce qui pose un risque potentiel de fuite de données considérable.

zkPass propose une solution révolutionnaire qui positionne le prouveur entre le validateur et la source de données. Contrairement aux méthodes traditionnelles, le prouveur utilise ses jetons d'accès pour localiser et récupérer directement les données de la source de données, puis génère une preuve à divulgation nulle de connaissance (ZKP) pour que le validateur puisse l'examiner. Ce processus garantit que le validateur ne connaît toujours pas les informations personnelles du prouveur. Cette architecture intègre 3P-TLS, MPC (calcul multipartite) et des technologies ZK (à divulgation nulle de connaissance) hybrides.

Composants technologiques clés :

3P-TLS : sécurité de la couche de transport à trois parties basée sur le protocole DH à courbe elliptique, combinant MPC et le transfert oblivieux (OT) pour prévenir la tricherie.

Mélange ZK : Système de preuve à deux niveaux combinant ZK interactif (VOLE-ZK 23) et ZK non interactif (SNARK/Circom)

zkSBT : un jeton lié à l'âme basé sur la norme NFT ERC998, stockant les déclarations principales et les déclarations de requête.

3P-TLS et MPC : percée technologique de la poignée de main à trois parties

La première clé de fonctionnement de zkPass repose sur le protocole 3P-TLS. La sécurité de la couche de transport (TLS) est le protocole de communication sécurisé de HTTPS, pris en charge par presque toutes les sources de données. zkPass a construit le protocole 3P-TLS basé sur le protocole DH à courbe elliptique et l'a combiné avec MPC et Oblivious Transfer pour réaliser une communication sécurisée à trois parties.

Phase 1 : La poignée de main entre P, V et S génère conjointement une clé de session, P et V obtiennent chacun une part de ces clés. Cela est réalisé à l'aide de l'algorithme de cryptage Paillier, qui offre l'homomorphisme d'addition. La clé maîtresse préliminaire est divisée en deux parties, P et V reçoivent chacune la moitié, tandis que S conserve la clé maîtresse préliminaire complète. Afin d'empêcher le client de falsifier de faux sites Web, le client demandera au serveur de retourner le certificat, garantissant ainsi la confiance dans la source des données.

Deuxième étape : Échange de clés et calcul MPC avec P et V pour créer la clé de chiffrement (enc_key) et la clé de code d'authentification des messages (mac_key). La conception clé réside dans le fait que V ne possède qu'une partie de la mac_key et n'a pas d'enc_key, ce qui garantit que V ne peut pas accéder aux informations personnelles de l'utilisateur. En revanche, P détient une partie de la mac_key, pouvant accéder à des informations d'identité spécifiques mais ne pouvant pas les modifier ; toute modification peut être détectée en vérifiant l'authenticité du message via la mac_key.

Troisième étape : Préparation des données d'application pour le TLS standard et le ZKP. Le protocole de communication suit le protocole TLS standard, P et V échangent des clés pour se préparer à la phase impliquant la preuve à connaissance nulle. L'algorithme MPC de zkPass a subi des optimisations significatives en termes de temps de communication, de fonctions de hachage et d'opérations mémoire, avec une augmentation de l'efficacité de plus de trois fois. En adoptant une nouvelle méthode de preuve AES128, le nombre de blocs a été réduit de 300 fois, et le temps d'exécution de Garbler/Evaluator a été multiplié par dix. Plus précisément, zkPass utilise le Silent OT pour les opérations OT, réduisant la taille des circuits de brouillage grâce à la GC empilée, ce qui réduit considérablement le temps d'exécution de l'ensemble du processus MPC.

Mélange ZK : La combinaison parfaite entre interactif et non interactif

Le deuxième aspect clé du fonctionnement de zkPass réside dans l'approche mixte des connaissances nulles. La dernière étape du protocole zkPass implique que le client génère une preuve de connaissance nulle, que le contrat intelligent sur la blockchain vérifie. Cette approche mixte combine les avantages des protocoles ZK interactifs et non interactifs.

Connaissance Zéro Interactive (IZK) : Le zkPass VOLE-ZK 23 utilise un protocole ZK interactif basé sur VOLE pour l'authentification, garantissant que les données proviennent de sources précises et les protégeant contre la falsification côté client. Le protocole VOLE-ZK 23 est un cadre de “soumission et preuve”, où le prouveur (P) et le vérificateur (V) génèrent ensemble un grand nombre d'instances VOLE, chaque instance satisfaisant la formule linéaire “m = k + w * delta”. P soumet certains composants de cette formule comme engagement, tandis que V comprend les autres composants.

Cette linéarité est la raison clé pour laquelle la solution est rentable, la distinguant des autres solutions polynomiales de haut degré comme SNARK. P n'a besoin de transmettre que deux éléments de champ au vérificateur, puis V utilise ses paramètres VOLE pour vérifier la pertinence. Cette étape comporte cinq principales restrictions, garantissant que les demandes sont chiffrées à l'aide de clés cryptographiques, qu'elles doivent être générées à l'aide du jeton d'accès de l'utilisateur, que l'utilisateur doit posséder la clé cryptographique pour déchiffrer la réponse, que l'utilisateur ne peut pas modifier la réponse, et que les données de réponse doivent respecter les conditions spécifiques énoncées dans le modèle.

La technologie d'optimisation zkPass a subi plusieurs optimisations pour améliorer l'utilité du protocole. L'introduction de SoftSpoken réduit d'environ 50 % les frais de réseau et accélère la génération de VOLE. En utilisant les propriétés d'homomorphisme additif de VOLE, les engagements des portes XOR et INV sont réduits à zéro. Pour les cas d'utilisation spécifiques impliquant les mêmes opérations, les paramètres VOLE peuvent être réutilisés, transformant les opérations de multiplication en opérations d'addition, ce qui est appelé “entrée de signal de données multiples”, similaire à l'architecture CPU SIMD.

La preuve non interactive à connaissance nulle (NIZK) passe ensuite de la preuve interactive à la preuve NIZK, avec pour objectif de masquer le modèle de gabarit réel, permettant aux utilisateurs de divulguer sélectivement des preuves pour une validation publique par toute partie. Utilisation du cadre SNARK, en particulier Circom. Une fois que le client a réussi à passer la vérification IZK, le nœud fournira une signature pour le résultat, le client insérera le résultat et sa signature associée dans l'arbre de Merkle et mettra à jour la racine dans le contrat SBT. Lorsque le client a besoin de prouver le résultat, il suffit de fournir une preuve à connaissance nulle, prouvant que le résultat est une feuille dans l'arbre de Merkle et qu'il a déjà été signé par le nœud.

zkSBT : système de jetons liés à l'âme combinables

Le troisième élément clé du fonctionnement de zkPass réside dans l'architecture zkSBT. zkPass adhère à la norme ERC998, une norme NFT composable. tSBT représente des catégories telles que l'identité légale, les réseaux sociaux et les informations financières, tandis que dSBT contient les certificats réels revendiqués par l'utilisateur. Ces déclarations se déclinent en deux types : déclarations principales et déclarations de requête.

Les principales réclamations concernent l'obtention par les utilisateurs de leurs données personnelles à partir de sources de données après l'exécution de MPC, telles que le pays/région, l'âge, le sexe et d'autres informations provenant de sites gouvernementaux. En fonction de ces données, un arbre de réclamation est construit, chaque nœud représentant la valeur de hachage de ses nœuds enfants. Une signature babyjub est utilisée pour ajouter un nombre aléatoire afin de prévenir les attaques détaillées, et la racine du hachage de l'arbre principal de déclaration est stockée dans le dSBT, qui doit être générée par un contrat intelligent et vérifiée par une preuve à connaissance nulle de la validité de l'arbre.

Concernant la déclaration de la requête, par exemple pour déterminer si l'âge de l'utilisateur est supérieur à 18 ans, l'utilisateur doit simplement fournir une preuve, dont la feuille représentant son âge est incluse dans la structure arborescente, et la valeur de cette feuille est supérieure à 18. L'utilisateur peut transmettre directement cette preuve au vérificateur, qui peut exécuter une fonction en chaîne pour valider la preuve. Cela garantit que les données privées réelles de l'utilisateur restent cachées pour toutes les parties concernées, seules les déclarations de la requête de données étant révélées de manière sélective à des vérificateurs spécifiques.