Qu'est-ce qu'une preuve sans connaissance (zk-SNARK vs. zk-STARK) ?

Comprendre les preuves sans connaissance dans la blockchain

Les preuves à connaissance nulle (ZKP) sont des protocoles cryptographiques permettant à une partie de prouver la validité d'une déclaration sans révéler aucune donnée sous-jacente. Dans les écosystèmes blockchain, les ZKP servent d’outils fondamentaux pour améliorer la confidentialité, l’évolutivité et l’efficacité de la vérification. Ils permettent aux nœuds de confirmer l'exactitude de la transaction sans accéder aux adresses de l'expéditeur, aux détails du destinataire ou aux montants. Cette propriété est particulièrement précieuse dans les registres publics où la transparence entre en conflit avec la confidentialité des utilisateurs.

Deux implémentations importantes dominent l'infrastructure actuelle : zk-SNARK et zk-STARK. Les deux répondent aux exigences de connaissance nulle, d’exhaustivité et de solidité, mais divergent considérablement dans la philosophie de conception, les hypothèses de confiance et le comportement informatique. Leur adoption influence les architectures de couche 2, les stratégies de cumul et les coûts de vérification en chaîne sur les principaux réseaux comme Ethereum et Starknet.

zk-SNARK : Argument succinct et non interactif de la connaissance

1. S'appuie sur des cérémonies d'installation fiables impliquant plusieurs participants générant des paramètres cryptographiques appelés déchets toxiques.

2. Utilise la cryptographie à courbe elliptique et les mathématiques basées sur l'appariement, ce qui donne lieu à des tailles de preuve extrêmement petites, souvent inférieures à 300 octets.

3. Le temps de vérification reste constant quelle que soit la complexité des calculs, ce qui le rend idéal pour les environnements contraints comme les contrats intelligents.

4. Nécessite un prétraitement des circuits au format R1CS avant la génération de la preuve, ce qui limite la flexibilité de la logique dynamique.

5. Vulnérable aux compromissions si la configuration de confiance est violée, bien que les déploiements réels atténuent cela via le calcul multipartite.

zk-STARK : argument de connaissances transparent et évolutif

1. Élimine le besoin d'une configuration fiable en s'appuyant sur des fonctions de hachage résistantes aux collisions et sur l'heuristique Fiat-Shamir.

2. Utilise le caractère aléatoire transparent dérivé des données publiques, augmentant ainsi l'auditabilité et réduisant les risques de centralisation.

3. Génère des preuves plus volumineuses (généralement des dizaines de kilo-octets), ce qui augmente les frais de données d'appel sur Ethereum L1.

4. Offre une sécurité post-quantique en raison de sa dépendance à la cryptographie symétrique plutôt qu'aux hypothèses de la théorie des nombres.

5. Prend en charge la composition récursive de manière plus naturelle, permettant des vérifications imbriquées complexes sans surcharge exponentielle.

Compromis de performances dans les systèmes de production

1. Les zk-SNARK dominent dans les applications donnant la priorité à une empreinte minimale sur la chaîne, telles que les échanges DeFi préservant la confidentialité et les attestations d'identité.

2. Les zk-STARK alimentent des cumuls à haut débit comme StarkEx et Starknet, où l'intégrité informatique doit évoluer indépendamment des contraintes du vérificateur.

3. Les modèles de coût du gaz diffèrent fortement : la vérification SNARK consomme environ 200 000 gaz par preuve, tandis que la vérification STARK peut dépasser 500 000 gaz en fonction de la taille du champ et de la profondeur de récursion.

4. Les outils de compilation varient : Circom et SnarkJS prennent en charge les flux de travail SNARK, tandis que Cairo et Warp ciblent les environnements d'exécution compatibles STARK.

5. Les efforts d'accélération matérielle se concentrent sur le déchargement FPGA pour les prouveurs STARK, tandis que les optimisations SNARK mettent l'accent sur les clusters de démonstration basés sur GPU.

Foire aux questions

Q : Les zk-SNARK nécessitent-ils une nouvelle configuration fiable pour chaque changement de circuit ? Oui. Toute modification du système de contraintes nécessite une nouvelle configuration de confiance, à moins que des schémas de configuration universels comme PLONK avec une configuration unique pour tous les circuits ne soient utilisés.

Q : Les zk-STARK peuvent-ils vérifier directement la logique arbitraire des contrats intelligents ? Non. Ils vérifient les calculs exprimés dans des représentations algébriques intermédiaires (AIR), nécessitant une traduction via des langages spécifiques à un domaine comme Cairo avant la génération de la preuve.

Q : Pourquoi certains protocoles combinent-ils à la fois les zk-SNARK et les zk-STARK ? Les approches hybrides utilisent les STARK pour l'intégrité de la couche de base et les SNARK pour une vérification finale succincte, tirant parti de la transparence de STARK et de la compacité de SNARK dans les architectures en couches.

Q : Y a-t-il des implications au niveau du consensus lors du passage d’un type de ZKP à l’autre ? Oui. La modification des systèmes de preuve nécessite souvent des hard forks ou des contrats de vérificateurs évolutifs, ce qui affecte les délais de gouvernance et la compatibilité des clients sur les nœuds complets et les clients légers.