La tendance vers la Politique de confidentialité de la blockchain : les preuves à divulgation nulle de connaissance

ONEune des principales tendances du monde de la blockchain, notamment dans le domaine des services financiers et plus particulièrement des opérations sur les Marchés de capitaux, est le besoin de Politique de confidentialité et de respect de la vie privée dans le cadre des activités quotidiennes. C'est pourquoi les solutions blockchain sont conçues en tenant compte de ce besoin primordial. C'est ce qui explique le développement actuel de toutes les solutions blockchain privées.

Construire pour préserver la confidentialité implique des compromis. On perd principalement en transparence, caractéristique majeure de la première blockchain : Bitcoin. À l'origine, une blockchain est une machine à transparence. Dans ce système, les ordinateurs sont distribués et ONE entité ne contrôle le réseau. De plus, n'importe qui peut être validateur et lire ou écrire sur le réseau. Les clients et les validateurs peuvent être anonymes et toutes les données sont stockées localement sur chaque nœud (réplication). Cela rend toutes les données de transaction publiques.

La sécurité du Bitcoin repose sur un processus de vérification permettant à chaque participant de valider individuellement et de manière autonome les transactions. Bien que le Bitcoin résolve le problème de Politique de confidentialité en attribuant des adresses pseudonymes, il est toujours possible de découvrir l'identité de ces adresses grâce à diverses techniques.

C’est l’exact opposé de ce qui se passe dans le monde de la blockchain privée, où la décentralisation et la transparence ne sont pas considérées comme nécessaires pour de nombreux cas d’utilisation des Marchés financiers.

Ce qui compte, c'est la confidentialité, la latence (vitesse) et l'évolutivité (capacité à maintenir des performances élevées malgré l'ajout de nœuds à la blockchain). Les transactions chiffrées de nœud à nœud (n2n) impliquent que seules les deux parties impliquées reçoivent les données. Dans nombre de ces systèmes, des nœuds tiers (régulateurs) peuvent participer à la transaction.

D’autres systèmes sont en cours de développement à des fins similaires, qui ont étéécrit sur ce blog, disposent d' un générateur de blocs désigné qui collecte et valide les transactions proposées, les regroupant périodiquement dans une nouvelle proposition de bloc. Le consensus est assuré par un générateur qui applique les règles (validations) convenues par les nœuds (cœurs de la chaîne) au bloc et aux signataires de bloc désignés.

Dans ces systèmes, la décentralisation n'est tout simplement pas nécessaire, car tous les nœuds sont des parties connues. Dans les blockchains privées, les nœuds doivent être connus afin de satisfaire à certaines exigences réglementaires et de conformité. L'accent a été mis sur la préservation de la confidentialité tout en garantissant rapidité, évolutivité et stabilité du réseau. Par conséquent, il existe des recours juridiques, même entre des parties qui ne se font T nécessairement confiance.

Identification cryptographique solide et durable

Que sont la cryptographie et le cryptage ?

Comme indiqué précédemment, la Politique de confidentialité et la protection de la vie privée étant essentielles, le chiffrement est devenu un enjeu majeur pour toutes les blockchains. Nombre de ces solutions utilisent des techniques cryptographiques avancées offrant de solides garanties mathématiquement démontrables de Politique de confidentialité des données et des transactions.

Dans un article de blog récent intitulé «Un petit rappel sur le cryptage" par Kathleen Breitman de R3CEV, elle fournit succinctement une excellente définition de travail :

Le chiffrement désigne l'opération consistant à dissimuler du texte en clair, c'est-à-dire des informations à dissimuler. L'ensemble des règles de chiffrement du texte est appelé algorithme de chiffrement. Le fonctionnement d'un algorithme dépend de la clé de chiffrement, c'est-à-dire d'une entrée de l'algorithme contenant le message. Pour qu'un utilisateur obtienne un message à partir de la sortie d'un algorithme, il doit disposer d'un algorithme de déchiffrement qui, associé à une clé de déchiffrement, reproduit le texte en clair.

Si ce chiffrement utilise du texte chiffré pour déchiffrer ce texte en clair, on obtient un chiffrement homomorphe, qui (combiné aux techniques de signature numérique) constitue la base des techniques cryptographiques abordées dans cet article. Le chiffrement homomorphe permet d'effectuer des calculs sur des données chiffrées sans avoir à les déchiffrer au préalable. Autrement dit, cette technique préserve la Politique de confidentialité des données ou des transactions pendant les calculs, sans les révéler. Seuls les détenteurs des clés de déchiffrement peuvent accéder à la nature exacte de ces données ou transactions.

Le chiffrement homomorphe signifie que décrypter(crypter(A) + crypter(B)) == A + B. On parle alors d'homomorphisme sous addition.

Ainsi, un calcul effectué sur les données chiffrées une fois déchiffrées est égal à un calcul effectué sur les données chiffrées.

La question clé posée est la suivante :Comment convaincre un système d’un changement d’état sans révéler trop d’informations ?

Après tout, les blockchains souhaitent partager un (changement d') état, et non des informations. Sur une blockchain, un processus métier passe d'un état X à un état Y. Ce changement doit être enregistré et prouvé tout en préservant la Politique de confidentialité et en limitant le partage d'informations. De plus, ce changement d'état doit être légal, sous peine d'atteinte à la Politique de confidentialité .

Les techniques cryptographiques comme les preuves à divulgation nulle de connaissance (ZKP), qui utilisent différents types de chiffrement homomorphe, séparent :

1) parvenir à une conclusion sur un état de fait

2) les informations nécessaires pour atteindre cet état de fait

3) montrer que cet état est valide.

La suite de cet article abordera la manière dont la tendance à la Politique de confidentialité a conduit à l'utilisation de techniques cryptographiques, anciennes ou nouvelles, pour chiffrer les transactions et les données qui leur sont associées, à l'exception des parties concernées. L'accent sera mis sur les preuves à connaissance nulle, les SNARK zk, Hawk, les signatures confidentielles, les canaux d'état et le chiffrement homomorphe.

Le problème de Politique de confidentialité sur une blockchain est la principale lacune dans le déploiement de toutes les solutions cryptographiques évoquées ci-dessous.

En dehors de la blockchain, il existe des exemples concrets de chiffrement homomorphe. CryptDB est un exemple de système utilisant le chiffrement homomorphe et d'autres techniques de chiffrement préservant les attributs pour interroger des bases de données en toute sécurité. Il est utilisé en production chez Google et Microsoft, entre autres.

Il présente cependant des limites : il faut définir à l'avance les types de requêtes souhaitées et les fuites de données sont faciles. CryptDB assure la confidentialité du contenu des données et des noms de colonnes et de tables. Cependant, CryptDB ne masque pas la structure globale des tables, le nombre de lignes, les types de colonnes ni lestaille approximative des données en octetsONEune des méthodes utilisées par CryptDB pour chiffrer chaque élément de données est l'onioning. Cela permet de placer chaque élément de données dans des couches de chiffrement de plus en plus robustes.

Signatures confidentielles

Gregory Maxwell a conçu un outil cryptographique (CT) pour améliorer la Politique de confidentialité et la sécurité des blockchains de type Bitcoin. Il rend les montants transférés visibles uniquement aux participants à la transaction. Les CT rendent les montants et les soldes des transactions privés sur une blockchain grâce au chiffrement, notamment. cryptage additivement homomorpheLes utilisateurs peuvent consulter le solde de leurs propres comptes et les transactions qu'ils reçoivent. Des preuves à connaissance nulle sont nécessaires pour démontrer à la blockchain qu'aucune des sorties chiffrées ne contient de valeur négative.

Le problème avec les transactions confidentielles est qu'elles n'autorisent que des preuves très limitées comme mentionné ci-dessus. Les zkSNARK et les preuves à connaissance nulle (ZKP), qui seront décrits en détail ci-dessous, vous permettent de prouver pratiquement tous les types de validation de transaction tout en gardant toutes les entrées privées.

Preuves à connaissance nulle (ZKP)

Les preuves à connaissance nulle (ZKP) ne sont pas nouvelles. Elles ont été conceptualisées pour la première fois en 1985 dans un article intitulé « La complexité des connaissances des systèmes de preuve interactifs » (https://groups.csail.mit.edu/cis/pubs/shafi/1985-stoc.pdf). Une ZKP est une technique cryptographique qui permet à deux parties (un prouveur et un vérificateur) de prouver la véracité d'une proposition, sans révéler d'informations sur celle-ci, hormis sa véracité. Dans le cas des cryptomonnaies et des blockchains, il s'agit généralement de données transactionnelles.

Une preuve à connaissance nulle doit satisfaire trois propriétés :

• Exhaustivité : si l'affirmation est vraie, le vérificateur honnête (c'est-à-dire ONE qui suit correctement le protocole) sera convaincu de ce fait par un prouveur honnête.
• Solidité:si l'affirmation est fausse, aucun démonstrateur tricheur ne peut convaincre le vérificateur honnête qu'elle est vraie, sauf avec une faible probabilité.
• Connaissance zéro : Si l'énoncé est vrai, aucun vérificateur frauduleux n'apprend autre chose que ce fait. Ceci est formalisé en montrant que chaque vérificateur frauduleux dispose d'un simulateur qui, étant donné uniquement l'énoncé à prouver (et sans accès au prouveur), peut produire une transcription qui « LOOKS » à une interaction entre le prouveur honnête et le vérificateur frauduleux.

Les deux premiers sont des propriétés plus générales.systèmes de preuve interactifs. Le troisième est ce qui rend la preuve à connaissance nulle.

zk-SNARKs

Un zk-SNARK (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) est une preuve à connaissance nulle permettant de prouver un fait informatique relatif à des données sans les révéler. Les Zk-SNARK constituent l'outil cryptographique sous-jacent utilisé par Zcash et Hawk, qui construisent tous deux des blockchains avec des ZKP et seront expliqués ultérieurement. Dans le cas de Zcash, ces SNARK servent à vérifier les transactions et dans le cas de Hawk, à vérifier les contrats intelligents. Ceci tout en protégeant la Politique de confidentialité des utilisateurs.

Un zk-SNARK est une preuve de connaissance à divulgation nulle de connaissance, non interactive, concise et dont les preuves sont très courtes et faciles à vérifier. On peut les considérer comme de petits circuits logiques devant générer une preuve d'énoncé pour vérifier chaque transaction. Pour ce faire, ils prennent un instantané de chaque transaction, génèrent une preuve, puis doivent convaincre le destinataire que le calcul a été effectué correctement, sans révéler aucune donnée autre que la preuve elle-même. Le fonctionnement de base d'une exécution SNARK consiste en une entrée codée dans ce circuit, déchiffrable.

Les zk-SNARK étant vérifiables rapidement et les preuves étant courtes, ils peuvent protéger l'intégrité du calcul sans surcharger les non-participants. Il convient de noter que cette Technologies commence tout juste à mûrir, mais présente encore des limites. La génération de preuves est très gourmande en ressources processeur et peut prendre jusqu'à une minute pour en générer de nouvelles. La mise à l'échelle reste donc un problème à résoudre.

Les tout premiers points de données pour les zk-SNARK seront Zcash , qui est une combinaison d'état distribué et de preuve que vous possédez les actifs.

Zcash

Zcash peut être décrit comme un registre chiffré, ouvert, sans autorisation et répliqué. Il s'agit d'un protocole cryptographique permettant de stocker des données privées sur une blockchain publique. Zcash peut être considéré comme une extension du protocole Bitcoin . En effet, Zcash a ajouté des champs au format de transaction Bitcoin pour prendre en charge les transactions chiffrées.

Zcash utilise des SNARK (ZKP) pour chiffrer toutes les données et ne fournit les clés de déchiffrement qu'aux parties autorisées à y accéder. Jusqu'à présent, cela n'était pas possible sur une blockchain publique, car auparavant, si tout était chiffré, les mineurs ne pouvaient pas vérifier la validité des transactions. Les ZKP ont rendu cela possible en permettant au créateur d'une transaction de prouver sa véracité sans révéler l'adresse de l'expéditeur, l'adresse du destinataire et le montant de la transaction.

Zooko explique cela en expliquant que Bitcoin possède trois colonnes, correspondant aux trois mentionnées ci-dessus (adresse de l'expéditeur, adresse du destinataire, montant de la transaction) et Zcash quatre. La preuve de la quatrième colonne T connaît ni l'adresse de l'expéditeur, ni celle du destinataire, ni le montant transféré. Elle sait en revanche que personne n'aurait pu créer la preuve accompagnant les valeurs chiffrées sans une clé Secret suffisamment précieuse pour couvrir le montant de la transaction. Il s'agit d'une preuve que les données chiffrées satisfont correctement aux constructions de validité. Cela permet d'éviter les doubles dépenses et les transactions inférieures à zéro.

Zcash est globalement similaire à Bitcoin. Les mineurs et les nœuds complets sont des validateurs de transactions. Zcash utilise un système de preuve de travail (POW) qui permet aux mineurs de vérifier les ZKP associés à chaque transaction et d'obtenir une récompense pour la validation de ces transactions. Les nœuds complets sont identiques, sauf que si vous disposez des clés privées, vous pouvez détecter si certaines transactions contiennent de l' argent. Les SNARK permettent aux mineurs de rejeter une transaction si sa clé privée ne contient T suffisamment d'argent pour cette transaction.

En gardant toutes les données privées à l'exception de la 4ème colonne, Zcash évite que des informations ne fuient sur une blockchain privée qui permet à chacun de consulter les informations sur les transactions. transparence sélective Bitcoin impose une transparence obligatoire. Cela signifie que Zcash peut révéler des informations spécifiques à des personnes spécifiques, moyennant autorisation. Il révèle des transactions spécifiques que toute personne les consultant peut vérifier dans la blockchain.

Quelques différences par rapport à laLivre blanc Zcash inclure:

La valeur de Zcash est représentée par des billets, qui précisent un montant et une clé de paiement. La clé de paiement fait partie d'une adresse de paiement, qui est une destination vers laquelle les billets peuvent être envoyés. Comme dans Bitcoin, elle est associée à une clé privée permettant de dépenser les billets envoyés à cette adresse ; dans Zcash, on parle de clé de dépense.

Une adresse de paiement comprend deux clés publiques : une clé de paiement correspondant à celle des billets envoyés à l'adresse, et une clé de transmission pour un système de chiffrement asymétrique à clé privée. « Clé privée » signifie que les textes chiffrés ne révèlent pas la clé avec laquelle ils ont été chiffrés, sauf au détenteur de la clé privée correspondante, appelée ici clé de visualisation. Cette fonctionnalité permet de communiquer les billets chiffrés de sortie sur la chaîne de blocs à leur destinataire, qui peut utiliser la clé de visualisation pour scanner la chaîne de blocs à la recherche des billets qui lui sont adressés, puis les déchiffrer.

Les propriétés de Politique de confidentialité de Zcash reposent sur le principe suivant : lorsqu'un billet est dépensé, son détenteur prouve seulement qu'un engagement a été pris, sans révéler ONE. Cela implique qu'un billet dépensé ne peut être lié à la transaction qui l'a créé.

Zcash est un système de paiement anonyme décentralisé (DAP). Un DAP permet aux utilisateurs de se payer directement et en toute confidentialité : la transaction correspondante masque l'origine, la destination et le montant transféré du paiement.

Avec Zcash, les transactions pèsent moins de 1 Ko et leur vérification prend moins de 6 ms, soit des ordres de grandeur plus efficaces que Zerocoin, moins anonyme, et compétitifs par rapport à Bitcoin. Cependant, la Politique de confidentialité obtenue est nettement supérieure à celle obtenue avec Bitcoin. La désanonymisation des Bitcoin est devenue beaucoup plus facile grâce à des services qui suivent et surveillent Bitcoin mouvements et les données qui leur sont associées. Les services Mixer permettent de changer les cryptomonnaies au fur et à mesure de leur circulation dans le système via un organisme central, mais cela reste insuffisant.

Le Livre blanc ZcashÉtats :

Les mélanges présentent trois limites : (i) le délai de récupération des pièces doit être important pour permettre le mélange d'une quantité suffisante ; (ii) le mélange permet de tracer les pièces ; et (iii) le mélange peut voler des pièces. Pour les utilisateurs ayant « quelque chose à cacher », ces risques peuvent être acceptables. Mais les utilisateurs légitimes typiques (1) souhaitent KEEP leurs habitudes de consommation confidentielles, (2) sont réticents au risque et ne souhaitent pas déployer d'efforts constants pour protéger leur Politique de confidentialité, et (3) ne sont souvent pas suffisamment conscients de la compromission de leur Politique de confidentialité.

Les principales motivations des ZKP et du protocole Zcash sont 1) la Politique de confidentialité et 2) la fongibilité. La fongibilité permet de substituer des unités individuelles d'un bien ou d'une monnaie par une quantité équivalente. Cela peut poser un réel problème lorsque certaines unités de valeur sont jugées inférieures car jugées « sales ». Masquer l'historique des métadonnées T qu'une cryptomonnaie présentant un historique erroné soit rejetée par un commerçant ou une plateforme d'échange. Gregory Maxwell a déclaré : « Un manque de Politique de confidentialité peut également entraîner une perte de fongibilité – certaines pièces étant considérées comme plus acceptables que d’autres – ce qui compromettrait encore davantage l’utilité du Bitcoin en tant que monnaie. »

Zcash devrait lancement prochain Et avec cela, le bloc de genèse de la blockchain Zcash . Comme pour la blockchain Bitcoin , il permettra à quiconque dans le monde de miner du Zcash. Ce sera un système ouvert, sans autorisation (entièrement décentralisé). Les utilisateurs pourront l'envoyer à qui ils veulent, en utilisant la Politique de confidentialité à connaissance nulle.

L'utilisation par ZCash de techniques cryptographiques de pointe comporte des risques importants. Une attaque cryptographique permettant la falsification de preuves à divulgation nulle de connaissance permettrait à un attaquant de créer invisiblement une monnaie illimitée et de déprécier la valeur de Zcash. Des attaques de ce type ont été découvertes et corrigées récemment. Heureusement, les techniques de masquage des métadonnées utilisées dans Zcash sont plus robustes en production et peuvent être considérées comme moins risquées.

Faucon

Andrew Miller dans sonlivre blanc: "Hawk : Le modèle blockchain de cryptographie et les contrats intelligents préservant la confidentialité" a développé un système de contrat intelligent programmable qui fonctionne de la même manière que Zcash pour les contrats intelligents.

Hawk ne stocke pas les transactions financières sur la blockchain et préserve la confidentialité du code du contrat, des données envoyées au contrat et des fonds échangés et reçus par le contrat. Seules les preuves sont visibles, toutes les autres informations utiles étant masquées. Comme pour Zcash, la transparence est sélective dans Hawk et ne devrait T être utilisée par tous les contrats intelligents, mais dépend des cas d'utilisation et des préférences des parties concernées. Il vise également à résoudre les problèmes de Politique de confidentialité et de fongibilité, à l'instar du protocole Zcash .

Le livre blanc du Hawk décrit très bien la motivation de la sécurité contractuelle qu'il cherche à fournir pour les transactions financières :

Alors que la Politique de confidentialité sur la chaîne protège la Politique de confidentialité des parties contractantes du public (c'est-à-dire des parties non impliquées dans le contrat financier), la sécurité contractuelle protège les parties d'un même accord contractuel les unes contre les autres. Hawk suppose que les parties contractantes agissent égoïstement pour maximiser leurs propres intérêts financiers. En particulier, elles peuvent s'écarter arbitrairement du protocole prescrit, voire interrompre prématurément le contrat. Par conséquent, la sécurité contractuelle est une notion multidimensionnelle qui englobe non seulement les notions cryptographiques de confidentialité et d'authenticité, mais aussi l'équité financière en cas de tricherie et d'interruption.

Selon Andrew Miller, Hawk repose sur plusieurs primitives cryptographiques. Il utilise la même bibliothèque de preuve à divulgation nulle de connaissance que Zcash, appelée libsnark. Hawk utilise également des implémentations personnalisées d'une fonction de hachage basée sur un réseau et un chiffrement à clé publique. Hawk utilise un outil open source jSnark.

Dans Hawk, chaque partie génère ses propres clés Secret . Miller a déclaré :Pour chaque contrat, il existe également un paramètre public de confiance, similaire à Zcash. La seule façon de générer ces paramètres est un processus impliquant la génération d'une valeur Secret lors d'une étape intermédiaire, laquelle doit être effacée à la fin du protocole. Pour reprendre le terme de Zcash, il s'agit d'un « déchet toxique » issu de la procédure de configuration et, comme tout déchet industriel, il doit être éliminé de manière sécurisée. Il existe de nombreuses options… nous pourrions faire comme Zcash et utiliser un calcul multipartite pour générer ces paramètres, simplement confier cette tâche à un tiers de confiance (ce dernier n'étant utilisé qu'une seule fois et pouvant ensuite être déconnecté), ou utiliser un matériel de confiance comme SGX.

Miller a indiqué qu'il existe des différences entre les contrats Ethereum et les contrats Hawk. Contrairement à Ethereum, le langage d'entrée des contrats privés dans Hawk est le code C. Un contrat privé Hawk n'est pas un processus à état long comme un contrat Ethereum , mais plutôt un contrat à un coup qui se déroule par phases : il reçoit d'abord les entrées de chaque partie, puis calcule les sorties pour chaque partie. Une fois les sorties calculées, le contrat est terminé et ne présente plus de solde. Il s'agit donc d'un modèle de calcul légèrement différent. Hawk prend en charge les contrats privés, comme décrit ci-dessus, ainsi que les contrats publics, qui sont exactement comme ceux d' Ethereum. (Cependant, aucune garantie de Politique de confidentialité n'est fournie pour les contrats publics).

Comme pour Zcash, la mise à l'échelle de la blockchain et l'optimisation des schémas cryptographiques pour garantir leur efficacité lors de l'utilisation de ZKP posent certains défis. Hawk s'efforce d'effectuer autant de calculs hors chaîne que possible. En effet, dans les blockchains publiques, les calculs en chaîne sont répliqués sur chaque nœud, ce qui ralentit considérablement les opérations. Produire la preuve peut prendre plusieurs minutes (ce qui est long) et s'avérer coûteux. Les nœuds qui vérifient la preuve ne prennent que quelques millisecondes pour le faire. Données du livre blanc : dans Hawk, il faut environ une minute de temps CPU pour chaque participant à un contrat Hawk. Les calculs en chaîne prennent environ 9 à 20 millisecondes.

Hawk n'a pas encore annoncé de date de sortie car ils travaillent toujours sur l'optimisation de leurs outils de compilation snark pour améliorer les performances.

chaînes d'État

Les canaux d'état permettent des canaux de paiement hors chaîne et autorisent les mises à jour de tout type d'applications dont l'état change. À l'instar du Lightning Network, deux utilisateurs ou plus peuvent échanger des paiements qui nécessiteraient normalement une transaction blockchain sans avoir à les publier sur la blockchain ni à attendre de confirmation, sauf lors de la configuration ou de la fermeture du canal.

Vitalik Buterin explique cela dans son article pour R3CEV "Examen de la plateforme Ethereum"

« Les canaux d'état sont une stratégie qui vise à résoudre le défi de l'évolutivité en gardant le protocole de blockchain sous-jacent identique, en changeant plutôt la façon dont le protocole est utilisé : plutôt que d'utiliser la blockchain comme couche de traitement principale pour chaque type de transaction, la blockchain est plutôt utilisée uniquement comme couche de règlement, traitant uniquement la transaction finale d'une série d'interactions et exécutant des calculs complexes uniquement en cas de litige.

Les canaux d'état ne sont pas une solution parfaite ; en particulier, il est moins clair comment ils s'étendent aux applications multi-utilisateurs massives, et ils n'offrent aucune amélioration d'évolutivité par rapport à la blockchain d'origine en termes de capacité à stocker une grande taille d'état - ils augmentent uniquement le débit des transactions de facto.

Cependant, ils présentent un certain nombre d'avantages, dont le plus important est peut-être qu'en plus d'être une solution d'évolutivité, ils constituent également une solution de Politique de confidentialité , car la blockchain ne voit aucun des paiements ou contrats intermédiaires à l'exception du règlement final et des éventuels litiges, et une solution de latence, car les mises à jour des canaux d'état entre deux parties sont instantanées - beaucoup plus rapides que n'importe quelle solution directe sur blockchain, privée ou publique, pourrait l'être, et potentiellement même plus rapides que les approches centralisées, car les mises à jour des canaux de A à B peuvent être sécurisées sans passer par un serveur centralisé.

Les canaux d'État visent à résoudre les problèmes d'évolutivité, les problèmes de Politique de confidentialité et les délais de confirmation associés aux blockchains publiques tout en permettant aux acteurs qui ne se font T nécessairement confiance d'effectuer des transactions.

Avez-vous vraiment besoin d’une blockchain ? Un consensus est-il nécessaire ?

Pour beaucoup, toutes ces méthodes cryptographiques qui MASK l'intégralité des données transactionnelles peuvent surprendre. La blockchain est censée être un outil de transparence permettant à chacun de rejoindre le réseau et ainsi d'en consulter toutes les informations. Même les blockchains privées offrent une vue plus ouverte sur les données que les protocoles mentionnés dans cet article.

Une autre question qui pourrait venir à l'esprit est de savoir si le consensus est vraiment nécessaire, puisque tout est privé, sauf la preuve. Si la preuve n'est établie qu'entre les deux parties impliquées dans la transaction, pourquoi un consensus est-il nécessaire et pourquoi utiliser une blockchain publique ? Cela peut paraître paradoxal, mais la réponse est oui : une blockchain publique est nécessaire, tout comme le consensus, et cela est dû à la Politique de confidentialité des preuves. En substance, une transparence totale est nécessaire pour préserver la Politique de confidentialité des preuves.

Les ZKP et les blockchains se complètent. ONEun T remplacer l'autre. Une blockchain permet de garantir que l'ensemble du réseau s'accorde sur un état, chiffré ou non. Les ZKP permettent d'être sûr de certaines propriétés de cet état. Dans ce scénario, une source de vérité canonique est toujours nécessaire : une clé de vue qui révèle toutes les transactions entrantes, mais pas les transactions sortantes. Pour ce faire, un registre entièrement décentralisé, avec consensus, est nécessaire, où tous les acteurs s'accordent sur les données qui y sont enregistrées.

Par exemple, Zcash possède des données contenant des informations inutiles et illisibles pour la plupart des acteurs. Il s'agit d'une base de données d'engagements et de données opaques. Il s'agit simplement d'un moyen de synchroniser les données entre les acteurs. (Zooko Wilcox a déclaré publiquement que si Chainalysis réalisait un graphique, il ne s'agirait que d'une série d'horodatages indiquant le moment où une transaction a eu lieu.) Dans les cas où le nombre de transactions est faible, les attaques temporelles pourraient révéler l'origine des transactions, ce qui équivaut à un ONE nœud connecté à un réseau Tor.

L'accent est mis sur le portefeuille pour les acteurs, car il leur permet de dépenser de l'argent et de transférer des actifs. Avec Bitcoin, vous pouvez utiliser une clé privée pour transférer des Bitcoin. C'est désormais plus que cela. Il s'agit d'une clé privée et d'un ensemble de secrets que vous KEEP pour prouver les preuves précédentes et générer une nouvelle preuve que vous utilisez pour convaincre les autres. Pour cela, un registre entièrement décentralisé est nécessaire, avec un consensus où tous les acteurs sont d'accord sur les données qui y sont enregistrées.

Une blockchain est nécessaire car elle nécessite un consensus entre tous : il est nécessaire de disposer d'un accord sur les preuves dans le registre pour transférer des actifs ultérieurement. Si ces preuves ne sont T disponibles dans chaque nœud, il est T de convaincre quiconque de leur validité lors d'un transfert ultérieur. Ces preuves doivent être stockées de manière ouverte afin qu'elles puissent être considérées comme vérifiées et acceptées par les parties réceptrices.

Il y a deux niveaux différents : 1) Il faut un accord sur les preuves que tout le monde accepte 2) Il faut un accord sur ce que vous pouvez prouver et ce qui se passe en cas de preuve de connaissance nulle et ce qui se passe une fois que vous connaissez l'information.

Comment générer une preuve et transmettre cette information à la personne suivante ? La clé est d'obtenir l'autorité de la transaction en ajoutant une preuve ou des métadonnées à la transaction à l'aide d'un script conditionnel (instructions « if then » pour l'acceptation de la transaction). Ce code contient les règles de validité de la transaction. Une personne voit la preuve de l'extérieur, mais ne sait T si la règle elle-même a été déclenchée.

Maintenant que vous avez obtenu la Politique de confidentialité des ZKP, pour garantir la conformité de la transaction, vous devez prouver qu'elle respecte les règles. Vous pouvez donc créer deux preuves que la personne qui les reçoit pourra utiliser pour vérifier qu'elles sont acceptées par l'ensemble du réseau. Une fois que les preuves ont une signification pour vous, conformément aux règles, vous pouvez admettre qu'elles ont été prouvées par le passé et pourront être utilisées ultérieurement pour effectuer des transactions et transférer de l'argent.

Limites

Les ZKP sortent du cadre théorique pour devenir des outils de production. Il est temps de voir leur faisabilité. Ils commencent seulement à être testés à l'échelle mondiale et souffrent encore de gros problèmes d'évolutivité.

Développer une preuve est un travail colossal et engendre des coûts de calcul considérables. Comme mentionné précédemment, dans Zcash , créer une preuve pour transférer de l'argent d'un tiers prend entre 45 secondes et 1 minute sur un ordinateur très puissant. Des travaux sont actuellement en cours pour améliorer l'efficacité des SNARK et des ZKP en permettant d'obtenir davantage de preuves par seconde ou des preuves plus élaborées dans le même laps de temps.

Des changements profonds doivent être apportés au niveau architectural des DLT : comprendre la connaissance de l’architecture ZKP nécessite de comprendre les contraintes de ce que vous pouvez prouver et à quelle échelle.

Cet article a déjà été publié sur le site de l'auteur.bloget a été republié ici avec permission.

Déclaration de transparence:CoinDesk est une filiale de Digital Currency Group, qui détient une participation dans Zcash.

Image de serrures et de clésvia Shutterstock