Chaîne de blocs
Un aperçu des cumuls de couche 2
Au cours des dernières années, les options de cumul de couche 2 (L2) sont devenues au premier plan à mesure que l’activité sur le réseau Ethereum augmentait. L’activité et l’engagement avec les jetons non fongibles (NFT) et la finance décentralisée (DeFi) ont provoqué une augmentation de l’activité de la blockchain de couche 1 (L1).
À son tour, la demande d’espace de bloc, représentée par les coûts du gaz, a augmenté. Et le délai de finalisation des transactions a augmenté en raison de l’augmentation de la cost du réseau.
Alors que la fusion Ethereum a jeté les bases des futures optimisations des frais de gaz ; il n’a pas directement réduit les frais de gaz de transaction.
Au cours de l’année entre l’été 2020 et le pic de la demande à l’été 2021, le coût du gaz à Gwei sur le réseau Ethereum a augmenté jusqu’à 1300 %. La nécessité de rendre les transactions rapides et abordables a stimulé la création de deux formes principales de rollup : Optimistic et Zero-Data (ZK).
Les cumuls aident à supprimer les demandes de calcul sur le réseau Ethereum en déplaçant le traitement des transactions hors chaîne, en les convertissant en une seule donnée, puis en les renvoyant sur Ethereum par heaps pour réduire les coûts et le temps associés.
La grande différence entre les deux est que les cumuls Optimistes utilisent des preuves de fraude, tandis que les cumuls ZK s’appuient sur des preuves à connaissance nulle pour vérifier les modifications apportées à la chaîne principale.
Cumuls optimistes et ZK : preuves de fraude vs preuves de validité
Les preuves de fraude regroupent les transactions hors chaîne, puis les republient sur le L1. Une fois qu’un bundle a été soumis sur la L1, il y a une période de défi, au cours de laquelle n’importe qui peut contester le résultat du cumul en calculant une preuve de fraude.
De même, la connaissance zéro vérifie les transactions par heaps hors chaîne et les soumet en une seule transaction. Là où ils diffèrent, c’est plutôt que de supposer que les transactions sont correctes au départ, ils utilisent une preuve de validité pour prouver instantanément si les transactions sont valides. Une fois que les transactions ont été confirmées comme valides, elles sont ensuite soumises au L1.
C’est ainsi qu’ils tirent leurs noms respectifs – les preuves de fraude sont l’endroit où les transactions sont vérifiées rétrospectivement pour voir s’il y a des transactions frauduleuses, tandis que les preuves de validité sont complétées avant que les transactions ne soient soumises au L1.
Bien qu’il existe des projets importants pour les deux, ils présentent chacun leurs propres avantages et inconvénients respectifs. Les roll-ups optimistes ont l’avantage que les preuves de fraude ne sont requises qu’en cas de problème.
Cela signifie qu’ils nécessitent moins de ressources de calcul et qu’ils peuvent bien évoluer. Le problème réside dans la période de défi. Une période de contestation plus longue augmente la probabilité que des transactions frauduleuses soient identifiées, mais cela signifie également que les utilisateurs doivent attendre plus longtemps pour retirer leurs fonds.
Pour les principales options de cumul optimistes, telles que Arbitrum et Optimism, cette période d’attente peut durer jusqu’à une semaine. Alternativement, les cumuls ZK ont l’avantage de toujours refléter un état L2 right. Leur inconvénient est que des preuves sont requises pour toutes les transitions d’état, plutôt que uniquement lorsqu’elles sont contestées, ce qui limite l’évolutivité. Cette scenario est encore aggravée par la nature complexe et le stade précoce de la technologie.
Malgré leurs défis respectifs, les rollups ZK sont annoncés comme l’avenir des rollups. Cela est principalement dû à la génération automatique de preuves de validité augmentant la sécurité du protocole, au temps de retrait considérablement réduit en raison de l’absence de période de défi et au fait que les cumuls ZK offrent une meilleure compression des données.
Pour ces raisons, nous nous concentrerons sur l’état actuel de l’espace ZK-rollup, les dernières improvements et ce qui nous attend dans le futur.
L’espace ZK-Rollup
Comme nous en avons discuté, les rollups ZK sont principalement au centre des préoccupations avec des acteurs comme zkSync, Starknet, Polygon zkEVM et Scroll qui lèvent tous de gros capitaux pour développer leurs options malgré le lancement de StarkNet sur le réseau principal (780 hundreds of thousands de {dollars} au whole) .
Chacun de ces projets a pris son propre angle, différant principalement par sa stratégie de disponibilité des données de cumul et son algorithme de preuve. La stratégie de disponibilité des données détermine où les données d’état d’un roll-up sont stockées, le stockage en chaîne a une sécurité accrue mais il utilise de l’espace de bloc sur le réseau Ethereum, ce qui réduit le débit des transactions.
L’algorithme de preuve est le moyen de générer une preuve de validité, qui peut être STARK ou SNARK.
Ces deux algorithmes aident les développeurs à déplacer le calcul et le stockage hors chaîne, augmentant ainsi l’évolutivité. Ils sont également en mesure de vérifier si un utilisateur dispose de fonds suffisants et de la bonne clé privée sans avoir à accéder aux informations elles-mêmes, améliorant ainsi la sécurité.
Vous pouvez en savoir plus sur les différences strategies ici. Les STARK ont l’avantage d’offrir plus d’évolutivité, de sécurité et de transparence par rapport aux SNARK.
Mais l’inconvénient de STARKS est une taille d’épreuve plus grande, qui prend plus de temps à vérifier, et que les SNARK n’utilisent comparativement que 24% du gaz. Pour SNARKS et STARKS, nous avons le compromis entre la vitesse et le coût par rapport à l’évolutivité, la sécurité et la transparence.
Alors que de nombreuses méthodes différentes sont explorées, il n’y a pas encore de réponse définitive quant à la meilleure façon de mettre en place un cumul ZK. Chaque configuration apporte des avantages respectifs et de nombreux développeurs explorent encore le choix ou la combinaison optimale pour leurs conceptions de cumul.
Les obstacles à surmonter
Comme nous en avons discuté, les rollups ZK sont toujours en développement et divers défis doivent être surmontés avant que les utilisateurs de la blockchain puissent en tirer pleinement parti.
La compatibilité linguistique est l’un de ces défis; la traduction de langages de programmation compatibles EVM, tels que Solidity, dans un langage personnalisé spécifiquement optimisé pour ZKP peut aider à augmenter leur efficacité, mais cela entraîne des défis d’adoption pour les développeurs.
Par exemple, StarkNet cherche à résoudre ce problème avec Warp, un compilateur de langage Solidity to Cairo (le langage du ZKP de StarkNet) qui cherche à convertir automatiquement Solidity en Cairo. L’utilisation de Warp supprime la nécessité pour les développeurs de réécrire leur code dans Cairo, ce qui en fait un processus beaucoup plus fluide.
Parmi les autres défis, citons la nature secrète des projets, dont beaucoup vont à l’encontre de la philosophie open supply de la cryptographie en raison de préoccupations concernant l’avantage du premier arrivé et la seize d’une base d’utilisateurs collante. La plupart des rollups ZK ont été lancés pour la première fois cette année, soulignant la quantité de travail qui reste à faire dans l’espace.
Enfin, bien que les cumuls (à la fois optimistes et à connaissance nulle) présentent les avantages d’une vitesse et d’un coût améliorés, ils ont tendance à se faire au détriment de la décentralisation.
Cela est dû au besoin inhérent de séquenceurs, les acteurs regroupant les transactions et soumettant les preuves à la L1.
Tous les rollups ont actuellement besoin d’un séquenceur centralisé et utilisent des contrats intelligents évolutifs qui sont gérés par une seule entité. Parce que l’espace est encore si tôt, un level focal central est généralement requis pour corriger rapidement les bogues dans le code. Ajoutez à cela que les projets ne sont pas open supply, ce qui crée un autre impediment pour que les membres de la communauté agissent en tant que séquenceurs.
De nombreux projets ont indiqué qu’ils prévoyaient de décentraliser leurs fonctions de séquenceur à l’avenir, mais cela prendra sans aucun doute des ressources et du temps supplémentaires.
Plans de décentralisation
Le lancement d’un jeton et d’un code open-source sera la prochaine étape pour de nombreux projets en quête de décentralisation. La tokenisation de ces providers pour générer de l’activité et décentraliser le produit est un autre domaine où nous nous attendons à voir une myriade de options différentes apparaître alors que les projets cherchent à créer la L2 la plus évolutive, décentralisée et lively du marché.
StarkWare et zkSync prévoient tous deux de lancer un jeton et Polygon pourrait potentiellement utiliser MATIC pour soutenir l’initiative zkEVM de Polygon. L’ingénierie de jetons sur les rollups ZK est un espace encore plus naissant que la technologie de rollup optimiste et trouver un modèle efficace et sturdy peut différencier et stimuler l’adoption.
L’avenir
Les zkEVM en sont encore à leurs débuts et la course est lancée pour être lancée sur le réseau principal. StarkNet a l’avantage du premier arrivé, mais a encore des défis en ce qui concerne la prise en cost des fonctionnalités de Solidity en raison de l’utilisation de Cairo, laissant la possibilité aux concurrents d’apporter des améliorations.
Les projets capables d’accumuler des bases d’utilisateurs importantes attireront les développeurs de dapps, apportant à leur tour plus de dApps à leur plate-forme et augmentant l’ensemble de fonctionnalités. Le zkEVM de ConsenSys passe actuellement à testnet et se concentre spécifiquement sur les développeurs dapp pour cette raison, en tirant parti d’outils comme MetaMask, Infura et Truffle afin qu’ils puissent déployer et gérer des functions comme s’ils utilisaient directement Ethereum.
Et bien que nous ayons discuté des acteurs actuels du marché zkEVM, d’autres options de cumul prédominantes telles que Polygon, Optimism et Arbitrum détiennent toujours une half de marché importante.
Au fur et à mesure que les options zkEVM mûrissent, nous pourrions voir ces projets chercher à passer à des preuves de validité ou à des options hybrides, en tirant parti de leurs bases d’utilisateurs existantes pour attirer le développement de dapp et maintenir leur domination du marché. En fin de compte, les nombreuses options de déploiement (et la concurrence accrue entre elles) continueront d’améliorer l’expérience utilisateur du web3 et d’introduire des plates-formes d’functions pour intégrer la prochaine génération d’utilisateurs.
Compte tenu de ces menaces, nous ne sommes pas surpris du secret des projets dans l’espace, mais nous pensons que le vrai gagnant sera en mesure de tirer parti de l’efficacité des rollups ZK et de le combiner avec une expérience de développeur et d’utilisateur transparente pour s’imposer. .
