Le co-fondateur de Scroll, Zhang Ye, a parlé de quatre parties. Dans la première partie, Zhang Ye a présenté le contexte du développement et pourquoi nous avons besoin de zkEVM en premier lieu et pourquoi il est devenu si populaire au cours des deux dernières années. a expliqué comment, à travers un processus complet, la construction de zkEVM à partir de zéro inclut des systèmes arithmétiques et de preuve. La troisième partie parle des problèmes rencontrés lors de la construction de zkEVM à travers quelques questions de recherche intéressantes, et présente enfin quelques autres applications utilisant zkEVM.
La blockchain traditionnelle de couche 1 aura certains nœuds maintenus ensemble via le réseau P2P. Lorsqu'ils recevront la transaction de l'utilisateur, ils l'exécuteront dans la machine virtuelle EVM, liront le contrat d'appel et le stockage, et mettront à jour l'arborescence d'état globale en fonction de la transaction.
L'avantage d'une telle architecture est la décentralisation et la sécurité. L'inconvénient est que les frais de transaction sur L1 sont chers et la confirmation des transactions est lente.
Dans l'architecture ZK-Rollup, le réseau L2 n'a besoin que de télécharger les données et la preuve pour vérifier l'exactitude des données vers L1, où la preuve est calculée via un circuit de preuve à connaissance nulle.
Au début du ZK-Rollup, le circuit était conçu pour des applications spécifiques. Les utilisateurs devaient envoyer des transactions à différents prouveurs, puis les ZK-Rollups de différentes applications soumettaient leurs propres données et preuves à L1. Le problème que cela pose est que la composabilité du contrat L1 original est perdue.
Ce que fait Scroll est une solution zkEVM native, qui est un ZK-Rollup à usage général. Ceci est non seulement plus convivial, mais offre également aux développeurs une meilleure expérience de développement sur L1. Bien entendu, le développement est très difficile et le coût de la génération actuelle de preuves est également très élevé.
Heureusement, l'efficacité des preuves sans connaissance s'est considérablement améliorée au cours des deux dernières années, c'est pourquoi zkEVM est devenu si populaire au cours des deux dernières années. Il y a au moins quatre raisons pour lesquelles cela devient réalisable. La première est l'émergence de l'engagement polynomial. Dans le système de preuve original de Groth16, l'échelle des contraintes était très grande, mais l'engagement polynomial peut prendre en charge des contraintes d'ordre supérieur et réduire l'échelle de la contrainte. la preuve ; deuxièmement, l'émergence de tables de recherche et de portes personnalisées peut prendre en charge des conceptions plus flexibles et rendre les preuves plus efficaces ; le troisième concerne les avancées en matière d'accélération matérielle, qui peuvent réduire le temps de preuve de 1 à 2 ordres de grandeur grâce aux GPU, FPGA et ASIC ; .Le quatrième Sous preuve récursive, plusieurs preuves peuvent être compressées en une seule preuve, ce qui rend la preuve plus petite et plus facile à vérifier. Ainsi, en combinant ces quatre facteurs, l'efficacité de génération de preuves sans connaissance est trois ordres de grandeur supérieure à celle d'il y a deux ans, ce qui est également à l'origine de Scoll.
Selon la définition de Justin Drake, zkEVM peut être divisé en trois catégories. La première catégorie est la compatibilité au niveau du langage. La raison principale est que EVM n'est pas conçu pour ZK et comporte de nombreux opcodes qui ne sont pas compatibles avec ZK, ce qui entraînera un problème. beaucoup de frais généraux supplémentaires. Par conséquent, des sociétés comme Starkware et zkSync choisissent de compiler Solidity ou Yul dans des compilateurs compatibles ZK au niveau du langage.
Le deuxième type est la compatibilité au niveau du bytecode effectuée par Scroll, qui prouve directement si le traitement du bytecode de l'EVM est correct ou non, et hérite directement de l'environnement d'exécution d'Ethereum. Certains compromis qui peuvent être faits ici consistent à utiliser une racine d'état différente de celle de l'EVM, par exemple en utilisant une structure de données compatible ZK. Hermez et Consensys font quelque chose de similaire.
La troisième catégorie concerne la compatibilité au niveau du consensus. Le compromis ici est qu’il est non seulement nécessaire de conserver l’EVM inchangé, mais également d’inclure la structure de stockage pour obtenir une compatibilité totale avec Ethereum, au prix d’un temps de preuve plus long. Scroll est construit en coopération avec l’équipe PSE de la Fondation Ethereum pour réaliser la ZKisation d’Ethereum.
Dans la deuxième partie, Zhang Ye a montré à tout le monde comment créer ZKVM à partir de zéro.
Processus complet
Tout d'abord, dans la partie frontale de ZKP, vous devez exprimer vos calculs via l'arithmétique mathématique. Les plus couramment utilisés sont le R1CS linéaire, ainsi que Plonkish et AIR. Après avoir obtenu les contraintes par l'arithmétique, vous devez exécuter l'algorithme de preuve sur le backend de ZKP pour prouver l'exactitude du calcul. Voici les preuves oracle interactives polynomiales (Polynomial IOP) et le schéma d'engagement polynomial (PCS).
Ici, nous devons prouver que zkEVM et Scroll utilisent une combinaison de Plonkish, Plonk IOP et KZG.
Comprendre pourquoi nous utilisons ces trois solutions. Nous commençons par le R1CS le plus simple. La contrainte dans R1CS est que la combinaison linéaire multipliée par la combinaison linéaire est égale à la combinaison linéaire. Vous pouvez ajouter n'importe quelle combinaison linéaire de variables sans surcharge supplémentaire, mais l'ordre maximum dans chaque contrainte est de 2. Par conséquent, pour les opérations d’ordre supérieur, davantage de contraintes sont nécessaires.
Dans Plonkish, vous devez remplir toutes les variables dans le tableau, y compris les entrées, les sorties et les témoins pour les variables intermédiaires. En plus de cela, vous pouvez définir différentes contraintes. Il existe trois types de contraintes disponibles dans Plonkish.
Le premier type de contrainte est une porte personnalisée. Vous pouvez définir des relations de contrainte polynomiale entre différentes cellules, telles que va3 * vb3 * vc3 - vb4 =0. Par rapport à R1CS, l'ordre peut être plus élevé car vous pouvez définir des contraintes sur n'importe quelle variable, et vous pouvez définir des contraintes très différentes.
Le deuxième type de contrainte est la permuation, ou contrôle d'égalité. Il peut être utilisé pour vérifier l'équivalence de différentes cellules et est souvent utilisé pour associer différentes portes dans un circuit, par exemple pour prouver que la sortie de la porte précédente est égale à l'entrée de la porte suivante.
Le dernier type de contrainte est une table de recherche. Nous pouvons comprendre la table de recherche comme une relation entre des variables, qui peut être exprimée sous forme de tableau. Par exemple, nous voulons prouver que vc7 est compris entre 0 et 15. Dans R1CS, vous devez d'abord décomposer cette valeur en un binaire de 4 bits, puis prouver que chaque bit est compris entre 0 et 1, ce qui nécessitera quatre contraintes. Dans Plonkish, vous pouvez lister toutes les plages possibles dans la même colonne et il vous suffit de prouver que vc7 appartient à cette colonne. Ceci est très efficace pour les preuves de plage. Dans zkEVM, les tables de recherche sont très utiles pour prouver les lectures et écritures en mémoire.
Pour résumer, Plonkish prend également en charge les portes personnalisées, les contrôles d'équivalence et les tables de recherche, qui peuvent être très flexibles pour répondre aux différents besoins des circuits. Une simple comparaison de STARK. Chaque ligne dans STARK est une contrainte. La contrainte doit représenter la transition d'état entre les lignes, mais la flexibilité des contraintes personnalisées dans Plonkish est évidemment plus élevée.
La question est maintenant de savoir comment choisir le frontal dans zkEVM. Il y a quatre défis principaux pour zkEVM. Le premier défi est que le champ d'EVM est de 256 bits, ce qui signifie que les variables doivent être limitées efficacement en termes de plage ; le deuxième défi est que EVM a de nombreux opcodes incompatibles avec ZK, des contraintes à très grande échelle sont donc nécessaires pour prouver ces opérations. .code, tel que Keccak-256 ; le troisième défi est le problème de lecture et d'écriture de la mémoire, vous avez besoin d'un mappage efficace pour prouver que ce que vous lisez est cohérent avec ce que vous avez écrit auparavant ; le quatrième défi est que la trace d'exécution de l'EVM ; change dynamiquement, nous avons donc besoin de portes personnalisées pour s'adapter aux différentes traces d'exécution. Nous avons choisi Plonkish pour les considérations ci-dessus.
Examinons ensuite le processus complet de zkEVM. Sur la base de l'arborescence d'état globale initiale, après l'arrivée d'une nouvelle transaction, EVM lira le bytecode des contrats stockés et appelés et générera les traces d'exécution correspondantes basées sur la transaction, telles que PUSH, PUSH , STORE, CALLVALUE, puis mettez progressivement à jour l'état global pour obtenir l'arborescence d'état globale après la transaction. zkEVM prend en entrée l'arborescence d'état globale initiale, la transaction elle-même et l'arborescence d'état globale après la transaction, et utilise la spécification EVM pour prouver l'exactitude de la trace d'exécution.
En approfondissant les détails du circuit EVM, chaque étape de la trace d'exécution a des contraintes de circuit correspondantes. Plus précisément, les contraintes de circuit de chaque étape incluent le contexte d'étape, le commutateur de cas et le témoin spécifique de l'opcode. Le contexte de l'étape contient le codehash, le gaz restant et le compteur correspondant à la trace d'exécution ; Case Switch contient tous les opcodes, toutes les conditions d'erreur et les opérations correspondantes de l'étape ; Opcode Specific Witness contient des témoins supplémentaires requis par l'opcode, tels que l'attente des opérandes.
En prenant l'addition simple comme exemple, vous devez vous assurer que la variable de contrôle sADD de l'opcode d'addition est définie sur 1 et que les variables de contrôle des autres opcodes sont toutes nulles. Dans le contexte Step, le gaz consommé est contraint à être égal à 3 en définissant gas' - gas - 3 = 0. De même, le compteur est contraint à accumuler 1 après le pas dans le Case Switch ; les variables sont contrôlées à 1 via l'opcode. Pour contraindre cette étape à être une opération d'addition ; dans Opcode Specific Witness, contraignez l'ajout réel d'opérandes.
De plus, des contraintes de circuit supplémentaires sont nécessaires pour garantir l'exactitude des opérandes lus dans la mémoire. Ici, nous devons d’abord créer une table de recherche pour prouver que l’opérande appartient à la mémoire. Et vérifiez l'exactitude de la table mémoire via le circuit mémoire (circuit RAM).
La même méthode peut être appliquée aux fonctions de hachage non compatibles avec zk. Créez une table de recherche de la fonction de hachage, mappez l'entrée et la sortie de hachage dans la trace d'exécution à la table de recherche et utilisez un circuit de hachage supplémentaire pour vérifier la fonction de hachage. l'exactitude de la table de recherche.
Examinons maintenant l'architecture du circuit de zkEVM.Le circuit EVM principal est utilisé pour contraindre l'exactitude de chaque étape de la trace d'exécution.Dans certains endroits où les contraintes du circuit EVM sont difficiles, nous utilisons des tables de recherche pour mapper, y compris la table fixe, Keccak. Table, table RAM, bytecode, transaction, contexte de bloc, puis utilisez des circuits séparés pour contraindre ces tables de recherche, tels que les circuits Keccak pour contraindre les tables Keccak.
Pour résumer, le flux de travail complet de zkEVM est présenté dans la figure ci-dessous.
système de preuve
Parce que la vérification directe des circuits EVM, circuits de mémoire, circuits de stockage, etc. mentionnés ci-dessus sur L1 coûte cher, le système de preuve de Scroll adopte une architecture à deux couches.
La première couche est chargée de prouver directement l'EVM lui-même, nécessitant une grande quantité de calculs pour générer la preuve. Par conséquent, le système de preuve de premier niveau est requis pour prendre en charge les portes et les tables de recherche personnalisées, être compatible avec l'accélération matérielle, générer des calculs en parallèle avec une mémoire de faible pointe et disposer d'un petit circuit de vérification qui peut être vérifié rapidement. Les alternatives prometteuses incluent Plonky2, Starky et eSTARK. Elles utilisent toutes essentiellement Plonk sur le front-end, mais peuvent utiliser FRI sur le back-end, et répondent toutes aux quatre caractéristiques ci-dessus. Un autre type de solutions alternatives inclut Halo2 développé par Zcash et la version KZG de Halo2.
Il existe également de nouveaux systèmes de preuve prometteurs, tels que HyperPlonk, qui a récemment supprimé la FFT, et le système de preuve NOVA peut réaliser des preuves récursives plus petites. Mais ils ne soutiennent le R1CS que dans la recherche. S'ils peuvent soutenir Plonkish à l'avenir et l'appliquer dans la pratique, ce sera très pratique et efficace.
Le système de preuve de deuxième niveau est utilisé pour prouver l'exactitude de la preuve de premier niveau et doit être vérifié efficacement dans l'EVM. Idéalement, il devrait être compatible avec l'accélération matérielle et prendre en charge une configuration transparente ou universelle. Les alternatives prometteuses incluent Groth16 et le système d'épreuve Plonkish sans colonne. Groth16 est toujours un représentant d'une efficacité de preuve extrêmement élevée dans les recherches actuelles, et le système de preuve Plonkish peut également atteindre une efficacité de preuve élevée même avec un petit nombre de colonnes.
Chez Scroll, nous utilisons le système d'épreuves Halo2-KZG dans nos deux systèmes d'épreuves à deux couches. Étant donné que Halo2-KZG peut prendre en charge des portes et des tables de recherche personnalisées, il fonctionne bien sous l'accélération matérielle GPU, et le circuit de vérification est de petite taille et peut être vérifié rapidement. La différence est que nous utilisons le hachage Poséidon dans le système de preuve de première couche pour améliorer encore l'efficacité de la preuve, tandis que le système de preuve de deuxième couche utilise toujours le hachage Keccak car il est vérifié directement sur Ethereum. Scroll explore également la possibilité d'un système de preuve multicouche pour regrouper davantage les preuves agrégées générées par le système de preuve de deuxième niveau.
Dans la mise en œuvre actuelle, le circuit EVM du système de preuve de premier niveau de Scroll comporte 116 colonnes, 2 496 portes personnalisées, 50 tables de recherche, l'ordre le plus élevé est 9 et nécessite 2 ^ 18 lignes sous 1 M de gaz tandis que le système de preuve de deuxième niveau a le circuit EVM du système de preuve de premier niveau de Scroll. Le circuit d'agrégation n'a que 23 colonnes, 1 porte personnalisée, 7 tables de recherche et l'ordre le plus élevé est 5. Afin d'agréger le circuit EVM, le circuit de mémoire et le circuit de stockage, 2 ^ 25 lignes sont nécessaires.
Scroll a également effectué de nombreux travaux de recherche et d'optimisation sur l'accélération matérielle GPU. Pour les circuits EVM, le prouveur GPU optimisé ne prend que 30 secondes, ce qui est 9 fois plus efficace que le prouveur CPU. Pour les circuits d'agrégation, après optimisation du prouveur GPU uniquement. prend 149 secondes, ce qui est 15 fois plus efficace que le CPU. Dans les conditions d'optimisation actuelles, le système de preuve de premier niveau 1M Gas prend environ 2 minutes et le système de preuve de deuxième niveau prend environ 3 minutes.
Dans la troisième partie, Zhang Ye a parlé de quelques questions de recherche intéressantes dans le processus de construction de zkEVM par Scroll, du circuit arithmétique frontal à la mise en œuvre du prouveur.
circuit
Le premier est le caractère aléatoire du circuit. Le champ EVM étant de 256 bits, nous devons le diviser en 32 champs de 8 bits pour effectuer une preuve de portée plus efficacement. Ensuite, nous utilisons la méthode Random Linear Combination (RLC) pour coder 32 champs en 1 en utilisant des nombres aléatoires. Il nous suffit de vérifier ce champ pour vérifier le champ original de 256 bits. Mais le problème est que le nombre aléatoire doit être généré après la division des champs pour garantir qu'il ne soit pas falsifié. Par conséquent, Scroll et l'équipe PSE ont proposé une solution de preuve en plusieurs étapes pour garantir qu'après la division des champs, des nombres aléatoires sont utilisés pour générer RLC. Cette solution est encapsulée dans l'API Challenge. RLC a de nombreux scénarios d'application dans zkEVM. Il peut non seulement compresser le champ EVM en un seul champ, mais également chiffrer les entrées de longueur variable ou optimiser la disposition de la table de recherche. Cependant, de nombreux problèmes restent à résoudre.
Une deuxième question de recherche intéressante dans le domaine des circuits est la disposition des circuits. La raison pour laquelle le front-end Scroll utilise Plonkish est que la trace d'exécution d'EVM change de manière dynamique et doit être capable de prendre en charge différentes contraintes et tests d'équivalence changeants, et la porte standardisée de R1CS nécessite une plus grande échelle de circuit pour être mise en œuvre. Cependant, Scroll utilise actuellement plus de 2 000 portes personnalisées pour répondre aux traces d'exécution qui changent dynamiquement, et explore également comment optimiser davantage la disposition des circuits, notamment en divisant l'Opcode en Micro Opcode ou en réutilisant les cellules dans la même table.
Une troisième question de recherche intéressante dans le domaine des circuits est la mise à l'échelle dynamique. Parce que l'échelle du circuit des différents opcodes est différente, mais afin de répondre à la trace d'exécution qui change dynamiquement, l'opcode de chaque étape doit respecter l'échelle maximale du circuit, comme le hachage Keccak, nous payons donc en fait une surcharge supplémentaire. En supposant que nous puissions faire en sorte que zkEVM s'adapte dynamiquement aux traces d'exécution qui changent dynamiquement, cela évitera une surcharge inutile.
prouveur
En termes de prouveurs, Scroll a apporté de nombreuses optimisations pour MSM et NTT en termes d'accélération GPU, mais le goulot d'étranglement s'est désormais déplacé vers la génération de témoins et la copie de données. Parce qu'on suppose que MSM et NTT occupent 80 % du temps de preuve, même si l'accélération matérielle peut améliorer cette efficacité de plusieurs ordres de grandeur, le temps de preuve initial de 20 % pour la génération et la copie des données deviendra un nouveau goulot d'étranglement. Un autre problème avec le prouveur est qu'il nécessite beaucoup de mémoire, des solutions matérielles moins chères et plus décentralisées doivent donc être explorées.
Dans le même temps, Scroll explore également l’accélération matérielle et les algorithmes de preuve pour améliorer l’efficacité des prouveurs. Il existe actuellement deux directions principales, soit passer à un domaine plus petit, comme l'utilisation du domaine Goldilocks 64 bits, Mersenne Prime 32 bits, etc., soit s'en tenir à un nouveau système de preuve basé sur des courbes elliptiques (EC par exemple SuperNova). . Bien sûr, il existe d’autres voies possibles, et les amis ayant des idées sont invités à contacter directement Scroll.
sécurité
Lors de la création de zkEVM, la sécurité est primordiale. Le zkEVM construit conjointement par PSE et Scroll contient environ 34 000 lignes de code. Du point de vue de l'ingénierie logicielle, il est impossible que ces bases de code complexes soient exemptes de vulnérabilités pendant une longue période. Scroll examine actuellement la base de code zkEVM à travers un grand nombre d'audits, notamment réalisés par les plus grands cabinets d'audit du secteur.
La partie 4 explore d'autres applications qui utilisent zkEVM.
Dans l'architecture zkRollup, nous vérifions que n transactions sur L2 sont valides via le contrat intelligent sur L1.
Si nous vérifions directement le bloc L1, alors le nœud L1 n'a pas besoin d'exécuter la transaction à plusieurs reprises, mais doit uniquement vérifier la validité de chaque certificat de bloc. Une telle solution architecturale s’appelle Enshrine Blockchain. Actuellement, il est très difficile de l’implémenter directement sur Ethereum car l’ensemble du bloc Ethereum doit être vérifié, ce qui impliquera la vérification d’un grand nombre de signatures, ce qui entraînera un temps de vérification plus long et une sécurité moindre. Bien entendu, il existe déjà d'autres chaînes publiques qui utilisent des preuves récursives pour vérifier l'intégralité de la blockchain à l'aide d'une seule preuve, comme Mina.
Étant donné que zkEVM peut prouver les transitions d'état, il peut également être utilisé par les chapeaux blancs pour prouver qu'ils connaissent les vulnérabilités de certains contrats intelligents et recherchent des primes auprès des parties au projet.
Le dernier cas d'utilisation consiste à prouver les affirmations concernant les données historiques grâce à une preuve de connaissance nulle et à les utiliser comme oracle. Axiom fabrique actuellement des produits dans ce domaine. Lors du récent hackathon ETHBeijing, l'équipe GasLockR a profité de cette fonctionnalité pour prouver les frais généraux historiques de Gas.
Enfin, Scroll construit la solution de mise à l'échelle universelle de zkRollup pour Ethereum, en utilisant des circuits arithmétiques et des systèmes de preuve très avancés, et en créant des vérificateurs rapides grâce à l'accélération matérielle pour prouver la récursivité. À l'heure actuelle, le réseau de test Alpha est en ligne et fonctionne de manière stable depuis longtemps.
Bien sûr, il reste encore quelques problèmes intéressants à résoudre, notamment la conception de protocoles et de mécanismes, l'ingénierie sans connaissance et l'efficacité réelle. Tout le monde est invité à rejoindre Scroll pour construire ensemble !
