Deux familles de preuves à divulgation nulle de connaissance se disputent aujourd’hui l’infrastructure de la blockchain vérifiable : le zk-SNARK et le zk-STARK. Les deux permettent de prouver qu’un calcul a été exécuté correctement sans en révéler le contenu, mais elles reposent sur des hypothèses mathématiques totalement différentes. Une étude comparative publiée en 2025 sur quatre plateformes (Apple M1, Raspberry Pi, Ubuntu, PPC64) a mesuré des preuves SNARK de 384 octets contre des preuves STARK de 68 564 octets pour un même calcul, un écart de près de 179 fois. Cet article compare les deux systèmes sur la taille des preuves, les temps de génération et de vérification, la nécessité d’une configuration de confiance, la résistance à l’informatique quantique et les coûts réels de déploiement sur Ethereum, avec des exemples concrets tirés de Zcash, zkSync Era, Polygon, StarkNet, RISC Zero et Mina Protocol.
zk-SNARK et zk-STARK : deux réponses au même problème cryptographique
Un zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) et un zk-STARK (Zero-Knowledge Scalable Transparent Argument of Knowledge) répondent tous deux à la même question : comment convaincre quelqu’un qu’un calcul a été fait correctement sans lui montrer les données d’entrée. Le S de SNARK signifie succinct, celui de STARK signifie scalable, une distinction également détaillée dans le glossaire technique de Gemini Cryptopedia sur les preuves à divulgation nulle. Cette différence de vocabulaire n’est pas cosmétique, elle résume l’opposition centrale entre les deux approches.
Les zk-SNARK reposent historiquement sur des couplages de courbes elliptiques et des hypothèses de logarithme discret. Cette base mathématique permet des preuves minuscules, de l’ordre de quelques centaines d’octets, quelle que soit la taille du calcul prouvé. Les zk-STARK, à l’inverse, s’appuient uniquement sur des fonctions de hachage et de l’arithmétique sur des corps finis, via un protocole appelé FRI (Fast Reed-Solomon Interactive Oracle Proof). Cette base plus simple élimine certains risques cryptographiques, mais produit des preuves nettement plus volumineuses, souvent 40 Ko à plus de 500 Ko selon la complexité du programme prouvé.
Le choix entre les deux n’est donc pas une question de supériorité générale, mais un arbitrage entre taille de preuve, vitesse de calcul, hypothèses de sécurité et résistance à long terme. Le reste de cet article détaille chacun de ces arbitrages avec des chiffres vérifiés.
Comment fonctionne un zk-SNARK
Un circuit zk-SNARK transforme un programme en un système d’équations arithmétiques, appelé R1CS (Rank-1 Constraint System) ou représentation par portes arithmétiques selon le compilateur utilisé (Circom, Noir, Halo2). Le prouveur encode ensuite ce système sous forme de polynômes, puis produit une preuve compacte en évaluant ces polynômes en un point secret grâce à un couplage bilinéaire sur courbe elliptique.
Le système historique le plus utilisé en production, Groth16, publié en 2016, produit des preuves d’une taille constante d’environ 804,7 octets selon une évaluation de performance menée en 2026, quelle que soit la taille du circuit prouvé. C’est cette propriété de taille constante qui a rendu Groth16 dominant dans les premières générations de rollups Ethereum et dans Zcash. Son inconvénient majeur est qu’il exige une configuration de confiance spécifique à chaque circuit : toute modification du programme prouvé oblige à relancer une cérémonie de génération de paramètres.
Les générations plus récentes, PLONK et ses variantes, ainsi que Halo2, ont cherché à réduire cette contrainte. PLONK utilise une chaîne de référence structurée universelle (SRS), générée une seule fois et réutilisable pour n’importe quel circuit jusqu’à une taille donnée. Halo2 va plus loin en s’appuyant sur des arguments de produit interne qui permettent d’éviter une cérémonie de confiance classique, tout en conservant des preuves de petite taille. C’est cette architecture que zkSync Era et Aztec ont adoptée pour leurs circuits de production.
Comment fonctionne un zk-STARK
Un zk-STARK part d’une trace d’exécution complète du programme, représentée comme une table de valeurs à chaque étape de calcul. Cette trace est encodée en polynômes via une transformation de Reed-Solomon, puis le prouveur s’engage sur ces polynômes à l’aide d’arbres de Merkle construits avec des fonctions de hachage. Le protocole FRI, décrit dans le document de recherche original sur les preuves d’intégrité computationnelle transparentes et post-quantiques, permet ensuite de vérifier, par un nombre logarithmique de requêtes, que les polynômes respectent bien les contraintes du calcul, sans jamais recourir à un couplage de courbe elliptique.
Cette conception rend le système entièrement transparent : aucune cérémonie de configuration de confiance n’est nécessaire, la seule source d’aléa provient de valeurs publiques (typiquement dérivées d’un hachage de bloc ou d’une source de hasard vérifiable). C’est l’argument central mis en avant par StarkWare depuis la création du langage Cairo, utilisé pour écrire les programmes exécutés sur StarkNet et StarkEx.
Le langage Cairo compile un programme vers une représentation intermédiaire algébrique (AIR), puis un prouveur STARK, tel que le Stone Prover de StarkWare ou le framework open source Winterfell, génère la preuve correspondante. Des hachages optimisés pour l’arithmétique en circuit, comme Poseidon, Poseidon2 ou Rescue, réduisent le nombre de contraintes nécessaires par opération de hachage à l’intérieur de la preuve, ce qui améliore le temps de calcul par rapport à l’usage d’un hachage générique comme SHA-256 à l’intérieur du circuit.
Taille des preuves : l’écart se compte en kilooctets
C’est la différence la plus nette et la plus constante entre les deux systèmes, confirmée par plusieurs études indépendantes. Une analyse comparative de 2025 rapporte des preuves zk-SNARK de 384 octets contre des preuves zk-STARK de 68 564 octets pour le même calcul, un rapport de 179 fois. Un autre benchmark multi-protocoles publié la même année situe les preuves SNARK autour de 288 octets et les preuves STARK autour de 45 000 octets, soit un rapport d’environ 156 fois. Une évaluation spécifique de Groth16 menée en 2026 confirme une taille de preuve constante de 804,7 ± 1,7 octets, indépendante de la taille du circuit testé.
Cette différence a des conséquences concrètes sur la conception d’un système. Une preuve SNARK tient dans un seul appel de fonction Ethereum sans coût de stockage significatif. Une preuve STARK de plusieurs dizaines de kilooctets pèse directement sur les frais de calldata, ce qui explique pourquoi StarkNet et StarkEx ont investi massivement dans la compression de preuves et le regroupement de transactions par lot plutôt que dans la vérification directe de preuves individuelles sur la couche 1.
À l’inverse, la taille de preuve STARK reste relativement stable même quand la complexité du calcul prouvé augmente fortement, car elle croît de façon logarithmique par rapport au nombre d’opérations, alors qu’un circuit SNARK mal dimensionné peut voir son temps de configuration initiale et ses coûts de cérémonie grimper avec la complexité.
Temps de génération des preuves : la donnée qui façonne l’architecture
Sur le même jeu de plateformes (M1, Raspberry Pi, Ubuntu, PPC64), l’étude comparative de 2025 mesure des temps de génération SNARK allant de 55,47 ms sur M1 à 3,37 secondes sur Ubuntu, contre des temps STARK allant de 3,81 secondes sur M1 à 31,04 secondes sur PPC64. Sur ce jeu de données précis, générer une preuve SNARK est environ 68 fois plus rapide que générer une preuve STARK pour un calcul identique.
Ce résultat ne se généralise cependant pas à tous les types de charge de travail. Une thèse de 2025-2026 sur l’optimisation de compilateurs pour zkVM (machines virtuelles à preuve de calcul) rapporte l’inverse pour des programmes de grande taille : 4,708 secondes de preuve STARK contre 12,488 secondes de preuve SNARK pour le même programme volumineux. Pour des programmes petits ou moyens dans cette même étude, les deux systèmes restent proches, autour de 2,1 à 2,2 secondes pour STARK contre 9,3 secondes pour SNARK.
La conclusion pratique est que le temps de preuve dépend fortement de la structure du circuit, du compilateur utilisé et de la taille du programme. Les circuits SNARK bien optimisés pour de petites opérations (transferts, signatures, vérifications simples) restent généralement plus rapides à prouver. Les zkVM à usage général qui exécutent de longs programmes arbitraires, comme RISC Zero, tendent à mieux tirer parti de l’architecture STARK à mesure que la taille du calcul augmente.
Vérification : le contre-pied des benchmarks
C’est le point le plus contre-intuitif de la comparaison. En théorie, un SNARK de type Groth16 vérifie en temps constant, indépendamment de la taille du circuit, tandis qu’un STARK vérifie en temps logarithmique par rapport au nombre d’opérations. On pourrait donc s’attendre à ce que le SNARK gagne systématiquement. Dans la pratique, les benchmarks publiés se contredisent selon l’implémentation testée.
Dans l’étude comparative multi-plateformes de 2025, la vérification SNARK prend 1 807,42 ms sur M1 contre seulement 472,25 ms pour la vérification STARK sur la même machine, soit un STARK environ 3,8 fois plus rapide à vérifier dans ce cas précis. Mais un autre benchmark multi-protocoles publié la même année trouve l’inverse : environ 10 ms pour vérifier une preuve SNARK contre 16 ms pour une preuve STARK. Une évaluation séparée d’implémentations Groth16 sur les frameworks Arkworks et Gnark mesure des temps de vérification de 2,55 ms et 1,85 ms respectivement, nettement plus rapides que les deux exemples précédents.
Ce grand écart entre études s’explique par des choix d’implémentation très différents : bibliothèque cryptographique utilisée, taille du circuit testé, optimisations de bas niveau du couplage de courbe elliptique et paramètres FRI choisis pour le STARK. Comme le résume une analyse comparative publiée par Chainlink, le message à retenir n’est pas quel système gagne dans l’absolu, mais que la vérification, pour les deux familles, reste de l’ordre de la milliseconde à quelques centaines de millisecondes dans une implémentation bien optimisée, ce qui la rend compatible avec un usage en production dans les deux cas.
Configuration de confiance : Groth16, PLONK, Halo2 face à la transparence STARK
Groth16 exige une cérémonie de configuration de confiance spécifique à chaque circuit : un groupe de participants génère collectivement des paramètres secrets, dont les fragments individuels (appelés « toxic waste ») doivent être détruits pour garantir la sécurité du système. Si un seul participant honnête détruit sa part, le système reste sûr, mais toute modification du circuit oblige à relancer intégralement la cérémonie. C’est ce modèle qu’a utilisé Zcash pour sa cérémonie Sapling.
PLONK a introduit une chaîne de référence structurée universelle : une seule cérémonie suffit pour tous les circuits jusqu’à une taille maximale donnée, ce qui réduit considérablement la friction opérationnelle par rapport à Groth16. C’est cette architecture que zkSync Era utilise pour ses circuits de validité. Halo2, développé initialement par l’équipe Electric Coin (Zcash) puis repris par d’autres projets dont Scroll et Taiko, évite une cérémonie de confiance classique grâce à des arguments de produit interne récursifs, tout en conservant des propriétés de succinctness proches de PLONK.
Les zk-STARK n’ont, par construction, aucune cérémonie de confiance à organiser. Toute l’aléa nécessaire au protocole FRI provient de valeurs publiques et vérifiables. C’est un argument de poids pour des cas d’usage sensibles où la moindre suspicion de collusion lors d’une cérémonie pourrait nuire à la confiance dans le système, par exemple dans des applications d’identité numérique ou de vote électronique.
Résistance post-quantique : l’argument qui pèse de plus en plus lourd
Les zk-SNARK basés sur des couplages de courbes elliptiques reposent sur la difficulté du logarithme discret, un problème que l’algorithme de Shor résoudrait efficacement sur un ordinateur quantique suffisamment puissant. Ce n’est pas une faiblesse immédiate, mais un risque structurel identique à celui que court RSA ou ECDSA : toute preuve SNARK générée aujourd’hui sur courbe elliptique deviendrait falsifiable rétroactivement si un adversaire disposait un jour d’un ordinateur quantique capable de casser la courbe utilisée.
Les zk-STARK, en s’appuyant uniquement sur la résistance aux collisions de fonctions de hachage et sur de l’arithmétique de corps finis, sont considérés comme résistants aux attaques quantiques connues à ce jour. C’est l’un des arguments centraux mis en avant par StarkWare depuis la conception du système, largement documenté dans la littérature technique sur les preuves à divulgation nulle publiée par Ethereum.org. Cet avantage explique en partie pourquoi des projets orientés vers l’infrastructure publique ou la conformité réglementaire à long terme regardent de plus près l’architecture STARK, dans un contexte où les autorités de cybersécurité européennes poussent activement à la migration post-quantique de la cryptographie critique.
Certains projets SNARK travaillent à réduire cette dépendance en explorant des variantes basées sur des hypothèses de treillis (lattice-based) plutôt que sur des couplages elliptiques, mais ces constructions restent expérimentales et ne sont pas déployées en production en 2026. Pour l’instant, la résistance post-quantique reste un avantage structurel propre aux STARK et, plus largement, à toute preuve fondée uniquement sur du hachage.
Coûts de vérification on-chain sur Ethereum
La vérification d’une preuve Groth16 ou PLONK sur Ethereum s’appuie sur les précompilés de couplage de courbe elliptique intégrés nativement à l’EVM, ce qui ramène le coût typique à environ 200 000 à 400 000 gas par preuve pour les circuits de production utilisés par zkSync Era, Polygon zkEVM et Scroll. Ce coût reste quasiment constant, quelle que soit la complexité du calcul prouvé, grâce à la propriété de succinctness des couplages elliptiques.
La vérification d’une preuve STARK directement sur la couche 1 est nettement plus coûteuse, car l’EVM ne dispose d’aucun précompilé dédié au protocole FRI : le vérificateur doit recalculer des arbres de Merkle et des opérations de hachage entièrement en Solidity, ce qui peut représenter plusieurs millions de gas pour une preuve isolée. C’est pour cette raison que StarkNet et StarkEx ne vérifient pas chaque preuve individuellement sur L1, mais amortissent ce coût sur des lots pouvant regrouper plusieurs milliers de transactions, ramenant le coût par transaction à un niveau comparable, voire inférieur, à celui d’un rollup SNARK.
Tableau comparatif complet : zk-SNARK vs zk-STARK
| Critère | zk-SNARK | zk-STARK |
|---|---|---|
| Taille de preuve typique | 128 à 804 octets | 40 Ko à plus de 500 Ko |
| Temps de génération (petit circuit) | 55 ms à quelques secondes | 2 à 4 secondes |
| Temps de génération (grand programme) | peut dépasser 12 secondes | souvent plus rapide sur de très gros calculs |
| Temps de vérification | 1,85 ms à environ 1,8 s selon l’implémentation | 16 ms à environ 470 ms selon l’implémentation |
| Configuration de confiance | oui pour Groth16 (par circuit), SRS universel pour PLONK, minimale pour Halo2 | aucune, protocole transparent |
| Hypothèse de sécurité | couplages de courbes elliptiques, logarithme discret | résistance aux collisions de hachage, arithmétique de corps finis |
| Résistance post-quantique | non, vulnérable à l’algorithme de Shor | oui, jugée résistante aux attaques quantiques connues |
| Coût de vérification sur Ethereum L1 | environ 200 000 à 400 000 gas | plusieurs millions de gas si vérifié seul, amorti par lot |
| Langage / outillage principal | Circom, Noir, Halo2, snarkjs, Arkworks, Gnark | Cairo, Winterfell, Stone Prover, Miden VM |
| Complexité de vérification théorique | constante, O(1) | logarithmique, O(log n) |
| Maturité en production | élevée depuis 2016 (Zcash Sapling) | croissante depuis le lancement de StarkNet |
| Cas d’usage dominant en 2026 | rollups à petites transactions, paiements privés, identité | zkVM généralistes, rollups à très haut débit, calcul vérifiable |
Benchmarks croisés : ce que disent trois études indépendantes
Comparer des chiffres isolés est trompeur dans ce domaine, car les résultats varient fortement d’une implémentation à l’autre. Le tableau suivant met côte à côte trois sources distinctes publiées en 2025 et 2026, chacune avec sa propre méthodologie.
| Source du benchmark | Preuve SNARK | Preuve STARK | Génération SNARK | Génération STARK | Vérification SNARK | Vérification STARK |
|---|---|---|---|---|---|---|
| Analyse multi-plateformes 2025 (Apple M1) | 384 octets | 68 564 octets | 55,47 ms | 3 809,64 ms | 1 807,42 ms | 472,25 ms |
| Benchmark multi-protocoles 2025 | ~288 octets | ~45 000 octets | ~2,3 s | ~1,6 s | ~10 ms | ~16 ms |
| Évaluation Groth16 dédiée 2026 | 804,7 ± 1,7 octets | non mesuré | non mesuré | non mesuré | 662 ± 32 ms | non mesuré |
| Thèse d’optimisation zkVM 2025-2026 (programme large) | non mesuré | non mesuré | 12 488 ms | 4 708 ms | non mesuré | non mesuré |
Le seul point de consensus entre les trois études qui mesurent la taille de preuve est l’écart de un à deux ordres de grandeur en faveur du SNARK. Sur le temps de génération et de vérification, les résultats divergent selon la taille du circuit et l’implémentation testée, ce qui confirme qu’il n’existe pas de réponse universelle sur la vitesse brute des deux systèmes.
Coûts et tarification pour les équipes qui développent avec la preuve à divulgation nulle
Contrairement à un logiciel commercial, ni le zk-SNARK ni le zk-STARK ne sont vendus sous forme de licence payante : les principales bibliothèques, Circom, snarkjs, Arkworks, Gnark et Halo2 côté SNARK, Winterfell, Cairo, Stone Prover et Miden côté STARK, sont open source et gratuites. Le vrai coût se déplace donc vers l’infrastructure de calcul, les frais de gas et l’audit de sécurité du circuit lui-même.
| Poste de coût | zk-SNARK | zk-STARK |
|---|---|---|
| Licence des bibliothèques | gratuite, open source | gratuite, open source |
| Charge de calcul par preuve (proxy du coût cloud) | plus faible sur circuits petits/moyens : de 55 ms à quelques secondes | plus élevée sur circuits petits/moyens : 2 à 4 secondes, mais compétitive sur très gros calculs |
| Frais de gas pour la vérification on-chain | environ 200 000 à 400 000 gas par preuve | plusieurs millions de gas si vérifiée seule sur L1, amortie par lot de transactions |
| Coût organisationnel de la configuration initiale | cérémonie multi-parties nécessaire pour Groth16, SRS universel pour PLONK | aucun coût de cérémonie, setup transparent |
| Coût de stockage on-chain (calldata) par preuve | faible, 128 à 804 octets | nettement plus élevé, 40 Ko à plus de 500 Ko |
| Maturité de l’écosystème d’audit disponible | élevée, écosystème établi depuis Zcash (2016) | croissante, écosystème plus jeune autour de Cairo et StarkNet |
Cinq projets en production : qui utilise quoi
La théorie ne suffit pas à trancher, alors regardons comment les grands projets blockchain ont tranché en pratique.
- Zcash a été le premier réseau à déployer des zk-SNARK Groth16 en production pour ses transactions confidentielles (protocole Sapling), et reste aujourd’hui la référence historique de l’usage SNARK pour la confidentialité des paiements. Le projet explore depuis plusieurs années des circuits basés sur Halo2 pour réduire encore la dépendance à une cérémonie de confiance spécifique.
- zkSync Era, développé par Matter Labs, utilise des zk-SNARK de type PLONK pour générer des preuves de validité de son rollup, compilant les circuits depuis des contrats Solidity et Vyper. L’objectif affiché du projet est de rendre l’expérience développeur aussi proche que possible de l’Ethereum Virtual Machine classique, tout en s’appuyant sur des preuves succinctes pour la finalité des transactions.
- Polygon zkEVM s’appuie sur une architecture SNARK combinant des composants Groth16 et PLONK pour produire des preuves de validité vérifiées directement sur Ethereum, avec un objectif d’équivalence complète au bytecode EVM afin de permettre le déploiement de contrats existants sans réécriture.
- StarkNet, le rollup général de StarkWare, repose entièrement sur des zk-STARK et le langage Cairo, avec une preuve générée par le Stone Prover pour chaque lot de transactions. StarkWare met en avant l’argument de la transparence totale et de la résistance post-quantique comme différenciateur central face aux rollups basés sur des SNARK à couplage elliptique.
- RISC Zero a construit un zkVM généraliste basé sur une architecture proche du STARK, capable de prouver l’exécution de n’importe quel programme compilé pour le jeu d’instructions RISC-V, ce qui permet en théorie de générer une preuve de calcul vérifiable pour du code écrit dans des langages classiques comme Rust ou C++, sans avoir à réécrire la logique dans un langage de circuit dédié.
- Mina Protocol utilise des zk-SNARK récursifs pour maintenir une taille de chaîne constante quelle que soit la profondeur de son historique, une approche différente de celle des rollups classiques mais toujours fondée sur les couplages elliptiques. Chaque nouveau bloc inclut une preuve qui atteste de la validité de toute la chaîne précédente, ce qui permet à un nouveau nœud de vérifier l’état du réseau en téléchargeant une preuve unique plutôt que l’historique complet.
On observe une tendance claire : les projets centrés sur la confidentialité des paiements et les transferts de valeur (Zcash, zkSync, Polygon, Mina) ont majoritairement choisi le SNARK pour sa compacité, tandis que les projets orientés calcul généraliste et infrastructure publique à long terme (StarkNet, RISC Zero, Polygon Miden) misent davantage sur le STARK pour sa transparence et sa résistance post-quantique.
Quel système choisir selon votre cas d’usage
- Paiements privés à faible latence : privilégier le zk-SNARK (Groth16 ou PLONK), dont la preuve minuscule minimise les frais de transaction et le temps de vérification côté portefeuille.
- Rollup généraliste à très haut débit : le zk-STARK s’impose souvent, car le coût de vérification amorti sur un grand lot de transactions compense la taille de preuve plus importante.
- Identité numérique et conformité réglementaire : le zk-STARK est préférable dès qu’une absence totale de cérémonie de confiance est exigée par un régulateur ou un auditeur externe.
- Jeux vidéo et micro-transactions on-chain : le zk-SNARK reste plus adapté grâce à des preuves qui tiennent en quelques centaines d’octets, compatibles avec des appareils mobiles aux ressources limitées.
- Archivage et infrastructures publiques pensées pour durer des décennies : le zk-STARK est le choix le plus prudent, sa résistance aux attaques quantiques évitant une migration coûteuse plus tard.
- Calcul vérifiable généraliste (zkVM) : les architectures STARK, à l’image de RISC Zero, tendent à mieux passer à l’échelle sur de longs programmes arbitraires que les circuits SNARK classiques.
Guide de migration : faire évoluer une architecture existante
Migrer d’un système à l’autre, ou simplement moderniser un circuit SNARK existant, suit généralement une séquence d’étapes similaire, que ce soit pour passer d’un Groth16 à cérémonie spécifique vers un PLONK à SRS universel, ou pour évaluer une bascule complète vers un système STARK.
- Cartographier le circuit existant : nombre de contraintes, dépendances à une cérémonie de confiance spécifique, taille moyenne du calcul prouvé.
- Mesurer les coûts actuels sur trois axes : gas de vérification on-chain, temps de génération de preuve côté client ou serveur, taille de calldata par transaction.
- Identifier si la contrainte dominante est la taille de preuve (favorise le maintien en SNARK) ou le débit de transactions par lot (favorise une bascule vers STARK).
- Pour une migration SNARK vers SNARK plus moderne, recompiler le circuit avec Halo2 ou un système PLONK afin de remplacer la cérémonie par circuit par un SRS universel réutilisable.
- Pour une migration vers STARK, réécrire la logique métier en Cairo ou dans un langage compatible AIR, puis valider les traces d’exécution avec un prouveur comme Winterfell avant tout déploiement en production.
- Déployer en parallèle sur un réseau de test pendant plusieurs semaines, en comparant les coûts de gas réels et les temps de preuve mesurés en conditions de charge réelle, avant toute bascule du contrat de vérification en production.
- Prévoir un mécanisme de retour arrière (contrat de vérification legacy conservé actif) tant que le nouveau système n’a pas prouvé sa stabilité sur plusieurs mois d’exploitation.
Un exemple concret de commandes utilisées côté SNARK avec l’outil open source snarkjs, pour la génération et la vérification d’une preuve Groth16 :
circom circuit.circom --r1cs --wasm --sym
snarkjs groth16 setup circuit.r1cs pot12_final.ptau circuit_0000.zkey
snarkjs zkey contribute circuit_0000.zkey circuit_final.zkey
snarkjs groth16 prove circuit_final.zkey witness.wtns proof.json public.json
snarkjs groth16 verify verification_key.json public.json proof.jsonEt côté STARK, l’équivalent avec la chaîne d’outils Cairo de StarkWare :
cairo-compile program.cairo --output program.json
cairo-run --program=program.json --layout=starknet --print_output --trace_file=trace.bin --memory_file=memory.bin
cpu_air_prover --out_file=proof.json --private_input_file=private_input.json --public_input_file=public_input.json --prover_config_file=prover_config.json --parameter_file=cpu_air_params.json
cpu_air_verifier --in_file=proof.jsonRecursion de preuve : quand SNARK et STARK travaillent ensemble
La séparation entre les deux camps s’estompe de plus en plus dans les architectures de production les plus récentes. La technique de recursion de preuve consiste à faire vérifier une preuve par un autre système de preuve, plutôt que par un contrat on-chain classique. Concrètement, un calcul volumineux est d’abord prouvé en STARK, où le temps de génération reste raisonnable même sur de très grands programmes, puis cette preuve STARK, encore lourde de plusieurs dizaines de kilooctets, est elle-même donnée en entrée à un circuit SNARK dont la seule tâche consiste à vérifier que la preuve STARK est valide. Le résultat final est une preuve SNARK compacte de quelques centaines d’octets, qui peut être vérifiée à bas coût sur Ethereum grâce aux précompilés de couplage.
C’est exactement l’approche retenue par plusieurs zkEVM de deuxième génération : la partie la plus lourde du calcul (l’exécution complète de la machine virtuelle Ethereum) est prouvée avec une architecture proche du STARK pour profiter de sa meilleure scalabilité sur de longs programmes, puis le résultat est compressé via un « wrapper » SNARK avant d’être publié sur la couche 1. Cette combinaison cherche à cumuler les deux avantages : la scalabilité de calcul du STARK côté prouveur, et la compacité de vérification du SNARK côté vérificateur on-chain.
Cette hybridation a aussi un coût : elle ajoute une étape de calcul supplémentaire (la génération du SNARK de compression), ce qui augmente le temps de bout en bout par rapport à un système purement STARK ou purement SNARK. Les équipes qui envisagent cette voie doivent donc mesurer si le gain sur le coût de vérification final justifie la complexité d’implémentation et le temps de calcul additionnel du wrapper de recursion.
Avantages et inconvénients de chaque système
zk-SNARK, les avantages : preuve minuscule (quelques centaines d’octets), coût de vérification on-chain faible et stable, écosystème mature depuis Zcash en 2016, temps de preuve généralement plus rapide sur les circuits de petite et moyenne taille.
zk-SNARK, les inconvénients : dépendance à une configuration de confiance pour Groth16, vulnérabilité structurelle aux ordinateurs quantiques via les courbes elliptiques, outillage de circuit (Circom, R1CS) plus exigeant à auditer pour des développeurs non spécialistes.
zk-STARK, les avantages : aucune cérémonie de confiance requise, résistance jugée robuste face aux attaques quantiques connues, meilleure scalabilité théorique pour de très grands calculs, écosystème de langage (Cairo) pensé pour le calcul généraliste.
zk-STARK, les inconvénients : preuves 40 à plus de 500 fois plus lourdes que les SNARK, coût de vérification directe sur L1 nettement plus élevé sans précompilé dédié, écosystème d’outils encore plus jeune et moins standardisé que celui des SNARK.
Un dernier point mérite d’être ajouté à cette balance : le choix d’un système de preuve engage rarement un projet pour toujours. Grâce à la recursion de preuve et à la maturité croissante des deux écosystèmes, une équipe peut aujourd’hui démarrer avec un circuit SNARK simple pour valider son produit, puis migrer progressivement certaines briques vers une architecture STARK à mesure que le volume de calcul ou les exigences de conformité post-quantique augmentent, sans nécessairement tout réécrire d’un bloc.
Le verdict : ce que dit vraiment la donnée
Aucun des deux systèmes ne domine sur tous les critères, et c’est précisément ce que montrent les chiffres rassemblés dans cet article. Le zk-SNARK garde un avantage écrasant sur la taille de preuve, avec un rapport de 156 à 179 fois selon les études, ce qui en fait le choix par défaut pour tout ce qui touche aux paiements, à l’identité mobile et aux applications où chaque octet de calldata compte. Le zk-STARK, lui, gagne sur la transparence totale, l’absence de cérémonie de confiance et la résistance post-quantique, un argument dont le poids augmente chaque trimestre à mesure que les régulateurs européens accélèrent leurs feuilles de route de migration cryptographique.
Sur la vitesse pure, ni la génération ni la vérification ne tranchent de façon universelle : les résultats dépendent trop fortement de l’implémentation, du circuit et du matériel pour dégager une règle simple. La tendance de fond pour 2026 est plutôt à la coexistence : les applications de paiement et de confidentialité continuent de miser sur le SNARK, tandis que l’infrastructure de calcul généraliste et les projets pensés pour durer plusieurs décennies se tournent de plus en plus vers le STARK.
Questions fréquentes
Un zk-SNARK est-il moins sûr qu’un zk-STARK ?
Non, les deux offrent un niveau de sécurité cryptographique comparable pour les menaces actuelles. La différence porte sur la nature du risque à long terme : le SNARK dépend d’hypothèses sur les courbes elliptiques, vulnérables en théorie à un ordinateur quantique suffisamment puissant, tandis que le STARK repose uniquement sur la résistance aux collisions de hachage.
Pourquoi les preuves STARK sont-elles tellement plus grosses que les preuves SNARK ?
Parce qu’un STARK encode la preuve entière avec des arbres de Merkle et des vérifications de cohérence issues du protocole FRI, alors qu’un SNARK compresse l’ensemble du calcul en un unique point d’évaluation grâce à un couplage de courbe elliptique, une opération beaucoup plus compacte mathématiquement.
Un projet peut-il utiliser à la fois zk-SNARK et zk-STARK ?
Oui, certaines architectures combinent les deux : un calcul est d’abord prouvé en STARK pour sa scalabilité, puis cette preuve STARK est elle-même « enveloppée » dans une preuve SNARK plus compacte avant vérification finale sur Ethereum, une technique appelée recursion de preuve.
La configuration de confiance de Groth16 est-elle vraiment un risque ?
Le risque est faible en pratique tant qu’au moins un participant honnête à la cérémonie détruit sa part secrète, mais il reste un point de confiance sociale que les architectures PLONK, Halo2 et STARK cherchent justement à éliminer entièrement.
Quel système coûte le moins cher à vérifier sur Ethereum ?
Le zk-SNARK, grâce aux précompilés de couplage intégrés à l’EVM qui ramènent le coût de vérification à environ 200 000 à 400 000 gas par preuve, contre potentiellement plusieurs millions de gas pour une vérification STARK isolée sur la couche 1.
Cairo est-il uniquement utilisé pour les zk-STARK ?
Cairo a été conçu spécifiquement par StarkWare pour produire des traces d’exécution compatibles avec les prouveurs STARK, comme le Stone Prover, ce qui en fait aujourd’hui le langage de référence pour développer des applications STARK sur StarkNet.
Les zk-STARK vont-ils remplacer les zk-SNARK d’ici la fin de la décennie ?
Rien ne l’indique aujourd’hui : les deux architectures répondent à des besoins différents, et la tendance observée en 2026 est à la spécialisation plutôt qu’au remplacement, avec un usage croissant de la recursion de preuve pour combiner leurs avantages respectifs.
Faut-il des compétences en mathématiques avancées pour développer avec ces systèmes ?
Comprendre les fondations mathématiques (courbes elliptiques, polynômes, protocole FRI) aide à concevoir des circuits efficaces, mais des langages de haut niveau comme Circom, Noir ou Cairo permettent à des développeurs sans formation cryptographique poussée d’écrire des programmes prouvables, à condition de rester attentif aux contraintes de performance propres à chaque système.
