Article original de @Calvin, analyste commercial PSE
« Dans l'ensemble, mon point de vue est qu'à court terme, le rollup Optimistic 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 devoir accéder à tous les détails des transactions, améliorant ainsi 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 de preuves sans connaissance
J'attribue la raison pour laquelle la preuve de connaissance zéro actuelle est toujours dans la période de goulot d'étranglement à trois aspects : les problèmes de compatibilité, les problèmes d'efficacité et les problèmes de structure de données.
1.1 Le problème principal et le plus urgent : les problèmes de compatibilité
Au fur et à mesure que l'EVM (Ethereum Virtual Machine) a atteint le statut de Java dans l'espace blockchain, il est devenu la lingua franca du nouvel Internet de la 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 sera éventuellement implémenté en Java".
Un autre concept important mais déroutant est la "compatibilité EVM" et "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 haute. 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 « é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înes d'outils et d'infrastructures, comprenant divers outils de développement, des cadres de test, des bibliothèques de codes et des 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, alors ces contrats peuvent s'exécuter sur cette solution L2 sans modification ou avec une modification minime.
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é.
Limitations sur la flexibilité et l'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 une 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 ARB dans la période de croissance barbare initiale. Il y a un écart entre l'équivalent EVM et ARB en compatibilité, mais maintenant il a été changé, et il surpasse même ARB en 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 être 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 sans connaissance (ZK-SNARK) pour compresser les transactions et prouver leur validité. Toutes les données de transaction doivent être disponibles en chaîne afin que chacun puisse générer des preuves de validité. Si l’échelle des données est trop grande et qu’elles sont toutes stockées sur la chaîne principale, des goulots d’étranglement de capacité peuvent se produire.
À 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 à l'égard 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 vérifiables externes 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 d'environ quelques centaines de transactions par seconde, une limitation qui expose un goulot d'étranglement important des performances.
Afin d'étendre TPS, il y a deux façons principales d'envisager : l'une consiste à continuer à améliorer les capacités d'un seul séquenceur, mais cela peut augmenter le risque de centralisation du système ; l'autre consiste à introduire davantage 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 à favoriser 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. La recherche et le développement 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 elle est confrontée, 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 une nouvelle quête 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 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 afin 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.En outre, 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 à fermer.
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 type 1 ZK-EVM vise à être complètement équivalent à Ethereum sans compromis. Cela ne change rien, même si cela rend difficile la génération des preuves.
Avantages : compatibilité parfaite.
Inconvénient : Long temps de preuve.
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 dans les 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 fermentation 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 de 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é totale, 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 de l'EVM compatible ZK est un processus complexe mais nécessaire. Non seulement l'EVM doit être équivalent au ZK-EVM, mais il doit également prendre en compte le développement futur possible 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 aussi dans l'intégration des outils de développement et le 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 d’une preuve de connaissance nulle (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 complètement équivalente à l'EVM existant, 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 manière 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 annonce également la naissance d’une nouvelle méthode de connexion plus avancée.
Lien d'origine
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 sortie des preuves sans connaissance ?
Article original de @Calvin, analyste commercial PSE
« Dans l'ensemble, mon point de vue est qu'à court terme, le rollup Optimistic 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 devoir accéder à tous les détails des transactions, améliorant ainsi 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 de preuves sans connaissance
J'attribue la raison pour laquelle la preuve de connaissance zéro actuelle est toujours dans la période de goulot d'étranglement à trois aspects : les problèmes de compatibilité, les problèmes d'efficacité et les problèmes de structure de données.
1.1 Le problème principal et le plus urgent : les problèmes de compatibilité
Au fur et à mesure que l'EVM (Ethereum Virtual Machine) a atteint le statut de Java dans l'espace blockchain, il est devenu la lingua franca du nouvel Internet de la 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 sera éventuellement implémenté en Java".
Un autre concept important mais déroutant est la "compatibilité EVM" et "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 haute. 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 « é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înes d'outils et d'infrastructures, comprenant divers outils de développement, des cadres de test, des bibliothèques de codes et des 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 ARB dans la période de croissance barbare initiale. Il y a un écart entre l'équivalent EVM et ARB en compatibilité, mais maintenant il a été changé, et il surpasse même ARB en 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 à l'égard 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 vérifiables externes 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 d'environ quelques centaines de transactions par seconde, une limitation qui expose un goulot d'étranglement important des performances.
Afin d'étendre TPS, il y a deux façons principales d'envisager : l'une consiste à continuer à améliorer les capacités d'un seul séquenceur, mais cela peut augmenter le risque de centralisation du système ; l'autre consiste à introduire davantage 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 à favoriser 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. La recherche et le développement 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 elle est confrontée, 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 une nouvelle quête 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 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 afin 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.En outre, 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 à fermer.
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 type 1 ZK-EVM vise à être complètement équivalent à Ethereum sans compromis. Cela ne change rien, même si cela rend difficile la génération des preuves.
Avantages : compatibilité parfaite.
Inconvénient : Long temps de preuve.
Qui le développe ? : Édition communautaire ZK-EVM.
Le ZK-EVM de type 2 cherche à être totalement équivalent à l'EVM, mais avec des modifications dans les 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 fermentation 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 de 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é totale, 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 de l'EVM compatible ZK est un processus complexe mais nécessaire. Non seulement l'EVM doit être équivalent au ZK-EVM, mais il doit également prendre en compte le développement futur possible 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 aussi dans l'intégration des outils de développement et le 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 d’une preuve de connaissance nulle (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 complètement équivalente à l'EVM existant, 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 manière 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 annonce également la naissance d’une nouvelle méthode de connexion plus avancée.
Lien d'origine