Un guide du développeur pour le zkGalaxy

Il s'agit d'une heuristique extrêmement utile pour différencier les approches de prise en charge d'un zkEVM. Cependant, les zkEVM sont un sous-ensemble de toutes les façons possibles de créer des applications sans connaissance. Pour un programmeur qui souhaite tirer parti des propriétés uniques du calcul zk, à savoir concision, connaissance nulle et exactitude, un zkEVM n'est peut-être pas le meilleur choix. En présentant l'ensemble des outils de développement, j'espère fournir un guide qui facilitera le processus de prise de décision concernant la bonne pile zk pour votre application.

Au cours de la dernière année ou deux, il y a eu d'énormes progrès dans les outils zk. Ils approchent d'un point où les développeurs de logiciels ordinaires peuvent tirer parti des puissantes propriétés de zk sans une compréhension approfondie des mathématiques et de l'ingénierie sous-jacentes intimidantes. D'un autre côté, il y a eu une prolifération d'outils pour les utilisateurs expérimentés qui donnent aux experts zk un contrôle extrêmement fin sur la pile zk.

Les logiciels modernes sont construits sur d'innombrables couches d'abstraction pour maximiser la productivité des spécialistes. L'abstraction en ingénierie présente de nombreux avantages quelque peu intuitifs - un développeur Web n'a pas besoin de comprendre en profondeur le fonctionnement des systèmes d'exploitation. 

La clé pour créer de bonnes couches d'abstraction réutilisables est d'encapsuler la complexité d'une couche, puis de fournir des interfaces simples mais expressives pour les couches supérieures dans la pile à utiliser. Fait correctement, cela permet aux développeurs ayant différents domaines d'expertise et de connaissances de créer des outils utiles à travers la pile.

Sans surprise, ces mêmes principes s'appliquent aux systèmes zk, et ces couches d'abstraction deviennent suffisamment matures pour qu'un novice zk commence à les utiliser et à créer des applications aujourd'hui.

Arkworks-rs est un écosystème de bibliothèques Rust qui fournit des implémentations efficaces et sécurisées des sous-composants d'une application zkSNARK. Arkworks fournit les interfaces nécessaires aux développeurs pour personnaliser la pile logicielle d'une application zk sans avoir à réimplémenter les points communs avec d'autres bibliothèques existantes.

Avant Arkworks, la seule façon de créer une nouvelle application zk était de tout construire à partir de zéro. Les principaux avantages d'Arkworks-rs par rapport aux outils intégrés verticalement sur mesure sont le niveau de flexibilité, la réduction de l'ingénierie dupliquée et la réduction des efforts d'audit. Les lignes d'interface sensibles d'Arkworks entre les composants permettent un rythme d'évolutivité qui peut maintenir la pile pertinente au milieu du rythme effréné de l'innovation dans les technologies zk, sans obliger les équipes à tout reconstruire à partir de zéro.

Arkworks est destiné aux projets qui nécessitent un contrôle précis sur l'ensemble de la pile logicielle zk, mais qui ne souhaitent pas créer toutes les pièces redondantes à partir de zéro. Si vous envisagez une version personnalisée d'un circuit DSL parce que, par exemple, vous prototypez un nouveau système de preuve mais n'êtes pas sûr du schéma d'engagement ou de la courbe elliptique correspondante, arkworks vous permettra de basculer rapidement entre plusieurs options avec des interfaces partagées, plutôt que de repartir de zéro.

Afin de créer une preuve sur un calcul, ce calcul doit d'abord être exprimé sous une forme qu'un système zkSNARK peut comprendre. Plusieurs langages spécifiques à un domaine ont créé des langages de programmation qui permettent aux développeurs d'applications d'exprimer leur calcul de cette manière. Ceux-ci inclus Noir aztèque, de Starknet Caire, Circom, ZoKrates, et Aléo Leo entre autres. Le système de preuve sous-jacent et les détails mathématiques ne sont généralement pas exposés au développeur de l'application.

Les développeurs zkApp doivent maîtriser l'écriture de leurs programmes dans des langages spécifiques à un domaine. Certains de ces langages ressemblent beaucoup à des langages de programmation familiers, tandis que d'autres peuvent être assez difficiles à apprendre. Décomposons quelques-uns d'entre eux :

Caire – Starkware DSL nécessaire pour créer des applications sur Starknet. Compile dans un langage d'assemblage spécifique à Cairo qui peut être interprété par Cairo zkVM.

ZoKrates - ZoKrates est une boîte à outils pour les besoins courants de SNARK, y compris un langage de haut niveau pour écrire des circuits. ZoKrates a également une certaine flexibilité autour des courbes, du schéma de preuve et du backend, permettant aux développeurs d'échanger à chaud par un simple argument CLI.

Circom — Circom est un langage spécialement conçu pour la construction de circuits. Actuellement, c'est le langage de facto pour les circuits en production. La langue n'est pas spécialement ergonomique. Le langage lui-même vous rend intensément conscient du fait que vous écrivez des circuits.

Leo — Leo a été développé comme langage pour la blockchain Aleo. Leo a une syntaxe de type Rust et est spécialement conçu pour les transitions d'état à l'intérieur d'une blockchain.

Noir – Syntaxe inspirée de Rust. Architecturé autour de l'IR plutôt que du langage lui-même, ce qui signifie qu'il peut avoir une interface arbitraire. 

Tout développeur d'applications qui souhaite tirer parti des propriétés uniques de zk dans son application. Certaines de ces langues ont été testées au combat avec des milliards de dollars qui les traversent via des chaînes comme ZCash et Starknet. Bien que certains des projets dont nous parlerons ne soient pas tout à fait prêts pour une utilisation en production, écrire vos circuits dans l'un de ces langages est actuellement la meilleure stratégie, à moins que vous n'ayez besoin des contrôles plus fins fournis par une boîte à outils comme Arkworks.

L'objectif principal d'un zkEVM est de prendre une transition d'état Ethereum et de prouver sa validité à l'aide d'une preuve succincte d'exactitude sans connaissance. Comme mentionné dans l'article de Vitalik, il existe plusieurs façons de procéder avec des différences subtiles et des compromis correspondants. 

La principale différence technique entre tous ces éléments est l'endroit exact où, dans la pile du langage, le calcul est converti en une forme (arithmétisation) qui peut être utilisée dans un système de démonstration. Dans certains zkEVM, cela se produit dans les langages de haut niveau (Solidity, Vyper, Yul), tandis que d'autres approches tentent de prouver l'EVM jusqu'au niveau de l'opcode. Les compromis entre ces approches ont été traités en profondeur dans le message de Vitalik, mais je vais le résumer en une phrase : plus la conversion/arithmétisation est faible dans la pile, plus la pénalité de performance est importante.

Le principal défi de la création de preuves pour une machine virtuelle est que la taille du circuit augmente proportionnellement à la taille de TOUTES les instructions possibles pour chaque instruction exécutée. Cela se produit parce que le circuit ne sait pas quelles instructions seront exécutées dans chaque programme, il doit donc toutes les prendre en charge.

Cela signifie en pratique que vous payez (en coût de performance) pour l'instruction la plus chère possible, même lorsque vous n'exécutez que l'instruction la plus simple. Cela conduit à un compromis direct entre la généralisabilité et les performances - à mesure que vous ajoutez plus d'instructions pour la généralisabilité, vous payez pour cela sur chaque instruction que vous prouvez!

C'est un problème fondamental avec les circuits universels, mais avec nouveaux développements dans les technologies comme IVC (calcul incrémentiel vérifiable), cette limitation peut être améliorée en divisant le calcul en morceaux plus petits qui ont chacun des sous-circuits spécialisés et plus petits.

Les implémentations zkEVM d'aujourd'hui utilisent différentes stratégies pour atténuer l'impact de ce problème… Par exemple, zkSync extrait les opérations les plus coûteuses (principalement des précompilations cryptographiques comme les hachages et ECDSA) du circuit de preuve d'exécution principal dans des circuits séparés qui sont agrégés ensemble au fin via la récursivité snark. zkSync a adopté cette approche après avoir réalisé que la majorité de ses coûts provenaient de quelques instructions complexes.

À la base, la raison pour laquelle prouver un jeu d'instructions plus équivalent à EVM est plus cher est que l'EVM n'a pas été conçu pour les calculs zk. Abandonner l'EVM plus tôt dans la pile permet aux zkEVM de s'exécuter sur des jeux d'instructions plus optimisés pour zk, et donc moins chers à prouver.

Les clients idéaux pour un zkEVM sont les applications de contrat intelligentes qui nécessitent des transactions beaucoup moins chères que ce qui est disponible sur L1 Ethereum. Ces développeurs n'ont pas nécessairement l'expertise ou la bande passante pour écrire des applications zk à partir de zéro. Par conséquent, ils préfèrent écrire leurs applications dans des langages de niveau supérieur qui leur sont familiers, comme Solidity. 

Mise à l'échelle d'Ethereum est actuellement l'application la plus demandée de la technologie zk.

Un zkEVM est une solution de mise à l'échelle Ethereum qui atténue sans friction le problème de congestion qui limite les développeurs dApp L1.

L'objectif d'un zkEVM est de prendre en charge une expérience de développeur aussi proche que possible du développement actuel d'Ethereum. La prise en charge complète de Solidity signifie que les équipes n'ont pas à créer et à gérer plusieurs bases de code. C'est quelque peu impossible à faire parfaitement car les zkEVM doivent faire des compromis sur la compatibilité pour pouvoir générer des preuves de taille raisonnable dans un laps de temps raisonnable.

La principale différence entre zkSync et Scroll est où/quand dans la pile ils effectuent l'arithmétisation - c'est-à-dire où ils convertissent des constructions EVM normales en une représentation compatible SNARK. Pour zkSync, cela se produit lorsqu'ils convertissent le bytecode YUL en leur propre jeu d'instructions zk personnalisé. Pour Scroll, cela se produit à la fin, lorsque la trace d'exécution réelle est générée avec les opcodes EVM réels.

Ainsi, pour zkSync, tout est identique à l'interaction avec l'EVM jusqu'à ce que le bytecode zk soit généré. Pour Scroll, tout est pareil jusqu'à ce que le bytecode réel soit exécuté. Il s'agit d'une différence subtile, qui échange les performances contre le support. Par exemple, zkSync ne prendra pas en charge les outils de bytecode EVM comme un débogueur prêt à l'emploi, car il s'agit d'un bytecode complètement différent. Alors que Scroll aura plus de difficulté à obtenir de bonnes performances avec un jeu d'instructions, cela n'a pas été conçu pour zk. Il y a des avantages et des inconvénients aux deux stratégies et, en fin de compte, il y a beaucoup de facteurs exogènes qui auront un impact sur leur succès relatif.

???? Malgré son nom, LLVM n'est pas une VM (machine virtuelle). LLVM est le nom d'un ensemble d'outils de compilation qui est ancré par une représentation intermédiaire (IR) indépendante du langage.

=néant ; Fondation (à propos du nom, c'est un Blague sur l'injection SQL si vous vous posez la question) construit un compilateur qui peut convertir n'importe quel langage frontal LLVM en une représentation intermédiaire qui peut être prouvée dans un SNARK. Le zkLLVM est conçu comme une extension de l'infrastructure LLVM existante, une chaîne d'outils standard de l'industrie qui prend en charge de nombreux langages de haut niveau comme Rust, C, C++, etc.

Un utilisateur qui veut prouver un calcul implémentera simplement ce calcul en C++. Le zkLLVM prend ce code source de haut niveau qui est pris en charge par leur compilateur clang modifié (actuellement C++) et génère une représentation intermédiaire du circuit. À ce stade, le circuit est prêt à être prouvé, mais l'utilisateur peut souhaiter prouver le circuit en fonction de certaines entrées dynamiques. Pour gérer les entrées dynamiques, le zkLLVM dispose d'un composant supplémentaire appelé l'assignateur, qui génère une table d'assignation avec toutes les entrées et témoins entièrement prétraités et prêts à être prouvés aux côtés du circuit.

Ces 2 composants sont tout ce qui est nécessaire pour générer une preuve. Un utilisateur peut théoriquement générer une preuve lui-même, mais comme il s'agit d'une tâche de calcul quelque peu spécialisée, il peut souhaiter payer quelqu'un d'autre, qui possède le matériel, pour le faire à sa place. Pour ce mécanisme de découverte de contrepartie, =nil ; Foundation a également établi un « marché de la preuve » où les démonstrateurs rivalisent pour prouver le calcul pour les utilisateurs qui les paieront pour le faire. Cette dynamique de marché libre conduira les prouveurs à optimiser les tâches de preuves les plus précieuses.

Étant donné que chaque tâche de calcul à prouver est unique et génère un circuit différent, il existe un nombre infini de circuits que les prouveurs devront être capables de gérer. Cette généralisabilité forcée rend difficile l'optimisation des circuits individuels. L'introduction d'un marché de la preuve permet une spécialisation sur les circuits que le marché juge précieux. Sans ce marché, il serait difficile de convaincre un prouveur d'optimiser ce circuit en raison de ce problème naturel de démarrage à froid.

L'autre compromis est l'abstraction classique contre le contrôle. Les utilisateurs qui souhaitent utiliser cette interface facile à utiliser abandonnent le contrôle des primitives cryptographiques sous-jacentes. Pour de nombreux utilisateurs, il s'agit d'un compromis très valable à faire, car il est souvent préférable de laisser les experts en cryptographie prendre ces décisions pour vous.

Un zkVM décrit le sur-ensemble de toutes les machines virtuelles zk, tandis qu'un zkEVM est un type spécifique de zkVM, qui méritait d'être discuté en tant que sujet distinct en raison de sa prévalence aujourd'hui. Il existe quelques autres projets qui travaillent à la construction de zkVM plus généralisés basés sur des ISA en plus des crypto-VM sur mesure.

Au lieu de prouver l'EVM, le système pourrait prouver une architecture de jeu d'instructions (ISA) différente, telle que RISC-V ou WASM dans une nouvelle machine virtuelle. Deux projets qui travaillent sur ces zkVM généralisés sont RISC Zero et zkWASM. Plongeons un peu dans RISC Zero ici pour démontrer comment cette stratégie fonctionne et certains de ses avantages/inconvénients. 

RISC Zero est capable de prouver tout calcul exécuté sur une architecture RISC-V. RISC-V est une norme d'architecture de jeu d'instructions (ISA) open source qui gagne en popularité. La philosophie RISC (ordinateur à jeu d'instructions réduit) consiste à construire un jeu d'instructions extrêmement simple avec une complexité minimale. Cela signifie que les développeurs des couches supérieures de la pile finissent par assumer une plus grande charge dans la mise en œuvre des instructions utilisant cette architecture tout en simplifiant la mise en œuvre matérielle.

Cette philosophie s'applique également à l'informatique générale, les puces ARM ont tiré parti des jeux d'instructions de style RISC et ont commencé à dominer le marché des puces mobiles. Il s'avère que les jeux d'instructions plus simples ont également une plus grande efficacité énergétique et de surface de matrice.

Cette analogie vaut assez bien pour l'efficacité de la génération de preuves zk. Comme indiqué précédemment, lorsque vous prouvez une trace d'exécution en zk, vous payez la somme du coût de toutes les instructions pour chaque élément de la trace, donc des instructions plus simples et moins nombreuses sont préférables.

Du point de vue d'un développeur, l'utilisation de RISC Zero pour gérer les épreuves zk ressemble beaucoup à l'utilisation des fonctions AWS Lambda pour gérer l'architecture du serveur principal. Les développeurs interagissent avec RISC Zero ou AWS Lambda en écrivant simplement du code et le service gère toute la complexité du backend.

Pour RISC Zero, les développeurs écrivent Rust ou C++ (éventuellement tout ce qui cible RISC-V). Le système prend ensuite le fichier ELF généré lors de la compilation et l'utilise comme code d'entrée pour le circuit VM. Les développeurs appellent simplement prouver qui renvoie un objet de réception (qui contient la preuve zk de la trace d'exécution) que n'importe qui peut appeler "vérifier" de n'importe où. Du point de vue du développeur, il n'est pas nécessaire de comprendre le fonctionnement de zk, le système sous-jacent gère toute cette complexité.

Pour certains circuits basiques et réutilisables particulièrement utiles aux applications blockchain ou ailleurs, les équipes peuvent déjà avoir construit et optimisé ces circuits pour vous. Vous pouvez simplement fournir l'entrée pour votre cas d'utilisation particulier. Une preuve d'inclusion Merkle, par exemple, est quelque chose qui est couramment nécessaire dans les applications cryptographiques (listes de largages, Tornado Cash, etc.). En tant que développeur d'applications, vous pouvez toujours réutiliser ces contrats éprouvés et modifier simplement les couches supérieures pour créer une application unique.

Par exemple, les circuits de Tornado Cash peuvent être réutilisés pour une application de largage privé ou demande de vote privé. Manta et Semaphore construisent une boîte à outils complète de gadgets de circuit communs comme celui-ci qui peuvent être utilisés dans les contrats Solidity avec peu ou pas de compréhension des mathématiques sous-jacentes de la lune zk.

Comme discuté en détail, il existe une myriade d'options différentes pour développer une application zk, toutes avec leur propre ensemble unique de compromis. Ce tableau vous aidera à résumer cette matrice de décision afin qu'en fonction de votre niveau d'expertise zk et de vos besoins de performance, vous puissiez choisir le meilleur outil pour le travail. Ce n'est pas une liste exhaustive, je prévois de l'ajouter à l'avenir au fur et à mesure que je prends connaissance de plus d'outils à venir dans l'espace.

zk est à la pointe de plusieurs technologies, et sa construction nécessite une compréhension approfondie des mathématiques, de la cryptographie, de l'informatique et de l'ingénierie matérielle. Pourtant, avec de plus en plus de couches d'abstraction disponibles chaque jour, les développeurs d'applications peuvent tirer parti de la puissance de zk sans doctorat. Comme les limites des temps de vérification sont lentement levées au fil du temps via des optimisations à tous les niveaux de la pile, nous verrons probablement des outils encore plus simples pour le développeur moyen.

J'espère vous avoir convaincu, le développeur de logiciels curieux, que vous pouvez commencer à utiliser zk dans vos applications dès aujourd'hui. Bon piratage 🙂

Divulgations: Blockchain Capital est un investisseur dans plusieurs des protocoles mentionnés ci-dessus.

Les opinions exprimées dans chaque article de blog peuvent être les opinions personnelles de chaque auteur et ne reflètent pas nécessairement les opinions de Blockchain Capital et de ses affiliés. Ni Blockchain Capital ni l'auteur ne garantissent l'exactitude, l'adéquation ou l'exhaustivité des informations fournies dans chaque article de blog. Aucune représentation ou garantie, expresse ou implicite, n'est faite ou donnée par ou au nom de Blockchain Capital, l'auteur ou toute autre personne quant à l'exactitude, l'exhaustivité ou l'équité des informations contenues dans tout article de blog et aucune responsabilité n'est acceptée. pour toute information de ce type. Rien de ce qui est contenu dans chaque article de blog ne constitue un conseil d'investissement, réglementaire, juridique, de conformité ou fiscal ou autre, et ne doit pas non plus être invoqué pour prendre une décision d'investissement. Les articles de blog ne doivent pas être considérés comme des recommandations ou des sollicitations actuelles ou passées d'une offre d'achat ou de vente de titres ou d'adoption d'une stratégie d'investissement. Les articles de blog peuvent contenir des projections ou d'autres déclarations prospectives, qui sont basées sur des croyances, des hypothèses et des attentes qui peuvent changer en raison de nombreux événements ou facteurs possibles. Si un changement se produit, les résultats réels peuvent différer sensiblement de ceux exprimés dans les déclarations prospectives. Toutes les déclarations prospectives ne sont valables qu'à la date à laquelle ces déclarations sont faites, et ni Blockchain Capital ni chaque auteur n'assume l'obligation de mettre à jour ces déclarations, sauf si la loi l'exige. Dans la mesure où des documents, présentations ou autres éléments produits, publiés ou autrement distribués par Blockchain Capital sont référencés dans un article de blog, ces éléments doivent être lus avec une attention particulière à toute clause de non-responsabilité qui y est fournie.