Mesurer les performances de SNARK : Frontends, backends et l'avenir

Un SNARK (Succinct Non-interactive Arguments of Knowledge) est une primitive cryptographique importante qui trouve des applications pour l'évolutivité de la blockchain (par exemple, les cumuls L2) et la confidentialité. Les SNARK permettent à quelqu'un de prouver à un vérificateur méfiant V (par exemple, la blockchain Ethereum) qu'ils connaissent certaines données (par exemple, un lot de transactions valides). Une façon naïve de le prouver serait d'envoyer les données à V, qui peut alors vérifier directement sa validité. Un SNARK réalise la même chose, mais avec de meilleurs coûts pour V. En particulier, une preuve SNARK devrait être plus courte que la preuve naïve comprenant les données elles-mêmes. (Pour plus de détails, voir le brouillon de mon manuel, Preuves, arguments et connaissance zéro. Pour une introduction aux SNARK, voir Sarah Meicklejohn's présentation à la crypto a16z Série de recherche d'été.)

Les coûts de vérification des SNARK peuvent varier, mais ils sont bien compris et souvent assez bons. Par exemple, Pinard les preuves coûtent environ 290,000 gaz à vérifier sur Ethereum, tandis que les preuves de StarkWare coûtent environ 5 millions de gaz. Les SNARK sont potentiellement applicables dans divers contextes, même en dehors des chaînes de blocs, par exemple en permettant l'utilisation de systèmes rapides mais non fiables. serveurs ainsi que matériel. 

Mais comme la vérification SNARK est généralement bon marché, les principaux déterminants de l'applicabilité sont les coûts du prouveur SNARK P. Dans cet article, j'explique comment estimer ces coûts pour déterminer quand il est raisonnable d'utiliser les SNARK et comment les SNARK pourraient s'améliorer à l'avenir. Il convient de noter qu'il s'agit d'un espace en évolution rapide et que plusieurs des projets abordés dans cet article améliorent activement leurs performances.

Mais d'abord : comment les SNARK sont déployés

Dans le déploiement SNARK, un développeur écrit généralement un programme informatique ψ qui prend en entrée les données w que le démonstrateur prétend connaître (w peuplements pour témoin), et vérifie que w est valable. Par exemple, dans les cumuls, le programme vérifiera que toutes les transactions dans w sont signés numériquement, ne font tomber aucun solde de compte en dessous de zéro, etc. Le programme ψ est ensuite alimenté par un Interface SNARK qui le compile dans un format plus adapté à l'application de la technologie SNARK. Ce format compatible avec SNARK est appelé un représentation intermédiaire (RI). 

En règle générale, l'IR est une sorte d'instance de satisfaction de circuit qui équivaut à ψ. Cela signifie que le circuit C prend en entrée les données w, ainsi que certaines entrées supplémentaires généralement appelées «conseils non déterministes», et exécute ψ on w. Les entrées de conseils sont utilisées pour aider C courir ψ, en gardant C petit. Par exemple, à chaque fois ψ divise deux nombres x ainsi que y, le quotient q et reste r peuvent être fournis à titre de conseils Cet C peut simplement vérifier que x = qy + r. Ce contrôle est moins cher que de faire C exécuter un algorithme de division pour calculer q ainsi que r à partir de rien.

Enfin, un SNARK pour la satisfaction du circuit est appliqué à C. C'est ce qu'on appelle le back-end SNARK. Pour une poignée de problèmes hautement structurés tels que multiplication matricielle, circonvolutionset plusieurs problèmes de graphe, il existe des SNARK connus qui évitent ce paradigme frontend/backend et permettent ainsi d'obtenir un prouveur beaucoup plus rapide. Mais cet article se concentre sur les SNARK à usage général.

Comme nous le verrons, les coûts de preuve du backend SNARK augmentent avec C's Taille. En gardant C petit peut être difficile, car les circuits sont un format extrêmement limité pour exprimer un calcul. Ils consistent en portes, connecté par fils. Chaque porte g reçoit des valeurs et applique un très fonction simple à ces valeurs. Le résultat est ensuite introduit dans des portes "aval" via les fils issus de g.

Évolutivité SNARK : combien de temps cela prend-il vraiment ?

La question clé est de savoir combien de temps prend le prouveur SNARK, par rapport à la simple réexécution ψ sur les données ? La réponse est la frais généraux de l'étalon du SNARK, par rapport à contrôle direct des témoins. Cette dernière expression fait référence au fait que, dans la preuve naïve dans laquelle P envoie w à V, V chèques wla validité de en exécutant ψ sur elle. 

Il est utile de diviser les frais généraux du prouveur en « frais généraux frontaux » et « frais généraux principaux ». Si l'évaluation du circuit C porte par porte est F fois plus cher que courir ψ, alors nous disons que la surcharge frontale est F. Si vous appliquez le prouveur principal à C is B fois plus cher que d'évaluer C porte par porte, alors nous disons que les frais généraux du backend sont B. Le surcoût total du prouveur est le produit, F·B. Ce surcoût multiplicatif peut être substantiel même si F ainsi que B sont individuellement modestes. 

Dans la pratique, F ainsi que B peuvent tous deux être d'environ 1000 ou plus. Cela signifie que les frais généraux totaux du prouveur par rapport à la vérification directe des témoins peuvent être de 1 à 10 millions ou plus. Un programme qui s'exécute pendant une seule seconde sur un ordinateur portable peut facilement conduire à un prouveur SNARK nécessitant des dizaines ou des centaines de jours de temps de calcul (mono-thread). Heureusement, ce travail est généralement parallélisable à des degrés divers (selon le SNARK). 

En résumé, si vous souhaitez utiliser un SNARK dans une application aujourd'hui, alors l'une des trois choses doit être vraie :

1. La vérification directe des témoins prend beaucoup moins d'une seconde sur un ordinateur portable.
2. La vérification directe des témoins se prête particulièrement à la représentation dans un circuit, de sorte que la surcharge frontale est faible.
3. Vous êtes prêt à attendre des jours que le prouveur SNARK se termine et/ou à payer pour d'énormes ressources de calcul parallèles.

TLe reste de cet article explique d'où viennent les frais généraux du frontend et du backend, et comment je les estime pour différents SNARK. Nous aborderons ensuite les perspectives d'amélioration. 

Séparer les frontends et les backends

Séparer complètement les frontends des backends peut être difficile car différents backends prennent en charge différents types de circuits. Par conséquent, les frontends peuvent différer en fonction du backend avec lequel ils s'attendent à s'interfacer.

Les backends SNARK prennent généralement en charge les circuits dits arithmétiques, ce qui signifie que les entrées des circuits sont des éléments d'un champ fini et que les portes du circuit effectuent l'addition et la multiplication de deux éléments de champ. Ces circuits correspondent à peu près à des programmes informatiques linéaires (pas de branches, d'instructions conditionnelles, etc.) qui sont de nature algébrique - c'est-à-dire que leur type de données primitif est constitué d'éléments de champ. 

La plupart des backends prennent en charge une généralisation des circuits arithmétiques souvent appelés instances R1CS (Rank-1 Constraint Satisfaction). A l'exception notable de Groth16 et ses prédécesseurs, ces SNARK peuvent également être conçus pour prendre en charge d'autres IR. Par exemple, StarkWare utilise quelque chose appelé Algebraic Intermediate Representation (AIR), qui est également similaire à une notion appelée Arithmétisation de PlonKish qui peut être pris en charge par PlonK et d'autres backends. La capacité de certains backends à prendre en charge des IR plus généraux peut réduire la surcharge des frontends qui produisent ces IR. 

Les backends varient également en termes de champs finis qu'ils prennent en charge de manière native. J'en parlerai plus en détail dans la section suivante.

Différentes approches des interfaces

Certains programmes informatiques (très particuliers) correspondent naturellement à des circuits arithmétiques. Un exemple est le programme informatique qui effectue une multiplication naïve de matrices sur un certain champ. Mais la plupart des programmes informatiques ne sont ni linéaires ni algébriques. Ils impliquent souvent des instructions conditionnelles, des opérations telles que la division entière ou l'arithmétique à virgule flottante qui ne correspondent pas naturellement à l'arithmétique sur corps fini, etc. Dans ces cas, les frais généraux du frontend seront substantiels. 

Une approche frontale populaire consiste à produire des circuits qui exécutent essentiellement étape par étape un processeur simple, également appelé machine virtuelle (VM). Les concepteurs frontaux spécifient un ensemble d'"opérations primitives" analogues aux instructions d'assemblage pour les vrais processeurs informatiques. Les développeurs qui souhaitent utiliser l'interface écriront soit des "programmes de vérification de témoins" directement dans le langage d'assemblage, soit dans un langage de niveau supérieur tel que Solidity, et verront leurs programmes automatiquement compilés en code d'assemblage. 

Par exemple, StarkWare Caire est un langage d'assemblage très limité dans lequel les instructions d'assemblage permettent à peu près l'addition et la multiplication sur un champ fini, les appels de fonction, et lit et écrit dans une mémoire immuable (c'est-à-dire à écriture unique). La VM Cairo est une architecture von Neumann, ce qui signifie que les circuits produits par le frontend prennent essentiellement un programme Cairo comme entrée publique et « exécutent » le programme sur le témoin. Le langage du Caire est Turing Complete - malgré son jeu d'instructions limité, il peut simuler des architectures plus standard, même si cela peut être coûteux. L'interface du Caire transforme les programmes du Caire en exécution T instructions primitives dans ce qu'on appelle un "degré-2 AIR avec T rangées et environ 50 Colonnes." Quoi exactement cela signifie n'est pas important pour ce poste, mais en ce qui concerne les prouveurs SNARK, cela correspond à des circuits avec entre 50 et 100 portes pour chacun des T étapes du CPU du Caire. 

RISC Zéro adopte une approche similaire au Caire, mais avec la machine virtuelle étant la soi-disant Architecture RISC-V, une architecture open source avec un riche écosystème logiciel qui gagne en popularité. En tant que jeu d'instructions très simple, la conception d'une interface SNARK efficace qui le prend en charge peut être relativement gérable (au moins par rapport aux architectures compliquées telles que x86 ou ARM). À partir de mai, RISC Zero tourne des programmes exécution T instructions RISC-V primitives en AIR de degré 5 avec 3T lignes et 160 Colonnes. Cela correspond à des circuits avec au moins 500 portes par étape du processeur RISC-V. D'autres améliorations sont prévues dans un proche avenir.

Les différents projets zkEVM (par exemple, zkSync 2.0, Scroll, zkEVM de Polygon) considèrent la machine virtuelle comme (duh) la machine virtuelle Ethereum. Le processus de transformation de chaque instruction EVM en un « gadget » équivalent (c'est-à-dire un circuit optimisé implémentant l'instruction) est beaucoup plus complexe que pour les architectures Cairo et RISC-V plus simples. Pour cette raison et d'autres, certains des projets zkEVM n'implémentent pas directement le jeu d'instructions EVM, mais compilent plutôt des programmes Solidity de haut niveau dans d'autres langages d'assemblage avant de les transformer en circuits. Les résultats de performance de ces projets sont en attente.

Les projets « d'émulateur CPU » tels que RISC-V et Cairo produisent un circuit unique capable de gérer tous les programmes dans le langage d'assemblage associé. Les approches alternatives sont "de type ASIC", produisant différents circuits pour différents programmes. Cette approche de type ASIC peut produire des circuits plus petits pour certains programmes, en particulier lorsque l'instruction d'assemblage que le programme exécute à chaque pas de temps ne dépend pas de l'entrée du programme. Par exemple, il peut potentiellement éviter entièrement les frais généraux du frontend pour les programmes linéaires tels que la multiplication matricielle naïve. Mais l'approche ASIC semble également très limitée ; pour autant que je sache, on ne sait pas comment l'utiliser pour prendre en charge des boucles sans limites d'itération prédéterminées. 

Le dernier composant de la surcharge frontale vient du fait que tous les SNARK utilisent des circuits qui fonctionnent sur des champs finis. Le processeur de votre ordinateur portable peut multiplier ou additionner deux nombres entiers avec une seule instruction machine. Si un frontal produit un circuit sur un champ de caractéristique suffisamment grande, il peut essentiellement simuler cette multiplication ou addition via l'opération de champ correspondante. Cependant, la mise en œuvre de l'opération sur le terrain sur un vrai CPU nécessitera généralement de nombreuses instructions machine (bien que certains processeurs modernes aient un support natif pour certains champs). 

Certains backends SNARK permettent des choix de champs plus flexibles que d'autres. Par exemple, si le backend utilise un groupe cryptographique G, le champ du circuit doit correspondre au nombre d'éléments dans G, ce qui peut être limitant. De plus, tous les champs ne prennent pas en charge les algorithmes FFT pratiques. 

Il n'y a qu'un seul SNARK implémenté, Freinage, qui prend en charge nativement les calculs sur des champs arbitraires (suffisamment grands). Accompagné de son descendants, il a les performances de preuve concrètes les plus rapides connues, même sur des champs pris en charge par d'autres SNARK, mais ses preuves sont actuellement trop volumineuses pour de nombreuses applications de blockchain. Travail récent cherche à améliorer la taille de la preuve, mais le démonstrateur est asymptotiquement plus lent et il semble être obstacles à la praticité.

Certains projets ont choisi de travailler sur des champs avec une arithmétique particulièrement rapide. Par exemple, Plonky2 et d'autres utilisent un champ de caractéristique 2⁶⁴ au 2 Février³² + 1 because arithmetic in this field can be implemented several times faster than in less structured fields. However, using such a small characteristic may lead to challenges in efficiently representing integer arithmetic via field operations (e.g., multiplying two 32-bit unsigned integers might yield a result greater than the field characteristic). 

 Mais quoi qu'il en soit, pour que tous les SNARK populaires d'aujourd'hui atteignent 128 bits de sécurité (sans augmentation significative des coûts de vérification), ils doivent travailler sur un champ de taille supérieure à 2¹²⁸. Pour autant que je sache, cela signifie que chaque opération sur le terrain nécessitera au moins une dizaine de multiplications machine 64 bits, et beaucoup plus d'additions et d'opérations au niveau du bit. Par conséquent, il convient de prendre en compte au moins un ordre de grandeur de surcharge frontale en raison du besoin de circuits fonctionnant sur des champs finis. 

Pour résumer, les interfaces existantes qui utilisent une abstraction de machine virtuelle produisent des circuits avec des portes 100x à 1000x par étape de la machine virtuelle, et éventuellement plus pour les machines virtuelles plus complexes. En plus de cela, l'arithmétique de champ fini est au moins 10 fois plus lente que les instructions analogues sur les processeurs modernes (avec des exceptions possibles si le processeur a un support intégré pour certains champs). Une "approche frontale ASIC" pourrait réduire certains de ces frais généraux, mais elle est actuellement limitée dans les types de programmes qu'elle peut prendre en charge.

Quels sont les goulots d'étranglement du backend ?

Les SNARK pour la satisfaction des circuits sont généralement conçus en combinant un protocole d'information théoriquement sécurisé appelé "PIO polynomiale" avec un protocole cryptographique appelé "schéma d'engagement polynomial.” Dans la plupart des cas, le goulot d'étranglement concret pour le démonstrateur est le schéma d'engagement polynomial. En particulier, ces SNARK font engager cryptographiquement le prouveur sur un ou plusieurs polynômes dont le degré est (au moins) |C|, le nombre de portes dans le circuit C. 

À son tour, le goulot d'étranglement concret dans le schéma d'engagement polynomial dépendra du schéma utilisé et de la taille du circuit. Mais il s'agira toujours de l'une des trois opérations suivantes : calcul de FFT, exponentiations dans un groupe cryptographique, ou Merkle-hachage. Le hachage Merkle n'est généralement un goulot d'étranglement que si le circuit est petit, nous n'en discuterons donc pas davantage. 

Engagements polynomiaux basés sur un log discret

En engagements polynomiaux basés sur la dureté du problème du logarithme discret dans un groupe cryptographique G (KZG, Bulletproofs, Doryet Hyrax-engagement), le démonstrateur doit calculer un Engagement vectoriel de Pedersen aux coefficients du polynôme. Il s'agit d'une multi-exponentiation, de taille égale au degré du polynôme. Dans les SNARK, ce degré correspond généralement à la taille |C| du circuit C.

Fait naïvement, une multi-exponentiation de taille |C| nécessite environ 1.5·|C|·enregistrer |G| ≈ 400·|C| opérations du groupe, où |G| indique le nombre d'éléments dans le groupe G. Cependant, il existe une approche, appelée algorithme de Pippenger, qui peut réduire cela d'un facteur d'environ log |C|. Pour les grands circuits (par exemple, |C| ≥ 225), ce journal |C| le facteur peut concrètement être de 25 ou plus, c'est-à-dire que pour les grands circuits, nous nous attendons à ce que l'engagement vectoriel de Pedersen puisse être calculable avec un peu plus de 10·|C| opérations de groupe. Chaque opération de groupe à son tour a tendance à être (en gros) environ 10 fois plus lente qu'une opération de champ fini. Les SNARK utilisant ces engagements polynomiaux sont aussi chers pour P comme environ 100·|C| opérations sur le terrain. 

Malheureusement, les SNARK existants ont des frais généraux supplémentaires en plus du facteur 100x ci-dessus. Par exemple:

• spartiateLe prouveur de , qui utilise l'engagement polynomial Hyrax, doit faire |C|^½ de nombreuses multi-exponentiations chacune de taille |C|^½, affaiblissant l'accélération de l'algorithme de Pippenger d'un facteur d'environ deux. 
• In Groth16, P doit travailler sur un groupe compatible avec l'appariement, dont les opérations sont généralement au moins 2 fois plus lentes que les groupes qui ne sont pas compatibles avec l'appariement. P doit également effectuer 3 multi-exponentiations au lieu de 1. Combinées, cela se traduit par au moins un ralentissement supplémentaire de facteur 6 par rapport aux 100·|C| estimation ci-dessus. 
• Marlin ainsi que Pinard exigent également des appariements, et leurs démonstrateurs s'engagent à bien plus de 3 polynômes. 
• Pour tout SNARK qui utilise Bulletproofs (par exemple, Halo2, qui est à peu près PlonK mais avec des engagements polynomiaux Bulletproofs plutôt que KZG), le démonstrateur doit calculer de manière logarithmique de nombreuses multi-exponentiations pendant la phase "d'ouverture" du schéma d'engagement, ce qui efface en grande partie toute accélération de Pippenger. 

En résumé, les SNARK connus utilisant les engagements vectoriels Pedersen semblent avoir une surcharge de backend d'au moins 200x et jusqu'à 1000x ou plus. 

Autres engagements polynomiaux

Pour les SNARK utilisant d'autres engagements polynomiaux (tels que VEN ainsi que Ligero-engagement), le goulot d'étranglement est que le prouveur doit effectuer de grandes FFT. Par exemple, dans les AIR de degré 2 produites par le Caire (avec 51 colonnes et T rangées, une par étape du processeur du Caire), le prouveur déployé de StarkWare effectue au moins 2 FFT par colonne, d'une longueur comprise entre 16 ·T ainsi que 32 ·T. Les constantes 16 ainsi que 32 dépendent des paramètres internes de FRI définis par StarkWare et peuvent être réduits, mais au prix d'une augmentation des coûts de vérification. 

De manière optimiste, une FFT de longueur 32·T prend environ 64·T·journal(32T) multiplications de champs. Cela signifie que même pour des valeurs relativement faibles de T (par exemple, T ≥ 2²⁰), le nombre d'opérations de champ par colonne est d'au moins 64·25·T= 1600·T. Ainsi, les frais généraux du backend semblent être au moins dans les milliers. De plus, il est possible que les grandes FFT soient encore plus goulottées par la bande passante mémoire que par les opérations sur le terrain. 

Dans certains contextes, la surcharge du backend des SNARK qui exécutent de grandes FFT peut être atténuée grâce à une technique appelée agrégation de preuves. Pour les cumuls, cela signifierait que P (le service de cumul) divise un gros lot de transactions en, disons, 10 lots plus petits. Pour chaque petit lot i, P produit une preuve SNARK πi de la validité du lot. Mais P ne publie pas ces preuves sur Ethereum, car cela entraînerait une multiplication par près de 10 des coûts du gaz. Au lieu de cela, le SNARK est appliqué à nouveau, cette fois pour produire une preuve π établissant que P sait π₁ ...,π₁₀. C'est-à-dire que le témoin P prétend connaître est les dix preuves π₁,…,π₁₀, et la vérification directe par témoin applique la procédure de vérification SNARK à chacune des preuves. Cette seule preuve π est posté sur Ethereum. 

Dans les engagements polynomiaux tels que FRI et Ligero-commit, il existe une forte tension entre P le temps et V coûts, avec des paramètres internes agissant comme un bouton qui peut échanger l'un contre l'autre. Depuis π₁ ,…,π₁₀ ne sont pas postés sur Ethereum, le bouton peut être réglé donc ces preuves sont grandes et leur production est plus rapide. Seulement dans l'application finale du SNARK, pour agréger π₁ ,…,π₁₀ en une seule preuve π, le schéma d'engagement doit-il être configuré pour assurer une petite preuve. 

StarkWare prévoit de déployer l'agrégation de preuves imminemment. C'est aussi l'objet de projets tels que Plonky2.

Quels sont les autres goulots d'étranglement à l'évolutivité de SNARK ?

Cet article s'est concentré sur le prouveur fiable, mais d'autres coûts du prouveur peuvent également constituer des goulots d'étranglement pour l'évolutivité. Par exemple, pour de nombreux backends SNARK, le prouveur doit stocker plusieurs éléments de champ pour chaque porte dans C, et ce coût d'espace peut être énorme. Par exemple, un programme ψ s'exécuter en une seconde sur un ordinateur portable peut effectuer peut-être un milliard d'opérations primitives sur un processeur moderne. Comme nous l'avons vu, en général, il faut s'attendre à C nécessiter bien plus de 100 portes pour une telle opération. Cela signifie 100 milliards de portes, ce qui, selon le SNARK, pourrait signifier des dizaines ou des centaines de téraoctets d'espace pour P. 

Autre exemple : de nombreux SNARK populaires (par exemple, Pinard, Marlin, Groth16) nécessitent une «cérémonie de configuration de confiance» compliquée pour générer une «clé de preuve» structurée qui doit être stocké par le démonstrateur. Autant que je sache, le la plus grande cérémonie de ce genre a généré une clé de preuve capable de supporter des circuits avec environ 2²⁸≈250 millions de portes. La clé de preuve a une taille de plusieurs dizaines de gigaoctets. 

Dans les contextes où l'agrégation de preuves est possible, ces goulots d'étranglement peuvent être considérablement atténués. 

Perspectives d'avenir : perspectives pour des SNARK plus évolutifs

Les frais généraux frontend et backend peuvent être de trois ordres de grandeur ou plus. Pouvons-nous nous attendre à ce que ceux-ci diminuent considérablement dans un proche avenir? 

Je pense que nous le ferons - jusqu'à un certain point. Tout d'abord, les backends les plus rapides aujourd'hui (par exemple, spartiate ainsi que Freinage, et d'autres SNARK qui combinent le protocole de contrôle de somme avec des engagements polynomiaux) ont de grandes preuves - généralement une racine carrée dans la taille du circuit - donc les gens ne les utilisent pas vraiment. Je m'attends à ce que la taille de la preuve et le temps de vérification soient considérablement réduits dans un avenir proche via une composition en profondeur avec des SNARK à petite preuve. Semblable à l'agrégation de preuves, cela signifie qu'un prouveur générerait d'abord une preuve SNARK π avec le SNARK "fast-prover, large-proof", mais pas envoyer π à V. Plutôt, P utiliserait un SNARK à petite preuve pour produire une preuve π» qu'il sait π, et envoyer π» à V. Cela pourrait réduire d'un ordre de grandeur les frais généraux du backend des SNARK qui sont populaires aujourd'hui. 

Deuxièmement, l'accélération matérielle peut aider. Une règle générale très approximative est que les GPU peuvent acheter une accélération de 10x par rapport aux CPU et les ASIC une accélération de 10x par rapport aux GPU. Cependant, j'ai trois préoccupations à ce sujet. Premièrement, les grandes FFT peuvent être goulottées par la bande passante de la mémoire plutôt que par les opérations sur le terrain, de sorte que les SNARK qui effectuent de telles FFT peuvent voir des accélérations limitées du matériel spécialisé. Deuxièmement, alors que cet article se concentrait sur le goulot d'étranglement de l'engagement polynomial, de nombreux SNARK exigent que le prouveur effectue d'autres opérations qui ne sont que légèrement moins coûteuses. Donc, briser le goulot d'étranglement de l'engagement polynomial (par exemple, accélérer les multi-exponentiations dans les SNARK basés sur des journaux discrets) peut laisser une nouvelle opération de goulot d'étranglement qui n'est pas vraiment meilleure que l'ancienne. (Par exemple, les SNARK, y compris Groth16, Marlin et PlonK, ont également le prouveur qui fait des FFT, en plus des multi-exponentiations.) Enfin, les champs et les courbes elliptiques qui conduisent aux SNARK les plus efficaces peuvent continuer à évoluer pendant un certain temps, ce qui peut créer des défis pour l'accélération du prouveur basé sur ASIC.

Du côté frontal, nous pouvons de plus en plus constater que l'approche «émulateur CPU» de projets tels que Cairo, RISC Zero, zkEVM et d'autres évolue assez bien (en termes de performances) avec la complexité des jeux d'instructions CPU. En effet, c'est précisément l'espoir de divers projets zkEVM. Cela peut signifier que, bien que la surcharge du frontend reste de trois ordres de grandeur ou plus, les frontends parviennent à prendre en charge des machines virtuelles qui correspondent de plus en plus aux architectures CPU réelles. Une préoccupation compensatoire est que les interfaces peuvent devenir compliquées et difficiles à auditer, à mesure que les gadgets codés à la main mettant en œuvre des instructions de plus en plus compliquées prolifèrent. Les méthodes de vérification formelle joueront probablement un rôle important pour répondre à cette préoccupation. 

Enfin, au moins dans les applications blockchain, nous pouvons constater que la plupart des contrats intelligents apparaissant dans la nature utilisent principalement des instructions simples et compatibles avec SNARK. Cela peut permettre de faibles frais généraux frontaux dans la pratique tout en conservant la généralité et l'amélioration de l'expérience de développement qui accompagne la prise en charge de langages de programmation de haut niveau comme Solidity et de jeux d'instructions riches, y compris ceux de l'EVM. 

***

Justin Thalier is professeur agrégé à l'Université de Georgetown. Avant de rejoindre Georgetown, il a passé deux ans en tant que chercheur scientifique chez Yahoo Labs à New York, avant d'être chercheur au Institut Simons pour la théorie de l'informatique à UC Berkeley. 

***

Remerciements : Je remercie Elena Burger d'avoir proposé le sujet de ce post, et de Arasu Arun, Joseph Bonneauet Sam Ragsdale pour des commentaires avisés. Un merci spécial également à mon éditeur, Tim Sullivan.

***

Les opinions exprimées ici sont celles du personnel individuel d'AH Capital Management, LLC (« a16z ») cité et ne sont pas les opinions d'a16z ou de ses sociétés affiliées. Certaines informations contenues ici ont été obtenues de sources tierces, y compris de sociétés de portefeuille de fonds gérés par a16z. Bien qu'elles proviennent de sources considérées comme fiables, a16z n'a pas vérifié ces informations de manière indépendante et ne fait aucune déclaration quant à l'exactitude durable des informations ou à leur pertinence dans une situation donnée. De plus, ce contenu peut inclure des publicités de tiers ; a16z n'a pas examiné ces publicités et n'approuve aucun contenu publicitaire qu'elles contiennent.

Ce contenu est fourni à titre informatif uniquement et ne doit pas être considéré comme un conseil juridique, commercial, d'investissement ou fiscal. Vous devriez consulter vos propres conseillers sur ces questions. Les références à des titres ou à des actifs numériques sont uniquement à des fins d'illustration et ne constituent pas une recommandation d'investissement ou une offre de fournir des services de conseil en investissement. En outre, ce contenu n'est ni destiné ni destiné à être utilisé par des investisseurs ou des investisseurs potentiels, et ne peut en aucun cas être invoqué pour prendre une décision d'investir dans un fonds géré par a16z. (Une offre d'investissement dans un fonds a16z ne sera faite que par le mémorandum de placement privé, le contrat de souscription et toute autre documentation pertinente de ce fonds et doit être lu dans son intégralité.) Tous les investissements ou sociétés de portefeuille mentionnés, référencés ou décrits ne sont pas représentatifs de tous les investissements dans des véhicules gérés par a16z, et rien ne garantit que les investissements seront rentables ou que d'autres investissements réalisés à l'avenir auront des caractéristiques ou des résultats similaires. Une liste des investissements effectués par des fonds gérés par Andreessen Horowitz (à l'exclusion des investissements pour lesquels l'émetteur n'a pas autorisé a16z à divulguer publiquement ainsi que des investissements non annoncés dans des actifs numériques cotés en bourse) est disponible sur https://a16z.com/investments /.

Les tableaux et graphiques fournis ici sont uniquement à des fins d'information et ne doivent pas être utilisés pour prendre une décision d'investissement. Les performances passées ne représentent pas les résultats futurs. Le contenu ne parle qu'à la date indiquée. Toutes les projections, estimations, prévisions, objectifs, perspectives et/ou opinions exprimées dans ces documents sont susceptibles d'être modifiées sans préavis et peuvent différer ou être contraires aux opinions exprimées par d'autres. Veuillez consulter https://a16z.com/disclosures pour des informations supplémentaires importantes.