Preuves à divulgation nulle de connaissance : leurs applications sur Solana

Introduction

Voici le deuxième article d’une série d’introduction aux preuves à divulgation nulle de connaissance. Je vous recommande vivement de lire Preuves à divulgation nulle de connaissance : une introduction aux fondamentaux avant celui-ci, car il fournit le contexte nécessaire sur la théorie, les mathématiques et la cryptographie qui sous-tendent cette analyse. Cet article suppose que vous maîtrisez ces notions. Si les preuves à divulgation nulle de connaissance ne vous sont pas familières, je vous recommande donc vivement de lire d’abord l’article précédent. L’objectif est de vous apporter les connaissances nécessaires pour contribuer aux discussions sur les preuves à divulgation nulle de connaissance sur Solana, voire pour vous lancer dans le développement de nouvelles primitives innovantes dans ce domaine.

Grâce à ces nouvelles connaissances, nous pouvons enfin nous demander : que sont les preuves à divulgation nulle de connaissance ? Comment sont-elles utilisées sur Solana ?

Que sont les preuves à divulgation nulle de connaissance ?

Maintenant que nous disposons enfin des bases théoriques, mathématiques et cryptographiques nécessaires, il convient de se demander : qu’est-ce qu’une preuve à divulgation nulle de connaissance, exactement ?

Une preuve à divulgation nulle de connaissance est un procédé cryptographique par lequel une partie peut prouver à une autre qu’une affirmation est vraie sans révéler la moindre information supplémentaire, hormis le fait que cette affirmation est effectivement vraie. Ces preuves doivent être statistiquement fiables, complètes et protégées contre les fuites d’informations.

Il existe deux types d’affirmations que l’on peut vouloir prouver sans divulgation de connaissance. À un niveau général :

• Les affirmations portant sur des faits (par exemple, ce graphe précis admet une coloration en trois couleurs)
• Les affirmations portant sur une connaissance (par exemple, je connais la factorisation de N)

La première affirmation concerne, en définitive, une propriété intrinsèque de l’univers, quelque chose de fondamentalement vrai, comme 1 + 1 = 2. La seconde est appelée preuve de connaissance. Autrement dit, elle va au-delà de la simple preuve qu’une chose est vraie et repose sur ce que connaît le Prouveur.

Comme indiqué précédemment, les preuves utilisées pour établir ces affirmations peuvent être interactives ou non interactives. Dans une preuve interactive à divulgation nulle de connaissance, le Prouveur et le Vérificateur participent à une série d’échanges jusqu’à ce que le Vérificateur soit convaincu au-delà de tout doute raisonnable. Zcash utilise des preuves non interactives à divulgation nulle de connaissance afin de permettre aux utilisateurs d’effectuer des transactions anonymes. 

À l’inverse, dans le cas des preuves non interactives à divulgation nulle de connaissance, la preuve est transmise hors ligne, sans aucune communication directe entre le Prouveur et le Vérificateur. Le Prouveur génère alors une preuve qui contient toutes les informations nécessaires, et le Vérificateur peut la vérifier de façon indépendante, sans autre interaction. Filecoin utilise des preuves non interactives à divulgation nulle de connaissance pour prouver que les utilisateurs ont stocké des données sans révéler les données elles-mêmes. 

 zk-SNARKs et circuits

Un zk-SNARK est un argument de connaissance succinct et non interactif, soit Succinct Non-interactive ARgument of Knowledge en anglais. Ces preuves à divulgation nulle de connaissance sont particulièrement efficaces et compactes, ou succinctes. Une preuve est considérée comme succincte si sa taille et le temps nécessaire à sa vérification augmentent moins vite que le calcul à vérifier. Par conséquent, si nous voulons une preuve succincte, le vérificateur ne peut pas effectuer une opération à chaque tour de hachage, faute de quoi le temps de vérification serait proportionnel au calcul. Les preuves succinctes sont rendues possibles par les polynômes et l’heuristique de Fiat-Shamir.

Quelle que soit la complexité de l’affirmation à prouver, les zk-SNARKs conservent une petite taille de preuve et restent relativement rapides à vérifier. C’est ce qui les rend si intéressants pour les rollups : nous disposons ainsi d’une méthode pour prouver que toutes les transactions d’un L2 donné sont valides, avec une preuve suffisamment petite pour être vérifiée sur le L1. Des protocoles comme Mina vont plus loin et utilisent des preuves récursives, ce qui leur permet de vérifier l’intégralité de l’historique de la chaîne avec une preuve de taille constante. Pickles est le nouveau système de preuve de Mina et la boîte à outils associée. Il s’agit du premier zk-SNARK déployé capable de composition récursive sans configuration de confiance. Notez que la composition récursive fait ici référence aux circuits.

Les circuits décrivent le calcul que vous souhaitez prouver. Il s’agit d’une séquence d’opérations mathématiques qui reçoit des entrées et produit des sorties. Dans les preuves à divulgation nulle de connaissance, les circuits servent à représenter des calculs effectués correctement sans révéler leurs entrées. Le processus général est le suivant :

• Écriture et compilation du circuit — Nous devons écrire et compiler le circuit. Cela peut être aussi simple que de créer un circuit arithmétique sur un corps fini défini par le nombre premier p = 7 et le calcul x * y = z. L’idée générale consiste à représenter le calcul à prouver sous la forme d’un ensemble de contraintes entre des variables, à réduire ces contraintes en équations polynomiales et à écrire du code qui transpose toutes les valeurs vers une nouvelle structure algébrique (c’est-à-dire un homomorphisme). Le processus de compilation produit plusieurs artefacts, notamment l’ensemble des contraintes définies par le circuit et un script ou un binaire à utiliser lors des étapes suivantes
• Cérémonie de configuration de confiance — Selon le type de zk-SNARK utilisé, il peut être nécessaire d’organiser une cérémonie afin de générer les clés de preuve et de vérification
• Exécution du circuit — Un circuit doit être exécuté à l’aide du script ou du binaire généré pendant la compilation, comme s’il s’agissait d’un programme. L’utilisateur saisit les entrées publiques et privées, puis les valeurs de toutes les variables intermédiaires et de sortie sont calculées. Le témoin, également appelé trace, consigne toutes les étapes du calcul
• Génération de la preuve — À partir de la clé de preuve obtenue à la deuxième étape et du témoin produit à la troisième, le prouveur peut générer une preuve à divulgation nulle de connaissance attestant que toutes les contraintes définies dans le circuit sont respectées, tout en ne révélant que la valeur de sortie. Cette preuve est envoyée au vérificateur
• Vérification de la preuve — Le vérificateur utilise la preuve transmise et la clé de vérification pour confirmer que la preuve est correcte pour sa sortie publique

Certains types de zk-SNARKs, comme Groth16, nécessitent une configuration de confiance pour chaque circuit. Cela peut être contraignant, car une nouvelle cérémonie est nécessaire pour chaque nouveau programme. D’autres zk-SNARKs, comme PlonK, ne nécessitent qu’une seule configuration de confiance universelle, ce qui simplifie l’ensemble du processus. D’autres types de preuves à divulgation nulle de connaissance, comme les zk-STARKs, suppriment entièrement la nécessité d’une configuration de confiance.

zk-STARKs

Un zk-STARK est un argument de connaissance transparent et évolutif, soit Scalable Transparent ARgument of Knowledge en anglais. Les zk-STARKs ont été inventés par StarkWare et proposés pour la première fois dans cet article de 2018 comme une alternative aux zk-SNARKs. Ils permettent essentiellement aux blockchains de transférer les calculs vers un unique prouveur STARK hors chaîne, puis de vérifier l’intégrité de ces calculs à l’aide d’un Vérificateur STARK sur la chaîne. 

Les zk-STARKs sont considérés comme des preuves à divulgation nulle de connaissance parce que les entrées utilisées par le prouveur hors chaîne ne sont pas exposées à la blockchain, ce qui préserve la confidentialité de l’utilisateur. Ils sont évolutifs, car le transfert des calculs hors chaîne réduit considérablement les coûts de vérification sur le L1. Leurs preuves évoluent également de manière linéaire, tandis que celles des zk-SNARKs n’évoluent que de façon quasi linéaire. De plus, les zk-STARKs ne reposent pas sur des cérémonies élaborées de configuration de confiance, que leurs défenseurs considèrent comme vulnérables aux déchets toxiques : des preuves non valides pourraient être acceptées par les vérificateurs si la cérémonie n’était pas correctement menée. Les zk-STARKs utilisent plutôt un aléa vérifiable publiquement afin d’établir les interactions entre prouveurs et vérificateurs. Enfin, ces preuves ne peuvent être générées que par un prouveur hors chaîne ayant réellement exécuté le calcul, avec les entrées auxiliaires nécessaires.

Les zk-STARKs répondent aux limites des zk-SNARKs en proposant des arguments de connaissance évolutifs et transparents. Ils reposent également sur des hypothèses cryptographiques bien plus simples et évitent entièrement les éléments tels que les courbes elliptiques. Ils s’appuient uniquement sur les hachages et la théorie de l’information, ce qui les rend résistants aux ordinateurs quantiques. Toutefois, la taille de leurs preuves atteint plusieurs centaines de kilo-octets, ce qui peut limiter leur viabilité dans les environnements où la bande passante ou le stockage sont restreints, comme les blockchains. Notez que certaines configurations de preuve et zkVM plus complexes combinent des preuves récursives de zk-STARKs au sein d’un zk-SNARK, uniquement pour l’étape finale de vérification.

ZK Compression

Le problème de la croissance de l’état

L’un des problèmes les plus urgents de Solana est celui de la croissance de l’état. Pour le contextualiser, l’état de Solana est stocké sur les disques des nœuds complets dans l’Accounts DB. Il s’agit d’un magasin clé-valeur dans lequel chaque entrée de la base de données est appelée un compte. Chaque compte possède une adresse de 32 octets et peut stocker entre 0 et 10 Mo de données. À l’heure actuelle, le stockage de 10 Mo de données coûte environ 70 SOL, qu’elles soient réparties dans un seul compte de 10 Mo ou dans mille comptes de 10 Ko. Environ un million de nouveaux comptes sont ajoutés chaque jour à la chaîne, ce qui porte l’état total à plus de 500 millions de comptes, selon la publication de Toly sur la croissance de l’état. Cette situation posera plusieurs difficultés à mesure que Solana se développe, notamment une taille d’instantané non bornée, les limites de bande passante PCI, l’indexation des comptes ainsi qu’une gestion coûteuse de la mémoire et des disques. 

La taille actuelle d’un instantané complet est d’environ 70 Go, ce qui reste gérable avec le matériel disponible. Toutefois, une croissance continue entraînera inévitablement des inefficacités dans la gestion de l’état et des goulots d’étranglement potentiels. À mesure que la taille de l’instantané augmente, le temps nécessaire au démarrage à froid d’un nouveau système après une panne matérielle s’allonge considérablement, ce qui pourrait être préjudiciable en cas de redémarrage du réseau. 

La bande passante Peripheral Component Interconnect (PCI) désigne le débit de transfert des données entre le CPU et les périphériques, tels que les cartes graphiques, les cartes réseau et les dispositifs de stockage. PCI Express (PCIe) est une norme d’interface à haut débit conçue pour remplacer l’ancienne norme PCI et offrir de meilleurs débits de transfert. La bande passante PCI la plus récente peut atteindre 1 To, soit 128 Go/s. Cela peut sembler considérable, mais ce n’est pas le cas dans le contexte de Solana. Si une transaction lit ou écrit 128 Mo, une bande passante PCI de 128 Go/s limiterait Solana à 1 000 transactions par seconde (TPS). Toutefois, la plupart des transactions accèdent à des données récentes déjà chargées et mises en cache dans la RAM d’un validateur. Une gestion efficace de la mémoire d’état reste néanmoins essentielle pour conserver un débit élevé à mesure que Solana évolue. Sans cela, cette bande passante pourrait rapidement devenir un facteur limitant.

Chaque validateur doit tenir à jour un index de tous les comptes existants. En effet, la création d’un nouveau compte nécessite de prouver que ce compte n’existe pas déjà. Avec un état total dépassant 500 millions de comptes, même un index minimal, comprenant une clé de 32 octets et un hachage de données de 32 octets par entrée, nécessiterait environ 32 Go de RAM. Ce stockage d’état est coûteux et doit être géré avec soin pour éviter une dégradation des performances. À mesure que l’état de Solana se développe, la distinction entre l’utilisation d’une mémoire rapide et coûteuse, comme la RAM, pour certaines opérations et celle d’une mémoire plus lente et moins chère, comme le disque, devient cruciale.

Transactions et croissance de l’état

Chaque transaction Solana doit préciser tous les comptes qu’elle lit et dans lesquels elle écrit. Les transactions sont actuellement limitées à 1 232 octets et doivent inclure les éléments suivants :

• En-tête (3 octets)
• Signatures (64 octets chacune)
• Adresses des comptes (32 octets chacune)
• Données d’instruction (taille arbitraire)
• Hachage de bloc récent (32 octets)

Lors de l’exécution d’une transaction, les étapes suivantes ont lieu :

• Contrôles de cohérence — Seules les transactions récentes sont valides. La déduplication, la vérification structurelle, les frais et les signatures de la transaction sont contrôlés
• Chargement du programme — Le bytecode du programme est chargé à partir de son adresse, puis la Solana Virtual Machine (SVM) est instanciée
• Chargement des comptes — Tous les comptes référencés par la transaction sont contrôlés, chargés du stockage vers la mémoire, puis transmis à la SVM
• Exécution — Le bytecode du programme est exécuté
• Synchronisation — Tous les comptes modifiés sont resynchronisés avec le stockage

Ce cycle de vie pose plusieurs difficultés à mesure que l’état se développe. L’état sur la chaîne est notamment coûteux, et l’augmentation du nombre de comptes stockés sur disque entraîne des instantanés et des index plus volumineux. En outre, tous les comptes ne sont pas consultés fréquemment, ce qui rend inefficace le coût permanent des ressources qui leur sont consacrées.

Simplifier la gestion de l’état avec ZK Compression

Au lieu de stocker tous les comptes sur disque et de les lire lorsque cela est nécessaire, une transaction peut transmettre les données du compte dans sa charge utile. Les arbres de Merkle permettent de garantir que les utilisateurs qui soumettent des transactions fournissent le bon état. Les preuves de Merkle constituent un moyen d’engager des données. Elles peuvent ainsi être vérifiées par rapport à l’engagement afin de confirmer que l’état transmis est correct et que l’utilisateur ne ment pas sur l’état fourni. 

Bien que sécurisées, ces preuves peuvent être assez volumineuses. Par exemple, si un arbre contient 100 000 comptes, la preuve atteint 544 octets. Fournir des preuves pour plusieurs comptes pourrait rapidement dépasser la limite de 1 232 octets par transaction. Heureusement, des systèmes de preuve plus efficaces permettent de contourner ce problème. L’utilisation d’engagements à taille de preuve constante, tels que les engagements KZG ou Pedersen, réduirait la taille des preuves et faciliterait leur inclusion dans la limite de taille des transactions.

ZK Compression est simplement un mécanisme destiné à résoudre le problème de la taille des preuves de Merkle. Il permet de prouver qu’un calcul a été correctement effectué, sans supporter les coûts associés au stockage sur la chaîne, en exploitant le registre de Solana.

Qu’est-ce que ZK Compression ?

ZK Compression est une nouvelle primitive qui permet aux développeurs de compresser l’état sur la chaîne afin d’en réduire le coût de plusieurs ordres de grandeur, tout en préservant la sécurité, les performances et la composabilité. Par exemple, la création de 100 comptes de tokens coûte actuellement environ ~0,2 SOL. Avec ZK Compression, ce coût est divisé par 5 000 et tombe à environ ~0,00004 SOL. 

ZK Compression exploite les preuves à divulgation nulle de connaissance pour valider les transitions d’état sans exposer les données sous-jacentes. Pour cela, plusieurs comptes sont regroupés dans une seule racine de Merkle vérifiable stockée sur la chaîne, tandis que les données sous-jacentes sont conservées dans le registre. Les preuves de validité sont des preuves succinctes à divulgation nulle de connaissance qui servent à prouver l’existence de n comptes sous forme de feuilles dans m arbres d’état, tout en conservant une taille de preuve constante de 128 octets. Ces preuves sont générées hors chaîne et vérifiées sur la chaîne, ce qui réduit la charge de calcul globale sur Solana. ZK Compression utilise Groth16, un zk-SNARK réputé fondé sur les couplages, pour son système de preuve.

Ces comptes ne sont toutefois pas des comptes Solana ordinaires. Ce sont des comptes compressés.

Modèle de compte compressé

L’état compressé par ZK est stocké dans des comptes compressés. Ces comptes ressemblent aux comptes Solana ordinaires, mais présentent plusieurs différences majeures qui améliorent leur efficacité et leur évolutivité :

• Identification par hachage — Chaque compte compressé peut être identifié par son hachage
• Modification du hachage lors d’une écriture — Toute opération d’écriture dans un compte compressé modifie son hachage
• Adresse facultative — Une adresse peut éventuellement être définie comme identifiant unique permanent du compte compressé. Cela se révèle utile dans certains cas, notamment pour les NFT. Ce champ est facultatif afin d’éviter une surcharge de calcul, puisque les comptes compressés peuvent être référencés par leur hachage
• Arbres d’état clairsemés — Tous les comptes compressés sont stockés dans des arbres de Merkle, et seule la racine d’état de l’arbre, c’est-à-dire la racine de Merkle, est conservée dans l’espace des comptes sur la chaîne. Plus précisément, un arbre d’état est un arbre de Merkle concurrent fondé sur le hachage Poseidon

Les adresses dérivées de programme compressées (PDA) peuvent être identifiées par leur adresse unique et persistante. Leur structure ressemble à celle des comptes PDA ordinaires, avec les champs Data, Lamports, Owner et Address. Toutefois, contrairement aux PDA ordinaires, le champ Data intègre la structure AccountData, avec les champs Discriminator, Data et DataHash.

Nœuds

Différents types de nœuds jouent un rôle essentiel dans le fonctionnement de ZK Compression. Tout le monde peut exploiter un nœud Photon RPC, un nœud Prover ou un nœud Light Forester pour se connecter à Devnet et Mainnet-Beta. Pour le développement local, la commande test-validator de la CLI ZK Compression lance un cluster Solana à nœud unique comprenant tous les nœuds concernés, c’est-à-dire Photon RPC et Prover, ainsi que les programmes système, les comptes et les fonctionnalités d’exécution.

Les nœuds Photon RPC indexent les programmes de compression. Les clients peuvent ainsi lire et construire des transactions qui interagissent avec l’état compressé. L’indexeur de compression canonique s’appelle Photon et est fourni par Helius. Ce type de nœud peut être exécuté localement avec une configuration minimale et doit pointer vers un RPC existant. 

Les nœuds Prover servent à générer des preuves de validité pour l’inclusion dans l’état. Le point de terminaison getValidityProof de la spécification de l’API RPC de ZK Compression permet de récupérer les preuves. Les nœuds Prover peuvent fonctionner de manière autonome ou être regroupés avec un autre RPC. Notez que l’implémentation canonique de Photon RPC comprend un nœud Prover.

Les nœuds Light Forester gèrent la création, la rotation et la mise à jour des arbres d’état partagés et détenus par les programmes. Ils s’adressent aux développeurs qui souhaitent faire prendre en charge leurs propres arbres d’état détenus par un programme par un réseau de nœuds Light Forester.

Hypothèses de confiance

Tout le monde peut exploiter l’un des nœuds mentionnés précédemment, stocker les données brutes nécessaires à la génération des preuves et soumettre des transactions. Cela introduit une hypothèse de confiance qui affecte la disponibilité de l’état compressé. En particulier, si les données sont perdues ou retardées, aucune transaction ne peut être soumise à moins de stocker soi-même ces données. Puisqu’un seul nœud honnête suffit pour fournir les données et que les preuves sont auto-vérifiables, le problème concerne la disponibilité et le risque de censure plutôt que la sécurité.

En outre, le fait que le programme chargé de vérifier les comptes compressés soit actuellement évolutif introduit une autre hypothèse de confiance. Cette caractéristique permet de modifier le programme pour corriger d’éventuels problèmes ou l’adapter à de nouvelles exigences. Il pourra toutefois être rendu immuable ou gelé à l’avenir, une fois qu’il aura atteint un état stable et sécurisé.

L’utilisation de nœuds Forester implique une autre hypothèse de confiance liée à la disponibilité. Ces nœuds assurent la progression des racines d’état et gèrent les files d’annulateurs en les vidant et en faisant progresser les racines d’état de manière asynchrone. Les hachages des comptes sont alors remplacés par des zéros pour les annuler. La séparation de la progression et de l’annulation garantit la finalité instantanée des transitions de l’état compressé, tout en maintenant les transactions dans les limites de taille de Solana. Les files d’annulateurs ayant une taille constante, les nœuds Forester sont essentiels à la disponibilité du protocole. Une file pleine entraînerait une défaillance de disponibilité pour l’arbre d’état concerné. Heureusement, les nœuds Forester évitent ce problème en vidant les files. Des opérateurs doivent néanmoins continuer à exploiter ces nœuds afin de préserver l’intégrité et la disponibilité du protocole. Sans eux, ZK Compression ne pourrait prendre en charge qu’environ deux mille comptes ou adresses.

Limites 

Même lorsqu’il n’est pas nécessaire de masquer une information, les preuves à divulgation nulle de connaissance transforment les problèmes exigeant plusieurs étapes de calcul en problèmes pour lesquels il suffit de vérifier une seule preuve afin de savoir si les calculs ont été correctement effectués. Et ces calculs ne se limitent pas à déterminer si une feuille précise appartient à un arbre donné : ils peuvent être entièrement arbitraires. Cette possibilité a toutefois un coût.

Avant d’utiliser ZK Compression, tenez compte des points suivants :

• Taille de transaction supérieure — ZK Compression nécessite 128 octets pour la preuve de validité, auxquels s’ajoutent les données à lire ou à écrire sur la chaîne
• Utilisation accrue des unités de calcul — ZK Compression augmente considérablement l’utilisation des unités de calcul (CU), car la vérification de la preuve de validité nécessite ~100 000 CU, le système ~100 000 CU et chaque lecture ou écriture d’un compte compressé ~6 000 CU
• Coût d’état par transaction — Chaque opération d’écriture entraîne un faible coût réseau, puisqu’elle doit annuler l’état précédent du compte compressé et ajouter le nouvel état compressé à l’arbre d’état. Le coût total d’un compte compressé sur toute sa durée de vie peut donc dépasser celui de son équivalent non compressé s’il exige de nombreuses mises à jour de l’état

Il peut être préférable d’utiliser un compte ordinaire si :

• Le compte est mis à jour fréquemment
• Le nombre total d’écritures dans le compte sur sa durée de vie sera élevé (c’est-à-dire >1 000)
• Le compte stocke une grande quantité de données auxquelles les transactions sur la chaîne doivent accéder

Avantages

ZK Compression est une primitive évolutive, sécurisée, efficace et flexible qui s’attaque directement au problème de la croissance de l’état de Solana et prend en charge un large éventail d’applications et de cas d’usage. Son avantage le plus visible est sans doute la réduction du coût de l’état. ZK Compression permet aux applications de s’adapter facilement à des millions d’utilisateurs en stockant l’état de façon sécurisée dans l’espace moins coûteux du registre, tout en limitant au minimum le stockage sur la chaîne grâce à l’empreinte de l’état. Prenons l’exemple de la création de 10 000 comptes de tokens, avec un cours du SOL de 130 USD : l’opération coûterait environ 2 600 USD. ZK Compression réduit ce coût à moins de cinquante centimes.

ZK Compression s’intègre également parfaitement aux spécifications actuelles de Solana. Par exemple, la structure des comptes compressés est presque identique à celle des comptes Solana ordinaires. Elle prend aussi en charge des innovations propres à Solana, telles que le parallélisme. Deux transactions relevant du même arbre d’état, c’est-à-dire du même engagement, et accédant à des comptes compressés différents peuvent ainsi être exécutées en parallèle. De plus, ZK Compression renforce la composabilité atomique synchrone. Par exemple, une transaction répertoriant n comptes compressés et m comptes ordinaires constitue une configuration parfaitement valide. Une instruction faisant référence à un compte compressé peut appeler une autre instruction ou un autre programme qui fait référence à un compte ordinaire. Cela reste vrai même si les comptes sont compressés dans différents arbres d’état. Si une instruction échoue, l’intégralité de la transaction est annulée, et les modifications sont visibles d’une instruction à la suivante. Cette approche diffère de celle des rollups ZK, qui ne peuvent pas s’appeler mutuellement de façon synchrone ou atomique sans recourir à des verrous. Cela justifie naturellement une comparaison entre ZK Compression et les rollups.

ZK Compression n’est pas un rollup

ZK Compression n’est pas un rollup. Bien que les deux reposent sur la même technologie, leurs implémentations diffèrent. Il existe deux types de rollups :

• Rollups optimistes — Toutes les transactions sont présumées valides pendant une période donnée, et des preuves de fraude permettent d’identifier les transactions non valides durant cette période
• Rollups à divulgation nulle de connaissance — Des preuves de validité permettent de déterminer instantanément si les transactions sont valides ou non

L’intégralité de l’état d’un rollup à divulgation nulle de connaissance est représentée par une racine unique sur la couche de base, c’est-à-dire Ethereum. Cela a conduit plusieurs personnes à affirmer que ZK Compression est en réalité un rollup. Il existe toutefois plusieurs différences fondamentales.

Prenons un scénario comprenant 500 transactions sur un rollup ZK. Dans ce cas, le rollup entier est traité comme un seul circuit. Les 500 transactions sont vérifiées ensemble, ce qui produit une preuve unique confirmant que la racine d’état est passée de A à B. Une fois cette preuve vérifiée, le contrat intelligent qui gère les interactions entre le L1 et le L2 met à jour la racine d’état. Avec ZK Compression, en revanche, chacune des 500 transactions génère sa propre preuve afin de vérifier l’exactitude des données de compte. Ces transactions sont exécutées par la SVM elle-même, et les comptes sont traités comme des comptes « ordinaires » une fois chaque preuve validée.

Si nous considérions ZK Compression comme un rollup, cela signifierait que toute racine de Merkle stockée sur Solana pourrait être qualifiée de rollup fondé sur la validité. Si nous examinons toutes les racines de cNFT compressés actuellement présentes sur Solana, il existe alors environ 4 000 à 5 000 rollups fondés sur la validité, selon que l’on comptabilise ou non les arbres de Merkle ne contenant aucun mint.

Il apparaît donc clairement que ZK Compression est une solution unique, adaptée à l’architecture de Solana. Cette nouvelle primitive, distincte des rollups ZK, améliore l’évolutivité et l’efficacité sans introduire la complexité ni la séparation propres aux rollups.

L’avenir de la ZK sur Solana et de l’interopérabilité

État actuel de la ZK sur Solana

L’une de mes premières missions rédactionnelles chez Helius consistait à présenter la mise à jour v1.16 de Solana. J’étais particulièrement enthousiaste à l’idée de découvrir la meilleure prise en charge des preuves à divulgation nulle de connaissance par l’environnement d’exécution et je l’ai abordée dans l’article. Ces améliorations ont toutefois été reportées. J’ai commis l’erreur de les présenter une nouvelle fois, plus en détail, dans l’article sur la mise à jour v1.17, avant qu’elles ne soient à nouveau retardées. Je n’ai même pas pris la peine de les mentionner dans l’article sur la mise à jour v1.18. J’étais naturellement déçu, et d’autres ont exprimé leur frustration. 

Malgré ce sentiment, une communauté encore modeste de développeurs ZK commence à émerger sur Solana. Au départ, Light Protocol se concentrait sur l’exécution privée de programmes sous la forme de PSP (Private Solana Programs), avant de recentrer ses efforts sur ZK Compression. Dark protocol est également un protocole de confidentialité futarchique construit sur Solana. Il ne possède pas d’équipe centrale et les contributions s’effectuent par l’intermédiaire de propositions. Arcium, anciennement connu sous le nom d’Elusiv, utilise des environnements d’exécution de calcul multipartite (MXE) pour alimenter son propre réseau de calcul confidentiel parallélisé. Bonsol est un « coprocesseur » à divulgation nulle de connaissance qui permet aux développeurs d’exécuter n’importe quelle image risc0 et de la vérifier sur Solana, c’est-à-dire d’effectuer des calculs hors chaîne vérifiables. Des tutoriels et des listes de liens consacrés aux preuves à divulgation nulle de connaissance ont également circulé.

Plus particulièrement, le ZK Token Proof Program vérifie plusieurs preuves à divulgation nulle de connaissance conçues pour fonctionner avec les engagements Pedersen et le chiffrement Twisted ElGamal sur curve25519. Il permet les transferts confidentiels, qui utilisent des preuves à divulgation nulle de connaissance pour chiffrer les soldes et les montants des transactions de tokens SPL. L’objectif est la confidentialité plutôt que l’anonymat. Le chiffrement homomorphe permet d’effectuer des calculs sur des données chiffrées sans devoir les déchiffrer. Pour cela, les transferts confidentiels utilisent le chiffrement Twisted ElGamal pour les opérations mathématiques masquées sur le texte chiffré et les protocoles Sigma afin de valider ces transferts sans révéler d’informations sensibles. Seul le titulaire du compte possédant la clé de déchiffrement peut consulter son solde chiffré. Le Global Auditor System permet toutefois un accès sélectif en lecture à des fins de conformité et d’audit grâce à des clés de déchiffrement distinctes. 

Le ZK Token Proof Program est actuellement une fonctionnalité bloquée en raison de l’adoption de SIMD-0153: ZK ElGamal Proof Program. Cette nouvelle SIMD vise à rendre obsolète l’actuel ZK Token Proof program, spécialement conçu pour le programme SPL Token, et à le remplacer par un programme plus général de preuves à divulgation nulle de connaissance, indépendant de toute application spécifique. La SIMD a été fusionnée avec le soutien d’Anza et de l’équipe Firedancer.

La tendance commence toutefois à s’inverser. Solana est en passe de devenir un géant de la ZK, car ces améliorations arrivent enfin sur Devnet et Mainnet-Beta. Il existe désormais trois appels système ZK actifs sur Solana.

Appels système Poseidon

Poseidon est une famille de fonctions de hachage spécialement conçues pour les preuves à divulgation nulle de connaissance et utilisée dans des projets comme Zcash, Mina et Light Protocol. Pour ces preuves, Poseidon est plus efficace sur le plan du calcul que les fonctions de hachage généralisées traditionnelles telles que SHA-256. 

Les fonctions de hachage Poseidon sont adaptées à la divulgation nulle de connaissance, car elles :

• Effectuent efficacement les opérations arithmétiques
• Nécessitent moins d’étapes pour générer les preuves, c’est-à-dire qu’elles présentent une moindre complexité de circuit, grâce à leur conception adaptée à l’arithmétique, à leur S-box optimisée et à leur faible nombre de tours
• Utilisent des algorithmes capables de traiter des séquences de bits de n’importe quelle longueur, ce qui les rend extrêmement polyvalentes

Le calcul de hachages Poseidon dans une seule transaction était auparavant trop coûteux. Cela change avec l’époque 644 et l’activation de l’appel système Poseidon, c’est-à-dire un appel système qui reçoit en entrée une tranche bidimensionnelle d’octets et calcule le hachage Poseidon correspondant en sortie. Cette évolution est particulièrement intéressante, car ZK Compression repose sur le hachage Poseidon pour ses arbres d’état.

L’appel système Poseidon calcule les hachages à l’aide de la courbe BN254 avec les paramètres suivants :

• S-boxes — Boîtes de substitution x5
• Entrées — 1 ≤ n ≤ 12
• Largeur — 2 ≤ t ≤ 13
• Tours — 8 tours complets et des tours partiels selon t : [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Sa sortie correspond au résultat du hachage Poseidon, encodé sur 32 octets selon le boutisme indiqué.

Notez que la variante utilisée pour cet appel système est Poseidon avec une S-box x5 et des paramètres adaptés à la courbe BN254. Le crate light-poseidon facilitera le calcul de ces hachages. Le crate lui-même est audité et compatible avec Circom.

Appels système alt_bn128

alt_bn128 désigne l’implémentation de la courbe elliptique Barreto-Naehrig (BN-128), une courbe adaptée aux couplages qui permet d’effectuer efficacement les preuves et les calculs zk-SNARKs. Cette courbe est essentielle pour plusieurs systèmes de preuves à divulgation nulle de connaissance, notamment Groth16, sur lequel ZK Compression s’appuie pour valider les transitions d’état. Cet appel système réduit considérablement l’espace nécessaire à chaque preuve et apporte une optimisation cruciale de l’espace et du temps pour assurer l’efficacité des preuves sur la chaîne. 

Les appels système sol_alt_bn128_group_op calculent des opérations sur la courbe alt_bn128, notamment l’addition de points dans G1 (G1 désigne simplement un groupe de points sur une courbe elliptique donnée), la multiplication scalaire dans G1 et le couplage :

• Entrées — Points et scalaires sérialisés au format gros-boutiste
• Opérations — Addition de points dans G1, multiplication scalaire dans G1, couplage (1 point dans G1 et 1 point dans G2)
• Sorties — Points dans G1 ou résultats de couplage sérialisés sous forme d’entier de 256 bits

Les appels système sol_alt_bn128_compression compressent ou décompressent des points dans les groupes G1 ou G2 sur la courbe alt_bn128 et renvoient ces points au format gros-boutiste standard.

Ces appels système sont actuellement actifs sur testnet et devraient devenir disponibles sur Devnet une fois résolus les bugs de la phase de recompilation des programmes chargés, conformément à SIMD-0075: Secp256r1 Precompile. Cette proposition vise à simplifier les codes d’erreur des appels système alt_bn128 ainsi que de l’appel système Poseidon, afin d’assurer leur cohérence et de réduire le risque d’échecs du consensus dus à des codes d’erreur différents renvoyés par les validateurs.

Les appels système alt_bn128 peuvent être utilisés pour les engagements vectoriels ordinaires à taille de preuve constante, comme les engagements KZG. Ainsi, ils fonctionneront avec toute courbe adaptée aux couplages et ne nécessiteront pas de circuit de prouveur ZK. 

Interopérabilité

Solana est une chaîne ZK. Il s’agit d’une blockchain de couche 1 très performante, avec des frais faibles et une prise en charge des opérations sur les courbes elliptiques par l’environnement d’exécution. L’implémentation et la prise en charge des appels système liés aux preuves à divulgation nulle de connaissance favorisent l’innovation et permettent de construire sur Solana de nouvelles primitives et applications, telles que ZK Compression.

L’introduction des appels système alt_bn128 réduit l’écart de composabilité entre Solana et les contrats fondés sur Solidity, qui s’appuient sur des contrats précompilés pour les opérations sur les courbes elliptiques définies dans EIP-196, EIP-197 et EIP-198. Ces opérations facilitent la vérification des preuves zk-SNARK dans les limites de gas d’Ethereum. Les contrats Solidity qui reposent sur ces opérations de courbes elliptiques pourraient donc désormais migrer plus facilement vers Solana, voire interagir avec celle-ci.

SIMD-0075 est essentielle pour les solutions d’interopérabilité. Une fois entièrement implémentée, cette SIMD permettra à des projets comme le futur blobsream-solana, qui diffuse les données DA de Celestia vers Solana, d’utiliser la génération de preuves hors chaîne et leur vérification sur la chaîne afin de stocker des engagements de Merkle. Sans ces appels système, il serait impossible de vérifier les preuves Groth16 sur Solana. Ils renforcent également les ponts à confiance minimisée et l’interopérabilité, en permettant à d’autres blockchains d’interagir de manière fluide et sécurisée avec Solana.  

Toly a raison : avec toutes ces améliorations apportées à l’environnement d’exécution de Solana, Solana est un L2 d’Ethereum. Bientôt, rien ne vous empêchera de soumettre tous les blocs de Solana à un contrat de pont de validation des données sur Ethereum. Inversement, rien ne vous empêchera de soumettre tous les blocs d’Ethereum à un programme de pont de validation des données sur Solana. L’interopérabilité bidirectionnelle, accélérée par les preuves à divulgation nulle de connaissance plutôt que par des ponts obsolètes, ouvre à Solana un avenir prometteur en plein essor.

Conclusion

Les preuves à divulgation nulle de connaissance figurent sans aucun doute parmi les primitives les plus puissantes jamais développées par les cryptographes, si ce n’est la plus puissante. Cela devient évident lorsque l’on examine, comme dans le premier article, la théorie, les mathématiques et la cryptographie qui sous-tendent ce concept en repartant des principes fondamentaux. Les applications potentielles sont infinies : du véritable brouillard de guerre pour les jeux sur la chaîne jusqu’à la preuve qu’un ensemble de transactions sur un L2 a produit une transition d’état précise.

Cette série en deux parties aurait facilement pu compter cinquante pages supplémentaires et couvrir les subtilités du chiffrement homomorphe, la programmation de circuits dans Circom et l’analyse de différents schémas d’engagement. L’objectif de ces articles est toutefois de vous enseigner les fondamentaux des preuves à divulgation nulle de connaissance, afin que vous puissiez désormais mettre ces nouvelles connaissances en pratique sur Solana. 

Solana est en passe de devenir un géant de la ZK. Entre le lancement de ZK Compression et l’activation prochaine de différents appels système, son importance ne doit pas être sous-estimée. Si des primitives comme ZK Compression masquent toute la complexité des preuves à divulgation nulle de connaissance au développeur moyen, la maîtrise des fondamentaux reste inestimable pour faire avancer les discussions et leur développement sur Solana. 

Si vous avez lu jusqu’ici, merci, anon ! Saisissez votre adresse e-mail ci-dessous pour ne manquer aucune actualité concernant Solana. Vous souhaitez aller plus loin ? Découvrez les derniers articles du blog Helius et poursuivez dès aujourd’hui votre exploration de Solana.

Ressources supplémentaires

• Introduction approximative aux mécanismes qui rendent les zk-SNARKs possibles, par Vitalik
• POSEIDON : une nouvelle fonction de hachage pour les systèmes de preuves à divulgation nulle de connaissance (version mise à jour)
• SIMD-0075 : précompilation Secp256r1
• Comprendre la différence entre les zk-SNARKs et les zk-STARKs
• Documentation de ZK Compression