Preuve de déclaration de clé à connaissance nulle – CoinGeek


Cet article a été publié pour la première fois sur Medium.

Le livre blanc nChain #0488 intitulé « Preuves de déclaration de clé à connaissance nulle » introduit une preuve à connaissance nulle (ZKP) qui prouve qu’une clé privée, correspondant à une clé publique donnée, satisfait à certaines exigences, tout en gardant la clé privée confidentielle. Nous l’avons implémenté et appliqué à l’achat d’une adresse de vanité bitcoin en toute confiance. Il peut être généralisé à un large éventail d’applications, où des informations secrètes peuvent être achetées entre des parties se méfiant mutuellement sans tiers de confiance.

Preuve de déclaration clé sans connaissance

Comme nous l’avons présenté précédemment, une preuve de connaissance zéro permet à une partie de convaincre une autre partie qu’elle connaît un secret validant une déclaration, tout en ne révélant pas le secret.

Une preuve de déclaration de clé à connaissance nulle (ZKKSP) est un type spécial de ZKP où le secret est une clé privée correspondant à une clé publique connue. La clé privée satisfait des contraintes supplémentaires, telles que le hachage à une valeur donnée.

Déclaration clé avec hachage
Déclaration clé avec hachage

Le livre blanc nChain présente une approche efficace pour ZKKSP. Par rapport aux preuves à connaissance nulle pour les déclarations générales telles que zk-SNARKS, ZKKSP bénéficie de plusieurs avantages saillants :

  1. ZKKSP ne nécessite pas de configuration de confiance, un problème dont souffrent certains zk-SNARKS (par exemple, basés sur l’appariement).
  2. La preuve d’instruction clé dans zk-SNARKS nécessite un circuit de multiplication de courbe elliptique, ce qui entraîne une génération de preuve extrêmement exigeante en termes de calcul et une taille de preuve excessivement grande du côté du prouveur. En revanche, ZKKSP supprime le circuit en :
  • Travailler dans la même courbe elliptique ECDSA que la clé publique est dans
  • Vérification de la cohérence entre la clé publique et le zk-proof généré ; en particulier, vérifier la cohérence par rapport aux engagements intégrés dans le zk-proof¹.

Dans ZKP, une déclaration/un calcul est généralement codé dans un circuit arithmétique, composé de portes d’addition et de multiplication. Comme le montre la figure 1, zk-SNARKS contient des sous-circuits pour une fonction de hachage et une multiplication de courbe elliptique. Le dernier circuit vérifie la cohérence par rapport à la clé publique ECDSA connue. ZKKSP utilise uniquement le circuit de hachage et supprime l’autre circuit, qui est au moins un ordre de grandeur plus grand que le premier. Les lecteurs intéressés peuvent se référer au livre blanc pour plus de détails, que nous omettons ici en raison de l’espace limité.

schéma d'un circuit composite pour l'énoncé 1 dans zk-SNARKS²
Figure 1 : schéma d’un circuit composite pour l’énoncé 1 dans zk-SNARKS²
schéma d'un circuit composite pour la déclaration 1 dans ZKKSP³
Figure 2 : schéma d’un circuit composite pour l’énoncé 1 dans ZKKSP³

Mise en œuvre

Nous forkons une bibliothèque existante appelée ZoKrates pour générer le circuit arithmétique pour SHA256. Après avoir modifié le format du circuit, nous implémentons le reste de la preuve d’instruction clé comme indiqué dans le livre blanc.

ZoKrates

ZoKrates⁴ est une boîte à outils pour zkSNARKs sur Ethereum. Il se compose d’un langage spécifique au domaine, d’un compilateur et de générateurs de preuves et de contrats intelligents de vérification. Vous trouverez ci-dessous un programme source écrit dans ZoKrates qui vérifie sha256(preimage) == h.

github-vérifier sha256
sha256.zok : vérifiez sha256(preimage) == h dans zokrate

Flux de travail

Le prouveur exécute les commandes suivantes de manière séquentielle pour générer une preuve.

Le prouveur génère une preuve
Le prouveur génère une preuve

Le prouveur envoie la preuve générée dans preuve.json au vérificateur. Le vérificateur exécute la commande suivante pour vérifier si la clé publique correspond à la valeur de hachage. Notez que cette preuve est non interactive et ne nécessite pas d’interaction entre le prouveur et le vérificateur, grâce à l’heuristique Fiat-Shamir.

Le vérificateur valide une preuve
Le vérificateur valide une preuve

Vous pouvez trouver le code complet sur notre Github.

Application : Génération d’adresses de vanité externalisée

Cette section décrit l’application de ZKKSP à l’externalisation de la génération d’adresses personnalisées Bitcoin.

Étant donné que la recherche d’une adresse personnalisée peut être coûteuse en calculs, il est courant que la recherche soit externalisée. Traditionnellement, soit l’acheteur obtient la valeur requise avant que le vendeur ne soit payé, soit le vendeur est payé avant de libérer la valeur requise, soit ils doivent tous les deux faire confiance à un service d’entiercement. En utilisant ZKKSP, la vente d’une adresse de vanité peut être rendue sans confiance.

nChaîne
Adresse du réseau principal Bitcoin avec motif de vanité « nChain »

Le protocole pour cela est détaillé comme suit.

  1. L’acheteur et le vendeur conviennent du modèle de vanité requis et du prix (en BSV), et établissent un canal de communication (qui n’a pas besoin d’être sécurisé).
  2. L’acheteur génère une clé secrète aléatoire sécurisée sk_Bet la clé publique de courbe elliptique correspondante pk_B = sk_B * G
  3. L’acheteur envoie pk_B au vendeur.
  4. Le vendeur effectue ensuite une recherche du modèle requis dans l’adresse codée en Base58 dérivée de pk = pk_B + i * Gen changeant je.
  5. Lorsqu’une adresse avec le modèle requis est trouvée, le vendeur enregistre la valeur, signale à l’acheteur et l’envoie pk_S = i * Get le hachage SHA256.
  6. Le vendeur fournit également un ZKKSP à l’acheteur dont la pré-image est la clé privée correspondant à pk_S.
  7. L’acheteur vérifie la preuve, et confirme également que l’adresse pk = pk_B + pk_Scorrespondant à correspond au modèle convenu. A ce stade (en vertu de la preuve), l’acheteur sait que l’apprentissage de la valeur je lui permettra de dériver la clé privée complète de l’adresse personnelle (sk_B + je), et cette valeur particulière est hachée pour h = H(i).
  8. L’acheteur construit ensuite une transaction de contrat à temps de hachage (HTLC) Tx_1qui contient une sortie qui contient les frais convenus. Cette sortie peut être déverrouillée de deux manières :
    je. Avec une signature du vendeur et la pré-image de hachage, je, à tout moment.
    ii. Avec une signature de l’acheteur après un délai déterminé (OP_CLTV⁶)
  9. L’acheteur signe ensuite et diffuse cette transaction dans la blockchain, où elle est extraite en bloc.
  10. Une fois confirmé, le vendeur peut réclamer les frais à la sortie de Tx_1 en fournissant une transaction Tx_2 fournissant leur signature et la valeur jepour déverrouiller le hash-lock, qui est ensuite révélé sur la blockchain.
  11. L’acheteur calcule la clé privée de l’adresse de vanité finale sk = sk_B + i, où pk = sk * G
  12. Si le vendeur ne fournit pas la valeur jeavant une heure OP_CLTV spécifiée, l’acheteur peut alors fournir sa signature pour récupérer les frais (pour éviter que les frais ne soient perdus en raison d’un acheteur non coopératif).

L’échange est entièrement atomique et sans confiance, ce qui signifie que l’acheteur n’est payé que s’il fournit une valeur secrète valide ?? qui est révélé publiquement sur la blockchain. De plus, la clé privée complète n’est même pas connue du vendeur, en raison du fractionnement de la clé privée.

Sommaire

Nous avons montré comment prouver une déclaration de clé, dans laquelle la clé privée secrète est hachée à une valeur donnée. Bien que primitif à première vue, ZKKSP est extrêmement puissant pour permettre de nombreux échanges équitables atomiques en deux étapes générales :

  1. Le vendeur prouve à l’acheteur en utilisant ZKKSP qu’il connaît un secret dont ce dernier a besoin et qu’il hache à une valeur donnée ;
  2. L’acheteur met en place un contrat intelligent qui ne paie que si la pré-image de hachage est fournie.

Notez que l’étape 1 est terminée hors chaîne et peut être gourmand en calculs, tandis que l’étape 2 est sur chaîne et extrêmement léger.

La même technique peut être appliquée pour exiger que la clé privée satisfasse à d’autres exigences (c’est-à-dire des circuits), telles que le début ou la fin d’un modèle donné.

***

[1] Ceux-ci peuvent être atteints soit avec un système de preuve non succinct pour la satisfiabilité du circuit, soit avec un SNARK basé sur un journal discret. Nous avons mis en œuvre le premier.

[2] Les portes internes sont uniquement à des fins d’illustration – les vrais circuits auraient des milliers de portes.

[3] Le circuit vérifie que la sortie du hachage est égale à la clé publique EC : les valeurs surlignées en bleu sont révélées au vérificateur, toutes les autres valeurs sont cryptées.

[4] ZoKrates — Calculs hors chaîne évolutifs préservant la confidentialité, 2018

[5] Les deux préimage et h sont divisés en deux parties, puisque le type de base champ ne peut pas accueillir 256 bits.

[6] « OP_CLTV » sur BSV

Remerciements

Il s’agit d’un travail conjoint entre nChain Limited et sCrypt Inc.

Regardez: Présentation de CoinGeek New York, Kensei: the Gateway to the Definitive Blockchain

Nouveau sur Bitcoin? Découvrez CoinGeek Bitcoin pour les débutants section, le guide de ressources ultime pour en savoir plus sur Bitcoin—comme envisagé à l’origine par Satoshi Nakamoto—et la blockchain.



Source de l’article

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *