Article original de @Calvin, analyste commercial PSE
"Dans l'ensemble, je pense qu'à court terme, le rollup optimiste a le dessus en termes de compatibilité EVM, tandis que ZKrollup devrait être meilleur dans les couches de paiement simples, les transactions et d'autres cas d'utilisation spécifiques.
Cependant, à moyen et long terme, le rollup ZK gagnera dans tous les cas d'utilisation avec l'amélioration de la technologie ZK-SNARK. "
Ce sont les mots originaux de God V dans son blog "An Incomplete Guide to Rollups".
ZK est l'idéal de l'ETH. L'application des preuves de connaissance nulle (ci-après dénommées ZK) dans l'écosystème Ethereum révèle sa capacité à résoudre le problème du triangle impossible de la blockchain (c'est-à-dire la sécurité, l'évolutivité et la centralisation) sans avoir à accéder aux détails complets des transactions, ce qui améliore l'évolutivité du système sans compromettre la sécurité.
L'introduction de ZK a encore renforcé la décentralisation du système ETH (en abaissant le seuil des nœuds) et a assuré les capacités de décentralisation et d'anti-censure du réseau, faisant en sorte que l'ETH entre dans la mer comme un dragon et soit difficile à effacer.
Avec un ZK aussi important, pourquoi tout le monde a-t-il une si mauvaise expérience en l'utilisant, et la mise en œuvre à grande échelle ne peut provoquer aucune vague ?
1. Problème actuel de cumul sans preuve de connaissance
J'attribue la raison pour laquelle la preuve actuelle sans connaissance est toujours dans une période de goulot d'étranglement à trois aspects : les problèmes de compatibilité, les problèmes d'efficacité et les problèmes de structure des données.
1.1 Le problème principal et le plus pressant : les problèmes de compatibilité
À mesure que l’EVM (Ethereum Virtual Machine) a atteint le statut de Java dans l’espace blockchain, elle est devenue la lingua franca du nouvel Internet de valeur. Avec de nombreux outils, services, bibliothèques et infrastructures, l’utilisation généralisée de l’EVM est presque devenue une tendance inévitable dans l’environnement technologique actuel.
Il y a un dicton qui circule sur Internet : « Tout ce qui peut être implémenté en Java finira par être implémenté en Java ».
Un autre concept important mais déroutant est celui de la « compatibilité EVM » et de « l'équivalent EVM ».
Comprendre l'écart entre les deux à partir de la « proximité » et de la « méthode de mise en œuvre »——
« Compatible » : un système est capable d'exécuter et de comprendre le bytecode EVM d'une manière qui prend en charge les contrats intelligents écrits en Solidity ou dans d'autres langages EVM.
« Équivalent » : l'équivalence EVM est une barre plus élevée. Un système équivalent à l'EVM est non seulement capable d'exécuter le bytecode EVM, mais correspond également exactement à l'EVM en termes de comportement et de chemin. Tous les outils et bibliothèques ciblant Ethereum devraient également fonctionner sur des systèmes équivalents EVM sans aucune modification.
Avantages et inconvénients de "l'équivalent EVM" :
Avantage:
Prise en charge complète de la chaîne d’outils et de l’infrastructure : Ethereum dispose d’un vaste écosystème de chaîne d’outils et d’infrastructure, comprenant divers outils de développement, cadres de test, bibliothèques de codes et services. Si une solution L2 est équivalente à EVM, alors tous ces outils et services peuvent s'y intégrer de manière transparente, car de leur point de vue, cette solution L2 est comme un autre réseau Ethereum.
Plus facile d'attirer et de migrer les développeurs : les développeurs sur Ethereum se sont habitués au comportement et aux caractéristiques de l'EVM. Si une solution L2 est équivalente à EVM, alors les développeurs peuvent utiliser directement le langage (tel que Solidity) et les outils qu'ils connaissent déjà pour développer sur cette solution L2 sans apprendre un nouveau modèle ou langage de programmation.
Meilleure compatibilité des contrats : de nombreux contrats Ethereum existants reposent sur un comportement spécifique de l'EVM. Si une solution L2 est équivalente à EVM, ces contrats peuvent s'exécuter sur cette solution L2 sans modifications ou avec des modifications minimes.
Futures améliorations et fonctionnalités EVM : EVM continue d'évoluer et de s'améliorer, et de nouveaux EIP (Ethereum Improvement Proposals) peuvent introduire de nouvelles fonctionnalités ou optimisations. Ces améliorations et fonctionnalités peuvent être facilement implémentées sur une solution L2 si elle est équivalente à EVM.
Désavantages:
Plus complexe techniquement : l'EVM est une machine virtuelle complexe dont le comportement et les fonctionnalités nécessitent une compréhension approfondie et une mise en œuvre précise. Atteindre l'équivalence EVM dans les solutions L2 peut nécessiter de résoudre certaines difficultés techniques, telles que la façon de simuler le comportement de l'EVM dans un environnement de consensus ou un modèle de réseau différent.
Performances et efficacité : EVM est conçu pour Ethereum, et sa conception peut ne pas être entièrement adaptée aux caractéristiques et aux besoins des solutions L2. Par exemple, l'EVM utilise des entiers de 256 bits pour le calcul, tandis que de nombreux systèmes résistants à zk fonctionnent plus naturellement sur des champs de nombres premiers. La mise en œuvre directe de l'EVM peut nécessiter l'introduction d'opérations supplémentaires telles que la vérification de la portée, ce qui peut réduire les performances et l'efficacité.
Limites en matière de flexibilité et d'innovation : insister sur l'équivalence EVM peut limiter la flexibilité et les capacités d'innovation des solutions L2 à certains égards. Par exemple, si une solution L2 souhaite introduire une nouvelle fonctionnalité ou optimisation, elle doit s'assurer que ce changement ne rompt pas son équivalence EVM.
OP a écrit un article pour explorer la compatibilité EVM et l'équivalence EVM. Au début, l'OVM utilisé par OP a ensuite été remplacé par l'équivalence EVM. C'est aussi une raison importante pour laquelle je pense que l'OP n'a pas fait d'ARB au cours de la période initiale de croissance barbare. Il y a un écart entre l'équivalent EVM et l'ARB en termes de compatibilité, mais maintenant il a été modifié et il dépasse même l'ARB en termes de compatibilité. .
De ce point de vue, nous pouvons également comprendre l’importance de la compatibilité EVM, et même l’équivalence est nécessaire pour attirer les développeurs, créant ainsi des utilisateurs et créant ainsi une écologie.
1.2 L'environnement technique du rollup ZK est en fait immature
Du point de vue de la vérifiabilité des données, la vérifiabilité des données est une caractéristique clé du système blockchain, qui garantit la transparence et l'auditabilité du système.
La structure de preuve de ZK Rollup est relativement complexe, nécessitant que toutes les données soient disponibles sur la chaîne. Cela garantit une sécurité et une intégrité renforcées, mais augmente également la complexité et le coût du stockage des données, ce qui est très différent de l'OP.
Optimistic Rollup : OP Rollup utilise une stratégie optimiste dans laquelle les transactions sont supposées valides à moins qu'elles ne soient contestées. Cette approche ne nécessite pas que toutes les données soient stockées en chaîne, mais seulement suffisamment d'informations pour permettre à quiconque de contester la validité de la transaction. Par conséquent, OP Rollup a des exigences relativement faibles en termes de vérifiabilité des données.
ZK Rollup : ZK Rollup utilise des preuves à connaissance nulle (ZK-SNARK) pour compresser les transactions et prouver leur validité. Toutes les données de transaction doivent être disponibles en chaîne afin que n'importe qui puisse générer des preuves de validité. Si l'échelle de données est trop importante et que tout est stocké sur la chaîne principale, elle peut rencontrer des goulots d'étranglement de capacité.
À mesure que la taille des données de zkSync augmente, il peut devenir impossible de stocker toutes les données sur la chaîne principale. Cela peut nécessiter l'introduction d'une vérification externe des données, modifiant ainsi la méthode de vérification secondaire existante et réduisant la dépendance vis-à-vis des données du réseau principal.
De tels changements ont soulevé de nouveaux défis : comment assurer la sécurité du système tout en réduisant la dépendance vis-à-vis des données de la chaîne principale ?
Par conséquent, la transformation de zkSync en STARK est également en partie déclenchée par cela, car STARK est plus adapté à l'utilisation de données externes vérifiables que SNARK.
Selon la description ci-dessus, la mise en œuvre du cumul ZK doit toujours s'appuyer sur ETH pour des améliorations plus adaptées à ZK, telles que l'amélioration de la couche DA et de l'EVM.
1.3 En plus du cumul ZK, il existe d'autres problèmes, tels que des problèmes d'efficacité :
Dans le domaine de la blockchain, la vitesse du Sequencer (généralement mesurée par le nombre de transactions par seconde, TPS) est un indicateur clé pour évaluer les performances du système ZK. Sequencer est responsable du tri et du traitement des transactions, et sa capacité de traitement détermine directement le débit de toute la chaîne.
Cependant, dans l’implémentation actuelle (Zksync), la puissance de traitement d’un seul séquenceur n’est que de quelques centaines de transactions par seconde, une limitation qui expose à un goulot d’étranglement important en termes de performances.
Afin d'étendre le TPS, il y a deux façons principales d'envisager : l'une consiste à continuer à améliorer la capacité d'un seul séquenceur, mais cela peut augmenter le risque de centralisation du système ; l'autre consiste à introduire plus de séquenceurs pour répartir le traitement. charge, bien que ce soit le cas. Décentralisation améliorée, mais la coordination de plusieurs séquenceurs peut augmenter la latence et réduire le TPS global. Cette question met en évidence un défi soigneusement pesé consistant à trouver le juste équilibre entre l’amélioration des performances et le maintien de la décentralisation.
L'orientation du développement de la technologie ZK, comme le démontre zkSync, tend à promouvoir le processus de séquenceur décentralisé. Un tel choix fera que les performances continueront d’être un goulot d’étranglement important dans le développement de la technologie ZK. Bien que l'utilisation de plusieurs séquenceurs et d'une conception modulaire apporte une certaine solution, en pratique, des problèmes complexes de coordination et de synchronisation peuvent être impliqués. Non seulement cela pourrait affecter le temps de réponse et le débit du système, mais cela pourrait également introduire de nouveaux défis en matière de sécurité et de fiabilité.
Les problèmes de performance restent un défi majeur à résoudre. Les recherches et développements futurs devront peut-être se concentrer sur la manière d'améliorer les performances et l'évolutivité du système ZK en optimisant les algorithmes, les stratégies de coordination et le support matériel sans sacrifier le principe de décentralisation.
2. La preuve sans connaissance est l'idéal ultime de l'ETH
Nous avons parlé des problèmes actuels de ZK et des difficultés auxquelles il est confronté, alors quelle est la raison de la mort de ZK ?
2.1
"Le protocole Ethereum a été conçu à l'origine comme une version améliorée des crypto-monnaies, offrant des fonctionnalités avancées via un langage de programmation très polyvalent... Le protocole Ethereum va bien au-delà de la monnaie."
L’avenir de l’ETH ne se limite pas à être une plateforme de transfert de valeur, son idéal ultime est de créer un nouveau monde numérique crédible, évolutif et garantissant la confidentialité.
La preuve sans connaissance est une étape clé pour aider l'ETH à progresser vers un objectif plus élevé. La preuve sans connaissance n'est pas seulement le progrès technologique de l'ETH, mais aussi l'incarnation de sa culture et de sa philosophie. Il représente une nouvelle compréhension et recherche de la confidentialité, de la sécurité et de l'évolutivité.
2.2
Les structures sociales traditionnelles s'appuient sur des institutions centralisées pour instaurer la confiance. Les preuves à connaissance nulle permettent d'établir la confiance sans connaissance mutuelle. Ce modèle de confiance décentralisé a le potentiel de bouleverser les structures sociales, financières et gouvernementales existantes, déclenchant ainsi une révolution sociale.
La structure actuelle d’Ethereum sacrifie la confidentialité au profit de la sécurité et de la commodité. L'ETH redéfinit le concept de confidentialité grâce à l'introduction d'une preuve sans connaissance. Les gens n’ont plus à choisir entre vie privée et sécurité, mais peuvent jouir des deux droits en même temps.
La mise en œuvre de ZK permettra à un processus de vérification léger pour les nœuds ETH de vérifier la validité des transactions même sans connaître toutes les données. Cela peut réduire les exigences de calcul et de stockage pour le fonctionnement des nœuds, abaissant ainsi le seuil de participation au réseau. Selon les mots originaux de V God, "Les téléphones mobiles peuvent participer à l'exécution des nœuds ETH".
En réduisant les exigences matérielles et de maintenance pour l'exécution des nœuds, les ZKP permettent à davantage de participants de rejoindre le réseau. Cela augmente la nature décentralisée du réseau, renforçant ainsi la décentralisation.
2.3
La mise en œuvre de ZK peut empêcher toute autorité centrale de suivre et d'interférer avec des transactions spécifiques en protégeant la confidentialité des transactions. De plus, la décentralisation garantit en outre qu'il n'y a pas de point de défaillance unique, ce qui rend le réseau plus difficile à attaquer ou à arrêter.
La protection de la vie privée encourage davantage de personnes à participer, qu'il s'agisse d'individus ou d'organisations, afin que cet écosystème ouvert puisse se développer librement sans les contraintes d'une autorité centrale.
En fin de compte, ZK fait de l'ETH un véritable réseau mondial grâce à l'intégration de la confidentialité et de la décentralisation, avec un potentiel et une élasticité illimités, aussi indélébile qu'un dragon entrant dans la mer.
3. La connaissance zéro s'avère une voie raisonnable pour une mise en œuvre future
La nécessité est la destination, le problème est le statu quo, alors quel est le chemin ?
** Parlons d'abord de la conclusion : il s'agit de faire le cumul ZK équivalent d'EVM, et d'attendre que l'Ethereum actuel mette à niveau l'EVM compatible ZK, et d'aller de pair pour aider à l'intégration parfaite de la technologie ZK et de l'ETH. **
3.1 Les quatre types de ZKrollup dans la bouche de Dieu V
Type 1 (équivalent Ethereum complet)
Le ZK-EVM de type 1 vise à être complètement équivalent à Ethereum sans compromis. Cela ne change rien, même si cela rend difficile la génération de preuves.
Avantages : compatibilité parfaite.
Inconvénient : Temps de fermentation long.
Qui le développe ? : Édition communautaire ZK-EVM.
Type 2 (équivalent EVM complet)
Le ZK-EVM de type 2 cherche à être totalement équivalent à l'EVM, mais avec des modifications des structures de données externes.
Avantage : Exactement équivalent au niveau de la machine virtuelle.
Inconvénient : temps de preuve amélioré mais toujours lent.
Qui le développe ? : Parchemin et Polygone Hermez.
Type 3 (presque équivalent EVM)
Le ZK-EVM de type 3 est presque équivalent à l'EVM, mais certains compromis sont faits pour améliorer encore le temps de preuve et la facilité de développement.
Avantages : Plus facile à construire, temps d’épreuve plus rapide.
Inconvénient : plus d'incompatibilités.
Qui le développe ? : Défilement et Polygone.
Type 4 (équivalent linguistique de haut niveau)
Les systèmes de type 4 fonctionnent en compilant directement à partir d'un langage de haut niveau, sans exécution via l'EVM.
Avantage : Temps de preuve très rapide.
Inconvénient : plus d'incompatibilités.
Qui le développe ? : ZKSync et le projet Warp de Nethermind. (remarque, StarkNet n'est même pas compatible EVM et est hors discussion)
Les différents types de ZK-EVM présentent un ensemble complexe de compromis entre compatibilité et efficacité.
Le type 1 vise une compatibilité complète, mais est soumis à un long temps de preuve, ce qui expose le véritable défi qu'Ethereum n'a pas pris en compte dans une conception compatible avec ZK.
Les types 2 et 3 recherchent un équilibre entre une compatibilité totale et une efficacité de preuve, montrant l'exploration et le compromis de solutions pratiques dans les conditions techniques existantes.
Le type 4 prend la recherche de l'efficacité comme objectif principal, mais au détriment de la compatibilité, ce qui rend le développement écologique un peu difficile.
3.2 Mise à niveau conjointe d'EVM et de ZK : travailler ensemble pour se rencontrer à la fin
La meilleure voie pour ETH pour mettre en œuvre ZK implique non seulement la mise en œuvre de la preuve de connaissance zéro équivalente à ZK EVM, mais plus important encore, la mise à niveau et la transformation de l'EVM lui-même.
** Transformation conviviale ZK d'EVM **
La transformation ZK-friendly de l'EVM est un processus complexe mais nécessaire. Non seulement l'EVM doit être équivalent au ZK-EVM, mais il doit également prendre en compte l'éventuel développement futur des ASIC ZK-SNARK.
** Collaboration bidirectionnelle entre ZK-EVM et EVM **
La collaboration entre ZK-EVM et EVM réside non seulement dans la compatibilité et l'efficacité au niveau technique, mais également dans l'intégration d'outils de développement et de support de pré-compilation.
Pas à pas vers un avenir de type 1
C'est la vision de nombreuses personnes de réaliser progressivement le Type 1 grâce à l'amélioration continue de ZK-EVM et d'Ethereum lui-même. Le processus peut être lent, mais il trace une voie claire vers l'avenir.
3.3 Les efforts conjoints et la collaboration au sein de l'écologie sont la lumière
Le défi de la mise en œuvre de la preuve sans connaissance (ZK) sur Ethereum n'est pas seulement un problème technique, mais une exploration pour trouver le meilleur chemin entre l'idéal et la réalité. Ce processus révèle comment introduire progressivement des solutions plus rapides et plus efficaces tout en maintenant la compatibilité avec l'infrastructure existante.
Dans ce processus d'exploration, la solution idéale consiste à créer une solution ZK totalement équivalente à l'EVM existante, puis à attendre la mise à niveau compatible ZK de l'EVM lui-même. L'essence de ce processus est que les deux parties travaillent en tandem et avancent ensemble afin de se rencontrer à un moment intermédiaire.
Cette idée d'efforts conjoints ne se reflète pas seulement dans la mise en œuvre technique, mais aussi dans la façon de guider l'ensemble de la communauté pour se développer dans une direction plus sûre et évolutive sur la base du maintien de la valeur unique d'Ethereum et de l'écologie existante. Ce processus nécessite des connaissances techniques, une planification stratégique et une compréhension approfondie de la dynamique de l'ensemble de l'écosystème.
Par conséquent, nous pouvons voir que l’arrivée de la technologie ZK sur Ethereum n’est pas seulement une innovation technologique, mais un voyage de changement auquel participe l’ensemble de l’écosystème. Ce voyage façonnera l’avenir d’Ethereum, à la recherche d’un environnement blockchain qui équilibre innovation et stabilité, vitesse et compatibilité.
4. Résumé
L'ouverture de l'ère ZK marque non seulement un nouveau chapitre dans l'écologie Ethereum, mais aussi un saut historique. Dans cette vague de tendances, Ethereum devrait non seulement surpasser le système Internet existant à certains égards, mais aussi annoncer la naissance d'une nouvelle méthode de connexion plus avancée.
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.
PSE Trading : Où est la porte de sortie pour les preuves sans connaissance ?
Article original de @Calvin, analyste commercial PSE
"Dans l'ensemble, je pense qu'à court terme, le rollup optimiste a le dessus en termes de compatibilité EVM, tandis que ZKrollup devrait être meilleur dans les couches de paiement simples, les transactions et d'autres cas d'utilisation spécifiques.
Cependant, à moyen et long terme, le rollup ZK gagnera dans tous les cas d'utilisation avec l'amélioration de la technologie ZK-SNARK. "
Ce sont les mots originaux de God V dans son blog "An Incomplete Guide to Rollups".
ZK est l'idéal de l'ETH. L'application des preuves de connaissance nulle (ci-après dénommées ZK) dans l'écosystème Ethereum révèle sa capacité à résoudre le problème du triangle impossible de la blockchain (c'est-à-dire la sécurité, l'évolutivité et la centralisation) sans avoir à accéder aux détails complets des transactions, ce qui améliore l'évolutivité du système sans compromettre la sécurité.
L'introduction de ZK a encore renforcé la décentralisation du système ETH (en abaissant le seuil des nœuds) et a assuré les capacités de décentralisation et d'anti-censure du réseau, faisant en sorte que l'ETH entre dans la mer comme un dragon et soit difficile à effacer.
Avec un ZK aussi important, pourquoi tout le monde a-t-il une si mauvaise expérience en l'utilisant, et la mise en œuvre à grande échelle ne peut provoquer aucune vague ?
1. Problème actuel de cumul sans preuve de connaissance
J'attribue la raison pour laquelle la preuve actuelle sans connaissance est toujours dans une période de goulot d'étranglement à trois aspects : les problèmes de compatibilité, les problèmes d'efficacité et les problèmes de structure des données.
1.1 Le problème principal et le plus pressant : les problèmes de compatibilité
À mesure que l’EVM (Ethereum Virtual Machine) a atteint le statut de Java dans l’espace blockchain, elle est devenue la lingua franca du nouvel Internet de valeur. Avec de nombreux outils, services, bibliothèques et infrastructures, l’utilisation généralisée de l’EVM est presque devenue une tendance inévitable dans l’environnement technologique actuel.
Il y a un dicton qui circule sur Internet : « Tout ce qui peut être implémenté en Java finira par être implémenté en Java ».
Un autre concept important mais déroutant est celui de la « compatibilité EVM » et de « l'équivalent EVM ».
Comprendre l'écart entre les deux à partir de la « proximité » et de la « méthode de mise en œuvre »——
« Compatible » : un système est capable d'exécuter et de comprendre le bytecode EVM d'une manière qui prend en charge les contrats intelligents écrits en Solidity ou dans d'autres langages EVM.
« Équivalent » : l'équivalence EVM est une barre plus élevée. Un système équivalent à l'EVM est non seulement capable d'exécuter le bytecode EVM, mais correspond également exactement à l'EVM en termes de comportement et de chemin. Tous les outils et bibliothèques ciblant Ethereum devraient également fonctionner sur des systèmes équivalents EVM sans aucune modification.
Avantages et inconvénients de "l'équivalent EVM" :
Avantage:
Prise en charge complète de la chaîne d’outils et de l’infrastructure : Ethereum dispose d’un vaste écosystème de chaîne d’outils et d’infrastructure, comprenant divers outils de développement, cadres de test, bibliothèques de codes et services. Si une solution L2 est équivalente à EVM, alors tous ces outils et services peuvent s'y intégrer de manière transparente, car de leur point de vue, cette solution L2 est comme un autre réseau Ethereum.
Désavantages:
OP a écrit un article pour explorer la compatibilité EVM et l'équivalence EVM. Au début, l'OVM utilisé par OP a ensuite été remplacé par l'équivalence EVM. C'est aussi une raison importante pour laquelle je pense que l'OP n'a pas fait d'ARB au cours de la période initiale de croissance barbare. Il y a un écart entre l'équivalent EVM et l'ARB en termes de compatibilité, mais maintenant il a été modifié et il dépasse même l'ARB en termes de compatibilité. .
De ce point de vue, nous pouvons également comprendre l’importance de la compatibilité EVM, et même l’équivalence est nécessaire pour attirer les développeurs, créant ainsi des utilisateurs et créant ainsi une écologie.
1.2 L'environnement technique du rollup ZK est en fait immature
Du point de vue de la vérifiabilité des données, la vérifiabilité des données est une caractéristique clé du système blockchain, qui garantit la transparence et l'auditabilité du système.
La structure de preuve de ZK Rollup est relativement complexe, nécessitant que toutes les données soient disponibles sur la chaîne. Cela garantit une sécurité et une intégrité renforcées, mais augmente également la complexité et le coût du stockage des données, ce qui est très différent de l'OP.
À mesure que la taille des données de zkSync augmente, il peut devenir impossible de stocker toutes les données sur la chaîne principale. Cela peut nécessiter l'introduction d'une vérification externe des données, modifiant ainsi la méthode de vérification secondaire existante et réduisant la dépendance vis-à-vis des données du réseau principal.
De tels changements ont soulevé de nouveaux défis : comment assurer la sécurité du système tout en réduisant la dépendance vis-à-vis des données de la chaîne principale ?
Par conséquent, la transformation de zkSync en STARK est également en partie déclenchée par cela, car STARK est plus adapté à l'utilisation de données externes vérifiables que SNARK.
Selon la description ci-dessus, la mise en œuvre du cumul ZK doit toujours s'appuyer sur ETH pour des améliorations plus adaptées à ZK, telles que l'amélioration de la couche DA et de l'EVM.
1.3 En plus du cumul ZK, il existe d'autres problèmes, tels que des problèmes d'efficacité :
Dans le domaine de la blockchain, la vitesse du Sequencer (généralement mesurée par le nombre de transactions par seconde, TPS) est un indicateur clé pour évaluer les performances du système ZK. Sequencer est responsable du tri et du traitement des transactions, et sa capacité de traitement détermine directement le débit de toute la chaîne.
Cependant, dans l’implémentation actuelle (Zksync), la puissance de traitement d’un seul séquenceur n’est que de quelques centaines de transactions par seconde, une limitation qui expose à un goulot d’étranglement important en termes de performances.
Afin d'étendre le TPS, il y a deux façons principales d'envisager : l'une consiste à continuer à améliorer la capacité d'un seul séquenceur, mais cela peut augmenter le risque de centralisation du système ; l'autre consiste à introduire plus de séquenceurs pour répartir le traitement. charge, bien que ce soit le cas. Décentralisation améliorée, mais la coordination de plusieurs séquenceurs peut augmenter la latence et réduire le TPS global. Cette question met en évidence un défi soigneusement pesé consistant à trouver le juste équilibre entre l’amélioration des performances et le maintien de la décentralisation.
L'orientation du développement de la technologie ZK, comme le démontre zkSync, tend à promouvoir le processus de séquenceur décentralisé. Un tel choix fera que les performances continueront d’être un goulot d’étranglement important dans le développement de la technologie ZK. Bien que l'utilisation de plusieurs séquenceurs et d'une conception modulaire apporte une certaine solution, en pratique, des problèmes complexes de coordination et de synchronisation peuvent être impliqués. Non seulement cela pourrait affecter le temps de réponse et le débit du système, mais cela pourrait également introduire de nouveaux défis en matière de sécurité et de fiabilité.
Les problèmes de performance restent un défi majeur à résoudre. Les recherches et développements futurs devront peut-être se concentrer sur la manière d'améliorer les performances et l'évolutivité du système ZK en optimisant les algorithmes, les stratégies de coordination et le support matériel sans sacrifier le principe de décentralisation.
2. La preuve sans connaissance est l'idéal ultime de l'ETH
Nous avons parlé des problèmes actuels de ZK et des difficultés auxquelles il est confronté, alors quelle est la raison de la mort de ZK ?
2.1
"Le protocole Ethereum a été conçu à l'origine comme une version améliorée des crypto-monnaies, offrant des fonctionnalités avancées via un langage de programmation très polyvalent... Le protocole Ethereum va bien au-delà de la monnaie."
L’avenir de l’ETH ne se limite pas à être une plateforme de transfert de valeur, son idéal ultime est de créer un nouveau monde numérique crédible, évolutif et garantissant la confidentialité.
La preuve sans connaissance est une étape clé pour aider l'ETH à progresser vers un objectif plus élevé. La preuve sans connaissance n'est pas seulement le progrès technologique de l'ETH, mais aussi l'incarnation de sa culture et de sa philosophie. Il représente une nouvelle compréhension et recherche de la confidentialité, de la sécurité et de l'évolutivité.
2.2
Les structures sociales traditionnelles s'appuient sur des institutions centralisées pour instaurer la confiance. Les preuves à connaissance nulle permettent d'établir la confiance sans connaissance mutuelle. Ce modèle de confiance décentralisé a le potentiel de bouleverser les structures sociales, financières et gouvernementales existantes, déclenchant ainsi une révolution sociale.
La structure actuelle d’Ethereum sacrifie la confidentialité au profit de la sécurité et de la commodité. L'ETH redéfinit le concept de confidentialité grâce à l'introduction d'une preuve sans connaissance. Les gens n’ont plus à choisir entre vie privée et sécurité, mais peuvent jouir des deux droits en même temps.
La mise en œuvre de ZK permettra à un processus de vérification léger pour les nœuds ETH de vérifier la validité des transactions même sans connaître toutes les données. Cela peut réduire les exigences de calcul et de stockage pour le fonctionnement des nœuds, abaissant ainsi le seuil de participation au réseau. Selon les mots originaux de V God, "Les téléphones mobiles peuvent participer à l'exécution des nœuds ETH".
En réduisant les exigences matérielles et de maintenance pour l'exécution des nœuds, les ZKP permettent à davantage de participants de rejoindre le réseau. Cela augmente la nature décentralisée du réseau, renforçant ainsi la décentralisation.
2.3
La mise en œuvre de ZK peut empêcher toute autorité centrale de suivre et d'interférer avec des transactions spécifiques en protégeant la confidentialité des transactions. De plus, la décentralisation garantit en outre qu'il n'y a pas de point de défaillance unique, ce qui rend le réseau plus difficile à attaquer ou à arrêter.
La protection de la vie privée encourage davantage de personnes à participer, qu'il s'agisse d'individus ou d'organisations, afin que cet écosystème ouvert puisse se développer librement sans les contraintes d'une autorité centrale.
En fin de compte, ZK fait de l'ETH un véritable réseau mondial grâce à l'intégration de la confidentialité et de la décentralisation, avec un potentiel et une élasticité illimités, aussi indélébile qu'un dragon entrant dans la mer.
3. La connaissance zéro s'avère une voie raisonnable pour une mise en œuvre future
La nécessité est la destination, le problème est le statu quo, alors quel est le chemin ?
** Parlons d'abord de la conclusion : il s'agit de faire le cumul ZK équivalent d'EVM, et d'attendre que l'Ethereum actuel mette à niveau l'EVM compatible ZK, et d'aller de pair pour aider à l'intégration parfaite de la technologie ZK et de l'ETH. **
3.1 Les quatre types de ZKrollup dans la bouche de Dieu V
Le ZK-EVM de type 1 vise à être complètement équivalent à Ethereum sans compromis. Cela ne change rien, même si cela rend difficile la génération de preuves.
Avantages : compatibilité parfaite.
Inconvénient : Temps de fermentation long.
Qui le développe ? : Édition communautaire ZK-EVM.
Le ZK-EVM de type 2 cherche à être totalement équivalent à l'EVM, mais avec des modifications des structures de données externes.
Avantage : Exactement équivalent au niveau de la machine virtuelle.
Inconvénient : temps de preuve amélioré mais toujours lent.
Qui le développe ? : Parchemin et Polygone Hermez.
Le ZK-EVM de type 3 est presque équivalent à l'EVM, mais certains compromis sont faits pour améliorer encore le temps de preuve et la facilité de développement.
Avantages : Plus facile à construire, temps d’épreuve plus rapide.
Inconvénient : plus d'incompatibilités.
Qui le développe ? : Défilement et Polygone.
Les systèmes de type 4 fonctionnent en compilant directement à partir d'un langage de haut niveau, sans exécution via l'EVM.
Avantage : Temps de preuve très rapide.
Inconvénient : plus d'incompatibilités.
Qui le développe ? : ZKSync et le projet Warp de Nethermind. (remarque, StarkNet n'est même pas compatible EVM et est hors discussion)
Les différents types de ZK-EVM présentent un ensemble complexe de compromis entre compatibilité et efficacité.
Le type 1 vise une compatibilité complète, mais est soumis à un long temps de preuve, ce qui expose le véritable défi qu'Ethereum n'a pas pris en compte dans une conception compatible avec ZK.
Les types 2 et 3 recherchent un équilibre entre une compatibilité totale et une efficacité de preuve, montrant l'exploration et le compromis de solutions pratiques dans les conditions techniques existantes.
Le type 4 prend la recherche de l'efficacité comme objectif principal, mais au détriment de la compatibilité, ce qui rend le développement écologique un peu difficile.
3.2 Mise à niveau conjointe d'EVM et de ZK : travailler ensemble pour se rencontrer à la fin
La meilleure voie pour ETH pour mettre en œuvre ZK implique non seulement la mise en œuvre de la preuve de connaissance zéro équivalente à ZK EVM, mais plus important encore, la mise à niveau et la transformation de l'EVM lui-même.
La transformation ZK-friendly de l'EVM est un processus complexe mais nécessaire. Non seulement l'EVM doit être équivalent au ZK-EVM, mais il doit également prendre en compte l'éventuel développement futur des ASIC ZK-SNARK.
La collaboration entre ZK-EVM et EVM réside non seulement dans la compatibilité et l'efficacité au niveau technique, mais également dans l'intégration d'outils de développement et de support de pré-compilation.
C'est la vision de nombreuses personnes de réaliser progressivement le Type 1 grâce à l'amélioration continue de ZK-EVM et d'Ethereum lui-même. Le processus peut être lent, mais il trace une voie claire vers l'avenir.
3.3 Les efforts conjoints et la collaboration au sein de l'écologie sont la lumière
Le défi de la mise en œuvre de la preuve sans connaissance (ZK) sur Ethereum n'est pas seulement un problème technique, mais une exploration pour trouver le meilleur chemin entre l'idéal et la réalité. Ce processus révèle comment introduire progressivement des solutions plus rapides et plus efficaces tout en maintenant la compatibilité avec l'infrastructure existante.
Dans ce processus d'exploration, la solution idéale consiste à créer une solution ZK totalement équivalente à l'EVM existante, puis à attendre la mise à niveau compatible ZK de l'EVM lui-même. L'essence de ce processus est que les deux parties travaillent en tandem et avancent ensemble afin de se rencontrer à un moment intermédiaire.
Cette idée d'efforts conjoints ne se reflète pas seulement dans la mise en œuvre technique, mais aussi dans la façon de guider l'ensemble de la communauté pour se développer dans une direction plus sûre et évolutive sur la base du maintien de la valeur unique d'Ethereum et de l'écologie existante. Ce processus nécessite des connaissances techniques, une planification stratégique et une compréhension approfondie de la dynamique de l'ensemble de l'écosystème.
Par conséquent, nous pouvons voir que l’arrivée de la technologie ZK sur Ethereum n’est pas seulement une innovation technologique, mais un voyage de changement auquel participe l’ensemble de l’écosystème. Ce voyage façonnera l’avenir d’Ethereum, à la recherche d’un environnement blockchain qui équilibre innovation et stabilité, vitesse et compatibilité.
4. Résumé
L'ouverture de l'ère ZK marque non seulement un nouveau chapitre dans l'écologie Ethereum, mais aussi un saut historique. Dans cette vague de tendances, Ethereum devrait non seulement surpasser le système Internet existant à certains égards, mais aussi annoncer la naissance d'une nouvelle méthode de connexion plus avancée.