Explication détaillée de l'architecture zkSync et de ses similitudes et différences avec OP-Stack

Auteur : xpara, Four Pillars ; traduction : Jinse Finance xiaozou

Points clés:

Matterlabs, la société de développement de zkSync, a travaillé au développement de son zkEVM unique et à la création d'excellents produits.

Actuellement, l'ère zkSync affiche une croissance, comme en témoignent ses métriques impressionnantes et ses déploiements de développement à travers les projets.

Nous pouvons comprendre l'architecture zkSync à travers trois couches clés de zkSync : couche d'exécution, couche de règlement et couche de disponibilité des données.

ZK-Stack (la base de code sous-jacente de zkSync) et OP-Stack peuvent avoir des philosophies similaires. Pourtant, il existe des différences claires qui peuvent être observées du point de vue des développeurs dapp, des développeurs principaux et des opérateurs commerciaux.

1**, l'histoire du développement de zkSync******

1.1 Bref historique de zkSync

Le développement de zkSync a commencé dans EthCC en 2019. À cette époque, il s'agissait encore d'une petite équipe dédiée au développement et au déploiement conjoints de Rollup avec zkSNARK. Ils ont lancé une preuve de concept en janvier 2019 en utilisant zkSNARK pour exploiter une chaîne latérale dans Ethereum. Depuis lors, ils ont fait de la décentralisation un principe fondamental. Ils se sont concentrés sur le stockage de toutes les données de transaction dans Ethereum et ont élaboré un modèle multi-opérateurs pour gérer le modèle de décentralisation du trieur.

En juin 2020, l'équipe a fait des progrès significatifs avec le lancement du réseau principal zkSync v1. zkSync v1 est une étape clé dans le développement de zkSync, représentant la mise en œuvre effective de son concept original à plus grande échelle. Un an plus tard, en juin 2021, ils ont fait une nouvelle percée et ont publié le testnet zkSync 2.0, également connu sous le nom d'Era.

En mars 2023, le réseau principal complet de zkSync a été publié avec succès, marquant une réalisation majeure pour l'équipe. Cette évolution montre que la plateforme a atteint un haut niveau de maturité et est prête pour une adoption plus large. Il s'agit de la sortie du premier réseau principal zkEVM déployé dans l'écosystème Ethereum Rollup.

Actuellement, l'équipe travaille à rendre zkSync open source. Cela permettra un déploiement séparé des chaînes de cumul zk à partir d'un ZK-Stack, permettant aux équipes de lancer leurs propres cumuls personnalisés. De plus amples détails sur ce développement passionnant devraient être annoncés prochainement.

*** **** *' *** **

Matterlabs, l'équipe de développement derrière zkSync, a levé des fonds importants pour faire avancer sa mission. Avec leur dernier cycle de série C en novembre 2022, leur financement total s'est élevé à 458 millions de dollars, qui comprenait plusieurs cycles et des fonds dédiés à l'écosystème, y compris par exemple un fonds dédié à l'écosystème distinct de 200 millions de dollars, une série C de 200 millions de dollars, une série B de 50 millions de dollars. dirigé par a16z, et une série A de 8 millions de dollars et un tour de table.

· Cycle d'amorçage : lors du cycle d'amorçage, Matterlabs a reçu un financement de 2 millions de dollars de PlaceholderVC, Hashed et d'autres investisseurs. Ce premier stimulus financier a fourni la base nécessaire à leur travail pour démarrer le projet zkSync.

Série A : Suite à son tour de table, Matterlabs a levé 6 millions de dollars supplémentaires en financement de série A. Ce nouvel afflux de capitaux donne l'impulsion nécessaire pour faire progresser leur R&D et rapprocher zkSync de son objectif ultime.

Série B : Matterlabs prend de l'ampleur en réussissant à lever 50 millions de dollars lors d'un tour de série B mené principalement par a16z.

· Série C : la ronde de financement C de Matterlabs s'élève à 200 millions de dollars.

Enfin, en plus des cycles d'investissement ci-dessus, Matterlabs a lancé un fonds dédié à l'écosystème de 200 millions de dollars. Ce fonds est dédié à favoriser la croissance et le développement de l'écosystème zkSync plus large.

Toutes ces ressources fournissent à Matterlabs le soutien financier nécessaire pour faire avancer la mission de zkSync, accélérer le rythme de développement et favoriser la croissance de l'écosystème au sens large. Dans l'ensemble, Matterlabs dispose d'un financement important dans d'importants projets de blockchain.

2**、Statut actuel de l'écosystème zkSync**

2.1 État général

Au fil des ans, zkSync a fait des progrès de développement significatifs. zkSync v1, désormais zkSync Lite, a franchi une étape de développement en décembre 2020, dépassant 1 million de dollars en valeur totale verrouillée (TVL). Depuis lors, la TVL de l'écosystème zkSync a connu une croissance exponentielle. À ce jour, la TVL de zkSync a dépassé 650 millions de dollars, ce qui en fait le troisième plus grand cumul L2 de l'écosystème Ethereum.

En juin de cette année, zkSync disposait d'indicateurs clés impressionnants. Bien que zkSync ait été légèrement inférieur à Arbitrum en juin, il s'est classé premier dans TPS. Il a le taux de croissance TVL le plus rapide et est en tête du total des paiements de frais au niveau 1.

De plus, le nombre de portefeuilles uniques augmente également, ce qui indique une adoption croissante des utilisateurs. Dans le même temps, la quantité d'ETH reliée à zkSync augmente également.

2.2 Éléments principaux

2.2.1 Argent

Argent est un portefeuille mobile non dépositaire pour les crypto-monnaies basées sur Ethereum, offrant une expérience sécurisée et conviviale pour la gestion des actifs numériques.

Argent a une conception de mode de sécurité unique, même si le téléphone portable de l'utilisateur est perdu ou volé, il peut également protéger les actifs de l'utilisateur. Le modèle de sécurité comprend des fonctionnalités telles que l'authentification biométrique, la récupération sociale et les portefeuilles de contrats intelligents en chaîne. V God, le fondateur d'Ethereum, a également déclaré qu'Argent est un portefeuille doté de fonctions de sécurité multi-signatures et de récupération sociale.

2.2.2 Échange de synchronisation

SyncSwap est le plus grand protocole DeFi de l'ère zkSync. Il s'agit d'un DEX basé sur AMM qui fournit diverses fonctionnalités importantes dans la conception AMM. Il fournit un pool AMM pour divers jetons, les propriétés importantes sont les suivantes.

Stableswap : Le multi-pool permet à SyncSwap d'agréger plusieurs modèles de pool différents, chacun avec son propre scénario optimal, ce qui rend les transactions efficaces. Le premier modèle de pool à être mis en œuvre sera le Stable Pool.Comparé au Classic Pool à usage général, le Stable Pool prend en charge des transactions stables efficaces, permettant à SyncSwap d'entrer sur le marché à grande échelle des stablecoins.

· Smart Router : Il sert de plate-forme d'agrégation de liquidités qui regroupe différents pools de liquidités et divers modèles de pools pour fournir le meilleur prix sans effort. Fournit plusieurs sauts et un fractionnement de chemin.

Frais dynamiques : SyncSwap a introduit des frais dynamiques sur son DEX, permettant aux utilisateurs de personnaliser les frais de transaction en fonction des conditions du marché et des préférences de la communauté. Y compris les frais variables, les frais ciblés, les remises de frais et la délégation de frais. Ces fonctionnalités offrent aux utilisateurs la flexibilité et l'adaptabilité nécessaires pour optimiser leurs stratégies de trading et rester en phase avec les marchés et les communautés en constante évolution.

2.2.3 Tevaera

L'écosystème de jeu de Tevaera apporte un mélange unique d'aventure et de technologie au monde du jeu. Teva Games propose des jeux dans une variété de genres, se déroulant dans des environnements naturels et reliés par un scénario central de personnages de Guardian. Le premier jeu multijoueur fera ses débuts avec la sortie de Tevaera 2.0, offrant un gameplay passionnant comprenant des mises à niveau sur le thème de la cryptographie et plusieurs modes de jeu.

L'infrastructure de jeu en chaîne composée de Teva Core, Teva Chain, Teva Dex et Teva Market améliore encore l'écosystème.

· Teva Core est un cadre de jeu multijoueur avancé.

· Teva Chain est une hyperchaîne de jeu de troisième couche qui facilite la transition vers le jeu en chaîne complète.

· Teva DEX contribue à une économie de jeu durable grâce à la dex de jeu automatique.

· Teva Market permet la frappe et l'échange de caractères NFT uniques.

3**, Architecture zkSync**

zkSync Era est un protocole L2 conçu pour résoudre le problème d'évolutivité d'Ethereum, en utilisant une structure de cumul à connaissance nulle (ZK). Développé par Matter Labs, il s'agit d'une plate-forme zk-rollup axée sur les besoins des utilisateurs. La plate-forme est conçue pour être largement compatible avec la machine virtuelle Ethereum (EVM) dans une machine virtuelle personnalisée, optimisée pour les preuves à connaissance nulle.

Le fonctionnement de zkSync rollup peut être résumé dans les étapes suivantes :

(1) Dans un premier temps, les transactions ou actions prioritaires sont générées par les utilisateurs.

(2) Par la suite, l'opérateur assume la responsabilité du traitement de la demande de l'utilisateur. Une fois le traitement réussi, l'opérateur crée une opération de cumul et l'inclut dans le bloc.

(3) Une fois le bloc terminé, l'opérateur le soumet au contrat intelligent zkSync sous la forme d'une soumission de bloc. Il convient de noter que le contrat intelligent vérifie une partie de la logique exécutée par certains rollups.

(4) Enfin, la preuve du blocage est fournie au contrat intelligent zkSync, et cette étape est la vérification du blocage. Si le contrat validateur considère la validation réussie, il valide le nouvel état comme définitif. Il s'agit du cycle de vie opérationnel du cumul zkSync.

Cette section approfondira le fonctionnement de zkSync, en se concentrant sur trois couches de base :

(1) Couche d'exécution : La couche d'exécution fait référence au processus qui conduit à des changements ou à des transitions dans l'état de la blockchain. En termes simples, c'est l'endroit où les transactions sont reçues et appliquées à l'état précédent.

(2) Couche de règlement : la couche de règlement utilise un système de preuve pour garantir que les modifications apportées pendant la phase d'exécution reflètent avec précision l'état général du système.

(3) Couche de disponibilité des données : la couche de disponibilité des données est la partie de conservation des enregistrements du système. C'est là que toutes les données de transaction (entrées), les mises à jour du système (sorties) et les preuves sont stockées. Le but est de s'assurer que l'état actuel du système peut toujours être recréé à partir de zéro en cas de besoin.

3.1 Couche d'exécution

3.1.1 Couche d'exécution au niveau de la machine virtuelle

Il fonctionne sur type4 zkEVM, ce qui signifie qu'il prend un code de contrat intelligent écrit dans un langage de haut niveau (par exemple, Solidity, Vyper), puis le compile dans un langage convivial zk-SNARK.

De plus, une caractéristique unique de zkSync Era est qu'il utilise un compilateur basé sur LLVM qui permettra éventuellement aux développeurs d'écrire des contrats intelligents en C++, Rust et d'autres langages populaires.

Le framework LLVM est un compilateur permettant de créer des chaînes d'outils de langage de contrat intelligent. Sa représentation intermédiaire (IR) de haut niveau permet aux développeurs de concevoir, déployer et améliorer des fonctionnalités efficaces spécifiques au langage tout en tirant simultanément parti du vaste écosystème LLVM.

Dans la chaîne d'outils établie, LLVM traite LLVM IR, introduit des optimisations complètes et transmet enfin l'IR optimisé au générateur de code backend zkEVM.

3.1.2 Présentation de la couche d'exécution

Dans zkSync, Core App (application principale) joue un rôle clé dans la gestion de la couche d'exécution.

Sa principale responsabilité est de suivre les dépôts ou les opérations prioritaires des contrats intelligents L1. Ce mécanisme est essentiel pour assurer l'intégration transparente de zkSync avec le réseau Ethereum, car toutes les modifications initiées à partir du réseau Ethereum doivent être surveillées et reflétées dans l'environnement zkSync Layer 2 (L2).

L'application Core est également responsable de la gestion du pool de mémoire (mempool) qui collecte les transactions entrantes. Cette collection de transactions se trouve ensuite dans une file d'attente pour être traitée, agissant en fait comme une zone d'attente avant que les transactions ne soient confirmées et ajoutées à un bloc.

Les responsabilités de l'application principale incluent également la récupération des transactions à partir du mempool, leur exécution dans une machine virtuelle (VM) et l'ajustement de l'état si nécessaire. Essentiellement, le processus consiste à acquérir des transactions, à les traiter et à refléter les résultats dans le système.

Après avoir exécuté la transaction, l'application Core génère un bloc de chaîne. Ces blocs sont constitués de lots de transactions exécutées et vérifiées. L'application principale soumet ensuite ces blocs et preuves au contrat intelligent L1. Ce processus garantit que l'état de la chaîne L1 Ethereum est synchronisé avec la chaîne L2 zkSync.

Pour prendre en charge une interaction transparente entre les applications basées sur Ethereum, il fournit une API web3 compatible Ethereum. Cela rend zkSync plus accessible et convivial pour les développeurs et les utilisateurs expérimentés dans l'écosystème Ethereum.

3.2 Couche de règlement

La couche de règlement est chargée d'assurer l'intégrité des transitions d'état zkSync. Ce processus de vérification se fait dans un contrat intelligent déployé sur Ethereum. Il y a deux contrats importants dans ce processus.

(1) Contrat d'exécuteur : ce contrat obtient des données de bloc des validateurs et des preuves zk des transitions d'état dans zkSync.

(2) Contrat de vérificateur : Il s'agit d'un contrat logique qui permet au système de vérifier les données de bloc et les preuves zk fournies par le contrat d'exécuteur.

3.2.1 Contrat d'exécution

La fonction prouveBlocks joue un rôle central pour garantir l'intégrité et la sécurité du système zkSync. Sa principale responsabilité est de vérifier les preuves zk-SNARK des blocs soumis. Voici une brève description de son fonctionnement :

Tout d'abord, proofBlocks s'assure que les blocs sont vérifiés dans le bon ordre. Pour ce faire, il vérifie si le bloc précédent reçu est le bloc suivant dans la séquence de blockchain qui doit être vérifié.

· Ensuite, la fonction commence à itérer sur chaque bloc soumis. Il vérifie que les hachages de ces blocs correspondent à la valeur attendue à un emplacement particulier de la blockchain. Cela garantit que le bloc en cours de vérification est bien le bon bloc.

La fonction commence alors à construire le tableau proofPublicInput, qui devient la valeur d'entrée publique pour le processus de vérification de preuve zk-SNARK. Le numéro de bloc pour chaque bloc validé est contenu dans ce tableau.

Ensuite, en utilisant le tableau proofPublicInput et certains paramètres stockés, la fonction vérifiera la preuve zk-SNARK. C'est comme résoudre un puzzle, toutes les pièces doivent s'emboîter parfaitement.

· Si la preuve est vérifiée, la fonction met à jour le système pour refléter que les blocs sont maintenant vérifiés. C'est comme mettre une coche à côté d'un élément sur une liste de contrôle.

Enfin, pour chaque bloc vérifié, la fonction déclenche un événement spécial appelé BlockVerification. C'est comme envoyer une notification indiquant que le numéro de bloc, le hachage et l'engagement ont été vérifiés.

En un mot, la fonction proofBlocks agit comme un gardien vigilant, garantissant que les blocs sont vérifiés dans le bon ordre, garantissant que les preuves zk-SNARK sont exactes et mettant à jour l'état du système en conséquence. Son objectif est d'empêcher l'exécution de blocs non valides, garantissant ainsi la sécurité et l'intégrité globales du système zkSync.

3.2.2****Contrat de vérificateur

Le contrat de vérificateur est l'endroit où mettre en œuvre la logique de vérification ci-dessus. Il agit comme un garde pour zkSync en vérifiant les preuves zk-SNARK pour vérifier les données soumises. Le contrat de validation est utilisé pour vérifier si les données soumises à zkSync sont valides.

Le contrat de vérification stocke la "clé de vérification", qui est utilisée pour vérifier les preuves zk-SNARK. Chaque fois que zkSync veut valider une mise à jour, il génère une preuve zk-SNARK et la soumet au contrat de validateur via le contrat d'exécuteur.

Le contrat validateur utilise alors la clé de validation pour vérifier que la preuve est valide. Si cela fonctionne, vous savez que la mise à jour est légitime sans regarder les données réelles. S'il n'est pas valide, la mise à jour sera rejetée.

En vérifiant ces preuves, le contrat de validation garantit que seules des données correctes et valides sont reçues dans zkSync. Ceci est essentiel pour la sécurité et pour empêcher les mises à jour d'état non valides.

3.3 Couche de disponibilité des données

La couche de disponibilité des données du système agit comme une archive, stockant toutes les informations de transaction (entrées), les modifications du système (sorties) et les preuves. zkSync utilise une interface de contrat intelligente pour définir sa politique de disponibilité des données (DA). zkSync prévoit de fournir plusieurs options pour la disponibilité des données afin de réduire les coûts et de protéger la confidentialité.

3.3.1 zkPorter

zkSync a lancé une solution de disponibilité des données hors chaîne appelée "zkPorter". L'outil est conçu pour s'intégrer au système de cumul de zkSync, facilitant les interactions entre les cumuls et les comptes zkPorter. Pour assurer la sécurité des données au sein de zkPorter, les « gardiens » - les personnes qui jalonnent les jetons zkSync et vérifient la disponibilité des données en signant des blocs - sont activés.

zkPorter fonctionne comme un protocole de consensus interne, facilitant un débit de transaction massif. En comparaison, le mode ZK Rollup standard dans zkSync 2.0 est capable de traiter environ 1 000 à 5 000 transactions par seconde (TPS). zkPorter peut gérer de 20 000 à 100 000 TPS, selon la complexité de la transaction.

Un compromis de l'utilisation de zkPorter est que les utilisateurs doivent faire confiance au mécanisme de consensus interne de zkSync. Cela conduit à une solution de cumul moins décentralisée. La considération de l'utilisateur est de choisir entre le mode zkPorter (moins coûteux mais moins sécurisé) ou le mode ZK-rollup (sécurité la plus élevée).

De plus, zkSync 2.0 facilite l'interopérabilité, permettant des échanges transparents entre les comptes ZK-rollup et zkPorter. La différence fondamentale entre zkPorter et Starkware Volition est la détermination de la disponibilité des données : dans zkPorter, cette décision est prise sur la base d'un compte, tandis que dans Volition, cette décision est prise sur la base d'une transaction individuelle au sein d'un compte créé sur.

4**、Pile ZK et pile OP**

Récemment, Matter Labs a annoncé la sortie prochaine de ZK-Stack. ZK-Stack fournira un logiciel similaire à OP-Stack pour personnaliser et exploiter le rollup.

Les caractéristiques communes d'OP-Stack et de ZK-Stack sont les suivantes :

Gratuit et Open Source : Les deux sont développés sous une licence open source, garantissant un accès gratuit. Ils encouragent les développeurs à contribuer en s'appuyant sur le logiciel.

Interopérabilité : le concept d'hyperchaîne Hyperchain de ZK Stack peut être connecté sans effort dans un réseau sans confiance avec une faible latence et une liquidité partagée. De plus, OP-Stack envisage un concept de Superchain pour connecter toutes les chaînes basées sur OP-Stack.

· Décentralisation : Afin de parvenir à un réseau et une communauté plus décentralisés, OP-Stack et ZK-Stack ont clairement proposé un plan de décentralisation dans la récente feuille de route. Cette décision augmente non seulement la résilience du réseau, mais assure également une répartition plus équitable du pouvoir et du contrôle.

Malgré les similitudes d'un point de vue conceptuel, il existe des différences d'un point de vue technique et commercial. Cette section se penchera sur les différences entre les perspectives suivantes.

(1) Développeurs Dapp

(2) Développeurs principaux

(3) Affaires

4.1****Point de vue du développeur Dapp

4.1.1 Équivalence EVM

Déploiement EVM d'OP-Stack : L'EVM d'OP-Stack est implémenté en apportant des modifications mineures au geth d'Ethereum, rendant le système presque entièrement compatible avec EVM. D'autre part, ZK-Stack intègre quelques changements dans les opcodes EVM, et certains opcodes ne sont pas encore pris en charge. Malgré ces changements, l'impact a été minime et les projets ont été rigoureusement testés et validés dans le monde réel.

Cependant, il y a eu des incidents dus à l'équivalence non-EVM de ZK-Stack. Un exemple notable est 921 ETH pris au piège dans un contrat intelligent car le contrat utilise la fonction de transfert. Ce problème a été efficacement résolu.

4.1.2 Abstraction de compte natif

Contrairement à ERC-4337, l'architecture de ZK-Stack inclut une fonction native d'abstraction de compte (AA). Dans un système comme ERC-4337, il est nécessaire d'avoir un mempool séparé d'UserOps pour permettre l'abstraction de compte dans le réseau.

4.1.3 Prise en charge de la confidentialité

En utilisant validum, le stockage des données dans une base de données autrement confidentielle garantit la confidentialité en partant du principe que l'opérateur garde les données du bloc confidentielles. Cette fonctionnalité est particulièrement avantageuse pour les utilisateurs en entreprise.

4.2 Point de vue du développeur principal

4.2.1 Fonctionnement de l'infrastructure : OP-Stack est plus intuitif

Fonctionnement : zkSync et OP-Stack utilisent tous deux un séquenceur pour coordonner les transactions et stocker les données dans Ethereum. Cependant, zkSync nécessite un prouveur pour fonctionner. Cette application de preuve traite les blocs générés par le serveur et les métadonnées associées pour construire des preuves de validité sans connaissance. En revanche, OP-Stack ne nécessite pas d'infrastructure complexe distincte pour participer au jeu de défi de preuve.

4.2.2 Alternatives VM : ZK-Stack a plus de potentiel pour fournir diverses options

zkSync s'exécute avec le compilateur LLVM, qui se traduit par le bytecode zkEVM, montrant la possibilité de créer des environnements d'exécution à l'aide d'autres langages, tels que C++.

4.2.3 Disponibilité des données : ZK-Stack offre plusieurs options

La couche de disponibilité des données d'OP-Stack repose principalement sur Ethereum, où toutes les informations de transaction et les racines d'état de sortie sont stockées. Cela entraîne un coût élevé d'exploitation de la chaîne OP-Stack. Cependant, il y a eu des tentatives pour compenser ce coût en stockant les données de transaction dans Celestia DA.

ZK-Stack recherche et développe des alternatives aux solutions de disponibilité des données comme zkPorter. Cette approche permet aux utilisateurs de déterminer la disponibilité de leurs propres données en fonction de leur préférence pour une plus grande sécurité ou un moindre coût. De plus, les entreprises souhaitant préserver la confidentialité des données peuvent utiliser des solutions telles que Validium qui prennent en charge le stockage des données sans compromis.

4.3 Perspective commerciale : coûts et avantages

Aujourd'hui, le lancement de rollups indépendants est une option viable, d'autant plus que des logiciels open source tels que ZK-Stack et OP-Stack sont développés et maintenus publiquement. De plus, les plates-formes Rollup-as-a-Service (RaaS) telles que Caldera et Conduit simplifient considérablement le processus.

Au-delà du point de vue du développeur, il est essentiel d'évaluer de manière réaliste les coûts et avantages potentiels associés aux opérations de déploiement. Cependant, la prévision de ces montants peut être compliquée en raison de plusieurs variables.

Au fur et à mesure que des améliorations majeures sont apportées à la base de code, comme le montre la récente mise à jour de Bedrock d'Optimism, les coûts associés à l'exécution des rollups diminuent rapidement. Cette dynamique rend difficile l'estimation précise des coûts et des avantages. De plus, les coûts spécifiques associés aux serveurs et à l'infrastructure ne sont pas largement connus car une seule entité gère généralement l'ensemble du déploiement. Enfin, les fluctuations du prix du jeton sous-jacent (tels que zkSync et l'ETH d'Optimism) ajoutent une autre couche d'incertitude, car les coûts peuvent fluctuer en fonction du sentiment du marché.

Certains des principaux coûts et avantages sont les suivants :

4.3.1 Coût

· Coût de version L1 : le coût de stockage des transactions, des racines d'état et des données de preuve. En règle générale, un cumul optimiste est plus coûteux à émettre car il nécessite de stocker des données de transaction brutes pour la validation. Certains cumuls publient des différences d'état au lieu de données d'état complètes pour éviter des coûts supplémentaires.

· Coût de fonctionnement du trieur L2.

Coût de la preuve : pour zk, il s'agit du coût de génération et de vérification de la preuve ; pour la preuve de la fraude, il s'agit du coût de la contestation de la preuve.

4.3.2 Avantages

· Frais de transaction L2

Peut-être MEV, mais pour éviter les problèmes de centralisation, la plupart des trieurs L2 connus n'extraient pas MEV.

5. Conclusion

Matterlabs a travaillé sur le développement de zkEVM et a fait des progrès significatifs à ce sujet. Bien que n'étant pas entièrement compatible EVM (Type4 EVM), l'exploitation de LLVM semble avoir un grand potentiel. La prochaine phase des plans de Matterlabs est de publier ZK-Stack, une base de code qui permettra aux développeurs de tirer parti de sa base de code solide pour créer leurs propres cumuls. L'outil promet des avantages évidents par rapport à OP-Stack, notamment en termes de protection de la vie privée et d'évolutivité.

Cependant, les deux projets en sont encore à leurs débuts et il reste encore beaucoup de travail à faire. Une évaluation approfondie de la structure des coûts et des avantages associés au déploiement est essentielle. De plus, un défi important consiste à cultiver un écosystème de développeurs autour de ces deux bases de code. Une analyse détaillée et une planification stratégique sont essentielles pour assurer le développement durable de la plateforme et de ses technologies associées.

J'espère que les deux projets prospéreront et que la construction open source et les feuilles de route partagées deviendront la norme dans l'espace web3.