Une affiche du lancement de Polygon zkEVM a déclenché une grande discussion parmi les fondateurs de la chaîne publique sur l’évolutivité

Le 26 février, une affiche promotionnelle annonçant le lancement du réseau principal de Polygon zkEVM a déclenché un débat sur l’utilisation du terme d’équivalence « Ethereum », et Ye Zhang, le fondateur de Scroll, a solennellement souligné que Polygon zkEVM ne dispose pas de cette fonctionnalité. Avec le recul, Ryan Wyatt, directeur de Polygon Labs, a répondu que c’était plutôt le résultat d’une mauvaise communication entre les spécialistes du marketing et les techniciens au sein de l’équipe.

Ce n’est pas une question anodine, et l’étendue de l’efficacité sera même directement liée aux performances et à l’évolutivité L1/L2, il y a à peine deux jours, le co-créateur de Solana, Toly, a publié un article selon lequel les ZK L2 ne seront pas la meilleure solution pour résoudre le problème d’évolutivité.

Le 27 février, l’équipe technique de Polygon, protagoniste de cet événement, a également répondu activement au principe de fonctionnement de zkRollup, en expliquant où pointe l’évolutivité de zkRollup.

Le 1er mars, Solana a également annoncé un « plan d’amélioration de la mise à niveau du réseau » pour porter à nouveau la bannière du tueur d’Ethereum, mais son mécanisme de fonctionnement n’a pas été fondamentalement innové après de multiples pannes, et il s’agit plutôt d’une optimisation post-crise, qui jette également une ombre sur le remplacement d’Ethereum par un L1 haute performance.

Cet article combinera les tweets de plusieurs fondateurs de L1/L2 pour révéler les tenants et aboutissants de la grande discussion sur la performance des chaînes publiques.

Origines : le débat sur l’équivalence EVM

Le zkEVM de Polygon, à proprement parler, est un mécanisme zk VM, qui est cohérent avec le réseau principal Ethereum au niveau L2 grâce au mappage, et l’introduction de la technologie zk est la raison pour laquelle il est appelé zk VM, et dans un sens non strict, tant qu’il peut maintenir la synchronisation, il est inoffensif de l’appeler zk EVM.

Cependant, selon Ye Zhang, le fondateur de Scroll, l’équivalence EVM n’est pas exactement la même que l’équivalence Ethereum, car cette dernière doit être au moins cohérente avec le réseau principal Ethereum en termes de stockage de données.

D’un point de vue plus large, aucun des ponts inter-chaînes L2 ou Ethereum actuels ne peut prétendre être équivalent à Ethereum, et les piles plus modulaires et complexes d’Ethereum apporteront une compatibilité plus difficile.

Un exemple simple peut être donné pour comprendre intuitivement la différence entre les deux, Optimism traite de la différence entre les deux dans la planification des produits, à son avis :

Équivalence EVM : Principalement du point de vue des développeurs de dApps, leur expérience sur OVM n’est pas différente de celle du développement de dApps sur le réseau principal Ethereum, de sorte qu’OVM a une équivalence EVM ;

Équivalence Ethereum : Principalement du point de vue des développeurs de protocoles, il est nécessaire de maintenir un haut degré de cohérence avec Ethereum en termes de client, de couche de communication, de couche de consensus et de couche d’exécution.

En plus du débat sur l’équivalence EVM, il convient également de noter que la controverse sur l’évolutivité est actuellement au centre de la bataille entre la L2 basée sur Ethereum et la L1 haute performance.

Antécédent : Les doutes de Solana sur l’évolutivité de ZK

Le 24 février, deux jours avant le lancement de la bande-annonce de Polygon zkEVM, le co-créateur de Solana, Toly, a posté un message sur Twitter remettant en question la capacité des ZK L2 à résoudre le problème de la mise à l’échelle de la chaîne publique, afin de contrebalancer les doutes du public sur le mécanisme de fonctionnement de Solana.

Ses principaux points sont les suivants :

• Le téléchargement de données en temps réel vers la chaîne nécessite des capacités d’exécution séquentielle stables ;
• Le schéma de preuve ZK est valide, à condition que la somme du temps de génération de la preuve ZK + le temps de vérification soit inférieure au temps d’exécution en temps réel ;
• La solution ZK ne peut pas traiter de grandes quantités de données en temps réel, et ne peut effectuer qu’une agrégation intermittente, mais ne peut pas maintenir l’état en temps réel de l’état on-chain ;

Par conséquent, la solution ZK est plus adaptée aux scénarios ponctuels et à basse fréquence, tels que le règlement par lots, tandis que Solana est toujours nécessaire pour l’évolutivité de la chaîne publique.

Malheureusement, Solana a subi une grave panne le 25 février, et la communauté, les ingénieurs et les validateurs ont retrouvé le réseau principal après deux redémarrages, et la fuite de la maison a coïncidé avec la pluie de la nuit, et les « bienfaiteurs » ont profité de l’occasion pour remettre en question le mécanisme de Solana, l’utilisateur de Twitter DBCryptoX affirmant que « 90 à 95% des transactions sur Solana contiennent des messages de validation et un vote sur la chaîne ».

Solana utilise un mécanisme de consensus PoS, qui s’appelle lui-même un mécanisme de « preuve d’histoire ». Le PoH permet au réseau de fonctionner plus rapidement, car les nœuds n’ont pas besoin de communiquer pour valider un bloc, et le PoH permet aux validateurs d’identifier les événements à un moment donné.

D’une part, ce mécanisme apporte un haut degré d’uniformité, amenant le TPS bien au-delà du réseau principal Ethereum, mais d’autre part, il prend beaucoup d’espace de bloc sur la chaîne, et une fois que quelque chose ne va pas, il est difficile de parvenir à un consensus pour restaurer le réseau. Au moins une panne du réseau principal s’est produite par an pendant au moins 2021-2023.

L’événement de panne a contribué à une leçon négative sur l’évolutivité de Solana. Le co-créateur de Solana, Toly, estime que le prouveur sur ZK L2 ne peut pas être exécuté en temps réel, de sorte que l’exécution finale sur la chaîne des ZK L2 ne se fera pas dans l’ordre établi, de sorte que les utilisateurs peuvent soit exécuter des nœuds complets pour augmenter la charge sur le réseau, soit s’appuyer sur quelques nœuds honnêtes pour améliorer l’efficacité et devenir centralisés.

Cependant, il s’avère que le Solana L1 haute performance ne semble pas résoudre le problème de l’exécution en temps réel, après tout, un réseau effondré finira par perdre l’ordre établi, et les données récupérées de force deviendront un « consensus » artificiel plutôt que l’état spontané du réseau lui-même.

Conséquences : l’évolutivité de Polygon est critique

Polygon zkEVM a d’abord été interrogé par Solana, puis a annoncé qu’il y avait eu un incident oolong, qui était soupçonné d’être non professionnel et trompeur. Le développeur, Jordi Baylina, a donc sauté sur l’occasion et a relevé le défi du professionnalisme, en se concentrant sur l’explication que l’étalon n’est pas le facteur limitant pour les ZK L2, et que le véritable obstacle est la DA (disponibilité des données).

Le premier est le processus de fonctionnement de zkRollup, qui peut être grossièrement divisé en trois étapes, comme le montre la figure ci-dessous :

Pour maintenir le réseau synchronisé, quelle que soit l’architecture du cumul, tant que les données de L2 sont impliquées, il doit prouver la validité du lot de messages afin qu’ils puissent être confirmés lorsqu’ils sont finalement renvoyés à L1.

La génération de preuves agrégées nécessite l’utilisation du schéma de preuve zk (ZKP), qui peut être accéléré par un traitement parallèle, mais la génération de preuves par lots elle-même prend un certain temps. Il est même possible de concevoir des mécanismes dynamiques où le nombre de prouveurs de réseau peut être augmenté ou diminué en fonction des besoins du réseau.

Une fois que ZKP est en cours d’exécution, un réseau complet à l’épreuve de l’arbre est généré pour les données, ce qui permet à différents serveurs de vérifier les données et d’envoyer les résultats à la chaîne L1.

La seconde est la question du coût, dont le plus critique est le coût de preuve, le logiciel, le matériel et le temps de l’appel d’opération ZK seront inclus dans le facteur de calcul par les frais TX (transaction), et enfin reflétés dans les frais de gaz du réseau, et différents algorithmes, tels que STARK / SNARK / FLONK, etc., optimiseront considérablement le coût d’utilisation du réseau. Le point clé est que le chargement des données n’a pas besoin d’être effectué de manière séquentielle afin de faciliter la parallélisation.

Par conséquent, le Prover qui, selon Solana, ne peut pas entraver le fonctionnement des preuves ZK, et le véritable obstacle est la disponibilité des données, qui doit être résolue par ETH 2.0, DankSharding, EIP4844 et d’autres solutions.

Conclusion : Où va l’évolutivité

Le débat autour de Polygon zkEVM se poursuivra, et la clé sera de savoir dans quelle mesure le zk EVM peut résoudre le problème d’évolutivité actuel, ce qui sera le prochain test auquel les L1/L2 devront faire face avec les dApps et les utilisateurs à grande échelle.