Que sont les zk-SNARKs et comment permettent-ils la confidentialité sur les blockchains ?

Que sont les zk-SNARKs ?

Les zk-SNARKs sont des preuves cryptographiques qui permettent de démontrer qu’une information donnée ou qu’un calcul est correct, sans rendre publiques des informations sensibles. Ainsi, une blockchain peut par exemple vérifier qu’un paiement est valide, tandis que des données comme le montant ou le destinataire restent cachées. L’une des blockchains les plus connues qui utilise cette technologie est Zcash. Les zk-SNARKs y sont utilisés pour vérifier des transactions tout en laissant cachées des données comme le montant ou le destinataire.

Le nom zk-SNARK est l’abréviation de zero-knowledge succinct non-interactive argument of knowledge. Cela peut sembler complexe, mais on peut en décomposer simplement les éléments :

• Zero-knowledge : la preuve montre qu’une affirmation est vraie, par exemple qu’une transaction est valide, sans révéler d’informations sensibles comme l’adresse d’envoi, l’adresse de réception ou le montant de la transaction.
• Succinct : la preuve est courte. Un nœud ou un smart contract peut donc la vérifier relativement efficacement.
• Non-interactive : une fois la preuve créée, son auteur n’a pas besoin d’échanger à nouveau avec la personne qui la vérifie. La preuve peut être produite une seule fois, puis vérifiée.
• Argument of knowledge : l’auteur démontre qu’il dispose des informations nécessaires pour respecter les règles établies, par exemple les données permettant de créer une transaction valide. La sécurité repose ici sur des hypothèses cryptographiques : un attaquant disposant de ressources de calcul limitées ne peut pas, en pratique, produire une fausse preuve qui serait acceptée comme valide. Les informations utilisées pour créer la preuve sont souvent appelées la witness. Supposons que vous vouliez prouver que vous disposez d’un solde suffisant pour un paiement. La witness contient alors, par exemple, les données permettant de démontrer que vous avez assez de fonds et que vous êtes autorisé à les dépenser. La blockchain n’a pas besoin de voir ces données elle-même, mais elle peut vérifier que la preuve associée est valide.

En plus de la witness privée, un zk-SNARK peut aussi contenir des données d’entrée publiques. Il s’agit de données qui peuvent être visibles et que le vérificateur utilise avec la preuve pour contrôler si l’affirmation est correcte.

Point important à retenir : un zk-SNARK n’est pas un protocole unique et figé, mais un terme générique qui désigne plusieurs types de systèmes de preuve présentant ces propriétés. Leur fonctionnement précis peut varier d’un système à l’autre. Certains systèmes nécessitent par exemple un trusted setup, tandis que d’autres peuvent fonctionner sans une telle configuration.

À retenir

• Les zk-SNARKs prouvent qu’une chose est vraie sans révéler d’informations sensibles.
• Les données privées derrière une preuve sont souvent appelées la witness.
• Les preuves sont courtes et peuvent être vérifiées relativement efficacement.
• Une preuve publiée peut être vérifiée sans contact supplémentaire avec son auteur.
• Les zk-SNARKs constituent une catégorie de systèmes de preuve, et non un protocole unique.

Comment fonctionnent les zk-SNARKs ?

Dans un zk-SNARK, les règles auxquelles une transaction ou un calcul doit satisfaire sont d’abord transformées en contrôles qu’un ordinateur peut exécuter. Cet ensemble de contrôles est appelé un circuit ou un système de contraintes. Il indique précisément quelles conditions doivent être remplies pour qu’un élément soit considéré comme valide.

Prenons un paiement privé comme exemple. Le circuit peut par exemple vérifier qu’une personne dispose d’un solde suffisant, que ce solde n’a pas déjà été dépensé et qu’elle est autorisée à l’utiliser. Les données sensibles nécessaires à ces vérifications, comme le solde ou les informations permettant de le dépenser, restent cachées à la personne qui vérifie la preuve.

En grandes lignes, il y a trois étapes :

1. Setup Dans de nombreux zk-SNARKs classiques, des paramètres publics sont d’abord créés. Ces données sont nécessaires pour produire et vérifier les preuves.

2. Proof generation Le prover, c’est-à-dire la partie qui veut prouver quelque chose, utilise la witness et les règles du circuit pour produire une preuve cryptographique.

3. Vérification Le verifier, par exemple un nœud ou un smart contract, vérifie la preuve avec les données d’entrée publiques. Le verifier ne voit pas la witness privée et n’a pas besoin de refaire lui-même l’ensemble du calcul.

Un bon système zk-SNARK cherche à garantir trois propriétés importantes. Premièrement, la complétude : si l’affirmation est vraie et que la preuve est correctement produite, la preuve est acceptée. Deuxièmement, la soundness : un attaquant ne peut pas, en pratique, produire une preuve valide pour une affirmation fausse. Et troisièmement, le zero-knowledge : la preuve ne révèle aucune information sensible, si ce n’est le fait que l’affirmation démontrée est vraie.

Exemple : supposons que vous deviez prouver que vous avez plus de 18 ans, sans partager votre date de naissance. Un zk-SNARK peut en théorie prouver que vous remplissez cette condition, sans que le contrôleur voie votre date de naissance ni votre âge exact.

Il existe toutefois une limite importante. Un zk-SNARK ne vérifie que les règles définies dans le circuit. Si ces règles contiennent une erreur, une preuve peut être techniquement valide alors que le système autorise malgré tout quelque chose qui n’était pas prévu. La cryptographie ne peut donc pas corriger d’elle-même un circuit mal conçu.

À quoi servent les zk-SNARKs ?

Les zk-SNARKs sont utilisés lorsqu’une personne veut démontrer qu’un calcul a été exécuté correctement, sans rendre publiques toutes les données d’entrée ni les étapes intermédiaires. Cela rend la technique intéressante pour la confidentialité, mais aussi pour les cas d’usage où la personne qui vérifie la preuve n’a pas besoin de refaire tout le calcul.

Voici quelques applications connues :

• les paiements privés ;
• les applications dans lesquelles les données d’entrée ou certaines parties du calcul restent privées ;
• les preuves d’identité et de credentials, où vous prouvez une caractéristique sans partager toutes vos données personnelles ;
• la proof-of-reserves, où une partie peut démontrer que certaines réserves existent sans rendre publiques toutes les données sous-jacentes ;
• les validity rollups, qui traitent de nombreuses transactions en dehors d’Ethereum puis publient sur Ethereum une preuve du bon traitement.

Aleo utilise par exemple un modèle dans lequel un programme est exécuté localement. Ensuite, une preuve zero-knowledge est produite afin de démontrer que l’exécution était correcte. Les validateurs n’ont alors pas besoin de recevoir toutes les données d’entrée privées ni toutes les étapes intermédiaires, mais peuvent vérifier la preuve.

La confidentialité n’est pas automatique dès qu’un système utilise le terme « ZK ». Les données qui restent privées dépendent du protocole et de ce qui est défini comme privé ou public dans le circuit. Si certaines données de transaction sont volontairement rendues publiques, un zk-SNARK ne peut pas les masquer après coup.

Comment les zk-SNARKs soutiennent-ils la confidentialité ?

Les zk-SNARKs soutiennent la confidentialité parce qu’ils permettent de prouver qu’une transaction est valide sans révéler ses détails sensibles. Dans le cas d’un paiement privé, une personne peut par exemple prouver qu’elle dispose de fonds valides, qu’elle est autorisée à les dépenser et qu’elle ne dépense pas les mêmes fonds deux fois. L’expéditeur, le destinataire et le montant n’ont alors pas besoin d’être publics.

Zcash montre bien comment un tel modèle fonctionne. Un note y est utilisé pour enregistrer de manière privée une certaine quantité de ZEC. Sur la blockchain, on ne voit pas le contenu complet de ce note, mais un commitment : un engagement cryptographique correspondant. On peut le comparer à une enveloppe fermée et scellée. Tout le monde peut voir que l’enveloppe existe, mais pas ce qu’elle contient.

Les informations relatives au note sont chiffrées pour le destinataire. Lorsqu’un note est dépensé, un nullifier unique apparaît sur la blockchain. Ce nullifier ne révèle pas directement quel note a été dépensé, mais les nœuds peuvent vérifier si le même nullifier a déjà été utilisé. Le réseau peut ainsi empêcher la double dépense sans rendre publiques les données privées sous-jacentes.

La confidentialité ne signifie donc pas qu’aucune trace n’apparaît sur la blockchain. Les commitments et les nullifiers restent visibles. De même, des données comme les adresses IP, le timing, les métadonnées réseau et les informations qu’un utilisateur rend lui-même publiques ne sont pas automatiquement masquées par un zk-SNARK.

Comment les zk-SNARKs sont-ils utilisés pour la scalabilité ?

Pour la scalabilité, les zk-SNARKs peuvent être utilisés pour résumer une grande quantité de calculs dans une seule preuve compacte. C’est notamment le cas des validity rollups : les transactions sont traitées en dehors d’Ethereum, regroupées en lots, puis une preuve est produite pour montrer que le traitement s’est déroulé correctement.

L’opérateur d’un tel rollup traite les transactions et produit une validity proof qui démontre que le nouvel état a été calculé selon les règles du rollup. Un contrat de vérification sur Ethereum n’accepte ce nouvel état que si la preuve est valide. Ethereum n’a donc pas besoin de refaire tous les calculs de chaque transaction individuelle.

Avec la récursivité, ce processus peut être résumé encore davantage. Une nouvelle preuve peut alors démontrer que plusieurs preuves précédentes sont valides. Au final, de nombreux calculs ou preuves distincts peuvent être représentés par une seule preuve compacte.

Scroll utilise des preuves ZK pour démontrer l’exécution correcte de lots de transactions, puis la preuve peut être vérifiée sur Ethereum.

Mina utilise les zk-SNARKs récursifs d’une autre manière. Au lieu qu’un participant doive vérifier l’intégralité de l’historique de la blockchain depuis le début, la validité de l’état actuel de la blockchain peut être démontrée au moyen d’une preuve cryptographique compacte.

Une vérification rapide ne signifie pas que l’ensemble du processus est peu coûteux. La production d’une preuve peut au contraire demander beaucoup de puissance de calcul et de mémoire. En outre, une validity proof ne résout pas automatiquement d’autres problèmes, comme l’accessibilité des données, la censure par un opérateur ou les risques liés aux bridges entre blockchains.

Quelles blockchains et quelles cryptomonnaies utilisent les zk-SNARKs ?

Plusieurs projets crypto utilisent les zk-SNARKs, mais souvent pour des objectifs différents. La technique n’est donc pas utilisée uniquement pour les transactions privées.

• Zcash utilise les zk-SNARKs pour les transactions shielded. Dans le protocole Orchard, Halo 2 est utilisé pour prouver cryptographiquement ces transactions.
• Aleo utilise les zk-SNARKs pour des applications privées et programmables. Les programmes peuvent être exécutés localement, puis les validateurs vérifient la preuve d’exécution correcte sans avoir à voir les données d’entrée privées ni les étapes intermédiaires.
• Mina utilise des zk-SNARKs récursifs pour prouver de manière compacte la validité de l’état de la blockchain. L’objectif principal ici est la vérification compacte, et non la confidentialité automatique des transactions.
• Scroll utilise les zk-SNARKs dans son zkEVM pour prouver le traitement correct de lots de transactions. Ces preuves peuvent ensuite être vérifiées sur Ethereum.
• Ethereum prend en charge la vérification de certains zk-SNARKs basés sur les pairings via des precompiles. Cela permet aux smart contracts de vérifier des preuves zk-SNARK. Ethereum n’utilise pas lui-même les zk-SNARKs comme mécanisme de consensus général.

Attention à la différence entre un zk-SNARK et un zk-STARK. Les deux sont des systèmes de preuve cryptographiques qui peuvent prendre en charge le zero-knowledge, mais leur fonctionnement technique diffère. Les zk-STARKs n’ont généralement pas besoin de trusted setup, mais produisent souvent des preuves plus volumineuses que les zk-SNARKs. Un ZK-rollup n’est donc pas obligé d’utiliser un zk-SNARK.

Qu’est-ce qu’un trusted setup dans les zk-SNARKs ?

Un trusted setup est un processus unique au cours duquel, pour certains zk-SNARKs, des paramètres publics sont créés pour produire et vérifier les preuves. Ces paramètres sont souvent appelés structured reference string (SRS) ou common reference string (CRS).

L’élément sensible est l’information secrète aléatoire utilisée pendant cette configuration. On l’appelle aussi toxic waste. Si quelqu’un conserve cette information ou peut la reconstituer plus tard, cela peut, dans certains systèmes comme Groth16, être exploité en théorie pour produire de fausses preuves qui seraient tout de même acceptées comme valides.

C’est pourquoi certains projets utilisent une cérémonie de calcul multipartite. Plusieurs participants y ajoutent chacun leur propre aléa secret. Tant qu’au moins un participant agit honnêtement et détruit réellement sa contribution secrète, l’ensemble des informations secrètes de la configuration ne peut pas être reconstitué.

Cela réduit fortement le risque, mais signifie tout de même que l’on fait confiance au fait qu’au moins un participant n’a pas été compromis et a bien supprimé sa contribution secrète.

Tous les zk-SNARKs n’ont pas besoin d’un trusted setup. Zcash utilisait pour les anciens circuits Sprout et Sapling Groth16, qui nécessitaient un tel trusted setup. Le protocole Orchard plus récent utilise Halo 2 et n’a pas besoin d’un trusted setup avec toxic waste.

Quels sont les avantages des zk-SNARKs ?

Le grand avantage des zk-SNARKs est qu’ils permettent de concilier confidentialité et vérifiabilité. Vous pouvez prouver que vous respectez certaines règles sans rendre publiques les données sensibles derrière cette preuve.

Voici les principaux avantages :

• Confidentialité avec contrôle : les données sensibles peuvent rester cachées, tandis que les nœuds peuvent toujours vérifier qu’une transaction ou un calcul est valide.
• Preuves courtes : les preuves sont compactes par rapport au calcul qu’elles représentent.
• Vérification rapide : un nœud ou un smart contract n’a pas besoin de refaire tout le calcul.
• Contrôle public : une preuve peut être publiée puis vérifiée de manière indépendante.
• Résumé de nombreux calculs : avec des preuves récursives, plusieurs transactions, lots ou preuves antérieures peuvent finalement être résumés dans une nouvelle preuve compacte.

Sur Ethereum, certains zk-SNARKs basés sur les pairings peuvent aussi être vérifiés dans des smart contracts. Les applications peuvent ainsi faire vérifier sur Ethereum des preuves de calculs offchain ou des contrôles axés sur la confidentialité.

Point important toutefois : « court » et « efficace » décrivent surtout la taille de la preuve et sa vérification. Pour le prover, produire une telle preuve peut au contraire demander beaucoup de puissance de calcul et de mémoire.

Quelles sont les limites et les risques des zk-SNARKs ?

Les zk-SNARKs sont puissants, mais ils ne constituent pas une solution à tous les problèmes de confidentialité ou de scalabilité. La sécurité dépend de la cryptographie utilisée, du circuit et de la manière dont le système est intégré dans une blockchain ou une application.

Un risque important pour les systèmes qui dépendent d’un trusted setup est l’information secrète de configuration. Si la toxic waste d’une configuration Groth16, par exemple, tombe entre de mauvaises mains, des attaquants peuvent potentiellement produire de fausses preuves qui seraient tout de même acceptées comme valides. Dans une architecture de paiement privé, cela pourrait, dans le pire des cas, conduire à la création de soldes qui n’auraient pas dû exister selon les règles normales.

Par ailleurs, un zk-SNARK ne prouve que le respect des règles du circuit. Des erreurs dans le circuit, le code du prover, le code du verifier, les paramètres utilisés ou l’intégration avec une blockchain peuvent donc avoir de graves conséquences. Une preuve cryptographiquement correcte n’aide pas si les règles sous-jacentes sont mal conçues.

La confidentialité a aussi ses limites. Dans les transactions shielded de Zcash, par exemple, les commitments et les nullifiers restent visibles sur la blockchain, tandis que les informations relatives aux notes restent chiffrées. En outre, les données publiques, le timing, les adresses IP et d’autres métadonnées réseau peuvent parfois malgré tout révéler des informations ou rendre des liens visibles.

Dans les zk-rollups, un autre problème se pose. Une validity proof peut démontrer qu’un lot a été traité correctement, mais elle n’empêche pas automatiquement un opérateur de retarder des transactions ou de censurer des utilisateurs. Les risques liés aux bridges et à l’accessibilité des données restent également présents.

Enfin, le zero-knowledge ne signifie pas automatiquement qu’un système résiste à de futures attaques quantiques. Cela dépend de la construction cryptographique concrète. Les zk-SNARKs classiques basés sur les pairings utilisent des hypothèses cryptographiques différentes de celles, par exemple, des systèmes STARK transparents.

En résumé

Les zk-SNARKs permettent de prouver qu’une transaction ou qu’un calcul est correct, sans révéler les données sensibles qui se trouvent derrière. Ils sont donc intéressants pour les paiements privés, les applications axées sur la confidentialité et la scalabilité via les validity rollups. Zcash est l’un des exemples les plus connus de blockchain qui utilise les zk-SNARKs pour permettre des transactions shielded.

L’idée centrale est relativement simple : une blockchain ou un autre verifier n’a pas besoin de voir toutes les données sous-jacentes ni de refaire tout le calcul, tant qu’il peut vérifier une preuve cryptographique valide. Le niveau de confidentialité et de sécurité obtenu dépend toutefois de la conception du système. En fin de compte, un zk-SNARK n’est fiable qu’à la hauteur du circuit, de la cryptographie utilisée et de l’intégration qui l’entoure.