Les Zk-SNARK se sont révélés être un « couteau suisse » pour la blockchain et les registres distribués, avec des applications en matière de confidentialité, d’interopérabilité et d’évolutivité.
Depuis leur introduction, les preuves à connaissance nulle (ZKP) ont été utilisées pour prendre en charge des applications potentielles allant du calcul externalisé vérifiable aux informations d’identification anonymes, dans une multitude de paramètres qui nécessitent un équilibre entre confidentialité et intégrité. Les ZKP permettent à une partie de prouver à une autre qu’une certaine déclaration ou affirmation est vraie, sans en révéler le contenu. L’application des ZKP dans une variété de cas d’utilisation en chaîne contribue à résoudre les problèmes de confidentialité, d’interopérabilité et d’évolutivité.
Dans cet article, nous examinons les différents types de ZKP et leurs cas d’utilisation spécifiques. Nous discutons également des zk-SNARK, de certains problèmes connus dans son application, et proposons un mécanisme blockchain avec des caractéristiques sécurisées dans des conditions comparables à celles du protocole blockchain. L’article est basé sur le document de recherche « Mining for Privacy: How to Bootstrap a Snarky Blockchain » rédigé par Thomas Kerber, Aggelos Kiayias et Markulf Kohlweiss.
Différents types de ZKP
Dans le cadre de la blockchain, il est courant que les clients téléchargent et vérifient chaque transaction publiée sur le réseau. Cela signifie que des preuves de petite taille et un temps de vérification rapide sont importants pour le déploiement pratique de protocoles à connaissance nulle. Il existe plusieurs schémas pratiques parmi lesquels choisir, avec un vaste espace de compromis en termes de performances et d’hypothèses cryptographiques :
- Arguments non interactifs à connaissance nulle (NIZK) : c’est le concept le plus général. NIZK peut être non succinct mais, comme avantage, il peut s’appuyer sur des hypothèses cryptographiques standard et satisfaire souvent à de solides garanties de sécurité.
- Arguments succincts non interactifs à connaissance nulle (SNARG) : atteindre la concision au prix d’hypothèses cryptographiques plus fortes et de garanties de sécurité souvent plus faibles.
- Arguments de connaissance succincts et non interactifs à connaissance nulle (SNARK ou parfois zk-SNARK) : ce sont des SNARG qui sont aussi des preuves de connaissance et de connaissance nulle. Le nom est également populaire en raison du poème absurde de Lewis Carrol « La chasse au Snark ».
- Arguments de connaissance transparents et succincts (STARK) : transparent fait ici référence à la configuration ne nécessitant qu’une fonction de hachage fiable. Ceci est bénéfique mais peut entraîner une surcharge en termes de performances.
Actuellement, le système de preuve le plus attrayant du point de vue du vérificateur est un argument de connaissance succinct non interactif (prétraitement), ou zk-SNARK en abrégé, qui a une petite taille de preuve constante et des coûts de vérification à temps constant, même pour des preuves arbitrairement grandes. rapports. Les Zk-SNARK se sont révélés être un « couteau suisse » pour la blockchain et les registres distribués, avec des applications en matière de confidentialité, d’interopérabilité et d’évolutivité.
Cas d’utilisation
Les cas d’utilisation des zk-SNARK sont très divers. Parfois, les SNARK sont utilisés pour améliorer les performances et les propriétés de concision du système. D’autres cas d’utilisation utilisent des zk-SNARK pour améliorer la confidentialité. Certains cas sont mixtes, où les deux aspects jouent un rôle.
Dans le cadre de la blockchain, en tenant compte des performances et de la concision, zk-SNARKS peut grandement contribuer à des cas d’utilisation tels que :
- Clients légers : pour améliorer l’efficacité des paramètres et la structure globale des applications. Des systèmes de preuve efficaces (sans exigence de connaissance nulle) jouent un rôle important dans le démarrage des clients légers. Les systèmes de preuve récursive conviennent également parfaitement à ce cas d’utilisation pour garantir la sécurité d’une récursion illimitée ainsi que l’utilisation de fonctions externes (par exemple, des fonctions de hachage) dans les preuves récursives.
- Contrats intelligents : pour soulager une éventuelle congestion du grand livre en raison de l’exécution de contrats intelligents publics. La compilation de code en chaîne vers les SNARK, avec un temps de vérification constant ou logarithmique, peut permettre des validateurs plus complexes.
- Preuve de travail utile (PoUW) : les SNARK peuvent être la clé pour vérifier les « calculs utiles » effectués par les mineurs, dont la validation en chaîne serait autrement coûteuse.
Du point de vue de la confidentialité, de nombreuses applications utilisent des preuves de connaissance nulle pour déployer des solutions de paiement sécurisées, échanger des options, gérer les identités, voter, enchères, statistiques vérifiables (une forme d’oracle blockchain) ou encourager la communication anonyme. Les cas d’utilisation peuvent inclure :
- Contrats intelligents privés : les SNARK font partie intégrante de la conception actuelle des contrats intelligents privés. Deux choses sont primordiales : l’universalité, pour prendre en charge les contrats intelligents déployés par les utilisateurs, et la facilité de compilation. L’expressivité des contrats intelligents peut être éliminée pour réduire l’espace du problème, par exemple en interdisant les boucles illimitées et la récursion afin que la composition SNARK récursive ne soit pas nécessaire. Fondamentalement, un sous-ensemble d’un langage contractuel de haut niveau peut être compilé dans un circuit SNARK.
- Paiements privés : les actifs peuvent être considérés comme une forme particulière de revendication identitaire qui inclut la modélisation de la rareté. Une proposition de paiements privés peut également prendre en charge des jetons multi-actifs et non fongibles, et connecter ces jetons à des contrats intelligents.
- Gestion des identités : dans le contexte d’informations d’identification vérifiables, les émetteurs peuvent faire valoir des réclamations sur des sujets en générant des objets cryptographiques (informations d’identification). Les sujets présentent ensuite leurs informations d’identification à d’autres utilisateurs qui agissent en tant que vérificateurs. Les vérificateurs sont alors en mesure de valider qu’un émetteur a fait valoir des allégations concernant le sujet présentant le titre d’identification.
- Vote et trésorerie : les preuves ZK peuvent être utilisées lors du vote de trésorerie. Un protocole de système de trésorerie pour les crypto-monnaies , par exemple, fournit un système de vote préservant la confidentialité, dans lequel les bulletins de vote des électeurs sont cryptés puis comptabilisés à l’aide de calculs homomorphes. Les preuves ZK dans le trésor sont des protocoles Sigma non interactifs basés sur DLP utilisés pour prouver l’exactitude des messages cryptés à différentes étapes du protocole (par exemple, que le bulletin de vote crypté de l’électeur contient un bulletin de vote correctement composé).
Les cas d’utilisation mixtes incluent :
- Oracles blockchain : les SNARK peuvent réduire le coût de vérification lors de l’agrégation de données provenant de plusieurs sources, et ils peuvent réduire la taille des données en chaîne publiées en incluant uniquement la valeur agrégée et la preuve, au lieu de tous les points de données. Pour atteindre ces deux propriétés, les parties doivent être capables de prouver succinctement la connaissance des signatures sur un certain nombre de points de données ainsi que la moyenne/médiane/variance respective.
- Sidechains : une chaîne dans une configuration de rattachement de chaîne peut agir comme un client léger envers l’autre chaîne, vérifiant les transactions inter-chaînes sur l’autre chaîne sans avoir à vérifier l’intégralité de cette chaîne. La différence est que ce rattachement est souvent maintenu à long terme, et ainsi les preuves peuvent être fournies régulièrement et de manière « actualisable ». Voir Preuve de participation Sidechains pour plus d’informations.
Problèmes connus
La connaissance zéro non interactive nécessite un certain caractère aléatoire partagé ou une chaîne de référence commune. Pour de nombreux systèmes succincts, une propriété plus forte est nécessaire :
Non seulement une valeur aléatoire partagée est nécessaire, mais elle doit également adhérer à une structure spécifique. Une chaîne de référence structurée (SRS) se compose généralement d’éléments de groupe associés, c’est-à-dire : g x i pour tout i∈𝕫 n .
La manière évidente d’échantillonner une telle chaîne de référence à partir du hasard public révèle les exposants utilisés – et la connaissance de ces valeurs brise la solidité du système de preuve lui-même. Pour aggraver les choses, la sécurité de ces systèmes repose généralement (entre autres choses) sur la connaissance des hypothèses sur les exposants, qui stipulent que pour créer des éléments de groupe liés de cette manière, il faut connaître les exposants sous-jacents, et par conséquent tout échantillonneur SRS devra « connaître » les exposants utilisés et être fiable pour les effacer, devenant ainsi un point de défaillance unique pour le système sous-jacent.
Le calcul multipartite sécurisé (MPC) peut être, et a été, utilisé pour réduire la confiance placée dans un tel processus de configuration. Cependant, la sélection des participants au calcul sécurisé et la vérification de la génération du SRS par le protocole MPC conservent un élément de centralisation. L’utilisation de MPC reste un élément controversé dans la mise en place d’un système décentralisé nécessitant des SNARK.
Résoudre les problèmes de confidentialité grâce à la génération sécurisée de SRS
Une chaîne de référence structurée pouvant être mise à jour (uSRS) peut être initialisée en toute sécurité à l’aide d’un grand livre distribué en exigeant que les créateurs de blocs effectuent des mises à jour sur un uSRS évolutif pendant une période de configuration initiale. Après avoir attendu un accord sur l’uSRS final, il peut être utilisé en toute sécurité.
La preuve en est basée sur les moyens de fonctionnement de base des registres de style Nakamoto : différents utilisateurs peuvent étendre une chaîne de blocs s’ils peuvent satisfaire une certaine condition, cette condition étant associée à un type de dureté qui garantit que les attaquants sont limités dans le nombre de blocs. extensions qu’ils peuvent effectuer. Étant donné une telle structure, nous associons une mise à jour uSRS à chaque bloc avant un instant 𝛿 1 . Ce moment est choisi de telle sorte que les propriétés de sécurité du grand livre garantissent qu’au moins un des blocs est honnête dans chaque chaîne concurrente à ce stade.
Cela peut être construit à partir d’une fonctionnalité de grand livre avec un état de leadership supplémentaire, dérivé des informations que les mineurs intègrent dans leurs blocs pour coder les mises à jour uSRS. Ceci reste suffisamment général pour permettre également d’autres utilisations. L’idée de base est de montrer qu’un registre qui effectue des mises à jour uSRS dans son état de leadership est équivalent à celui qui ne le fait pas, mais est accompagné d’un uSRS sécurisé. Après le temps 𝛿 1 , les utilisateurs attendent une période supplémentaire 𝛿 2 jusqu’à ce que le préfixe commun garantisse que toutes les parties sont d’accord sur la chaîne de référence.
Abstraction du grand livre proposée
Notre construction de la fonctionnalité de chaîne de référence structurée pouvant être mise à jour repose sur les propriétés du préfixe commun , de la qualité de la chaîne et de la croissance de la chaîne définies dans l’analyse du squelette Bitcoin par Garay et al., pour les algorithmes de consensus de style Nakamoto :
- Préfixe commun . Étant donné les chaînes actuelles 𝛱 1 et 𝛱 2 de deux partis, et en supprimant k blocs du premier, c’est un préfixe du second : 𝛱 1 ⌊k ≺𝛱 2 .
- Qualité de la chaîne existentielle . Pour la chaîne actuelle 𝛱 de n’importe quel parti, tous les blocs l consécutifs dans cette chaîne incluront au moins un bloc créé par un parti honnête.
- Croissance de la chaîne . Si la chaîne d’un correspondant est de longueur c , alors s créneaux horaires plus tard, elle aura au moins une longueur c+𝛾 .
Construction décentralisée de l’uSRS
La construction que nous proposons, détaillée dans l’article Mining for Privacy , est simple : chaque chaîne est associée à un uSRS spécifique, et lorsqu’un mineur étend une chaîne, il effectue en outre une mise à jour uSRS. Lors de la genèse de la chaîne, le caractère aléatoire connu (ou même l’absence de caractère aléatoire) peut être utilisé. Le principe derrière cette conception est simple : la possibilité de mise à jour de l’uSRS garantit que si une seule mise à jour est effectuée de manière honnête (à la fois en utilisant un véritable caractère aléatoire et en effaçant ce caractère aléatoire après la mise à jour), l’uSRS résultant peut être utilisé en toute sécurité. Nous nous appuyons sur la propriété de qualité de la chaîne existentielle pour garantir cela – une fois que les blocs ont été générés, au moins un d’entre eux doit être créé par un mineur honnête, et donc après lblocs, l’uSRS d’une chaîne est sécurisé.
Cependant, il ne suffit pas de savoir que la chaîne de référence d’une chaîne particulière est sécurisée : pour la plupart des applications pratiques, nous voulons que tous les utilisateurs se mettent d’accord sur la chaîne de référence. Ceci est fourni par la propriété de préfixe commun , qui garantit que pour toute chaîne longue de l+k blocs, tous les autres utilisateurs auront la même chaîne de référence que celle générée par cette chaîne – à condition que les utilisateurs arrêtent la mise à jour après l blocs !
Enfin, la croissance de la chaîne garantit que l’événement qui nous intéresse – lorsque tout le monde est d’accord sur la chaîne de référence – finira par se produire. Il garantit que les utilisateurs disposeront éventuellement d’une chaîne de longueur l+k . Plus précisément, comme toutes les s unités de temps, des blocs sont générés, l’événement se produira au plus tard au temps ⌈( l+k )/ s ⌉.
Tout cela est bien dans l’abstrait, mais laisse des questions pratiques : de telles analyses abstraites supposent que les mises à jour peuvent être créées à peu ou pas de frais, et qu’elles n’affectent pas la procédure d’exploration de données standard. Cependant, ce n’est pas tout à fait vrai pour le mining de preuve de travail :
- Les mises à jour sont relativement coûteuses, leur calcul prend entre 5 et 10 minutes, selon la taille de l’uSRS ciblé.
- Il est possible de tricher sur les mises à jour, en les effectuant plus rapidement mais sans ajouter la sécurité de la chaîne de référence.
Ensemble, ces facteurs posent un défi, en particulier dans le cadre de la preuve de travail, où la mise à jour doit être effectuée avant qu’un mineur puisse commencer à extraire un bloc. Cela retarde les mineurs qui ne trichent pas, alors que leurs homologues tricheurs exploitent déjà ! En conséquence, la difficulté du minage (correspondant au temps prévu entre les blocs) ne doit pas être trop faible, car plus elle est faible, plus le mineur tricheur en profite. D’un autre côté, une difficulté élevée entraîne naturellement un délai plus long pour parvenir à un consensus. Ce compromis est représenté dans la figure 1.
À condition que la difficulté soit calibrée de manière appropriée, une analyse de simulation montre que cet effet ne nuit pas à la sécurité globale. En fonction de la probabilité d’échec ( є ) que nous sommes prêts à tolérer et de la fraction de la puissance minière d’un attaquant ( а ) contre laquelle nous voulons nous protéger, l’uSRS peut être généré en toute sécurité avec la procédure soit en quelques heures, soit en quelques heures. mois dans un scénario plus pessimiste, comme le montre la figure 1.
Figure 1. Temps nécessaire jusqu’à ce qu’au moins une mise à jour honnête soit garantie, en fonction du temps de blocage cible
Source : document de recherche « Mining for Privacy : Comment démarrer une chaîne de blocs Snarky »
Un problème similaire se produit lorsqu’on considère un comportement rationnel : les mineurs qui recherchent uniquement le profit tenteront également de tricher sur leurs mises à jour, non pas par méchanceté, mais simplement parce qu’ils peuvent produire des blocs plus rapidement s’ils le font. Ceci peut être contourné en récompensant en outre le bon comportement : il peut être demandé après coup à un échantillon de mineurs de fournir le caractère aléatoire de leurs mises à jour et de démontrer qu’ils ont été échantillonnés de manière appropriée (par exemple, en utilisant une fonction de hachage). S’ils y parviennent, ils peuvent gagner une récompense supplémentaire, compensant toute perte qu’ils pourraient subir en ne trichant pas.
En résumé, l’applicabilité des zk-SNARK profite grandement à différents cas d’utilisation en chaîne, résolvant les problèmes de confidentialité, d’interopérabilité et d’évolutivité. Bien que la configuration fiable, requise pour de nombreux zk-SNARK, semble être en contradiction avec la nature décentralisée des registres distribués, elle peut être réalisée de manière entièrement décentralisée pour les SNARK avec des chaînes de référence pouvant être mises à jour. Bien qu’en principe il soit également possible d’utiliser des SNARK transparents tels que Halo , les techniques décrites ci-dessus permettent à des SNARK tels que Plonk (qui peuvent être plus efficaces selon les circonstances), en s’appuyant sur des chaînes de référence actualisables, d’être également utilisés en toute sécurité pour applications en chaîne – les configurations SNARK ne sont plus trop opaques pour faire confiance, si jamais elles l’étaient.
Source : https://iohk.io/en/blog/posts/2022/09/01/zk-snarks-updatable-setups-on-the-blockchain/