Les cinq types de ZK-EVM : aperçu des caractéristiques, avantages et inconvénients, ainsi que des exemples d'applications
TechFlow SélectionTechFlow Sélection
Les cinq types de ZK-EVM : aperçu des caractéristiques, avantages et inconvénients, ainsi que des exemples d'applications
Quels sont les cinq types de ZK-EVM ?
Dédié à des analyses Web3 approfondiesRédaction : cookies
Traduction : TechFlow
Connaissez-vous vraiment le ZK-EVM ?
Cet article examine en détail les cinq types de ZK-EVM, chacun ayant une architecture, des avantages et inconvénients uniques, ainsi que des solutions possibles.
L'article présente également plusieurs exemples concrets de projets afin d'aider les lecteurs à mieux comprendre la mise en œuvre pratique de ces différents types. Que vous soyez développeur blockchain ou simplement intéressé par cette technologie, cet article vous offrira des perspectives claires et approfondies.
Examinons ensemble les différents types de ZK-EVM, leurs forces et leurs faiblesses.
1. Type 1 : entièrement équivalent à Ethereum ;
2. Type 2 : entièrement équivalent au EVM ;
3. Type 2.5 : partiellement équivalent au EVM ;
4. Type 3 : presque équivalent au EVM ;
5. Type 4 : équivalence au niveau du langage de haut niveau.
Type 1 | Équivalent complet d’Ethereum
Architecture : identique à Ethereum, sans modification aucune de ses composants.
Type 1 | Avantages
Compatibilité parfaite :
· Capable de valider les blocs Ethereum ;
· Contribue à améliorer l'évolutivité (scalabilité) de la couche L1 d’Ethereum ;
· Adapté aux Rollups, car il peut réutiliser une grande partie de l'infrastructure existante.
Type 1 | Inconvénients
Compatibilité parfaite :
· Ethereum n’a pas été initialement conçu pour supporter les fonctionnalités ZK ;
· De nombreux composants d’Ethereum nécessitent des calculs intensifs pour générer des preuves ZK (ZKP) ;
· La génération d'une preuve pour un bloc Ethereum prend plusieurs heures.
Solutions potentielles :
· Parallélisation massive du système de preuve ;
· Utilisation de circuits intégrés spécialisés (ASIC) pour les ZK-SNARK.
Type 2 | Équivalent complet du EVM
Architecture :
· Diffère significativement d’Ethereum sur les structures de données (bloc, arbres d’état) ;
· Complètement compatible avec les applications existantes ;
· Apporte de légères modifications à Ethereum pour faciliter le développement et accélérer la génération des preuves.
Type 2 | Avantages
· Temps de génération des preuves plus rapides que le type 1 ;
· Les structures de données ne sont pas directement accessibles par le EVM ;
· Les applications tournant sur Ethereum peuvent très probablement fonctionner sur ce type ;
· Prend en charge les outils de débogage EVM existants et autres infrastructures de développement.
Type 2 | Inconvénients
Avant d’aborder les inconvénients, définissons « Keccak » :
· Algorithme de hachage utilisé par la blockchain Ethereum ;
· Sert à sécuriser les données sur Ethereum ;
· Garantit que les informations sont converties en hachages.
Le type 2 n’est pas compatible avec les applications qui utilisent des preuves Merkle pour vérifier des transactions historiques, des reçus ou des états passés. En effet, si l’algorithme de hachage change (c’est-à-dire s’il n’utilise plus Keccak), ces preuves deviennent invalides.
On peut voir Keccak comme une langue, et les preuves Merkle comme des mots formés avec cette langue. Si le ZK-EVM remplace Keccak par un autre algorithme de hachage (comme Poseidon), les preuves Merkle deviendront incompréhensibles, et les applications ne pourront plus lire ni valider leurs affirmations.
Solution potentielle aux inconvénients : Ethereum pourrait ajouter des pré-compilations extensibles dans le futur pour permettre l’accès à l’historique.
Projets de type 2
· Scroll ;
· Polygon Hermez.
Toutefois, ces projets n’ont pas encore implémenté les pré-compilations les plus complexes. Ils peuvent donc être considérés comme des types 2 incomplets.
Type 2.5 | Équivalent partiel du EVM
Architecture :
· Augmente le coût en gaz des opérations EVM spécifiques difficiles à prouver via ZK ;
· Pré-compilations ;
· Opcode Keccak ;
· Modèles d’appel de contrats ;
· Accès à la mémoire ;
· Stockage.
Type 2.5 | Avantages
· Améliore considérablement le temps de preuve dans les pires cas ;
· Plus sûr qu’une refonte profonde de la pile EVM.
Type 2.5 | Inconvénients
· Moins de compatibilité avec les outils de développement ;
· Certaines applications ne fonctionneront pas.
Type 3 | Presque équivalent au EVM
Architecture :
· Supprime certaines fonctionnalités particulièrement difficiles à implémenter en ZK, notamment certaines pré-compilations ;
· Présente de légères différences dans le traitement du code des contrats, de la mémoire ou de la pile.
Type 3 | Avantages
· Réduction du temps de vérification ;
· Rend le développement sur EVM plus facile ;
· Objectif : nécessiter le minimum de réécriture pour les applications peu compatibles.
Type 3 | Inconvénients
· Moins de compatibilité ;
· Les applications utilisant les pré-compilations supprimées devront être réécrites.
Type 3 | Projets
Actuellement, Scroll et Polygon sont considérés comme des types 3. Toutefois, les équipes ZK-EVM ne devraient pas se contenter de ce niveau : le type 3 est une étape transitoire vers le type 2.5, où des pré-compilations sont ajoutées pour améliorer la compatibilité.
Type 4 | Équivalent au niveau du langage de haut niveau
Architecture :
· Accepte du code de contrat intelligent écrit dans un langage de haut niveau (ex. Solidity, Vyper) ;
· Compile ce code vers un langage optimisé pour les ZK-SNARK.
Type 4 | Avantages
· Temps de preuve très rapide ;
· Réduction des coûts, du temps et de la charge de calcul ;
· Abaisse la barrière d'entrée pour devenir un proveur : augmente la décentralisation.
Type 4 | Inconvénients
· Dans un système de type 4, l'adresse des contrats peut différer de celle du EVM, car elle dépend du bytecode exact ;
· Cela signifie que si un ZK-EVM de type 4 ne dispose pas du bytecode, il ne pourra pas créer l'adresse ;
· Dans ce cas, le type 4 sera incompatible avec les applications basées sur des contrats contre-factuels ;
· De nombreuses infrastructures de débogage ne peuvent pas être portées, car elles fonctionnent sur le bytecode EVM.
Type 4 | Projets
· zkSync
Enfin, nous pouvons regrouper les différents types ci-dessus dans un tableau comparatif pour mieux visualiser les distinctions entre les divers ZK-EVM.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
cookies
