Celer : Panthéon - Plateforme d'évaluation des frameworks de développement ZKP
TechFlow SélectionTechFlow Sélection
Celer : Panthéon - Plateforme d'évaluation des frameworks de développement ZKP
Résultats des tests de performance de SHA-256 sur divers frameworks de développement zk-SNARK et zk-STARK.
Dédié à des analyses Web3 approfondies
Ces derniers mois, nous avons consacré beaucoup de temps et d'efforts au développement d'une infrastructure de pointe construite à l’aide de preuves succinctes zk-SNARK. Cette plateforme innovante de nouvelle génération permet aux développeurs de créer des applications blockchain selon des paradigmes entièrement nouveaux.
Durant ce processus, nous avons testé et utilisé plusieurs frameworks de développement de preuves à divulgation nulle (ZKP). Bien que cette expérience ait été enrichissante, nous avons également constaté qu’en raison de la grande diversité des frameworks ZKP disponibles, les nouveaux développeurs éprouvent souvent des difficultés à identifier celui qui correspond le mieux à leur cas d’usage et à leurs exigences en termes de performance. Face à ce défi, nous avons estimé nécessaire de mettre en place une plateforme communautaire offrant des résultats complets de tests de performance, ce qui accélérerait grandement le développement de ces nouvelles applications.
Pour répondre à ce besoin, nous lançons Panthéon, une initiative communautaire à but non lucratif destinée à évaluer les frameworks de développement ZKP. La première étape consiste à encourager la communauté à partager des résultats reproductibles de tests de performance pour divers frameworks ZKP. Notre objectif ultime est de collaborer ensemble afin de créer et maintenir une plateforme d’évaluation largement reconnue, capable d’évaluer les frameworks de circuits bas niveau, les machines virtuelles zk (zkVM), les compilateurs, ainsi que les fournisseurs d’accélération matérielle. Nous espérons que cette initiative aidera les développeurs à mieux comparer les performances des frameworks disponibles, favorisant ainsi l’adoption généralisée des ZKP. En outre, en fournissant un ensemble de résultats de performance de référence, nous souhaitons aussi stimuler l’amélioration continue des frameworks ZKP eux-mêmes. Nous allons investir massivement dans ce projet et invitons tous les membres de la communauté partageant nos valeurs à y contribuer !
Première étape : Test de performance des frameworks de circuits avec SHA-256
Dans cet article, nous posons la première pierre de la construction du « Panthéon ZKP », en fournissant un ensemble de résultats reproductibles de tests de performance utilisant SHA-256 sur plusieurs frameworks de développement de circuits bas niveau. Bien que d'autres granularités ou primitives puissent être envisageables, nous avons choisi SHA-256 car il s'applique à un large éventail de cas d'utilisation des ZKP, notamment les systèmes blockchain, les signatures numériques, les zkDID, etc.
Par ailleurs, nous utilisons également SHA-256 dans nos propres systèmes, ce qui facilite son intégration pour nous ! 😂
Nos tests de performance évaluent les performances de SHA-256 sur divers frameworks de développement de circuits zk-SNARK et zk-STARK. À travers cette comparaison, nous souhaitons offrir aux développeurs des perspectives claires sur l'efficacité et l'utilité pratique de chaque framework. Nous espérons que ces résultats aideront les développeurs à choisir judicieusement le meilleur framework adapté à leurs besoins.
Systèmes de preuve
Ces dernières années, nous avons observé une prolifération des systèmes de preuve à divulgation nulle. Suivre toutes les avancées passionnantes dans ce domaine s'avère difficile. Nous avons donc soigneusement sélectionné les systèmes suivants en fonction de leur maturité et de leur adoption par les développeurs. Notre objectif est de fournir un échantillon représentatif de différentes combinaisons front-end / back-end.
-
Circom + snarkjs / rapidsnark : Circom est un langage DSL populaire pour écrire des circuits et générer des contraintes R1CS, tandis que snarkjs permet de produire des preuves Groth16 ou Plonk à partir de Circom. Rapidsnark est également un prouveur pour Circom générant des preuves Groth16, mais grâce à l'utilisation de l'extension ADX et à une parallélisation poussée de la génération de preuves, il est généralement bien plus rapide que snarkjs.
-
gnark : gnark est un framework complet en Golang développé par Consensys, supportant Groth16, Plonk et de nombreuses fonctionnalités avancées.
-
Arkworks : Arkworks est un framework Rust complet dédié aux zk-SNARKs.
-
Halo2 (KZG) : Halo2 est l'implémentation zk-SNARK de Zcash combinée à Plonk. Il dispose d'une arithmétique Plonkish très flexible, supportant de nombreuses primitives utiles telles que des portes personnalisées et des tables de recherche. Nous utilisons ici un fork de Halo2 avec KZG soutenu par la Fondation Ethereum et Scroll.
-
Plonky2 : Plonky2 est une implémentation SNARK basée sur les technologies PLONK et FRI de Polygon Zero. Plonky2 utilise un petit champ dit « Goldilocks » et supporte une récursion efficace. Dans nos tests, nous visons une sécurité conjecturée de 100 bits, en utilisant les paramètres optimisant le temps de preuve. Plus précisément, nous avons utilisé 28 requêtes Merkle, un facteur d'échelle de 8 et un défi PoW de 16 bits. De plus, nous avons défini num_of_wires = 60 et num_routed_wires = 60.
-
Starky : Starky est un framework STARK haute performance de Polygon Zero. Dans nos tests, nous ciblons également une sécurité conjecturée de 100 bits, en utilisant les paramètres offrant le meilleur temps de preuve. Spécifiquement, nous avons utilisé 90 requêtes Merkle, un facteur d'échelle de 2 et un défi PoW de 10 bits.
Le tableau ci-dessous résume les frameworks mentionnés ainsi que les configurations utilisées dans nos tests. Cette liste n’est pas exhaustive, et nous prévoyons d’étudier à l’avenir de nombreuses autres solutions de pointe (par exemple Nova, GKR, Hyperplonk).
Veuillez noter que ces tests de performance concernent uniquement les frameworks de développement de circuits. Nous prévoyons de publier prochainement un article distinct évaluant les performances des différentes zkVM (par exemple Scroll, Polygon zkEVM, Consensys zkEVM, zkSync, Risc Zero, zkWasm) et des frameworks de compilation IR (par exemple Noir, zkLLVM).
Méthodologie d'évaluation des performances
Afin d’évaluer les performances de ces différents systèmes de preuve, nous avons calculé le hachage SHA-256 de données de taille N octets, en expérimentant avec N = 64, 128, ..., 64K (Starky constitue une exception, où le circuit répète le calcul de SHA-256 sur une entrée fixe de 64 octets, tout en conservant le même nombre total de blocs de message). Le code de performance et la configuration du circuit SHA-256 sont disponibles dans ce dépôt.
En outre, nous avons mesuré les indicateurs de performance suivants pour chaque système :
-
Temps de génération de la preuve (y compris le temps de génération du témoin)
-
Utilisation maximale de la mémoire pendant la génération de la preuve
-
Utilisation moyenne du CPU (en pourcentage) pendant la génération de la preuve. (Cet indicateur reflète le degré de parallélisation du processus de génération.)
Notez que nous faisons certaines hypothèses simplificatrices concernant la taille des preuves et le coût de vérification, car ces aspects peuvent être atténués en combinant Groth16 ou KZG avant publication sur chaîne.
Matériel utilisé
Nous avons mené les tests de performance sur deux machines différentes :
-
Serveur Linux : 20 cœurs @2,3 GHz, 384 Go de RAM
-
Macbook M1 Pro : 10 cœurs @3,2 GHz, 16 Go de RAM
Le serveur Linux simule un environnement à nombreux cœurs et mémoire abondante. Le Macbook M1 Pro, typiquement utilisé pour le développement, possède un CPU plus puissant mais moins de cœurs.
Nous avons activé le multithreading optionnel, mais nous n’avons pas utilisé d’accélération GPU pour ces tests. Des tests GPU seront réalisés ultérieurement.
Résultats des tests de performance
Nombre de contraintes
Avant d’aborder les résultats détaillés, il est utile de comprendre la complexité de SHA-256 en examinant le nombre de contraintes dans chaque système de preuve. Il est important de noter que le nombre de contraintes ne peut pas être directement comparé entre différents schémas arithmétiques.
Les résultats ci-dessous correspondent à une taille d'antécédent de 64 Ko. Bien que les résultats puissent varier selon la taille, ils s'échelonnent approximativement de façon linéaire.
-
Circom, gnark et Arkworks utilisent tous le même algorithme R1CS ; le nombre de contraintes R1CS pour le calcul de SHA-256 sur 64 Ko se situe entre 30 et 45 millions. Les différences entre Circom, gnark et Arkworks proviennent probablement de différences de configuration.
-
Halo2 et Plonky2 utilisent tous deux l'arithmétique Plonkish, avec un nombre de lignes compris entre 2^22 et 2^23. Grâce à l’utilisation de tables de recherche, l’implémentation de SHA-256 dans Halo2 est nettement plus efficace que celle de Plonky2.
-
Starky utilise l'algorithme AIR, nécessitant 2^16 étapes de transition dans la table d'exécution.
Temps de génération de la preuve
[Figure 1] illustre le temps de génération de preuve pour chaque framework avec SHA-256, sur différentes tailles d'antécédents, testé sur le serveur Linux. Voici les principales observations :
-
Pour SHA-256, les frameworks Groth16 (rapidsnark, gnark et Arkworks) génèrent des preuves plus rapidement que les frameworks Plonk (Halo2 et Plonky2). Cela s'explique par le fait que SHA-256 repose principalement sur des opérations bit à bit, dont les valeurs sont 0 ou 1. Pour Groth16, cela réduit considérablement le calcul de multiplication scalaire sur courbe elliptique vers une simple addition de points. En revanche, ces valeurs binaires ne sont pas directement exploitées dans les calculs Plonk, donc la structure particulière des connexions dans SHA-256 n'améliore pas l'efficacité des frameworks Plonk.
-
Parmi tous les frameworks Groth16, gnark et rapidsnark sont 5 à 10 fois plus rapides que Arkworks et snarkjs, grâce à leur capacité supérieure à paralléliser la génération de preuves sur plusieurs cœurs. Gnark est 25 % plus rapide que rapidsnark.
-
Concernant les frameworks Plonk, lorsque la taille de l'antécédent est ≥ 4 Ko, Plonky2 est 50 % plus lent que Halo2 pour SHA-256. Cela s'explique par le fait que l'implémentation d'Halo2 utilise largement des tables de recherche pour accélérer les opérations bit à bit, ce qui réduit le nombre de lignes d'environ moitié par rapport à Plonky2. Toutefois, si l'on compare Plonky2 et Halo2 avec un nombre de lignes identique (par exemple, Halo2 avec antécédent > 2 Ko contre Plonky2 avec > 4 Ko), Plonky2 devient 50 % plus rapide. Si nous implémentions SHA-256 avec des tables de recherche dans Plonky2, nous nous attendrions à ce qu’il soit encore plus rapide qu’Halo2, malgré une taille de preuve plus grande.
-
Inversement, pour de petites tailles d’antécédent (≤ 512 octets), Halo2 est plus lent que Plonky2 (et d'autres frameworks), car le coût fixe de configuration des tables de recherche représente une grande partie des contraintes. Toutefois, à mesure que la taille augmente, les performances d’Halo2 deviennent plus compétitives, et pour des antécédents jusqu’à 2 Ko, son temps de génération reste presque constant, montrant une évolution quasi linéaire.
-
Comme prévu, le temps de génération de preuve de Starky est beaucoup plus court (5 à 50 fois) que celui de tout framework SNARK, mais au prix d’une taille de preuve bien plus importante.
-
Il convient également de noter que même si la taille du circuit croît linéairement avec la taille de l’antécédent, le temps de génération des SNARKs croît de manière super-linéaire en raison du FFT en O(n log n) (bien que cet effet soit peu visible sur les graphiques à cause de l’échelle logarithmique).
Nous avons également effectué les tests de temps de génération sur Macbook M1 Pro, comme illustré dans [Figure 2]. Cependant, notez que rapidsnark n’est pas inclus dans ces tests en raison du manque de support pour l’architecture arm64. Pour utiliser snarkjs sur arm64, nous avons dû recourir à WebAssembly pour générer le témoin, ce qui est plus lent que la génération C++ utilisée sur le serveur Linux.
Plusieurs observations supplémentaires ont été faites lors des tests sur Macbook M1 Pro :
-
À l’exception de Starky, tous les frameworks SNARK rencontrent des erreurs de mémoire insuffisante (OOM) ou commencent à utiliser la mémoire d’échange (swap), ralentissant ainsi la génération, lorsque la taille de l’antécédent augmente. Plus précisément, les frameworks Groth16 (snarkjs, gnark, Arkworks) commencent à utiliser le swap dès 8 Ko, et gnark échoue en OOM à partir de 64 Ko. Halo2 atteint ses limites mémoire à partir de 32 Ko. Plonky2 commence à utiliser le swap à partir de 8 Ko.
-
Les frameworks basés sur FRI (Starky et Plonky2) sont environ 60 % plus rapides sur Macbook M1 Pro que sur le serveur Linux, alors que les autres frameworks montrent des temps similaires sur les deux machines. Ainsi, même sans tables de recherche, Plonky2 atteint un temps de preuve presque identique à celui d’Halo2 sur Macbook M1 Pro. La raison principale est que le Macbook M1 Pro possède un CPU plus puissant mais moins de cœurs. FRI repose surtout sur des opérations de hachage, sensibles au cycle d’horloge du CPU, mais moins parallélisables que KZG ou Groth16.
Utilisation maximale de la mémoire
[Figure 3] et [Figure 4] montrent respectivement l'utilisation maximale de la mémoire pendant la génération de preuve sur le serveur Linux et le Macbook M1 Pro. Ces résultats conduisent aux observations suivantes :
-
Parmi tous les frameworks SNARK, rapidsnark est le plus efficace en termes de mémoire. On observe également qu’Halo2 utilise plus de mémoire pour de petits antécédents en raison du coût fixe des tables de recherche, mais devient plus économe globalement pour de grandes tailles.
-
Starky est plus de 10 fois plus efficace en mémoire que les frameworks SNARK, en partie parce qu’il utilise moins de lignes.
-
Il convient de noter que, sur Macbook M1 Pro, l'utilisation de la mémoire reste relativement stable à mesure que la taille augmente, en raison de l'utilisation du swap.
Utilisation du CPU
Nous avons évalué le degré de parallélisation de chaque système en mesurant l’utilisation moyenne du CPU pendant la génération de la preuve SHA-256 avec un antécédent de 4 Ko. Le tableau ci-dessous indique l’utilisation moyenne du CPU sur le serveur Linux (20 cœurs) et le Macbook M1 Pro (10 cœurs) (avec entre parenthèses l’utilisation moyenne par cœur).
Principales observations :
-
Gnark et rapidsnark affichent les taux d’utilisation du CPU les plus élevés sur le serveur Linux, indiquant une bonne exploitation des cœurs multiples et une forte parallélisation. Halo2 présente également de bonnes performances en parallélisation.
-
La plupart des frameworks ont un taux d’utilisation du CPU environ deux fois plus élevé sur le serveur Linux que sur le Macbook M1 Pro, sauf snarkjs.
-
Bien que l’on pensait initialement que les frameworks basés sur FRI (Plonky2 et Starky) auraient du mal à exploiter efficacement plusieurs cœurs, leurs performances dans nos tests ne sont pas inférieures à certains frameworks Groth16 ou KZG. L’évolution de leur utilisation du CPU sur des machines à davantage de cœurs (par exemple 100) reste à observer.
Conclusion et recherches futures
Cet article présente une comparaison complète des performances de SHA-256 sur divers frameworks de développement zk-SNARK et zk-STARK. Cette analyse comparative offre une vision approfondie de l'efficacité et de l'utilité pratique de chaque framework, aidant ainsi les développeurs ayant besoin de générer des preuves succinctes pour des opérations SHA-256.
Nous constatons que les frameworks Groth16 (comme rapidsnark, gnark) sont plus rapides que les frameworks Plonk (comme Halo2, Plonky2) pour générer des preuves. Les tables de recherche dans l'arithmétique Plonkish réduisent significativement le nombre de contraintes et le temps de preuve pour SHA-256 avec de grands antécédents. En outre, gnark et rapidsnark excellent dans l'utilisation de plusieurs cœurs pour paralléliser la génération. En revanche, Starky produit des preuves beaucoup plus rapidement, au prix d'une taille de preuve substantiellement plus grande. En matière d'efficacité mémoire, rapidsnark et Starky surpassent les autres frameworks.
Cette initiative constitue la première étape vers la création du « Panthéon ZKP », une plateforme d'évaluation des preuves à divulgation nulle. Nous reconnaissons que ces résultats ne suffisent pas à constituer la plateforme complète que nous ambitionnons. Nous sommes ouverts à toute critique et suggestion, et invitons activement toute la communauté à contribuer, afin de rendre l'utilisation des ZKP plus accessible et facile. Nous sommes également disposés à financer des contributeurs individuels pour couvrir les coûts liés aux ressources informatiques nécessaires à de grands tests de performance. Ensemble, nous espérons améliorer l'efficacité et l'utilité pratique des ZKP, au bénéfice de toute la communauté.
Enfin, nous tenons à remercier chaleureusement les équipes de Polygon Zero, de gnark chez Consensys, de Pado Labs et de Delphinus Lab pour leurs retours précieux et leurs relectures des résultats de performance.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
