Expliquer en détail les cinq types de ZK-EVM : architecture, avantages et inconvénients et solutions

Auteur du texte original : s Compilation du texte original : Deep Tide TechFlow

Cet article explore en détail cinq types de ZK-EVM, chacun avec son architecture unique, ses avantages et ses inconvénients, et les solutions possibles.

En outre, l'article répertorie également quelques exemples de projets pratiques afin que les lecteurs puissent mieux comprendre les performances de ces types dans des applications pratiques. Que vous soyez un développeur blockchain ou un lecteur intéressé par la technologie blockchain, cet article vous fournira des informations détaillées et concises.

Explorons les types de ZK-EVM, leurs avantages et leurs inconvénients.

1. Type 1 : totalement équivalent à Ethereum ;

2. Type 2 : tout à fait équivalent à EVM ;

3. Type 2.5 : partiellement équivalent à EVM ;

4. Type 3 : presque équivalent à EVM ;

5. Type 4 : où le langage de haut niveau est équivalent.

Type 1 : entièrement équivalent à Ethereum

Architecture : C'est exactement la même chose qu'Ethereum et ne change aucune partie du système Ethereum.

avantage

Compatibilité parfaite :

• Capacité à vérifier les blocs Ethereum ;
• Contribuez à rendre Ethereum L1 plus évolutif ;
• Convient aux Rollups car ils peuvent réutiliser une grande partie de l'infrastructure.

lacune

Compatibilité parfaite :

• Ethereum n'a pas été conçu à l'origine pour la fonctionnalité ZK ;
• De nombreux composants d'Ethereum nécessitent beaucoup de calculs pour générer des preuves ZK (ZKP);
• Les preuves pour les blocs Ethereum prennent plusieurs heures à générer.

Solution au problème :

• Démonstrateur de parallélisation à grande échelle ;
• ASIC ZK-SNARK.

Type 2 : entièrement équivalent à EVM

Architecture:

• La structure des données (structure de blocs et arbre d'état) est significativement différente d'Ethereum ;
• Entièrement compatible avec les applications existantes ;
• Modifications mineures d'Ethereum pour un développement plus facile et une génération de preuve plus rapide.

avantage

• Fournit des temps d'épreuve plus rapides que le Type 1 ;
• La structure des données n'est pas directement accessible par l'EVM ;
• Applications fonctionnant sur Ethereum : susceptibles de fonctionner sur Type 2 ;
• Prise en charge des outils de débogage EVM existants et d'autres infrastructures de développement.

lacune

Avant de comprendre les inconvénients, comprenez d'abord ce qu'est "Keccak":

• L'algorithme de hachage de la blockchain Ethereum ;
• Utilisé pour protéger les données sur Ethereum ;
• Assurez-vous que le message est converti en hachage.

Le type 2 n'est pas compatible avec les applications qui vérifient les preuves Merkle des blocs historiques pour vérifier les informations sur les transactions historiques, les reçus/états. En effet, si l'algorithme de hachage change (et non plus Keccak), la preuve deviendra invalide.

On peut considérer Keccak comme un langage qui utilise des preuves Merkle (alphabets) Si ZK-EVM remplace Keccak par un autre algorithme de hachage (tel que Poséidon), les preuves Merkle deviendront inconnues et les applications ne pourront pas les lire et valider leurs affirmations.

Solution potentielle aux lacunes : Ethereum pourrait ajouter une future précompilation d'accès à l'historique évolutive.

projet

• Faire défiler;
• Polygone Hermez.

Cependant, ces projets n'ont pas encore mis en œuvre une précompilation plus sophistiquée, par conséquent, ils peuvent être considérés comme incomplets de type 2 .

Type 2.5 : partiellement équivalent à EVM

Architecture:

Augmenter le coût du gaz des opérations EVM spécifiques qui sont difficiles à prouver ZK ;

• Précompilé ;
• code opération Keccak ;
• Le mode d'appel du contrat ;
• Accéder à la mémoire ;
• stockage.

avantage

• Temps de preuve dans le pire des cas considérablement amélioré ;
• Plus sûr que d'apporter des modifications plus profondes à la pile EVM.

lacune

• La compatibilité des outils de développement est réduite ;
• Certaines applications ne fonctionneront pas.

Type 3 : Presque équivalent à EVM

Architecture:

• Dans l'implémentation ZK-EVM, certaines fonctions extrêmement difficiles à implémenter sont supprimées, généralement précompilées ;
• ZK-EVM a de légères différences dans la façon dont il gère le code de contrat, la mémoire ou la pile.

avantage

• raccourcir le temps de vérification ;
• Rendre EVM plus facile à développer ;
• L'objectif est d'exiger un minimum de réécritures pour les applications moins compatibles.

lacune

• Plus d'incompatibilités ;
• Les applications qui utilisent la précompilation qui ont été supprimées dans le Type 3 devront être réécrites.

projet

Actuellement, Scroll et Polygon sont considérés comme de type 3, cependant, l'équipe ZK-EVM ne devrait pas se contenter d'être de type 3, le type 3 est une étape de transition où ZK-EVM ajoute une précompilation pour améliorer la compatibilité et passe au type 2.5.

Type 4 : équivalent linguistique de haut niveau

Architecture:

• Acceptez le code de contrat intelligent écrit dans des langages de haut niveau (tels que Solidity, Vyper);
• Compilé dans un langage conçu pour être compatible avec ZK-SNARK.

avantage

• Temps de preuve très rapide ;
• Réduction des frais généraux (coût, temps et effort de calcul);
• Abaissez la barrière pour devenir un prouveur : augmentez le degré de décentralisation.

lacune

• Dans un système de type 4, l'adresse du contrat peut être différente de l'adresse dans l'EVM, car l'adresse dépend du bytecode exact ;
• Cela signifie que si les ZK-EVM de type 4 n'ont pas de bytecodes, ils ne pourront pas créer d'adresses ;
• Le type 4 sera incompatible avec les applications reposant sur des contrats contrefactuels dans les cas ci-dessus ;
• De nombreuses infrastructures de débogage ne sont pas portables car elles s'exécutent sur le bytecode EVM.

projet

• zkSync

Enfin, nous pouvons comparer les types ci-dessus pour aider tout le monde à comprendre les différents zkEVM en un coup d'œil.