*Note de l'éditeur : l'auteur l'a compilé sur la base de l'article d'introduction au ZK-EVM précédemment rédigé par Vitalik et a présenté en détail les différents types de ZK-EVM et leurs différences. *
Il y a environ un an, un groupe de ZK-EVM a annoncé qu'il était sur le point de lancer un testnet. Ces mouvements ont piqué la curiosité de la communauté Ethereum et suscité des discussions sur les nuances derrière des termes tels que l'équivalence Ethereum et l'équivalence EVM.
Par souci de clarté, Vitalik a écrit un article important intitulé « Différents types de ZK-EVM » qui classe les différents ZK-EVM en quatre types et explique leurs différences.
L'idée principale est la suivante : le type 1 (par exemple, Taiko) est entièrement équivalent à Ethereum, tandis que le type 4 (par exemple, zkSync) excelle dans la génération efficace de preuves. Tous les autres types, Type 2, Type 2.5 et Type 3, se situent entre les deux (par exemple Polygon zkEVM, Scroll, Linea).
La plupart des ZK-EVM sont initialement de type 2.5 et de type 3, avec une certaine intention d'évoluer vers le type 1 ou le type 2, bien que ces projets n'aient pas fourni de calendrier ou d'engagement spécifique à cet effet.
**Cet article se concentre sur les différences entre le type 1 et le type 2/type 2.5 et décrit les conséquences possibles de la rupture de l'équivalence Ethereum. Nous aborderons également brièvement d’autres types. **
L’objectif principal de ZK-EVM est de faire évoluer Ethereum, c’est-à-dire d’augmenter le débit d’Ethereum tout en conservant ses autres fonctionnalités (sécurité, expérience développeur, etc.). Idéalement, ZK-EVM devrait être capable de :
Démontre l'exécution d'un bytecode natif non modifié (couvrant 100 % des opcodes Ethereum) selon la spécification Ethereum Virtual Machine dans le Livre jaune.
Générez rapidement des preuves à faible coût.
Permet la réutilisation à 100 % des outils et infrastructures développés pour Ethereum.
Autoriser le redéploiement de n'importe quelle dApp Ethereum sur ZK-EVM « tel quel » (« tel quel » signifie aucune modification requise, aucun compromis).
Différences entre les types ZK-EVM
Dans le monde ZK-EVM, les différences proviennent principalement du niveau d'équivalence Ethereum/EVM, de l'impact des éléments hostiles à ZK sur le coût et la rapidité de génération de la preuve, et de la complexité de la mise en œuvre du circuit (telle que la construction ou l'état de la VM). des arbres).
Analysons ces différences, en distinguant spécifiquement le type 1 du type 2/type 2.5. Nous aborderons également les cas d'utilisation les plus pertinents pour chaque type.
Lorsque l’on compare différents types, le tableau suivant est souvent utilisé :
Pour ceux qui ne travaillent pas à temps plein dans le domaine ZK-EVM, ce tableau peut sembler déroutant, alors traduisons ces termes en termes simples et jetons un coup d'œil :
Ce diagramme donne une image plus claire de ce à quoi ressemble réellement chaque type, mais il peut encore être un peu obscur. Explorons pleinement le monde ZK-EVM en expliquant chaque type individuellement.
Type 1 : équivalent à Ethereum
Vitalik Buterin：
"Le type 1 ZK-EVM est ce dont nous avons finalement besoin pour rendre la couche 1 d'Ethereum elle-même plus évolutive."
Le type 1 signifie ne modifier aucune partie du système Ethereum pour faciliter la génération de preuves. Aucun changement apporté à Ethereum ne signifie aucun compromis sur la sécurité, car la plupart des primitives cryptographiques (par exemple les fonctions de hachage), l'infrastructure de développement (par exemple les débogueurs) ou l'infrastructure de chaîne (par exemple les clients d'exécution) sont déjà testées sur le terrain depuis 9 ans.
Le ZK-EVM de type 1 ne remplace rien : hachages, arbres d'état, arbres de transactions, précompilation ou toute autre logique de consensus, tout est exactement pareil que l'EVM du réseau principal.
Le type 1 est le seul qui peut vérifier la chaîne Ethereum elle-même - des blocs entiers à l'exécution des transactions, en passant par les contrats intelligents et la logique du compte.
Type 2 : équivalent à EVM
Le type 2 accélère la génération de preuves et facilite le développement de circuits en supprimant certaines parties qui ne sont pas propices au ZK. Cependant, en raison des conséquences de cela, cela peut rendre le développement d'autres parties du ZK-rollup (telles que le logiciel de nœud) plus complexe. Ces complexités peuvent être causées par des incompatibilités entre les meilleures pratiques et outils de test établis et les changements mis en œuvre (comme une arborescence d'état modifiée).
*Remarque : l’équivalent à Ethereum et l’équivalent à EVM ne sont pas identiques. Alors que l'équivalence avec Ethereum signifie qu'aucune partie d'Ethereum n'a été modifiée, ce qui signifie qu'il est entièrement compatible avec toutes les dApps Ethereum, l'équivalence avec EVM permet de modifier les structures de données (telles que les structures de blocs ou les arbres d'état). *
Bien que ces ajustements puissent sembler mineurs, ils ont un impact sur la compatibilité d’Ethereum. La modification des structures de données peut rendre les dApps Ethereum incompatibles avec le type 2 ZK-EVM, en particulier lors de la validation des preuves Merkle concernant les transactions, les reçus ou les états passés (par exemple sur des ponts de chaîne).
Supprimer les éléments hostiles à ZK
Les modifications apportées à Ethereum visent à simplifier le développement et à augmenter la vitesse de génération de preuves. L’objectif est d’élaguer les parties d’Ethereum qui reposent sur une cryptographie hostile à connaissance nulle. En termes plus techniques, les parties qui nécessitent un grand nombre de portes (opérations d'addition et de multiplication) en raison de domaines non locaux (comme les fonctions de hachage), un grand nombre de multiplications multi-scalaires et/ou des transformées de Fourier rapides (FFT) ; ou Juste la partie qui nécessite beaucoup de manipulations.
Exemples spécifiques d'éléments à connaissance nulle hostiles que le ZK-EVM de type 2 peut modifier :
Fonction de hachage : alors qu'Ethereum utilise la fonction de hachage Keccak, de nombreux ZK-EVM utilisent la fonction de hachage Poséidon, qui nécessite un nombre de portes nettement inférieur. Par exemple, estimons combien de fonctions de hachage de chaque type peuvent être calculées par seconde (c'est-à-dire une comparaison qui démontre la vitesse de génération).
Les fonctions de hachage Poséidon présentent des avantages significatifs en termes de vitesse dans la génération de preuves.
Cependant, il est important de noter que les primitives cryptographiques les plus récentes ne sont pas aussi populaires que les primitives cryptographiques établies qui sont largement reconnues par la communauté. Bien que Poséidon puisse offrir de la vitesse, les caractéristiques éprouvées du Keccak le rendent plus robuste et plus sûr car il est largement adopté.
C'est pourquoi Keccak, bien qu'il soit plus ancien et adopté par une communauté plus large (dans d'autres secteurs, comme les systèmes de sécurité ou les capteurs dans les appareils intelligents), peut être considéré comme plus éprouvé que Poséidon, qui fait après tout partie de la communauté ZK. Nouveau hachage fonctions à créer et à utiliser.
Arbres d'état pour le stockage des données : par exemple, alors qu'Ethereum utilise des arbres Merkle Patricia (en utilisant le hachage Keccak), certains ZK-EVM de type 2 choisissent des arbres Merkle clairsemés (en utilisant le hachage Poséidon). Changer l'arborescence des états peut entraîner des incompatibilités. Par exemple, l'arbre Merkle d'Ethereum a différents types de nœuds et utilise RLP pour coder les données, ce qui est une chose difficile à faire dans ZK.
Structure des blocs : les blocs contiennent une grande quantité d'informations. Cependant, lors de l'exploration de L2, nous ne nous soucions que du ution_payload_header (c'est-à-dire le hachage du bloc). Dans l'image ci-dessous, vous trouverez la structure (hachage de bloc) de toutes les données contenues dans ution_payload_header.
**Veuillez noter : la modification de l'un de ces composants annulera l'équivalence Ethereum. **
Type 2.5 : Équivalent à l'EVM, compte tenu du coût du gaz
Le type 2.5 ZK-EVM augmente le coût du gaz pour des opérations spécifiques difficiles à prouver en utilisant la technologie ZK dans EVM.
Compte tenu de la limite de gaz par bloc d'Ethereum (30 M de gaz), l'augmentation du coût du gaz par opcode entraîne moins d'opcodes par bloc. Par conséquent, des opcodes moins complexes peuvent être inclus dans un bloc. Des opcodes plus simples permettent aux circuits d'être plus petits et aux preuves d'être générées plus rapidement.
le gaz est une unité de mesure du travail.
Les prix des opcodes sont calculés en gaz.
Les opcodes spécifient les opérations dans les instructions en langage machine.
Un programme est une liste statique d'opcodes. L'exécution d'un programme est une trace d'exécution.
Une trace d'exécution est une liste ordonnée spécifique d'opcodes exécutés par un programme.
Les pièces difficiles à prouver ZK incluent :
Opcodes Keccak et quelques autres opcodes qui dépendent de Keccak.
Précompilé : fonctions accessibles à l'EVM. Certains d'entre eux fournissent des tâches complexes ou mathématiquement complexes, comme des fonctions cryptographiques (comme Blake 2 f ou Sha 256). Ils ne s'exécutent pas au sein de l'EVM, mais plutôt en tant que fonctions codées en dur dans le client d'exécution et exposées à l'EVM à l'aide d'APPELS à des adresses spéciales.
Accès à la mémoire : par exemple, augmentation de la taille de l'emplacement mémoire (par exemple, Ethereum utilise une mémoire alignée en octets, tandis que Polygon zkEVM utilise des emplacements mémoire de 32 octets). Pour rendre ce changement possible, la logique interne de certains opcodes (tels que MLOAD) a dû être modifiée.
Stockage (c'est-à-dire modification de la fonction de hachage ou de l'arborescence d'état comme décrit ci-dessus).
La modification des coûts du gaz peut réduire la compatibilité des outils de développement et interrompre certaines dApps. Par exemple, un contrat intelligent qui exécute fréquemment des opcodes avec des coûts de gaz croissants peut dépasser la limite de bloc de gaz et ne pas s'exécuter.
Type 3 : Presque équivalent à EVM
Le ZK-EVM de type 3 omet la précompilation non applicable à ZK et peut ajuster l'accès à la mémoire et au stockage.
Les dApps qui reposaient sur des applications précompilées supprimées devront être réécrites. Dans des cas inhabituels, les différences dans la façon dont les cas extrêmes sont gérés par le ZK-EVM de type 3 et l'EVM d'origine peuvent nécessiter des ajustements au dApp.
Type 4 (équivalent au langage de haut niveau)
Le type 4 est déjà loin de l’EVM.
Le code source du contrat intelligent écrit dans un langage de haut niveau (par exemple Solidity, Zinc) est compilé dans une représentation intermédiaire, générant des opcodes adaptés aux machines virtuelles compatibles ZK.
Cette méthode évite de générer des preuves ZK pour chaque étape d'exécution EVM, réduisant ainsi considérablement le travail de preuve.
Même si le contrat peut être compilé, des travaux supplémentaires sont nécessaires si la dApp utilise le bytecode écrit à la main EVM.
*Le type 4 ZK-EVM nécessite également ses propres outils de développement (niveau opcode uniquement) tels que des débogueurs et des traceurs.
Dans le circuit ZK qui prouve la trajectoire d'exécution, chaque étape implémente la contrainte et le coût de chaque étape est la somme de tous les opcodes. Par conséquent, le ZK-EVM de type 4 est conçu pour utiliser le moins d'opcodes complexes possible afin d'optimiser l'efficacité.
Il est à noter que les opcodes personnalisés (opcodes non couverts dans Ethereum) permettent de transmettre de nouvelles fonctionnalités qui ne sont pas possibles sur Ethereum par défaut. Par exemple, effectuez plusieurs appels pour exécution via la fonction d'abstraction de compte, ou lancez un portefeuille de contrat intelligent à l'aide d'une solution prête à l'emploi comme Argent.
Résumer
Différents types de ZK-EVM donnent la priorité à différents objectifs et caractéristiques. Le type 1 se concentre sur l’équivalence Ethereum, tandis que le type 4 donne la priorité à la génération efficace de preuves. D'autres types se situent entre ces extrêmes, et de nombreux protocoles ZK-EVM de types 2 et 3 ont annoncé leur intention de passer à leurs équivalents Ethereum.
Ces quatre types de classification peuvent ne pas constituer l’état final du cumul ZK et pourraient faire l’objet de modifications ultérieures. Par exemple, certains ZK-EVM peuvent devenir hybrides, les types 1/2 peuvent développer des solutions de type 4 (avec la plus grande efficacité possible) et fournir aux dApps les deux options, tandis que les ZK-EVM de types 3 et 4 peuvent ajouter une option équivalente à Ethereum.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Du Type1 au Type4, quelles sont les différences entre les différents types de ZK-EVM ?
Auteur original| Lisa Akselrod
Compilé | Odaily Planet Daily 0xAyA
*Note de l'éditeur : l'auteur l'a compilé sur la base de l'article d'introduction au ZK-EVM précédemment rédigé par Vitalik et a présenté en détail les différents types de ZK-EVM et leurs différences. *
Il y a environ un an, un groupe de ZK-EVM a annoncé qu'il était sur le point de lancer un testnet. Ces mouvements ont piqué la curiosité de la communauté Ethereum et suscité des discussions sur les nuances derrière des termes tels que l'équivalence Ethereum et l'équivalence EVM.
Par souci de clarté, Vitalik a écrit un article important intitulé « Différents types de ZK-EVM » qui classe les différents ZK-EVM en quatre types et explique leurs différences.
L'idée principale est la suivante : le type 1 (par exemple, Taiko) est entièrement équivalent à Ethereum, tandis que le type 4 (par exemple, zkSync) excelle dans la génération efficace de preuves. Tous les autres types, Type 2, Type 2.5 et Type 3, se situent entre les deux (par exemple Polygon zkEVM, Scroll, Linea).
La plupart des ZK-EVM sont initialement de type 2.5 et de type 3, avec une certaine intention d'évoluer vers le type 1 ou le type 2, bien que ces projets n'aient pas fourni de calendrier ou d'engagement spécifique à cet effet.
**Cet article se concentre sur les différences entre le type 1 et le type 2/type 2.5 et décrit les conséquences possibles de la rupture de l'équivalence Ethereum. Nous aborderons également brièvement d’autres types. **
L’objectif principal de ZK-EVM est de faire évoluer Ethereum, c’est-à-dire d’augmenter le débit d’Ethereum tout en conservant ses autres fonctionnalités (sécurité, expérience développeur, etc.). Idéalement, ZK-EVM devrait être capable de :
Différences entre les types ZK-EVM
Dans le monde ZK-EVM, les différences proviennent principalement du niveau d'équivalence Ethereum/EVM, de l'impact des éléments hostiles à ZK sur le coût et la rapidité de génération de la preuve, et de la complexité de la mise en œuvre du circuit (telle que la construction ou l'état de la VM). des arbres).
Analysons ces différences, en distinguant spécifiquement le type 1 du type 2/type 2.5. Nous aborderons également les cas d'utilisation les plus pertinents pour chaque type.
Lorsque l’on compare différents types, le tableau suivant est souvent utilisé :
Pour ceux qui ne travaillent pas à temps plein dans le domaine ZK-EVM, ce tableau peut sembler déroutant, alors traduisons ces termes en termes simples et jetons un coup d'œil :
Ce diagramme donne une image plus claire de ce à quoi ressemble réellement chaque type, mais il peut encore être un peu obscur. Explorons pleinement le monde ZK-EVM en expliquant chaque type individuellement.
Type 1 : équivalent à Ethereum
Vitalik Buterin：
Le type 1 signifie ne modifier aucune partie du système Ethereum pour faciliter la génération de preuves. Aucun changement apporté à Ethereum ne signifie aucun compromis sur la sécurité, car la plupart des primitives cryptographiques (par exemple les fonctions de hachage), l'infrastructure de développement (par exemple les débogueurs) ou l'infrastructure de chaîne (par exemple les clients d'exécution) sont déjà testées sur le terrain depuis 9 ans.
Le ZK-EVM de type 1 ne remplace rien : hachages, arbres d'état, arbres de transactions, précompilation ou toute autre logique de consensus, tout est exactement pareil que l'EVM du réseau principal.
Type 2 : équivalent à EVM
Le type 2 accélère la génération de preuves et facilite le développement de circuits en supprimant certaines parties qui ne sont pas propices au ZK. Cependant, en raison des conséquences de cela, cela peut rendre le développement d'autres parties du ZK-rollup (telles que le logiciel de nœud) plus complexe. Ces complexités peuvent être causées par des incompatibilités entre les meilleures pratiques et outils de test établis et les changements mis en œuvre (comme une arborescence d'état modifiée).
*Remarque : l’équivalent à Ethereum et l’équivalent à EVM ne sont pas identiques. Alors que l'équivalence avec Ethereum signifie qu'aucune partie d'Ethereum n'a été modifiée, ce qui signifie qu'il est entièrement compatible avec toutes les dApps Ethereum, l'équivalence avec EVM permet de modifier les structures de données (telles que les structures de blocs ou les arbres d'état). *
Bien que ces ajustements puissent sembler mineurs, ils ont un impact sur la compatibilité d’Ethereum. La modification des structures de données peut rendre les dApps Ethereum incompatibles avec le type 2 ZK-EVM, en particulier lors de la validation des preuves Merkle concernant les transactions, les reçus ou les états passés (par exemple sur des ponts de chaîne).
Supprimer les éléments hostiles à ZK
Les modifications apportées à Ethereum visent à simplifier le développement et à augmenter la vitesse de génération de preuves. L’objectif est d’élaguer les parties d’Ethereum qui reposent sur une cryptographie hostile à connaissance nulle. En termes plus techniques, les parties qui nécessitent un grand nombre de portes (opérations d'addition et de multiplication) en raison de domaines non locaux (comme les fonctions de hachage), un grand nombre de multiplications multi-scalaires et/ou des transformées de Fourier rapides (FFT) ; ou Juste la partie qui nécessite beaucoup de manipulations.
Exemples spécifiques d'éléments à connaissance nulle hostiles que le ZK-EVM de type 2 peut modifier :
Les fonctions de hachage Poséidon présentent des avantages significatifs en termes de vitesse dans la génération de preuves.
Cependant, il est important de noter que les primitives cryptographiques les plus récentes ne sont pas aussi populaires que les primitives cryptographiques établies qui sont largement reconnues par la communauté. Bien que Poséidon puisse offrir de la vitesse, les caractéristiques éprouvées du Keccak le rendent plus robuste et plus sûr car il est largement adopté.
C'est pourquoi Keccak, bien qu'il soit plus ancien et adopté par une communauté plus large (dans d'autres secteurs, comme les systèmes de sécurité ou les capteurs dans les appareils intelligents), peut être considéré comme plus éprouvé que Poséidon, qui fait après tout partie de la communauté ZK. Nouveau hachage fonctions à créer et à utiliser.
**Veuillez noter : la modification de l'un de ces composants annulera l'équivalence Ethereum. **
Type 2.5 : Équivalent à l'EVM, compte tenu du coût du gaz
Le type 2.5 ZK-EVM augmente le coût du gaz pour des opérations spécifiques difficiles à prouver en utilisant la technologie ZK dans EVM.
Compte tenu de la limite de gaz par bloc d'Ethereum (30 M de gaz), l'augmentation du coût du gaz par opcode entraîne moins d'opcodes par bloc. Par conséquent, des opcodes moins complexes peuvent être inclus dans un bloc. Des opcodes plus simples permettent aux circuits d'être plus petits et aux preuves d'être générées plus rapidement.
Les pièces difficiles à prouver ZK incluent :
La modification des coûts du gaz peut réduire la compatibilité des outils de développement et interrompre certaines dApps. Par exemple, un contrat intelligent qui exécute fréquemment des opcodes avec des coûts de gaz croissants peut dépasser la limite de bloc de gaz et ne pas s'exécuter.
Type 3 : Presque équivalent à EVM
Le ZK-EVM de type 3 omet la précompilation non applicable à ZK et peut ajuster l'accès à la mémoire et au stockage.
Les dApps qui reposaient sur des applications précompilées supprimées devront être réécrites. Dans des cas inhabituels, les différences dans la façon dont les cas extrêmes sont gérés par le ZK-EVM de type 3 et l'EVM d'origine peuvent nécessiter des ajustements au dApp.
Type 4 (équivalent au langage de haut niveau)
Le type 4 est déjà loin de l’EVM.
Le code source du contrat intelligent écrit dans un langage de haut niveau (par exemple Solidity, Zinc) est compilé dans une représentation intermédiaire, générant des opcodes adaptés aux machines virtuelles compatibles ZK.
Dans le circuit ZK qui prouve la trajectoire d'exécution, chaque étape implémente la contrainte et le coût de chaque étape est la somme de tous les opcodes. Par conséquent, le ZK-EVM de type 4 est conçu pour utiliser le moins d'opcodes complexes possible afin d'optimiser l'efficacité.
Il est à noter que les opcodes personnalisés (opcodes non couverts dans Ethereum) permettent de transmettre de nouvelles fonctionnalités qui ne sont pas possibles sur Ethereum par défaut. Par exemple, effectuez plusieurs appels pour exécution via la fonction d'abstraction de compte, ou lancez un portefeuille de contrat intelligent à l'aide d'une solution prête à l'emploi comme Argent.
Résumer
Différents types de ZK-EVM donnent la priorité à différents objectifs et caractéristiques. Le type 1 se concentre sur l’équivalence Ethereum, tandis que le type 4 donne la priorité à la génération efficace de preuves. D'autres types se situent entre ces extrêmes, et de nombreux protocoles ZK-EVM de types 2 et 3 ont annoncé leur intention de passer à leurs équivalents Ethereum.
Ces quatre types de classification peuvent ne pas constituer l’état final du cumul ZK et pourraient faire l’objet de modifications ultérieures. Par exemple, certains ZK-EVM peuvent devenir hybrides, les types 1/2 peuvent développer des solutions de type 4 (avec la plus grande efficacité possible) et fournir aux dApps les deux options, tandis que les ZK-EVM de types 3 et 4 peuvent ajouter une option équivalente à Ethereum.