Afin de résoudre le problème d'expansion du réseau blockchain Layer 1, la solution Rollup a vu le jour. Combiné à la technologie ZK, ZK Rollup est devenu le nouveau chouchou de la piste Layer 2. Cependant, pour la plupart des gens, des concepts connexes tels que ZK, Rollup et EVM peuvent avoir un certain seuil de compréhension. Par conséquent, l'objectif de ce rapport de recherche est de trier systématiquement pour vous une série de concepts de zkEVM Rollup dans un langage concis et facile à comprendre, d'analyser en profondeur l'évolution et l'état de développement de la technologie zkEVM Rollup et d'interpréter les principaux facteurs écologiques. projets en détail. Il est conçu pour vous aider à bien comprendre et à juger de la tendance de développement de la piste zkEVM Rollup.
PARTIE 1Comprendre ZK
ZK (ou ZKP), le nom complet est Zero-Knowledge Proof, c'est-à-dire la preuve de connaissance zéro. En cryptographie, la preuve de connaissance zéro ou le protocole de connaissance zéro est une méthode par laquelle une partie (le prouveur) peut soumettre au autre partie (certificateur de vérification) de prouver un fait sans divulguer les informations spécifiques du fait, c'est-à-dire qu'une partie (prouveur) peut faire savoir à l'autre partie si le fait est correct sans divulguer aucune "information spécifique" de le fait, donc la technologie ZK peut être utilisée en toute intimité Le domaine de la protection nous laisse beaucoup de place à l'imagination.
Bien sûr, en plus des avantages de la protection de la vie privée que la technologie ZK peut apporter, dans ZK Rollup, la technologie ZK est plus importante pour résoudre le problème de "vérification difficile". Le processus de "vérification" est très important pour la blockchain. La majeure partie du processus de calcul dans Ethereum consiste à répondre aux exigences de vérification, et ZK Rollup peut réduire considérablement le temps consacré à la vérification par l'ensemble du réseau de nœuds. Par exemple, si un bloc met beaucoup de temps à vérifier qu'il satisfait aux règles de l'ensemble du réseau lors de la génération du bloc, il peut y avoir un prouveur qui le vérifie en premier et génère une "preuve" du résultat de calcul de ce bloc, et le reste Le but de vérifier le bloc peut être atteint en vérifiant rapidement cette "preuve" au lieu du bloc d'origine avec une énorme quantité de calculs.
Un protocole ZK simple est divisé en étapes suivantes, génération de clé, preuve et vérification, et je vais les démonter pour vous une par une.
01Génération de clé, preuve et vérification
Dans ZK, il faut d'abord convertir le problème à vérifier en une expression mathématique, puis en un polynôme, et l'exprimer sous la forme d'un circuit arithmétique. Lorsqu'un programme est converti en un circuit arithmétique, il est décomposé en étapes individuelles consistant en des opérations arithmétiques de base telles que l'addition, la soustraction, etc. En tant que fonction qui sera sortie, elle peut être transformée dans le schéma de circuit suivant, voir Figure 1.
Figure 1 Un exemple de schéma de circuit, on peut remarquer que toutes les opérations du circuit sont divisées en opérations de base les plus simples | Source
En utilisant ce circuit et quelques nombres aléatoires en entrée, nous pouvons générer une clé de preuve (pk, clé de preuve) et une clé de vérification (vk, clé de vérification) pour le processus de vérification ultérieur, le schéma de principe est illustré à la figure 2.
Figure 2 Génération de "paramètres publics"
Notre système de preuve nécessite également deux types d'entrées - privées et publiques, ainsi que la clé de preuve pour générer la preuve. Parmi eux, l'entrée privée (témoin) est le secret que nous voulons cacher, et l'entrée publique est l'information qui peut être rendue publique. Par exemple, dans l'équation X+Y*Z=OUT, X et OUT sont des entrées publiques, tandis que Y et Z ont des valeurs que nous ne voulons pas rendre publiques au validateur. Bien que la valeur de Y*Z puisse être déduite sur la base des commentaires du public, les valeurs spécifiques de Y et Z sont encore incertaines.
Figure 3 Le processus de preuve et le processus de vérification des ZK-SNARK
Lorsque le vérificateur reçoit la preuve, il utilise l'entrée publique, la preuve et la clé de vérification pour vérifier la preuve et renvoie le résultat de la vérification (c'est-à-dire si la vérification est réussie).
Après avoir compris le processus ci-dessus, nous pouvons appliquer cette technologie pour bloquer la vérification afin de réaliser un petit ZK-SNARK, comme le montre la figure 3. Il existe de nombreux protocoles et méthodes pour réaliser une preuve à connaissance zéro. SNARK est relativement facile à comprendre, et c'est aussi le choix de la plupart des projets à ce stade. Dans le paragraphe "Des ZK-SNARKs à ZK-STARKs" nous parlerons des avantages et des inconvénients des SNARKs.
02Essayez un peu de SNARK
Prenons une preuve de connaissance zéro d'un arbre Merkle qui enregistre l'état du compte comme exemple de pratique. L'arbre Merkle enregistre l'adresse et le solde du compte. Lorsqu'une nouvelle transaction doit mettre à jour l'arbre Merkle, nous devons effectuer les opérations suivantes :
Vérifiez que l'expéditeur et le destinataire de la transaction se trouvent sur les nœuds feuilles de l'arborescence.
Vérifiez la signature de l'expéditeur.
Mettre à jour les soldes de l'expéditeur et du destinataire.
Mettez à jour le nœud racine de l'arbre Merkle (c'est-à-dire Merkle Root) et utilisez-le comme sortie finale.
En l'absence de preuves de connaissance nulle, le vérificateur doit répéter ces étapes pour s'assurer de l'exactitude du calcul. Mais après avoir utilisé la preuve à connaissance nulle, la situation est différente. Tout d'abord, nous devons identifier deux types d'entrées :
Au cours de ce processus, seules les nouvelles informations de transaction, la racine Merkle d'origine et la racine Merkle mise à jour sont des entrées publiques.
L'arbre Merkle lui-même agit comme un témoin (témoin) et n'a pas besoin d'être lu ou traité par le vérificateur.
Deuxièmement, nous devons générer des clés et calculer des circuits. Nous construisons des processus de calcul tels que la mise à jour de Merkle Tree et la vérification des adresses d'entrée et de sortie dans des circuits de calcul pour obtenir des clés de preuve et des clés de vérification. Ce circuit n'a rien à voir avec les informations de transaction d'entrée, ni avec la racine Merkle existante, car la méthode de calcul de l'arbre Merkle est fixe.
Au stade de la génération des preuves, nous prenons les deux arbres de Merkle et les informations de transaction en entrée. À l'étape du vérificateur, le vérificateur peut assurer la fiabilité de la mise à jour sans obtenir l'arbre de Merkle, c'est-à-dire sans connaître les informations du compte. Le circuit est comme une boîte noire solide, tant que l'entrée est correcte, il obtiendra la sortie correcte.
En utilisant la preuve de connaissance zéro, d'autres vérificateurs peuvent rapidement vérifier que le processus de génération de l'arbre Merkle est crédible, réduisant ainsi le temps de vérification répétée sur le réseau, et les informations de l'arbre Merkle n'ont pas besoin d'être divulguées au vérificateur.
03De ZK-SNARK à ZK-STARK
Le protocole de preuve mentionné ci-dessus est ZK-SNARKs. SNARK signifie arguments de connaissance succincts non interactifs, où succinct fait référence à la simplicité de cette méthode, et non interactif fait référence à celle par rapport à d'autres méthodes de preuve, les SNARK sont des preuves non interactives, c'est-à-dire que le vérificateur n'a besoin que d'utiliser le succinct La preuve générée permet d'obtenir le résultat de la vérification. Cependant, il y a quelques problèmes avec les ZK-SNARK. Dans l'étape de génération de clé, le circuit et le nombre aléatoire sont équivalents à un ensemble de paramètres publics initiaux, et il existe un problème inévitable de centralisation dans le processus de génération de ce paramètre public.
Les ZK-STARK ont une approche différente basée sur les SNARK, où "s" signifie scalabilité, ce qui prouve que le temps de génération et le temps de calcul d'origine sont quasi-linéaires, et le temps de vérification est logarithmique dans le calcul d'origine, ce qui signifie Dans le Dans le cas d'un grand jeu de données sous forme de données, le temps de vérification requis par le vérificateur est fortement raccourci.
Dans le même temps, en tant que version améliorée des ZK-SNARK, les ZK-STARK peuvent non seulement améliorer l'efficacité de la vérification (l'efficacité théorique est 10 fois), mais ne reposent pas non plus sur des courbes elliptiques ou des paramètres de confiance, et ne nécessitent pas le processus de générer des paramètres publics initiaux (la lettre "T" signifie transparence), ce qui supprime le besoin d'une configuration de confiance centralisée. Certains développeurs pensent que la fonction de hachage de ZK-STARK peut aider à résister aux attaques quantiques.
Cependant, ZK-STARKs a été introduit tardivement, la technologie actuelle n'est pas assez mature et repose sur des fonctions de hachage, ce qui limite sa polyvalence.ZK-SNARKs est toujours un algorithme de preuve général. Quelques exemples d'algorithmes basés sur STARK incluent Fractal, SuperSonic, etc., et les projets associés incluent StarkWare, Polygon Miden, etc.
PARTIE 2Comprendre le cumul
En plus de ZK, un autre concept que nous devons comprendre est Rollup.L'importance de Rollup est de résoudre le problème de congestion du réseau de couche 1.
Prenons Ethereum comme exemple, il a actuellement le problème de la congestion des transactions. Il existe deux façons de résoudre ce problème : l'une consiste à augmenter la capacité de transaction de la blockchain elle-même, par exemple en augmentant le débit de la blockchain grâce à des technologies telles que le sharding. Une autre approche consiste à modifier la façon dont la blockchain est utilisée, c'est-à-dire à effectuer la plupart des activités dans la deuxième couche (couche 2, ci-après appelée L2), plutôt que directement sur la chaîne. Dans ce cas, un contrat intelligent est souvent déployé sur la chaîne, qui n'est responsable que du traitement des dépôts et des retraits, et utilise diverses méthodes pour lire les données hors chaîne afin de vérifier que tout ce qui se passe hors chaîne est conforme aux règles. Cela équivaut à ériger une autoroute à côté d'une petite route, c'est-à-dire à travers l'expansion L2 pour résoudre le problème de congestion.
Actuellement, les trois principaux types ou solutions d'expansion L2 sont les canaux d'état, le plasma et le rollup. Ce sont trois paradigmes différents, chacun avec ses avantages et ses inconvénients. Toutes les extensions L2 peuvent être grossièrement classées dans ces trois catégories (bien qu'il existe des différends sur la dénomination, comme validium), parmi lesquelles Rollup a ses propres avantages.
Récapitulatif et disponibilité des données
Par rapport à d'autres solutions d'expansion, Rollup a certains avantages. L'un des avantages les plus intuitifs est qu'il résout le problème de disponibilité des données Plasma (mentionné dans le chapitre "Disponibilité des données" de l'article de M. Darren), et ici je vais également faire quelques supplément.
Le fait que les données soient en chaîne est très important (remarque : mettre des données "sur IPFS" ne fonctionnera pas, car IPFS ne fournit pas de vérification au niveau du consensus qu'il n'y a aucune garantie qu'une donnée donnée est disponible, c'est-à-dire que les données doivent être stockés dans des blocs). Dans les deux schémas d'expansion de Plasma et du canal précédent, les données et les calculs sont entièrement placés dans le réseau de deuxième couche. Lorsque le réseau de deuxième couche interagit avec Ethereum, toutes les données de transaction sur la chaîne de deuxième couche ne sont pas incluses. état Du point de vue de la machine, c'est-à-dire que chaque changement d'état de la chaîne Plasma n'est pas inclus. Cela conduira au fait que si Ethereum est séparé du réseau de second niveau tel que Plasma, il ne pourra pas restaurer les changements d'état précédents.Par conséquent, la disponibilité des données Ethereum dépend fortement de la protection des données Plasma.
Mécanisme de cumul
Afin d'assurer la disponibilité des données, le marché choisit Rollup, alors comment fonctionne Rollup ?
Figure 4 State Root dans le contrat L1 | Source
Dans la conception Rollup, il existe un contrat Rollup sur la chaîne principale, qui stocke une racine d'état. Cette racine d'état peut être considérée comme une version améliorée de la racine Merkle de l'arbre Merkle, qui stocke le solde du compte (c'est-à-dire une sorte d'état), le code de contrat et d'autres informations. La figure 4 montre la racine d'état stockée dans le contrat cumulatif. .
Le nœud L2 a trois fonctions principales : premièrement, déterminer quelles transactions doivent être emballées en premier (généralement ce type de nœud ou de client est appelé un séquenceur Sequencer), deuxièmement, il doit fournir une preuve pour chaque donnée emballée, et enfin la soumettre à le contrat L1 The Rollup est vérifié par ce contrat. La figure 5 montre le rôle du séquenceur dans L2.
Figure 5 Le séquençage, la vérification et la soumission du lot sont les principales fonctions de la phase L2 | Source
Plus précisément, L2 peut transférer un lot de données (batch) vers L1. Ces données peuvent être des collections de transactions hautement compressées ou des changements d'état après l'exécution du contrat, et également inclure la racine d'état stockée dans le contrat L1 et la nouvelle racine post-état ( post-state root) obtenu après que L2 a traité les données. Le contrat vérifie l'exactitude de la racine post-état basée sur ces données. Une fois la vérification réussie, le lot de données sera confirmé au niveau de la couche L1, complétant ainsi le processus en chaîne de L2 à L1.
La racine post-état (racine post-état) est calculée à partir des données d'origine. Pour s'assurer que la nouvelle racine post-état dans les données soumises est correcte, le moyen le plus simple consiste à laisser L1 recalculer une fois. Cependant, cela mettra sans aucun doute beaucoup de pression sur la L1. Pour résoudre ce problème critique, il existe deux schémas d'optimisation complètement différents, Optimistic Rollup et ZK Rollup.
Récapitulatif ZK et récapitulatif optimiste
ZK Rollup utilise des preuves de protocole cryptographique telles que ZK-SNARK ou ZK-STARK pour vérifier l'exactitude de la racine post-état après l'exécution du lot. Quelle que soit la quantité de calculs en L2, ZK Rollup peut rapidement vérifier sur la chaîne L1.
Un autre type de preuve est Optimistic Rollup, qui utilise des preuves de fraude. Il y a une analogie frappante ici : c'est comme une mère qui ne vérifie pas souvent les devoirs de son fils, mais tant que les devoirs ne sont pas terminés une fois, elle sera sévèrement punie. Dans le cadre de ce mécanisme, le contrat Rollup conserve une trace de l'historique complet de la racine d'état et des hachages de chaque lot. Si quelqu'un découvre qu'un lot a une racine post-état incorrecte, il peut publier une preuve que le lot a été calculé de manière incorrecte. Les autres nœuds vérifient ensemble la preuve et restaurent le lot et tous les lots suivants.
La figure 6 résume la comparaison des avantages et des inconvénients de Optimistic Rollup et ZK Rollup. Il est important de noter ici que ZK Rollup excelle en TPS et a un avantage significatif dans les cycles de remboursement. Cependant, ses inconvénients sont la compatibilité EVM et la consommation de calcul au niveau de la couche L2 :
Les projets Optimistic Rollup, tels que Optimism et Arbitrum, utilisent respectivement OVM et AVM, et leurs environnements virtuels sont fondamentalement les mêmes que EVM, de sorte qu'ils peuvent directement migrer les contrats L1 vers L2 pour le déploiement. Cependant, dans ZK Rollup, il est assez difficile d'utiliser ZK-SNARK pour prouver l'exécution générale d'EVM, car EVM n'est pas développé selon les exigences mathématiques du calcul de preuve ZK, il est donc nécessaire de transformer un certain type de client EVM en Utiliser Technologie ZK pour vérifier les transactions et les opérations contractuelles.
Dans le même temps, même après la conversion correspondante, le fonctionnement ZK nécessite encore beaucoup de puissance de calcul, donc ZK Rollup n'est pas aussi efficace que Optimistic Rollup dans l'efficacité de la couche L2.
ZK Rollup fournit une meilleure compression des données que Optimistic Rollup, de sorte qu'il peut soumettre des données plus petites sur L1.
Étant donné que le processus de vérification de preuve dans ZK est plus rapide et a une densité de lots plus élevée, ZK Rollup est plus faible dans la consommation de calcul de la couche L1. On peut comprendre que le paiement de nœud sur L2 réduit considérablement les exigences pour les nœuds L1, améliorant ainsi considérablement l'évolutivité de la couche L1.
Figure 6 Comparaison de deux méthodes de cumul | Source :
** Récapitulatif ZK ou cumul zkEVM ? **
Bien que ZK Rollup semble attrayant, il existe de nombreuses difficultés dans le déploiement réel. À l'heure actuelle, ZK Rollup a encore des limitations considérables, tandis que Optimistic Rollup est toujours la solution principale. La plupart des ZK Rollups mis en œuvre sont également personnalisés pour certaines applications spécifiques.
Comment comprendre le ZK Rollup personnalisé ? Les développeurs créent des circuits spécifiques à l'application ("ASIC") pour différents DApps, tels que Loopring, StarkEx rollup et zkSync 1.0, qui prennent en charge des types spécifiques de paiement, d'échange de jetons ou de coulée NFT. Cependant, leur conception de circuit nécessite un degré élevé de connaissances techniques, ce qui conduit à une mauvaise expérience de développeur. En prenant un type spécifique de données de paiement comme exemple, le nœud soumet les données de transaction au séquenceur, et le séquenceur les regroupe dans un lot et les soumet au nœud qui soumet la preuve en tant qu'entrée publique, le processus de preuve et le contrat processus d'exécution sur la machine virtuelle Cela n'a rien à voir, ZK est uniquement chargé de prouver le processus de calcul et de compression du cumul d'un résultat d'exécution spécifique.
Et zkEVM Rollup représente la capacité de cumuler les résultats d'exécution de la machine virtuelle. Lors de l'exécution d'un contrat intelligent à usage général sur la couche L2, il est nécessaire de prouver la validité de la transition d'état avant et après l'exécution du contrat, et un environnement virtuel est requis pour prendre en charge le fonctionnement de l'algorithme ZK. Par conséquent, le sens de zkEVM est d'exécuter le contrat, de générer l'état final, de prouver la validité du processus d'exécution du contrat et de soumettre les enregistrements de transaction, les enregistrements de compte et les données d'enregistrement de changement d'état ensemble dans le cumul. La couche L1 n'a besoin que de vérifier rapidement la preuve, la surcharge est faible et il n'est pas nécessaire d'exécuter à nouveau le contrat.La figure 7 illustre clairement le rôle de zkVM. Il convient de noter que zkEVM est en fait une machine virtuelle de type EVM fonctionnant sur la couche L2, donc un terme plus précis est Zero Knowledge Virtual Machine, zkVM, mais tout le monde souligne qu'il est compatible avec Ethereum et l'appelle zkEVM.
Figure 7 Un diagramme illustrant zkVM | Source
Les projets existants envisagent également d'abandonner progressivement l'optimisation pour des applications spécifiques et de procéder à une mise à niveau pour prendre en charge l'exécution de contrats à usage général, c'est-à-dire zkEVM Rollup. Par conséquent, bien que zkEVM Rollup soit un concept subordonné de ZK Rollup, dans la plupart des cas, lorsque ZK Rollup est mentionné, il fait référence à zkEVM Rollup.
PARTIE 4Aperçu du projet cumulatif zkEVM
Divers projets zkEVM verront le jour au cours du premier semestre 2023. En prêtant attention à ces projets, l'auteur se concentre principalement sur les aspects suivants :
Avancement actuel du projet : y compris l'étape actuelle du projet et l'heure de lancement prévue du réseau de test et du réseau principal, et si elle est cohérente avec la feuille de route de développement.
L'interaction réelle du projet : grâce à l'interaction avec le réseau de test (principal), etc., ressentez subjectivement le TPS du réseau, le temps de confirmation d'une seule transaction, etc., et ressentez intuitivement les performances du réseau.
Compatibilité zkEVM : C'est le point technique le plus central et le plus difficile à juger.Même si certains projets sont open source, la technologie au niveau des VM est la plus dure et implique plus de protocoles ZK. Plus précisément, il faut faire attention au protocole ZK, à la sécurité des VM, à la compatibilité, etc.
Architecture zkEVM Rollup : par rapport à zkEVM, les projets généraux divulgueront leur architecture Rollup dans des livres blancs et d'autres documents techniques, et la différence globale est moindre, mais il convient de prêter attention à son degré global de décentralisation.
Fonctionnement écologique : Le nombre d'utilisateurs du projet, le degré d'activité, le fonctionnement et l'incubation de l'écologie applicative sur la chaîne, et le maintien de la communauté des développeurs sont des indicateurs qui reflètent en douceur le fonctionnement du projet.
Situation des investissements et du financement.
Cet article considère le projet davantage du point de vue des quatre premiers points et accorde plus d'attention à l'architecture globale de zkEVM Rollup du niveau technique.
Faire défiler
Fondée en 2021, l'équipe Scroll s'est engagée à développer l'équivalent EVM de ZK Rollup pour la mise à l'échelle d'Ethereum Depuis près de deux ans, Scroll travaille avec l'équipe Privacy and Scaling Explorations et d'autres contributeurs open source pour créer publiquement un rollup compatible avec le bytecode .zkEVM. Fin février, Scroll a annoncé que son réseau de test Alpha était désormais en ligne sur Goerli. Tout utilisateur peut participer aux tests techniques sans autorisation. Le temps de blocage moyen du réseau de test est de 3 secondes. Il y a déjà plus de 20 millions de transactions et plus de 1,5 million de blocs et plus de 4 millions d'adresses interactives. Dans le même temps, Scroll a également ouvert l'interface de l'écosystème du site Web le 11 avril.
À en juger par la récente divulgation d'informations, Scroll progresse constamment sur la voie de l'équivalence EVM de type 2. Récemment, Scroll a terminé le développement compatible de tous les opcodes EVM, et est en cours d'audit.Parallèlement, le prochain objectif est d'être compatible avec les transactions EIP2718.
En termes d'architecture technique, l'architecture de Scroll est relativement traditionnelle, elle sera donc présentée en détail ici. Comme le montre la figure 8, il est principalement divisé en deux parties : la partie principale est zkEVM, qui est utilisée pour prouver l'exactitude de l'exécution d'EVM en L2 ; mais pour transformer zkEVM en un cumul ZK complet sur Ethereum, une L2 complète doit être construit autour de l'architecture zkEVM. Plus précisément, le testnet Scroll Alpha existant se compose de Scroll Node, Bridge Contract et Rollup Contract :
Figure 8 Architecture globale du cumul de défilement | Source
Noeud de défilement : composé d'un séquenceur, d'un relayeur et d'un coordinateur.
a) Sequencer, le soi-disant séquenceur, ouvre JSON-RPC aux utilisateurs et aux applications, lit les transactions dans le pool de transactions et génère des blocs L2 et des racines d'état. À ce stade, les nœuds Sequencer de Scroll sont centralisés et seront progressivement décentralisés dans les futures mises à jour.
b) Le coordinateur est responsable de la communication entre le rouleau et le nœud de défilement. Lorsqu'un nouveau bloc est généré dans le séquenceur, le rouleau du pool est sélectionné au hasard pour la génération de la preuve.
c) Le relais surveille le contrat de pont et le contrat de cumul sur les chaînes Ethereum et Scroll. Le contrat Rollup garantit la disponibilité des données L2 au niveau L1 et garantit que le bloc L2 peut être restauré au niveau L1. Une fois que le bloc soumis par la couche L2 est vérifié par le contrat Rollup sur la couche L1, le bloc atteindra la finalité au niveau de la couche L2. L'état immuable de . Le contrat de pont est responsable de la communication entre les contrats à double chaîne lors du franchissement des chaînes, de l'envoi de messages arbitraires dans les deux sens ou de la réalisation des opérations de nantissement et de retrait des actifs lors du franchissement des chaînes.
Figure 9 2. Réseau de rouleaux | Source
Réseau Roller : Roller a un zkEVM intégré, qui agit comme un prouveur dans le réseau et est chargé de générer des preuves de validité pour ZK Rollup, comme illustré à la Figure 9.
a) Roller convertit d'abord la trace d'action reçue du coordinateur (c'est-à-dire quelles opérations spécifiques le contrat a effectuées et quelles adresses sont impliquées) en témoins de circuit.
b) Il génère des preuves pour chaque circuit zkEVM et agrège finalement ces preuves à partir de plusieurs circuits ZK.
StarkWare
StarkWare fournit une solution de mise à l'échelle basée sur STARK pour garantir la sécurité L2, la vitesse et une expérience utilisateur transparente. Ils prennent en charge plusieurs modes de disponibilité des données. StarkNet est leur réseau L2, tandis que StarkEx est un service de vérification Rollup pour les utilisateurs d'entreprise, et les DApps peuvent être construits sur les services StarkEx. Cependant, actuellement, seuls des circuits personnalisés peuvent être écrits pour des DApp spécifiques, et non pour le cumul général de zkEVM. StarkEx prend en charge une série de services plug-and-play, y compris la frappe et le trading NFT, le trading de produits dérivés, etc. En termes d'écologie, la plateforme décentralisée de négociation de contrats à terme DYDX est un fidèle utilisateur de StarkWare.
StarkNet, à proprement parler, est zkVM Au lieu de faire des circuits ZK pour les opcodes Ethereum, il a créé un ensemble de langages d'assemblage plus compatibles avec ZK, AIR (Algebraic Intermediate Representation) et le langage de haut niveau Cairo. Bien que StarkNet lui-même ne soit pas compatible avec EVM, il peut toujours être compatible avec Ethereum via d'autres méthodes, y compris Kakarot (Kakarot est un zkEVM écrit au Caire, qui est un zkEVM dont le bytecode est équivalent à EVM). Selon ma compréhension, StarkNet est un projet relativement centralisé, dont l'un est qu'il ne peut pas être synchronisé avec la mise à niveau de sécurité d'Ethereum, il est donc nécessaire de concentrer le personnel de R&D pour pallier les lacunes en matière de sécurité et suivre le développement et adaptation du nouvel accord EPF.
StarkNet utilise STARK comme système de preuve.Par rapport à SNARK, STARK a plus d'innovations. Il n'a pas besoin de s'appuyer sur des "paramètres de confiance" comme SNARK. De plus, il a également des hypothèses cryptographiques plus simples, évite le besoin d'hypothèses de courbe elliptique, d'appariement et de connaissances exponentielles, et s'appuie uniquement sur le hachage et la théorie de l'information, il est donc plus résistant aux attaques quantiques. Dans l'ensemble, les STARK sont plus sûrs que les SNARK. En termes de capacités d'expansion, STARK a un effet marginal significatif, et plus la preuve est grande, plus le coût total est faible.
Cependant, en termes d'architecture, il n'y a actuellement qu'un seul séquenceur (séquenceur) dans le système, qui est contrôlé par StarkWare, et il n'y a qu'un seul prouveur (c'est-à-dire le prouveur qui génère ZK Proof), qui non seulement génère des preuves pour StarkNet, mais fonctionne également de manière autonome Preuve de génération pour toutes les autres applications du cumul StarkEx.
Variantes de ZK Rollup : Validiums et Volitions
Validium est également une solution de mise à l'échelle L2 qui utilise une preuve de calcul telle que ZK Rollup pour renforcer l'intégrité du processus de transaction. Contrairement à ZK Rollup, Validium ne stocke pas les données de transaction sur le réseau principal Ethereum. Sacrifier la disponibilité des données en chaîne est un compromis qui peut conduire à d'énormes améliorations de l'évolutivité, le point le plus immédiat étant que Validiums peut traiter environ 9 000 transactions par seconde.
Mais aux yeux de l'auteur, Validium ne peut pas être considéré comme un strict ZK Rollup. Cette solution est similaire à Plasma et n'assure pas la disponibilité des données au niveau de la couche L1. Elle ne peut donc pas être considérée comme un cumul. La différence avec Plasma est que Plasma a mis en place un "mécanisme de sortie de sept jours" similaire à OP Rollup dans la couche L2, tandis que Validium utilise et ZK signifie raccourcir le temps de vérification des données à la couche L2 et ne synchronise pas le données à la L1.
Volition, lancé par StarkWare, permet aux utilisateurs de basculer facilement entre ZK Rollup et Validium. Par exemple, certaines applications, telles que les échanges décentralisés de produits dérivés, peuvent être plus adaptées à Validium, tout en voulant toujours être interopérables avec les applications sur ZK Rollup, alors Volition fournit cette commutabilité.
zkSync
Semblable à StarkNet, zkSync a toujours insisté pour choisir zkVM, qui équivaut à un langage de haut niveau, et a attiré beaucoup d'attention, avec une popularité et un volume de verrouillage très élevés. zkSync 1.0 (zkSync Lite) a été lancé sur le réseau principal Ethereum le 15 juin 2020, atteignant un débit de transaction d'environ 300 TPS, mais il n'est pas compatible avec EVM. Et zkSync 2.0 (zkSync Era) sera lancé le 24 mars 2023.
L'objectif de zkSync Era est de générer des preuves plus rapidement en utilisant leur machine virtuelle personnalisée pour l'optimisation plutôt que de rechercher l'équivalence EVM. Il prend en charge Solidity, Vyper, Yul et Zinc (langage de programmation interne de rollup) via un puissant compilateur LLVM pour implémenter la plupart des fonctions de contrat intelligent. En raison de la VM auto-développée, zkSync Era prend en charge l'abstraction de compte native, de sorte que n'importe quel compte peut utiliser n'importe quel jeton pour payer.
De plus, grâce à l'application du protocole zkPorter, combiné aux rollups ZK et à la technologie de fragmentation, le débit du réseau a été augmenté de façon exponentielle, atteignant plus de 20 000 TPS (similaire à la commutation de disponibilité des données de Volitions).
Dans l'ensemble, zkSync est un projet L2 écologiquement riche qui a attiré l'attention des développeurs et des investisseurs. Bien qu'il y ait eu quelques cas récents de projets complètement échoués sur zkSync, il reste à savoir si les développeurs peuvent obtenir une bonne expérience de développement et de migration sur l'équivalent linguistique de haut niveau de zkVM. Il y a actuellement un manque de rapports d'utilisation exacts au niveau des développeurs. Si les développeurs ont une bonne expérience, à quoi servent les autres types de zkVM qui s'efforcent d'être proches de l'EVM ? Nous avons encore besoin de temps pour observer.
Polygone zkEVM
JeuxServer a lancé la version bêta du réseau principal zkEVM Rollup le 27 mars, qui est également la machine virtuelle équivalente d'Ethereum, et a ouvert tout le code zkEVM. Par rapport à zkSync, la quantité verrouillée de polygone zkEVM est beaucoup plus petite, mais il existe également de nombreux projets intéressants et dynamiques dans l'écologie.
En termes de conception de Rollup, Polygon diffère de Scroll en ce qu'il utilise un modèle de preuve d'efficacité (PoE) pour motiver le séquenceur et l'agrégateur à résoudre certains des défis de la décentralisation et des validateurs sans autorisation. Dans le modèle trieur-agrégateur en deux étapes sans autorisation, tout trieur peut soumettre une demande d'emballage de lots afin d'obtenir la redevance d'emballage, mais il doit payer la redevance Gaz de la couche L1 et déposer une certaine quantité de Token ; en même temps, les jetons d'agrégation doivent fixer leurs propres objectifs pour maximiser le profit garanti pour chaque génération de preuve. De plus, les modes Polygon et Volition (ZK Rollup et Validium) ont également des modèles de disponibilité des données profondément compatibles pour fournir aux utilisateurs différents niveaux de services.
De plus, Polygon a également investi une quantité considérable de travail dans le protocole ZK, et l'effet est également remarquable.Dans le document, ils résument leurs avantages techniques, notamment les points suivants :
Plus compatible : Polygon a toujours insisté sur l'utilisation de zkVM, qui équivaut à EVM, pour réduire le coût des développeurs qui migrent les dApps. Dans le même temps, bien que Polygon Miden adopte le protocole ZK-STARK, il prend toujours en charge l'exécution de contrats Solidity.
Vérification plus facile : la raison pour laquelle ZK Rollup est souvent critiqué est que la génération de preuves de validité nécessite un matériel spécialisé coûteux que les fournisseurs utilisent et répercutent le coût sur les utilisateurs. Polygon ZK Rollup (comme Polygon Zero) vise à simplifier les schémas de preuve afin que les appareils de niveau inférieur puissent participer, par exemple, aux tests de génération de preuve Plonky2 sur des PC grand public.
Processus de génération et de vérification de preuves plus rapides : Polygon Zero peut générer une preuve de 45 Ko en 170 millisecondes.
PARTIE 5Écart entre la technologie théorique et les projets pratiques
Ce rapport de recherche a principalement réalisé la vulgarisation scientifique de la technologie ZK et l'introduction du mécanisme Rollup, en insistant sur l'importance de la disponibilité des données, et a fait une certaine distinction sur la question du ZK ou zkEVM Rollup. De plus, sur la base de la distinction entre zkVM et zkEVM, il trie également en détail les différences entre les trois types de zkEVM et les différents types et pistes ZK associées. Enfin, associés à plusieurs projets avantageux, ils ont revu leurs cadres techniques respectifs et l'écologie existante.
Cependant, en termes de projets spécifiques, les projets qui choisissent des langages de haut niveau équivalents occupent la position dominante sur le marché, et certains produits fortement centralisés tels que StarkWare peuvent également gagner les faveurs du marché. Même si le premier type de VM mentionné dans la recherche théorique a de fortes limites, sous les clients du marché limité, "l'universalité" semble être un fardeau, et nous ne pouvons pas distinguer quels problèmes "l'expansion efficace" a percés et réalisé l'effet au-delà de la théorie . Bien sûr, en fait, beaucoup de gens ne font pas attention aux fonctionnalités techniques, donc cela ne semble pas très Web3, mais aussi très Web3.
Le but de la technologie Rollup est d'exploiter davantage la valeur de la blockchain, mais souvent en raison du besoin urgent de devenir un "concept innovant" sur le marché, il y a un phénomène de "retour en arrière" et de retour à la centralisation. C'est le problème du marché actuel.
La valeur de la blockchain est facile à voir, qui ne voudrait pas avoir un ordinateur éternel ? Mais le problème principal est que lorsque la capacité de fonctionnement de cet ordinateur est bien inférieure à celle de n'importe quel serveur autour de nous et nécessite beaucoup d'investissement en ressources, même si la valeur d'usage est bien inférieure à notre coût d'entrée, en tant que "produit public" , c'est encore Tout le monde peut-il s'impliquer ?
Alors que nous avons déjà des produits de nombreux pays, sociétés et même individus, dans quelles circonstances sommes-nous prêts à ignorer le coût élevé d'utilisation et à poursuivre le résultat du "toujours en ligne, toujours correct" ? Je pense que c'est quelque chose auquel l'industrie de la blockchain doit réfléchir aujourd'hui. La technologie Rollup peut techniquement améliorer ce problème, mais il reste encore un grand nombre de problèmes qui doivent être résolus par le marché impétueux.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
zkEVM Rollup : le décalage entre vision technologique et projet
Afin de résoudre le problème d'expansion du réseau blockchain Layer 1, la solution Rollup a vu le jour. Combiné à la technologie ZK, ZK Rollup est devenu le nouveau chouchou de la piste Layer 2. Cependant, pour la plupart des gens, des concepts connexes tels que ZK, Rollup et EVM peuvent avoir un certain seuil de compréhension. Par conséquent, l'objectif de ce rapport de recherche est de trier systématiquement pour vous une série de concepts de zkEVM Rollup dans un langage concis et facile à comprendre, d'analyser en profondeur l'évolution et l'état de développement de la technologie zkEVM Rollup et d'interpréter les principaux facteurs écologiques. projets en détail. Il est conçu pour vous aider à bien comprendre et à juger de la tendance de développement de la piste zkEVM Rollup.
PARTIE 1 Comprendre ZK
ZK (ou ZKP), le nom complet est Zero-Knowledge Proof, c'est-à-dire la preuve de connaissance zéro. En cryptographie, la preuve de connaissance zéro ou le protocole de connaissance zéro est une méthode par laquelle une partie (le prouveur) peut soumettre au autre partie (certificateur de vérification) de prouver un fait sans divulguer les informations spécifiques du fait, c'est-à-dire qu'une partie (prouveur) peut faire savoir à l'autre partie si le fait est correct sans divulguer aucune "information spécifique" de le fait, donc la technologie ZK peut être utilisée en toute intimité Le domaine de la protection nous laisse beaucoup de place à l'imagination.
Bien sûr, en plus des avantages de la protection de la vie privée que la technologie ZK peut apporter, dans ZK Rollup, la technologie ZK est plus importante pour résoudre le problème de "vérification difficile". Le processus de "vérification" est très important pour la blockchain. La majeure partie du processus de calcul dans Ethereum consiste à répondre aux exigences de vérification, et ZK Rollup peut réduire considérablement le temps consacré à la vérification par l'ensemble du réseau de nœuds. Par exemple, si un bloc met beaucoup de temps à vérifier qu'il satisfait aux règles de l'ensemble du réseau lors de la génération du bloc, il peut y avoir un prouveur qui le vérifie en premier et génère une "preuve" du résultat de calcul de ce bloc, et le reste Le but de vérifier le bloc peut être atteint en vérifiant rapidement cette "preuve" au lieu du bloc d'origine avec une énorme quantité de calculs.
Un protocole ZK simple est divisé en étapes suivantes, génération de clé, preuve et vérification, et je vais les démonter pour vous une par une.
01 Génération de clé, preuve et vérification
Dans ZK, il faut d'abord convertir le problème à vérifier en une expression mathématique, puis en un polynôme, et l'exprimer sous la forme d'un circuit arithmétique. Lorsqu'un programme est converti en un circuit arithmétique, il est décomposé en étapes individuelles consistant en des opérations arithmétiques de base telles que l'addition, la soustraction, etc. En tant que fonction qui sera sortie, elle peut être transformée dans le schéma de circuit suivant, voir Figure 1.
Figure 1 Un exemple de schéma de circuit, on peut remarquer que toutes les opérations du circuit sont divisées en opérations de base les plus simples | Source
En utilisant ce circuit et quelques nombres aléatoires en entrée, nous pouvons générer une clé de preuve (pk, clé de preuve) et une clé de vérification (vk, clé de vérification) pour le processus de vérification ultérieur, le schéma de principe est illustré à la figure 2.
Figure 2 Génération de "paramètres publics"
Notre système de preuve nécessite également deux types d'entrées - privées et publiques, ainsi que la clé de preuve pour générer la preuve. Parmi eux, l'entrée privée (témoin) est le secret que nous voulons cacher, et l'entrée publique est l'information qui peut être rendue publique. Par exemple, dans l'équation X+Y*Z=OUT, X et OUT sont des entrées publiques, tandis que Y et Z ont des valeurs que nous ne voulons pas rendre publiques au validateur. Bien que la valeur de Y*Z puisse être déduite sur la base des commentaires du public, les valeurs spécifiques de Y et Z sont encore incertaines.
Figure 3 Le processus de preuve et le processus de vérification des ZK-SNARK
Lorsque le vérificateur reçoit la preuve, il utilise l'entrée publique, la preuve et la clé de vérification pour vérifier la preuve et renvoie le résultat de la vérification (c'est-à-dire si la vérification est réussie).
Après avoir compris le processus ci-dessus, nous pouvons appliquer cette technologie pour bloquer la vérification afin de réaliser un petit ZK-SNARK, comme le montre la figure 3. Il existe de nombreux protocoles et méthodes pour réaliser une preuve à connaissance zéro. SNARK est relativement facile à comprendre, et c'est aussi le choix de la plupart des projets à ce stade. Dans le paragraphe "Des ZK-SNARKs à ZK-STARKs" nous parlerons des avantages et des inconvénients des SNARKs.
02 Essayez un peu de SNARK
Prenons une preuve de connaissance zéro d'un arbre Merkle qui enregistre l'état du compte comme exemple de pratique. L'arbre Merkle enregistre l'adresse et le solde du compte. Lorsqu'une nouvelle transaction doit mettre à jour l'arbre Merkle, nous devons effectuer les opérations suivantes :
Vérifiez que l'expéditeur et le destinataire de la transaction se trouvent sur les nœuds feuilles de l'arborescence.
Vérifiez la signature de l'expéditeur.
Mettre à jour les soldes de l'expéditeur et du destinataire.
Mettez à jour le nœud racine de l'arbre Merkle (c'est-à-dire Merkle Root) et utilisez-le comme sortie finale.
En l'absence de preuves de connaissance nulle, le vérificateur doit répéter ces étapes pour s'assurer de l'exactitude du calcul. Mais après avoir utilisé la preuve à connaissance nulle, la situation est différente. Tout d'abord, nous devons identifier deux types d'entrées :
Au cours de ce processus, seules les nouvelles informations de transaction, la racine Merkle d'origine et la racine Merkle mise à jour sont des entrées publiques.
L'arbre Merkle lui-même agit comme un témoin (témoin) et n'a pas besoin d'être lu ou traité par le vérificateur.
Deuxièmement, nous devons générer des clés et calculer des circuits. Nous construisons des processus de calcul tels que la mise à jour de Merkle Tree et la vérification des adresses d'entrée et de sortie dans des circuits de calcul pour obtenir des clés de preuve et des clés de vérification. Ce circuit n'a rien à voir avec les informations de transaction d'entrée, ni avec la racine Merkle existante, car la méthode de calcul de l'arbre Merkle est fixe.
Au stade de la génération des preuves, nous prenons les deux arbres de Merkle et les informations de transaction en entrée. À l'étape du vérificateur, le vérificateur peut assurer la fiabilité de la mise à jour sans obtenir l'arbre de Merkle, c'est-à-dire sans connaître les informations du compte. Le circuit est comme une boîte noire solide, tant que l'entrée est correcte, il obtiendra la sortie correcte.
En utilisant la preuve de connaissance zéro, d'autres vérificateurs peuvent rapidement vérifier que le processus de génération de l'arbre Merkle est crédible, réduisant ainsi le temps de vérification répétée sur le réseau, et les informations de l'arbre Merkle n'ont pas besoin d'être divulguées au vérificateur.
03 De ZK-SNARK à ZK-STARK
Le protocole de preuve mentionné ci-dessus est ZK-SNARKs. SNARK signifie arguments de connaissance succincts non interactifs, où succinct fait référence à la simplicité de cette méthode, et non interactif fait référence à celle par rapport à d'autres méthodes de preuve, les SNARK sont des preuves non interactives, c'est-à-dire que le vérificateur n'a besoin que d'utiliser le succinct La preuve générée permet d'obtenir le résultat de la vérification. Cependant, il y a quelques problèmes avec les ZK-SNARK. Dans l'étape de génération de clé, le circuit et le nombre aléatoire sont équivalents à un ensemble de paramètres publics initiaux, et il existe un problème inévitable de centralisation dans le processus de génération de ce paramètre public.
Les ZK-STARK ont une approche différente basée sur les SNARK, où "s" signifie scalabilité, ce qui prouve que le temps de génération et le temps de calcul d'origine sont quasi-linéaires, et le temps de vérification est logarithmique dans le calcul d'origine, ce qui signifie Dans le Dans le cas d'un grand jeu de données sous forme de données, le temps de vérification requis par le vérificateur est fortement raccourci.
Dans le même temps, en tant que version améliorée des ZK-SNARK, les ZK-STARK peuvent non seulement améliorer l'efficacité de la vérification (l'efficacité théorique est 10 fois), mais ne reposent pas non plus sur des courbes elliptiques ou des paramètres de confiance, et ne nécessitent pas le processus de générer des paramètres publics initiaux (la lettre "T" signifie transparence), ce qui supprime le besoin d'une configuration de confiance centralisée. Certains développeurs pensent que la fonction de hachage de ZK-STARK peut aider à résister aux attaques quantiques.
Cependant, ZK-STARKs a été introduit tardivement, la technologie actuelle n'est pas assez mature et repose sur des fonctions de hachage, ce qui limite sa polyvalence.ZK-SNARKs est toujours un algorithme de preuve général. Quelques exemples d'algorithmes basés sur STARK incluent Fractal, SuperSonic, etc., et les projets associés incluent StarkWare, Polygon Miden, etc.
PARTIE 2 Comprendre le cumul
En plus de ZK, un autre concept que nous devons comprendre est Rollup.L'importance de Rollup est de résoudre le problème de congestion du réseau de couche 1.
Prenons Ethereum comme exemple, il a actuellement le problème de la congestion des transactions. Il existe deux façons de résoudre ce problème : l'une consiste à augmenter la capacité de transaction de la blockchain elle-même, par exemple en augmentant le débit de la blockchain grâce à des technologies telles que le sharding. Une autre approche consiste à modifier la façon dont la blockchain est utilisée, c'est-à-dire à effectuer la plupart des activités dans la deuxième couche (couche 2, ci-après appelée L2), plutôt que directement sur la chaîne. Dans ce cas, un contrat intelligent est souvent déployé sur la chaîne, qui n'est responsable que du traitement des dépôts et des retraits, et utilise diverses méthodes pour lire les données hors chaîne afin de vérifier que tout ce qui se passe hors chaîne est conforme aux règles. Cela équivaut à ériger une autoroute à côté d'une petite route, c'est-à-dire à travers l'expansion L2 pour résoudre le problème de congestion.
Actuellement, les trois principaux types ou solutions d'expansion L2 sont les canaux d'état, le plasma et le rollup. Ce sont trois paradigmes différents, chacun avec ses avantages et ses inconvénients. Toutes les extensions L2 peuvent être grossièrement classées dans ces trois catégories (bien qu'il existe des différends sur la dénomination, comme validium), parmi lesquelles Rollup a ses propres avantages.
Récapitulatif et disponibilité des données
Par rapport à d'autres solutions d'expansion, Rollup a certains avantages. L'un des avantages les plus intuitifs est qu'il résout le problème de disponibilité des données Plasma (mentionné dans le chapitre "Disponibilité des données" de l'article de M. Darren), et ici je vais également faire quelques supplément.
Le fait que les données soient en chaîne est très important (remarque : mettre des données "sur IPFS" ne fonctionnera pas, car IPFS ne fournit pas de vérification au niveau du consensus qu'il n'y a aucune garantie qu'une donnée donnée est disponible, c'est-à-dire que les données doivent être stockés dans des blocs). Dans les deux schémas d'expansion de Plasma et du canal précédent, les données et les calculs sont entièrement placés dans le réseau de deuxième couche. Lorsque le réseau de deuxième couche interagit avec Ethereum, toutes les données de transaction sur la chaîne de deuxième couche ne sont pas incluses. état Du point de vue de la machine, c'est-à-dire que chaque changement d'état de la chaîne Plasma n'est pas inclus. Cela conduira au fait que si Ethereum est séparé du réseau de second niveau tel que Plasma, il ne pourra pas restaurer les changements d'état précédents.Par conséquent, la disponibilité des données Ethereum dépend fortement de la protection des données Plasma.
Mécanisme de cumul
Afin d'assurer la disponibilité des données, le marché choisit Rollup, alors comment fonctionne Rollup ?
Figure 4 State Root dans le contrat L1 | Source
Dans la conception Rollup, il existe un contrat Rollup sur la chaîne principale, qui stocke une racine d'état. Cette racine d'état peut être considérée comme une version améliorée de la racine Merkle de l'arbre Merkle, qui stocke le solde du compte (c'est-à-dire une sorte d'état), le code de contrat et d'autres informations. La figure 4 montre la racine d'état stockée dans le contrat cumulatif. .
Le nœud L2 a trois fonctions principales : premièrement, déterminer quelles transactions doivent être emballées en premier (généralement ce type de nœud ou de client est appelé un séquenceur Sequencer), deuxièmement, il doit fournir une preuve pour chaque donnée emballée, et enfin la soumettre à le contrat L1 The Rollup est vérifié par ce contrat. La figure 5 montre le rôle du séquenceur dans L2.
Figure 5 Le séquençage, la vérification et la soumission du lot sont les principales fonctions de la phase L2 | Source
Plus précisément, L2 peut transférer un lot de données (batch) vers L1. Ces données peuvent être des collections de transactions hautement compressées ou des changements d'état après l'exécution du contrat, et également inclure la racine d'état stockée dans le contrat L1 et la nouvelle racine post-état ( post-state root) obtenu après que L2 a traité les données. Le contrat vérifie l'exactitude de la racine post-état basée sur ces données. Une fois la vérification réussie, le lot de données sera confirmé au niveau de la couche L1, complétant ainsi le processus en chaîne de L2 à L1.
La racine post-état (racine post-état) est calculée à partir des données d'origine. Pour s'assurer que la nouvelle racine post-état dans les données soumises est correcte, le moyen le plus simple consiste à laisser L1 recalculer une fois. Cependant, cela mettra sans aucun doute beaucoup de pression sur la L1. Pour résoudre ce problème critique, il existe deux schémas d'optimisation complètement différents, Optimistic Rollup et ZK Rollup.
Récapitulatif ZK et récapitulatif optimiste
ZK Rollup utilise des preuves de protocole cryptographique telles que ZK-SNARK ou ZK-STARK pour vérifier l'exactitude de la racine post-état après l'exécution du lot. Quelle que soit la quantité de calculs en L2, ZK Rollup peut rapidement vérifier sur la chaîne L1.
Un autre type de preuve est Optimistic Rollup, qui utilise des preuves de fraude. Il y a une analogie frappante ici : c'est comme une mère qui ne vérifie pas souvent les devoirs de son fils, mais tant que les devoirs ne sont pas terminés une fois, elle sera sévèrement punie. Dans le cadre de ce mécanisme, le contrat Rollup conserve une trace de l'historique complet de la racine d'état et des hachages de chaque lot. Si quelqu'un découvre qu'un lot a une racine post-état incorrecte, il peut publier une preuve que le lot a été calculé de manière incorrecte. Les autres nœuds vérifient ensemble la preuve et restaurent le lot et tous les lots suivants.
La figure 6 résume la comparaison des avantages et des inconvénients de Optimistic Rollup et ZK Rollup. Il est important de noter ici que ZK Rollup excelle en TPS et a un avantage significatif dans les cycles de remboursement. Cependant, ses inconvénients sont la compatibilité EVM et la consommation de calcul au niveau de la couche L2 :
Les projets Optimistic Rollup, tels que Optimism et Arbitrum, utilisent respectivement OVM et AVM, et leurs environnements virtuels sont fondamentalement les mêmes que EVM, de sorte qu'ils peuvent directement migrer les contrats L1 vers L2 pour le déploiement. Cependant, dans ZK Rollup, il est assez difficile d'utiliser ZK-SNARK pour prouver l'exécution générale d'EVM, car EVM n'est pas développé selon les exigences mathématiques du calcul de preuve ZK, il est donc nécessaire de transformer un certain type de client EVM en Utiliser Technologie ZK pour vérifier les transactions et les opérations contractuelles.
Dans le même temps, même après la conversion correspondante, le fonctionnement ZK nécessite encore beaucoup de puissance de calcul, donc ZK Rollup n'est pas aussi efficace que Optimistic Rollup dans l'efficacité de la couche L2.
ZK Rollup fournit une meilleure compression des données que Optimistic Rollup, de sorte qu'il peut soumettre des données plus petites sur L1.
Étant donné que le processus de vérification de preuve dans ZK est plus rapide et a une densité de lots plus élevée, ZK Rollup est plus faible dans la consommation de calcul de la couche L1. On peut comprendre que le paiement de nœud sur L2 réduit considérablement les exigences pour les nœuds L1, améliorant ainsi considérablement l'évolutivité de la couche L1.
Figure 6 Comparaison de deux méthodes de cumul | Source :
** Récapitulatif ZK ou cumul zkEVM ? **
Bien que ZK Rollup semble attrayant, il existe de nombreuses difficultés dans le déploiement réel. À l'heure actuelle, ZK Rollup a encore des limitations considérables, tandis que Optimistic Rollup est toujours la solution principale. La plupart des ZK Rollups mis en œuvre sont également personnalisés pour certaines applications spécifiques.
Comment comprendre le ZK Rollup personnalisé ? Les développeurs créent des circuits spécifiques à l'application ("ASIC") pour différents DApps, tels que Loopring, StarkEx rollup et zkSync 1.0, qui prennent en charge des types spécifiques de paiement, d'échange de jetons ou de coulée NFT. Cependant, leur conception de circuit nécessite un degré élevé de connaissances techniques, ce qui conduit à une mauvaise expérience de développeur. En prenant un type spécifique de données de paiement comme exemple, le nœud soumet les données de transaction au séquenceur, et le séquenceur les regroupe dans un lot et les soumet au nœud qui soumet la preuve en tant qu'entrée publique, le processus de preuve et le contrat processus d'exécution sur la machine virtuelle Cela n'a rien à voir, ZK est uniquement chargé de prouver le processus de calcul et de compression du cumul d'un résultat d'exécution spécifique.
Et zkEVM Rollup représente la capacité de cumuler les résultats d'exécution de la machine virtuelle. Lors de l'exécution d'un contrat intelligent à usage général sur la couche L2, il est nécessaire de prouver la validité de la transition d'état avant et après l'exécution du contrat, et un environnement virtuel est requis pour prendre en charge le fonctionnement de l'algorithme ZK. Par conséquent, le sens de zkEVM est d'exécuter le contrat, de générer l'état final, de prouver la validité du processus d'exécution du contrat et de soumettre les enregistrements de transaction, les enregistrements de compte et les données d'enregistrement de changement d'état ensemble dans le cumul. La couche L1 n'a besoin que de vérifier rapidement la preuve, la surcharge est faible et il n'est pas nécessaire d'exécuter à nouveau le contrat.La figure 7 illustre clairement le rôle de zkVM. Il convient de noter que zkEVM est en fait une machine virtuelle de type EVM fonctionnant sur la couche L2, donc un terme plus précis est Zero Knowledge Virtual Machine, zkVM, mais tout le monde souligne qu'il est compatible avec Ethereum et l'appelle zkEVM.
Figure 7 Un diagramme illustrant zkVM | Source
Les projets existants envisagent également d'abandonner progressivement l'optimisation pour des applications spécifiques et de procéder à une mise à niveau pour prendre en charge l'exécution de contrats à usage général, c'est-à-dire zkEVM Rollup. Par conséquent, bien que zkEVM Rollup soit un concept subordonné de ZK Rollup, dans la plupart des cas, lorsque ZK Rollup est mentionné, il fait référence à zkEVM Rollup.
PARTIE 4 Aperçu du projet cumulatif zkEVM
Divers projets zkEVM verront le jour au cours du premier semestre 2023. En prêtant attention à ces projets, l'auteur se concentre principalement sur les aspects suivants :
Avancement actuel du projet : y compris l'étape actuelle du projet et l'heure de lancement prévue du réseau de test et du réseau principal, et si elle est cohérente avec la feuille de route de développement.
L'interaction réelle du projet : grâce à l'interaction avec le réseau de test (principal), etc., ressentez subjectivement le TPS du réseau, le temps de confirmation d'une seule transaction, etc., et ressentez intuitivement les performances du réseau.
Compatibilité zkEVM : C'est le point technique le plus central et le plus difficile à juger.Même si certains projets sont open source, la technologie au niveau des VM est la plus dure et implique plus de protocoles ZK. Plus précisément, il faut faire attention au protocole ZK, à la sécurité des VM, à la compatibilité, etc.
Architecture zkEVM Rollup : par rapport à zkEVM, les projets généraux divulgueront leur architecture Rollup dans des livres blancs et d'autres documents techniques, et la différence globale est moindre, mais il convient de prêter attention à son degré global de décentralisation.
Fonctionnement écologique : Le nombre d'utilisateurs du projet, le degré d'activité, le fonctionnement et l'incubation de l'écologie applicative sur la chaîne, et le maintien de la communauté des développeurs sont des indicateurs qui reflètent en douceur le fonctionnement du projet.
Situation des investissements et du financement.
Cet article considère le projet davantage du point de vue des quatre premiers points et accorde plus d'attention à l'architecture globale de zkEVM Rollup du niveau technique.
Faire défiler
Fondée en 2021, l'équipe Scroll s'est engagée à développer l'équivalent EVM de ZK Rollup pour la mise à l'échelle d'Ethereum Depuis près de deux ans, Scroll travaille avec l'équipe Privacy and Scaling Explorations et d'autres contributeurs open source pour créer publiquement un rollup compatible avec le bytecode .zkEVM. Fin février, Scroll a annoncé que son réseau de test Alpha était désormais en ligne sur Goerli. Tout utilisateur peut participer aux tests techniques sans autorisation. Le temps de blocage moyen du réseau de test est de 3 secondes. Il y a déjà plus de 20 millions de transactions et plus de 1,5 million de blocs et plus de 4 millions d'adresses interactives. Dans le même temps, Scroll a également ouvert l'interface de l'écosystème du site Web le 11 avril.
À en juger par la récente divulgation d'informations, Scroll progresse constamment sur la voie de l'équivalence EVM de type 2. Récemment, Scroll a terminé le développement compatible de tous les opcodes EVM, et est en cours d'audit.Parallèlement, le prochain objectif est d'être compatible avec les transactions EIP2718.
En termes d'architecture technique, l'architecture de Scroll est relativement traditionnelle, elle sera donc présentée en détail ici. Comme le montre la figure 8, il est principalement divisé en deux parties : la partie principale est zkEVM, qui est utilisée pour prouver l'exactitude de l'exécution d'EVM en L2 ; mais pour transformer zkEVM en un cumul ZK complet sur Ethereum, une L2 complète doit être construit autour de l'architecture zkEVM. Plus précisément, le testnet Scroll Alpha existant se compose de Scroll Node, Bridge Contract et Rollup Contract :
Figure 8 Architecture globale du cumul de défilement | Source
a) Sequencer, le soi-disant séquenceur, ouvre JSON-RPC aux utilisateurs et aux applications, lit les transactions dans le pool de transactions et génère des blocs L2 et des racines d'état. À ce stade, les nœuds Sequencer de Scroll sont centralisés et seront progressivement décentralisés dans les futures mises à jour.
b) Le coordinateur est responsable de la communication entre le rouleau et le nœud de défilement. Lorsqu'un nouveau bloc est généré dans le séquenceur, le rouleau du pool est sélectionné au hasard pour la génération de la preuve.
c) Le relais surveille le contrat de pont et le contrat de cumul sur les chaînes Ethereum et Scroll. Le contrat Rollup garantit la disponibilité des données L2 au niveau L1 et garantit que le bloc L2 peut être restauré au niveau L1. Une fois que le bloc soumis par la couche L2 est vérifié par le contrat Rollup sur la couche L1, le bloc atteindra la finalité au niveau de la couche L2. L'état immuable de . Le contrat de pont est responsable de la communication entre les contrats à double chaîne lors du franchissement des chaînes, de l'envoi de messages arbitraires dans les deux sens ou de la réalisation des opérations de nantissement et de retrait des actifs lors du franchissement des chaînes.
Figure 9 2. Réseau de rouleaux | Source
a) Roller convertit d'abord la trace d'action reçue du coordinateur (c'est-à-dire quelles opérations spécifiques le contrat a effectuées et quelles adresses sont impliquées) en témoins de circuit.
b) Il génère des preuves pour chaque circuit zkEVM et agrège finalement ces preuves à partir de plusieurs circuits ZK.
StarkWare
StarkWare fournit une solution de mise à l'échelle basée sur STARK pour garantir la sécurité L2, la vitesse et une expérience utilisateur transparente. Ils prennent en charge plusieurs modes de disponibilité des données. StarkNet est leur réseau L2, tandis que StarkEx est un service de vérification Rollup pour les utilisateurs d'entreprise, et les DApps peuvent être construits sur les services StarkEx. Cependant, actuellement, seuls des circuits personnalisés peuvent être écrits pour des DApp spécifiques, et non pour le cumul général de zkEVM. StarkEx prend en charge une série de services plug-and-play, y compris la frappe et le trading NFT, le trading de produits dérivés, etc. En termes d'écologie, la plateforme décentralisée de négociation de contrats à terme DYDX est un fidèle utilisateur de StarkWare.
StarkNet, à proprement parler, est zkVM Au lieu de faire des circuits ZK pour les opcodes Ethereum, il a créé un ensemble de langages d'assemblage plus compatibles avec ZK, AIR (Algebraic Intermediate Representation) et le langage de haut niveau Cairo. Bien que StarkNet lui-même ne soit pas compatible avec EVM, il peut toujours être compatible avec Ethereum via d'autres méthodes, y compris Kakarot (Kakarot est un zkEVM écrit au Caire, qui est un zkEVM dont le bytecode est équivalent à EVM). Selon ma compréhension, StarkNet est un projet relativement centralisé, dont l'un est qu'il ne peut pas être synchronisé avec la mise à niveau de sécurité d'Ethereum, il est donc nécessaire de concentrer le personnel de R&D pour pallier les lacunes en matière de sécurité et suivre le développement et adaptation du nouvel accord EPF.
StarkNet utilise STARK comme système de preuve.Par rapport à SNARK, STARK a plus d'innovations. Il n'a pas besoin de s'appuyer sur des "paramètres de confiance" comme SNARK. De plus, il a également des hypothèses cryptographiques plus simples, évite le besoin d'hypothèses de courbe elliptique, d'appariement et de connaissances exponentielles, et s'appuie uniquement sur le hachage et la théorie de l'information, il est donc plus résistant aux attaques quantiques. Dans l'ensemble, les STARK sont plus sûrs que les SNARK. En termes de capacités d'expansion, STARK a un effet marginal significatif, et plus la preuve est grande, plus le coût total est faible.
Cependant, en termes d'architecture, il n'y a actuellement qu'un seul séquenceur (séquenceur) dans le système, qui est contrôlé par StarkWare, et il n'y a qu'un seul prouveur (c'est-à-dire le prouveur qui génère ZK Proof), qui non seulement génère des preuves pour StarkNet, mais fonctionne également de manière autonome Preuve de génération pour toutes les autres applications du cumul StarkEx.
Variantes de ZK Rollup : Validiums et Volitions
Validium est également une solution de mise à l'échelle L2 qui utilise une preuve de calcul telle que ZK Rollup pour renforcer l'intégrité du processus de transaction. Contrairement à ZK Rollup, Validium ne stocke pas les données de transaction sur le réseau principal Ethereum. Sacrifier la disponibilité des données en chaîne est un compromis qui peut conduire à d'énormes améliorations de l'évolutivité, le point le plus immédiat étant que Validiums peut traiter environ 9 000 transactions par seconde.
Mais aux yeux de l'auteur, Validium ne peut pas être considéré comme un strict ZK Rollup. Cette solution est similaire à Plasma et n'assure pas la disponibilité des données au niveau de la couche L1. Elle ne peut donc pas être considérée comme un cumul. La différence avec Plasma est que Plasma a mis en place un "mécanisme de sortie de sept jours" similaire à OP Rollup dans la couche L2, tandis que Validium utilise et ZK signifie raccourcir le temps de vérification des données à la couche L2 et ne synchronise pas le données à la L1.
Volition, lancé par StarkWare, permet aux utilisateurs de basculer facilement entre ZK Rollup et Validium. Par exemple, certaines applications, telles que les échanges décentralisés de produits dérivés, peuvent être plus adaptées à Validium, tout en voulant toujours être interopérables avec les applications sur ZK Rollup, alors Volition fournit cette commutabilité.
zkSync
Semblable à StarkNet, zkSync a toujours insisté pour choisir zkVM, qui équivaut à un langage de haut niveau, et a attiré beaucoup d'attention, avec une popularité et un volume de verrouillage très élevés. zkSync 1.0 (zkSync Lite) a été lancé sur le réseau principal Ethereum le 15 juin 2020, atteignant un débit de transaction d'environ 300 TPS, mais il n'est pas compatible avec EVM. Et zkSync 2.0 (zkSync Era) sera lancé le 24 mars 2023.
L'objectif de zkSync Era est de générer des preuves plus rapidement en utilisant leur machine virtuelle personnalisée pour l'optimisation plutôt que de rechercher l'équivalence EVM. Il prend en charge Solidity, Vyper, Yul et Zinc (langage de programmation interne de rollup) via un puissant compilateur LLVM pour implémenter la plupart des fonctions de contrat intelligent. En raison de la VM auto-développée, zkSync Era prend en charge l'abstraction de compte native, de sorte que n'importe quel compte peut utiliser n'importe quel jeton pour payer.
De plus, grâce à l'application du protocole zkPorter, combiné aux rollups ZK et à la technologie de fragmentation, le débit du réseau a été augmenté de façon exponentielle, atteignant plus de 20 000 TPS (similaire à la commutation de disponibilité des données de Volitions).
Dans l'ensemble, zkSync est un projet L2 écologiquement riche qui a attiré l'attention des développeurs et des investisseurs. Bien qu'il y ait eu quelques cas récents de projets complètement échoués sur zkSync, il reste à savoir si les développeurs peuvent obtenir une bonne expérience de développement et de migration sur l'équivalent linguistique de haut niveau de zkVM. Il y a actuellement un manque de rapports d'utilisation exacts au niveau des développeurs. Si les développeurs ont une bonne expérience, à quoi servent les autres types de zkVM qui s'efforcent d'être proches de l'EVM ? Nous avons encore besoin de temps pour observer.
Polygone zkEVM
JeuxServer a lancé la version bêta du réseau principal zkEVM Rollup le 27 mars, qui est également la machine virtuelle équivalente d'Ethereum, et a ouvert tout le code zkEVM. Par rapport à zkSync, la quantité verrouillée de polygone zkEVM est beaucoup plus petite, mais il existe également de nombreux projets intéressants et dynamiques dans l'écologie.
En termes de conception de Rollup, Polygon diffère de Scroll en ce qu'il utilise un modèle de preuve d'efficacité (PoE) pour motiver le séquenceur et l'agrégateur à résoudre certains des défis de la décentralisation et des validateurs sans autorisation. Dans le modèle trieur-agrégateur en deux étapes sans autorisation, tout trieur peut soumettre une demande d'emballage de lots afin d'obtenir la redevance d'emballage, mais il doit payer la redevance Gaz de la couche L1 et déposer une certaine quantité de Token ; en même temps, les jetons d'agrégation doivent fixer leurs propres objectifs pour maximiser le profit garanti pour chaque génération de preuve. De plus, les modes Polygon et Volition (ZK Rollup et Validium) ont également des modèles de disponibilité des données profondément compatibles pour fournir aux utilisateurs différents niveaux de services.
De plus, Polygon a également investi une quantité considérable de travail dans le protocole ZK, et l'effet est également remarquable.Dans le document, ils résument leurs avantages techniques, notamment les points suivants :
Plus compatible : Polygon a toujours insisté sur l'utilisation de zkVM, qui équivaut à EVM, pour réduire le coût des développeurs qui migrent les dApps. Dans le même temps, bien que Polygon Miden adopte le protocole ZK-STARK, il prend toujours en charge l'exécution de contrats Solidity.
Vérification plus facile : la raison pour laquelle ZK Rollup est souvent critiqué est que la génération de preuves de validité nécessite un matériel spécialisé coûteux que les fournisseurs utilisent et répercutent le coût sur les utilisateurs. Polygon ZK Rollup (comme Polygon Zero) vise à simplifier les schémas de preuve afin que les appareils de niveau inférieur puissent participer, par exemple, aux tests de génération de preuve Plonky2 sur des PC grand public.
Processus de génération et de vérification de preuves plus rapides : Polygon Zero peut générer une preuve de 45 Ko en 170 millisecondes.
PARTIE 5 Écart entre la technologie théorique et les projets pratiques
Ce rapport de recherche a principalement réalisé la vulgarisation scientifique de la technologie ZK et l'introduction du mécanisme Rollup, en insistant sur l'importance de la disponibilité des données, et a fait une certaine distinction sur la question du ZK ou zkEVM Rollup. De plus, sur la base de la distinction entre zkVM et zkEVM, il trie également en détail les différences entre les trois types de zkEVM et les différents types et pistes ZK associées. Enfin, associés à plusieurs projets avantageux, ils ont revu leurs cadres techniques respectifs et l'écologie existante.
Cependant, en termes de projets spécifiques, les projets qui choisissent des langages de haut niveau équivalents occupent la position dominante sur le marché, et certains produits fortement centralisés tels que StarkWare peuvent également gagner les faveurs du marché. Même si le premier type de VM mentionné dans la recherche théorique a de fortes limites, sous les clients du marché limité, "l'universalité" semble être un fardeau, et nous ne pouvons pas distinguer quels problèmes "l'expansion efficace" a percés et réalisé l'effet au-delà de la théorie . Bien sûr, en fait, beaucoup de gens ne font pas attention aux fonctionnalités techniques, donc cela ne semble pas très Web3, mais aussi très Web3.
Le but de la technologie Rollup est d'exploiter davantage la valeur de la blockchain, mais souvent en raison du besoin urgent de devenir un "concept innovant" sur le marché, il y a un phénomène de "retour en arrière" et de retour à la centralisation. C'est le problème du marché actuel.
La valeur de la blockchain est facile à voir, qui ne voudrait pas avoir un ordinateur éternel ? Mais le problème principal est que lorsque la capacité de fonctionnement de cet ordinateur est bien inférieure à celle de n'importe quel serveur autour de nous et nécessite beaucoup d'investissement en ressources, même si la valeur d'usage est bien inférieure à notre coût d'entrée, en tant que "produit public" , c'est encore Tout le monde peut-il s'impliquer ?
Alors que nous avons déjà des produits de nombreux pays, sociétés et même individus, dans quelles circonstances sommes-nous prêts à ignorer le coût élevé d'utilisation et à poursuivre le résultat du "toujours en ligne, toujours correct" ? Je pense que c'est quelque chose auquel l'industrie de la blockchain doit réfléchir aujourd'hui. La technologie Rollup peut techniquement améliorer ce problème, mais il reste encore un grand nombre de problèmes qui doivent être résolus par le marché impétueux.