Un aperçu de Rollup

Rollup est une catégorie de solutions de mise à l'échelle de la couche 2 de la blockchain. Dans les schémas Rollup, les opérateurs du projet exploitent une plateforme de couche 2 relativement indépendante sous la chaîne principale étendue (c'est-à-dire la couche 1). Les utilisateurs peuvent exécuter des contrats ou transférer des jetons sur la plateforme de couche 2.

La sécurité de la plateforme Layer 2 est garantie par la blockchain Layer 1 sur laquelle elle repose. Lorsqu'un nouveau bloc est généré dans la couche 2, les informations de transaction du bloc de la couche 2, ainsi que la racine de l'état post-transaction de la couche 2, sont regroupées en une transaction Rollup et publiées sur la chaîne de la couche 1. L'exécution réelle de la transaction et les changements d'état sont traités sur la plateforme de la couche 2 en dessous de la chaîne principale, et la couche 1 doit seulement vérifier la justesse des transitions d'état de la couche 2. Étant donné que le coût de vérification de la justesse des transitions d'état est bien inférieur à l'exécution de ces transactions sur la couche 1, la couche 2 peut réaliser une expansion de la plateforme Layer 1. La plateforme Layer 2 peut offrir un débit de transaction plus élevé et des coûts de transaction inférieurs par rapport à la couche 1 tout en maintenant une sécurité équivalente.

Comparé à d'autres schémas de transaction hors chaîne, les Rollups ont deux caractéristiques :

• La disponibilité des données d'état pour la deuxième couche est résolue en les stockant sur la chaîne principale. La plateforme de couche 2 enregistre toutes les informations de transaction ou les changements d'état complets de la couche 2 en blocs sur la chaîne principale. Si l'état de la couche 2 est perdu, n'importe qui peut récupérer l'état manquant à partir des informations stockées sur la chaîne principale.
• Dans le schéma Rollup, les changements de racine d'état de la couche 2 emballés et stockés sur la chaîne principale doivent être vérifiés d'une manière ou d'une autre sur la chaîne principale. Après vérification, l'état de la couche 2 sera verrouillé sur la chaîne principale de la couche 1. Par conséquent, dans le cadre d'un schéma de vérification sécurisé, la couche 2 peut bénéficier du même niveau de sécurité que la couche 1.

Basé sur les méthodes de vérification des mises à jour d'état de la couche 2 par la chaîne principale, il existe actuellement deux principaux types de solutions technologiques Rollup. L'un est Optimistic Rollup. Dans ce type de schéma, le contrat de la chaîne principale ne vérifie pas directement le nouvel état soumis par la couche 2. Au lieu de cela, une période de contestation est préparée pour chaque nouvel état soumis. Comme Rollup soumet toutes les informations de transaction à la chaîne principale et les rend publiques, n'importe qui peut vérifier la mise à jour d'état (surtout lorsque la mise à jour implique leur propre portefeuille). Si le nouvel état est incorrect, un vérificateur peut générer une preuve de fraude contre cet état erroné et la soumettre dans la période de contestation, invalidant ainsi la mise à jour d'état incorrecte.

Un autre type de solution Rollup est zk Rollup. Dans ce type de schéma, après avoir exécuté la mise à jour de l'état de la couche 2, l'opérateur de la couche 2 doit fournir une preuve de connaissance nulle de la correction de la mise à jour de l'état et la soumettre à la chaîne principale avec la mise à jour de l'état. Le contrat sur la chaîne principale vérifiera la preuve pour déterminer la correction de la mise à jour de l'état.

Contrairement au schéma Optimistic Rollup, zk Rollup ne nécessite pas une période de défi prolongée pour finalement confirmer les transactions de la couche 2 et peut être confirmé plus rapidement. De plus, zk Rollup ne repose pas sur l'hypothèse qu'il y aura toujours des vérificateurs honnêtes dans le réseau qui soumettront en temps voulu des preuves de fraude en cas de fraude. Cependant, en même temps, zk Rollup est confronté à des problèmes tels que le coût de calcul élevé de la technologie de preuve de connaissance nulle, la complexité et la difficulté de développement, qui entravent la mise en œuvre pratique de la technologie zk Rollup dans les Rollups. Avec le développement ultérieur de la technologie de preuve de connaissance nulle au cours des deux dernières années, ces obstacles sont progressivement surmontés. La technologie zk Rollup commence à occuper une part de plus en plus importante du marché de la couche 2.

Comme le montre la figure ci-dessous, dans le domaine de mise à l'échelle Rollup de couche 2, zkRollup occupe déjà plus de la moitié du territoire et se développe rapidement.

Source de l'image

Données récupérées le : 18 janvier 2024

De zkRollup spécialisé à zkRollup général

Au cours de son développement, zkRollup a principalement traversé deux étapes. Le premier type est le zkRollup non général, tandis que le second type est le zkRollup général capable d'exécuter des contrats arbitraires complets de Turing.

La différence entre ces deux types de technologie zkRollup réside principalement dans le fait que la plateforme de couche 2 exécute une logique spécialisée limitée écrite par le fournisseur de la plateforme ou une logique de contrat intelligent arbitraire écrite par les utilisateurs dans les transactions.

Dans les projets zkRollup non généraux (comme zkSync Lite, qui se classe 8e dans la figure ci-dessus), les utilisateurs ne peuvent effectuer que quelques types d'opérations de transaction, telles que les transferts de jetons FT (jetons fongibles), les paiements, les échanges et les transferts de jetons NFT (jetons non fongibles). La logique de transaction pour ces opérations ne peut être définie et mise en œuvre que par les propriétaires du projet.

Grâce à de tels projets zkRollup, nous pouvons transférer avec des frais beaucoup plus bas par rapport au réseau principal Ethereum et obtenir un débit de transaction plus élevé. Cependant, si nous voulons essayer un contrat intéressant sur la chaîne, nous ne pourrons pas le faire.

Pourquoi les zkRollups spécialisés ne permettent-ils pas aux utilisateurs de déployer et d'utiliser leurs propres contrats intelligents ? Cela nous ramène à l'architecture de preuve des zkRollups eux-mêmes.

Pour garantir que les transitions d'état de L2 sont correctes et fiables, dans zkRollup, toute la logique des transitions d'état de L2 doit être écrite sous forme de circuits de preuve de connaissance nulle et vérifiée par les contrats L1. Seuls les états qui passent la vérification peuvent être acceptés par L1 et finalement compléter le Rollup. Ce processus exige que toute la logique d'exécution des transactions de la plate-forme zkRollup soit vérifiée dans le circuit de preuve de connaissance nulle. Cependant, le support de l'exécution de la logique de contrat arbitraire dans les circuits de preuve de connaissance nulle est un défi (les raisons de cette difficulté seront expliquées plus tard dans le texte). Par conséquent, les premiers projets zkRollup ne prenaient souvent en charge qu'un nombre limité de transactions relativement simples.

Pouvoir exécuter seulement un nombre fixe de transactions simples ne répond évidemment pas à nos attentes pour zkRollup. Heureusement, la technologie zkVM (Machine Virtuelle à Connaissance Zéro) a résolu la difficulté de prouver l'exécution de n'importe quel code Turing-complet arbitraire au sein de circuits de preuve à connaissance zéro, rendant possible la plateforme généraliste zkRollup. Ensuite, cet article présentera les principes de mise en œuvre de zkVM, permettant aux lecteurs de comprendre comment fonctionne cette partie la plus centrale de la technologie généraliste zkRollup.

Les principes de mise en œuvre de zkVM

Avant d'introduire les principes du zkVM, nous fournirons d'abord une brève introduction à la technologie de preuve de connaissance nulle. Ici, nous n'avons pas besoin d'une compréhension détaillée des principes mathématiques sous-jacents des preuves de connaissance nulle ; il suffit de comprendre ce que les preuves de connaissance nulle peuvent faire, comment elles sont utilisées, et les limitations imposées par leurs circuits de preuve spécialisés.

Une Introduction aux Preuves de Connaissance Zéro

Les preuves de zéro connaissance dans zkRollup servent à prouver que les transactions de la couche 2 ont été exécutées correctement et que l'état de la couche 2 a été mis à jour correctement.

Pour atteindre cette fin, le circuit zkVM doit prouver que tout contrat intelligent déployé sur la couche 2 a été exécuté correctement. Avant d'introduire les principes du zkVM, nous devons d'abord discuter du rôle des preuves de connaissance nulle et de leur fonctionnement.

Pourquoi les preuves de connaissance nulle sont nécessaires

La preuve de connaissance nulle est une primitive cryptographique qui permet à un prouveur de convaincre un vérificateur de la véracité d'une déclaration sans révéler d'informations supplémentaires au vérificateur.

Les preuves de zéro connaissance ont trois propriétés fondamentales :

• Complétude : Si l'énoncé à prouver est vrai, un vérificateur honnête (c'est-à-dire suivant correctement le protocole) sera convaincu de ce fait par un prouveur honnête.
• Solidité : Si l'énoncé à prouver est faux, un prouveur malhonnête a seulement une chance négligeable de convaincre l'honnête vérificateur que c'est vrai.
• Zéro-connaissance : En plus de la déclaration étant vraie, le vérificateur ne peut obtenir aucune information supplémentaire du processus de vérification.

Avec l'exhaustivité des preuves de zéro-connaissance, lorsque le prouveur termine un calcul complexe, il peut produire une preuve qui convainc le vérificateur que les données de sortie obtenues à partir des données d'entrée sont le résultat fourni par l'exécutant. La justesse des preuves de zéro-connaissance garantit que lorsque l'exécutant fournit un résultat incorrect, il ne peut pas générer une preuve valide.

Par conséquent, avec l'exhaustivité et la solidité des preuves à divulgation nulle, nous pouvons externaliser en toute confiance ces calculs complexes à d'autres et vérifier, par le biais d'un processus de vérification relativement simple, si le calcul est correct, sans avoir à faire confiance à la partie externalisée.

En plus des trois propriétés fondamentales des preuves de connaissance nulle, le schéma zk-SNARK largement utilisé a également la caractéristique de la concision. Cela signifie que pour toute logique complexe prouvée à l'aide de preuves de connaissance nulle, la taille de la preuve générée et le temps nécessaire pour vérifier la preuve sont tous deux fixes et relativement petits. Cela permet au zk-Rollup de décharger les calculs de mise à jour de l'état hors chaîne et de vérifier uniquement la justesse des opérations sur chaîne, rendant la solution de mise à l'échelle réalisable.

Le Processus des Preuves de Connaissance Zéro

Ensuite, cet article utilisera le calcul simple ci-dessous comme exemple pour expliquer le processus des preuves de zéro-connaissance.

c=a²+b+5

Dans le but d'expliquer l'aspect de connaissance nulle dans les preuves de connaissance nulle, nous allons définir les variables a et c comme les valeurs publiques de cette preuve de connaissance nulle, avec b comme entrée secrète connue uniquement du prouveur. Comme notre calcul est très simple, le vérificateur peut facilement déduire la valeur de l'entrée secrète à partir des valeurs publiques. Cela n'affecte pas la propriété de connaissance nulle de la méthode de preuve de connaissance nulle elle-même, car elle garantit seulement que le vérificateur ne peut pas obtenir d'informations sur l'entrée secrète à partir du processus de preuve.

Lors de la preuve, le prouveur sélectionne d'abord une valeur pour a et b respectivement en tant qu'entrées et calcule la valeur de c. Ici, nous fixons a = 3, b = 2, puis c = 16. Après avoir terminé tous les calculs, le prouveur peut générer une preuve de connaissance nulle pour ces valeurs et opérations.

Après avoir terminé la preuve, le prouveur donnera au vérificateur les entrées publiques de la preuve (c'est-à-dire les valeurs de a et c) ainsi que la preuve de non-divulgation.

Après avoir reçu la preuve, le vérificateur peut, en validant la preuve de zéro-connaissance, être convaincu que le prouveur a utilisé une entrée secrète b, ce qui rend la formule ci-dessus vraie lorsque a = 3 et c = 16 (c'est-à-dire les valeurs d'entrée publiques), et qu'il est incapable d'obtenir des informations au-delà des valeurs d'entrée publiques (a = 3, c = 16).

La prochaine partie de l'article présentera le processus de preuve spécifique. Lorsque nous devons prouver un calcul en utilisant la méthode de preuve à divulgation nulle, nous devons d'abord représenter le calcul sous la forme d'un circuit arithmétique que l'algorithme de preuve à divulgation nulle peut accepter. Les circuits arithmétiques sont des représentations complètes de Turing des calculs. Comme son nom l'indique, un circuit arithmétique est un circuit de calcul composé de portes qui effectuent des opérations arithmétiques. Dans notre exemple, le résultat de la conversion est montré dans la figure. Vous remarquerez peut-être qu'en plus des entrées publiques a et c et de l'entrée secrète b que nous avons mentionnées, il y a deux valeurs supplémentaires, d et e. Ce sont des variables intermédiaires utilisées dans le processus de calcul.

Nous pouvons considérer chaque fil dans le circuit arithmétique comme une valeur, qui pourrait être une entrée publique, une entrée secrète ou une variable intermédiaire. Après avoir étendu le calcul en un circuit arithmétique, chaque variable intermédiaire aura sa place et sera utilisée dans le processus de vérification. La seule différence entre elles et les entrées est que leurs valeurs ne sont pas directement saisies par le vérificateur mais déterminées par d'autres valeurs d'entrée dans le circuit arithmétique.

Nous pouvons voir le circuit arithmétique comme deux parties: une partie est constituée de toutes les valeurs numériques qui apparaissent dans le circuit, et l'autre partie est les relations (contraintes) entre ces valeurs. Nous faisons généralement référence aux entrées publiques dans le circuit comme l'énoncé (dans notre exemple, a et c), et toutes les autres valeurs, y compris les entrées secrètes (b) et les variables intermédiaires (d et e), comme le témoin.

Selon la logique du circuit, lorsque nous avons les entrées publiques comme l'énoncé et les entrées secrètes comme le témoin, nous pouvons calculer toutes les valeurs du témoin dans le circuit.

Par conséquent, le circuit de porte du circuit arithmétique peut également être représenté sous la forme suivante :

déclaration :

a,c

témoin :

b,d,e

contrainte :

d = a * a

e = b + 5

c = d + e

Après que le circuit à prouver a été arithmétisé, l'algorithme de preuve de connaissance nulle doit traiter les contraintes du circuit et les convertir dans la forme requise par l'algorithme pour la génération et la validation des preuves. Après traitement, le circuit produit une clé de vérification VK (Verification Key) de longueur fixe qui n'est pas liée à la taille du circuit. Le vérificateur peut vérifier la preuve de connaissance nulle du circuit correspondant grâce à la clé de vérification. La clé de vérification est quelque peu similaire à un engagement envers le circuit. Si des changements surviennent dans les contraintes, la clé de vérification correspondante changera également.

Dans les applications réelles, les utilisateurs des preuves de zéro connaissance doivent écrire la logique dont ils ont besoin dans le code source du circuit zk et générer un VK correspondant grâce à l'audit. Ce VK est remis au vérificateur. Les entrées publiques prouvées par le prouveur, ainsi que la preuve générée, sont soumises, et le vérificateur peut vérifier si ces entrées publiques respectent les contraintes. Dans cet exemple, le prouveur peut générer une preuve avec les valeurs de a, b et c. Le vérificateur peut vérifier si a2 + b est égal à C sans effectuer cette opération.

Limitations des circuits de preuve de connaissance nulle

Bien que les circuits zk soient complets au sens de Turing et puissent représenter toute computation, en raison de la nécessité de convertir les calculs en la forme de représentation spéciale des circuits arithmétiques, il existe quelques restrictions supplémentaires dans l'écriture des circuits arithmétiques.

Dans les programmes informatiques avec lesquels nous sommes plus familiers, nous pouvons contrôler les branches de l'exécution du programme avec des instructions if-else. Seule la branche sélectionnée dans le programme est exécutée. Cependant, dans le processus de preuve de zéro-connaissance, les calculs sont aplatis en circuits, et il n'y a pas de concept de chemins d'exécution ou de flux de contrôle. Ainsi, nous ne pouvons pas choisir une branche particulière à exécuter dans un circuit arithmétique.

Bien sûr, cela ne signifie pas que nous ne pouvons pas utiliser des branches et des sélections dans les circuits. Cela signifie simplement que dans les circuits, toutes les branches, qu'elles soient sélectionnées ou non, seront exécutées et contribueront à la production de la preuve. La sélection des branches n'affecte que le résultat de la branche qui sera renvoyé à la prochaine variable.

Prenez l'opération suivante comme exemple :

si (drapeau) {

c = x + x

} else {

c = x * x

}

Lorsque cette opération est convertie en un circuit arithmétique, elle sera convertie en les contraintes ci-dessous. De toute évidence, deux nouveaux témoins, temp1 et temp2, seront ajoutés au circuit. De plus, la valeur de x+x et la valeur de x*x seront toutes deux calculées.

C'est-à-dire, dans un circuit zk, toutes les branches et la logique seront calculées, qu'elles soient exécutées ou non.

temp1 = x + x

temp2 = x * x

c = drapeautemp1 + (1-flag)temp2

En raison de ces limitations, soutenir la sélection conditionnelle dans les circuits de preuve de connaissance nulle est assez difficile. Comment prouver le parcours d'exécution d'une logique de contrat intelligent avec de nombreuses variations dans une preuve de connaissance nulle est l'un des principaux défis d'une machine virtuelle zk.

Prouver l'exécution de n'importe quel programme — Prouver une machine à état universelle dans un circuit

Source de l'image

Nous décrivons la VM à travers un modèle d'une machine d'état universelle. Une VM est une machine d'état qui passe d'un état à un autre lorsque des instructions sont traitées. Illustrons comment une machine virtuelle est prouvée par un circuit de connaissance nulle avec un exemple de machine d'état très simple.

Nous supposons que cette machine à états universelle possède des registres à usage général (A et B) et, de plus, un registre de compteur de programme qui stocke le numéro d'instruction actuel.

L'état des registres avant d'exécuter l'instruction

La figure ci-dessous montre le flux de travail de base d'un circuit de preuve de machine virtuelle ZK :

L'état 0 peut être considéré comme l'état initial de cette machine virtuelle avant l'exécution. L'état initial, après un total de m instructions, atteint l'état final m. En plus de l'état initial, cette machine virtuelle possède deux tables d'entrée régulières :

• Tableau du code octet : Stocke le programme exécuté dans la machine d'état.
• Table d'E/S: Stocke toutes les entrées et sorties générées lors de l'exécution de la machine virtuelle.

Dans la figure, le processus d'exécution de l'nième instruction est abstrait et affiché sur la gauche. L'état de la machine d'état, État n, passe à l'état n+1 après l'exécution de l'nième instruction. Le même circuit, après m itérations, réalise l'exécution de m instructions dans le vm.

Il y a deux problèmes ici.

L'un est comment exécuter différentes instructions au sein d'un circuit fixe ? Lors de l'exécution du bytecode du contrat, il n'est pas possible de déterminer quelle est la nième instruction exécutée, donc la logique de circuit réelle ici ne peut pas être déterminée.

Le deuxième consiste à prouver si le nombre d'instructions à exécuter n'est pas m?

Pour la première question, la solution consiste à implémenter la logique pour toutes les instructions possibles dans le circuit. Ensuite, utilisez un Sélecteur, basé sur l'instruction, pour en choisir une comme prochain état, similaire au if-else dans le circuit spécialisé mentionné précédemment.

Pour la deuxième question, nous ne pouvons pas changer directement le nombre d'instructions dans le circuit. Cela est dû au fait que chaque instruction dans le circuit nécessite un segment de circuit indépendant pour être mise en œuvre. Si le nombre d'instructions augmente ou diminue, le circuit changera et la clé de vérification correspondante changera également. Cela rend impossible de satisfaire aux exigences de vérification de toute logique dans un circuit fixe.

Pour résoudre ce problème, une instruction noop qui ne modifiera pas l'état peut être ajoutée à l'ensemble d'instructions. Par conséquent, il existe une limite supérieure au nombre d'instructions que chaque circuit fixe peut exécuter. Le circuit zkVM peut être vu comme un conteneur avec un nombre fixe de slots d'instructions. Si plus d'instructions sont nécessaires, un circuit plus grand est requis. En preuve réelle, un circuit de taille appropriée peut être sélectionné selon les besoins.

Démontrer une instruction de base

Voici quelques instructions computationnelles de base à titre d'exemple de la manière dont les instructions de base dans le circuit sont prouvées:

Source de l'image

La figure montre le diagramme de flux du circuit de preuve d'instruction. Les formules ci-dessous sont les contraintes du circuit pour la preuve.

Ces deux contraintes peuvent prouver plusieurs instructions de base pour les registres généralistes A et B répertoriées dans le coin supérieur droit. Ces preuves peuvent charger des valeurs à partir du tableau d'entrée ou des valeurs immédiates des instructions dans les registres ou ajouter les valeurs dans les registres A et B et les écrire de nouveau dans les registres.

À partir de cette figure, nous pouvons voir que pour établir des contraintes pour les changements d'état, le circuit introduit quelques états de contrôle auxiliaires :

La logique de calcul entre ces registres auxiliaires et les registres polyvalents est implémentée par les formules ci-dessous. Les lecteurs intéressés peuvent substituer les valeurs correspondantes dans les formules de contrainte pour vérifier. On peut constater qu'avec ces deux contraintes, les instructions d'addition arithmétique de base peuvent être implémentées. Si plus d'opérations sont nécessaires, plus de contraintes d'instruction devront être ajoutées.

En revenant au diagramme de processus de base, nous pouvons considérer le circuit de calcul dans cette section comme une instruction dans le processus global. Le Sélecteur choisira si le résultat qu'il produit est l'état suivant à adopter par la machine à états. Les états auxiliaires requis par le circuit dans cette section sont générés par l'instruction pointée par le registre PC.

La récupération de l'instruction est mise en œuvre par un circuit de recherche spécialisé, qui peut prouver la récupération d'un segment de données à partir d'une table fixe par le biais d'un index. Par conséquent, le circuit zkVM peut prouver la transition d'état exécutée par la machine virtuelle spécifiée par PC.

Démonstration de jugements conditionnels et de sauts de flux de contrôle

La capacité de la machine à états d'exécuter une logique complexe repose sur des instructions conditionnelles et de saut. Dans les contrats réels, nous avons souvent besoin de traiter une logique qui modifie le chemin d'exécution en fonction des conditions, de tels circuits sont donc nécessaires.

Il convient de noter ici que les circuits zkVM ne sont pas des modules qui exécutent réellement la logique du contrat et calculent les résultats. Ce que les circuits zkVM font réellement, c'est prouver le processus de calcul de la logique du contrat. Par conséquent, lors de la preuve, il est nécessaire de remplir le processus de séquence d'instructions réellement exécuté dans le circuit, de vérifier à travers le circuit si les conditions de ce saut sont remplies, puis de prouver que le flux d'instructions exécuté a effectué le bon saut.

Tout d'abord, nous introduisons la preuve du jugement de condition :

Prendre le jugement de savoir si l'opérande dans la ième instruction est égal à zéro comme exemple. Nous ajoutons un état auxiliaire isZero pour le résultat du jugement. Si la valeur jugée est 0, alors la valeur de l'état auxiliaire isZero est 1; si la valeur jugée est toute autre valeur que 0, alors isZero est 0.

Ce processus est contraint par les deux formules dans le diagramme.

La validité de cette contrainte est liée aux propriétés mathématiques des courbes elliptiques utilisées dans les preuves de zéro connaissance. Chaque valeur dans un circuit de preuve de zéro connaissance est un élément dans un champ fini sur une courbe elliptique. Si sa valeur n'est pas 0, il doit exister un élément inverse qui, lorsqu'il est multiplié par lui-même, donne 1. En utilisant cette propriété, avec les deux contraintes dans le diagramme, il est possible de vérifier si une valeur est nulle et de la convertir en un état auxiliaire.

Une fois que nous avons cet état auxiliaire de condition isZero, nous pouvons procéder à la preuve des instructions de saut conditionnel :

En revenant au diagramme de processus de base, si l'instruction actuelle est une instruction de saut conditionnel. Il effectue d'abord une vérification isZero, détermine si la condition de saut est satisfaite, puis modifie la valeur de PC. Après avoir mis à jour la valeur de PC, l'exécution de l'instruction suivante implique d'abord une recherche basée sur PC pour trouver l'instruction après le saut.

Opérations E/S et complexes

Lors de l'utilisation d'un circuit de preuve de machine à états générale, pour gérer correctement les transitions d'états, il est nécessaire d'ajouter des états de contrôle correspondants et des contraintes pour chaque instruction prise en charge pendant une seule transition d'état. Le nombre de ces valeurs d'état et de contraintes doit également être multiplié par le nombre d'instructions prises en charge par le zkVM. Même si aucune opération n'est effectuée dans le programme réel exécuté par le zkVM (tous les NOP), ces valeurs d'état et ces vérifications de contraintes ne peuvent pas être omises.

Par conséquent, l'utilisation du circuit de machine état général dans la première moitié de cet article pour exécuter des calculs complexes est très inefficace. Si ces méthodes sont utilisées pour implémenter des calculs complexes, leurs performances sont difficiles à accepter. De plus, il est difficile pour le circuit de machine état général d'exécuter des instructions complexes ou d'interagir directement avec le monde extérieur.

Pour résoudre ce problème, les implémentations réelles des zkVM utilisent généralement une combinaison de circuits de machine à états généraux et de circuits de preuve spécialisés pour prouver les parties du programme séparément, puis agréger les preuves en une solution unique.

Source de l'image : 1 2

Le schéma de gauche est l'architecture de circuit du projet de défilement, et le schéma dans le coin inférieur droit est l'architecture de circuit de Polygon. Ils utilisent tous deux une approche similaire comme indiqué dans le schéma dans le coin supérieur.

La machine à états générale est responsable de prouver le contrôle logique d'exécution du programme. Dans la plupart des contrats, le temps d'exécution réel de cette partie de la logique est très court, il est donc encore acceptable en termes d'efficacité de le prouver avec la machine à états générale inefficace.

Des calculs complexes fixes, tels que le hachage, les opérations d'arbre MPT, les données d'entrée externes, etc., sont prouvés par des circuits spécialisés.

La machine à états générale et les circuits de preuve spécialisés interagissent à l'aide de tables de recherche. Chaque fois que le circuit de la machine à états appelle ces opérations, les modules qui génèrent le témoin de la preuve écriront les paramètres d'appel et les résultats de calcul dans la table de recherche. Ainsi, les appels à ces opérations dans le circuit de la machine à états sont simplifiés à une opération de recherche.

La justesse de chaque appel et de la valeur de retour dans la table de recherche est contrainte et prouvée par un circuit spécialisé.

Enfin, les contraintes de copie dans le circuit relient le circuit de machine à états, les circuits spécialisés et les tables de recherche, vérifiant si chaque élément dans la table de recherche est prouvé par le circuit spécialisé correspondant, et générant finalement une preuve pour le bloc complet.

Le contrat L1 doit seulement vérifier cette preuve globale pour confirmer la justesse de l'ensemble du processus d'exécution de la machine virtuelle.

Conclusion

La technologie de preuve de connaissance nulle a rendu possible la preuve de calculs de manière simple et rapide, ouvrant la porte à l'externalisation des processus de calcul dans un environnement sans confiance. Cette technologie, lorsqu'elle est utilisée dans la blockchain, libère l'exécution de la chaîne, permettant à la blockchain principale de se concentrer sur les problèmes de décentralisation et de sécurité. Mais la caractéristique des circuits spécialisés de preuve de connaissance nulle pour exécuter uniquement une logique fixe limite le potentiel des preuves de connaissance nulle sur la blockchain, confinant les capacités initiales de zkRollup à quelques types de transactions.

Cependant, avec le développement et la maturation des machines virtuelles zk, soutenir l'exécution Turing-complète de contrats intelligents arbitraires est devenu possible. Le potentiel de zkRollup sera vraiment libéré, réalisant sa vision de briser le trilemme de la blockchain.

Avertissement：

1. Cet article est repris de [ZAN], tous les droits d'auteur appartiennent à l'auteur original [ZAN et AntChain Open Labs]. Si des objections sont soulevées concernant cette reproduction, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Responsabilité de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.