Transmettre le titre original '[Série ZK - 1] ZK Rollups : Elephant In the Room'

Résumé

• Bien que les preuves à divulgation nulle de connaissance (ZKP) soient prometteuses pour un écosystème blockchain plus privé et évolutif, de nombreux aspects de ZK sont mal compris ou mis en œuvre différemment de ce que l’on pense généralement.
• Les ZKP ont deux aspects principaux : « Zero Knowledge » et « Succinctness ». Bien que cela ne soit pas incorrect, la majorité des cumuls ZK n’utilisent que la propriété de succinctness ; Les données de transaction et les informations de compte ne sont pas entièrement conservées à connaissance nulle ni privées.
• Les cumuls ZK ne sont peut-être pas un choix optimal en tant que pile de développement pour tous les types de DApps. Par exemple, la génération de ZKP peut agir comme un goulot d’étranglement pour une finalité rapide, diminuant les performances des jeux Web3, tandis que les méthodes d’assurance de la disponibilité des données basées sur la publication des différences d’état peuvent nuire au service des protocoles de prêt DeFi.

Figure 1 : ZK est un bon mot à la mode

(Source : imgflip)

L’état actuel de l’industrie de la blockchain peut être comparé à l’ère du Zero-Knowledge (ZK). Partout où vous regardez, ZK est proéminent... Il est de plus en plus rare de trouver des projets blockchain de nouvelle génération qui n’intègrent pas ZK dans leur nom. D’un point de vue technique, il est indéniable que ZK est une technologie prometteuse capable de contribuer à un écosystème blockchain plus évolutif et plus privé. Cependant, en raison de l’expérience technique complexe de ZK, de nombreux investisseurs, particuliers et institutionnels, se retrouvent souvent à investir dans des projets ZK en se basant sur la « conviction » qu’ils ont l’air cool, nouveaux et pourraient résoudre le trilemme de la blockchain, sans saisir pleinement comment la technologie ZK profite à chaque projet.

Dans cette série ZK, nous explorerons à la fois les vérités gênantes (inconvénients et inconvénients) et les applications bénéfiques des ZK rollups. Tout d’abord, nous allons décortiquer les deux propriétés fondamentales des preuves ZK (ZKP) pour les blockchains : « connaissance zéro » et « concision » ; Ensuite, nous verrons comment un grand nombre de ZK Rollups actuellement en service n’utilisent pas réellement l’aspect « zero-knowledge ». Ensuite, nous examinerons les domaines dans lesquels l’application du ZK rollup est plutôt préjudiciable que bénéfique, en évitant des problèmes bien connus comme la complexité de la mise en œuvre. Enfin, nous mettrons en évidence des projets exemplaires qui incarnent efficacement les principes ZK et démontrent réellement les avantages tangibles de leur utilisation de la technologie ZK.

Récapitulatif : Cycle de vie des transactions dans ZK Rollups

Les cumuls sont une solution de mise à l’échelle qui répond aux contraintes de débit des L1 en exécutant des bundles de transactions hors chaîne, puis en stockant des données récapitulatives du dernier état L2 sur le L1. Parmi eux, les rollups ZK se distinguent par leur capacité à retirer rapidement des fonds en soumettant des preuves de validité pour le calcul hors chaîne sur la chaîne. Avant d’aborder les problèmes liés aux rollups ZK, récapitulons brièvement son cycle de vie de transaction.

Figure 2 : Cycle de vie des transactions dans les rollups ZK

(Source : Presto Reserach)

1. Chaque utilisateur L2 génère et soumet sa transaction au séquenceur.
2. Le séquenceur agrège et ordonne plusieurs transactions, puis calcule le nouvel état de cumul en les exécutant hors chaîne. Par la suite, le séquenceur commet ce nouvel état de cumul dans le contrat intelligent d’état on-chain sous la forme d’un « lot », ainsi que les données de transaction L2 correspondantes compressées en blobs pour garantir la disponibilité des données.
3. Le lot est envoyé au prouveur et le prouveur crée une preuve de validité (ou ZKP) de l’exécution du lot. Cette preuve de validité est ensuite envoyée au contrat intelligent du vérificateur L1 avec les données supplémentaires (c’est-à-dire la racine de l’état précédent) qui aide le vérificateur à reconnaître ce qu’il vérifie.
4. Une fois que le contrat de vérification a vérifié que la preuve est valide, l’état du cumul est mis à jour et les transactions L2 du lot validé sont considérées comme finalisées.

(Notez que cette explication est une version simplifiée du processus complet de rollup ZK, et que chacune des implémentations peut varier en fonction du protocole. Il peut y avoir plus d’entités dans les L2 si nous séparons les rôles ; tels que les agrégateurs, les exécuteurs et les proposants. Les niveaux de blocs de données peuvent également différer tels que les blocs, les blocs et les lots en fonction de leurs utilisations. L’explication ci-dessus suppose une situation où un séquenceur centralisé a une forte autorité qui exécute les transactions et produit également un format de bloc de données unifié sous forme de lots.)

Contrairement aux rollups optimistes, grâce aux ZKP (par exemple, ZK-SNARK ou ZK-STARK), les rollups ZK peuvent vérifier l’exactitude de l’exécution de milliers de transactions simplement en vérifiant une simple preuve, sans les rejouer toutes. Alors, qu’est-ce que ce ZKP et quelles sont ses caractéristiques ?

Deux propriétés des ZKP : connaissance zéro et concision

Comme son nom l’indique, ZKP est essentiellement une preuve. Une preuve peut être tout ce qui peut étayer suffisamment l’affirmation du prouveur. Disons que Bob (prouveur) veut convaincre Alice (vérificateur) de l’autorité de son ordinateur portable. Le moyen le plus simple de le prouver est que Bob donne simplement le mot de passe à Alice, et Alice tape le mot de passe sur l’ordinateur portable et vérifie que Bob a une autorité. Cependant, ce processus de vérification n’est pas satisfaisant pour Alice et Bob. Si Bob a défini un mot de passe très long et enchevêtré, il serait très difficile pour Alice de le taper correctement (en supposant qu’Alice ne puisse pas copier et coller). Plus réalistement, Bob peut être réticent à divulguer son mot de passe à Alice afin de prouver son autorité.

Et s’il y avait un processus de vérification où Alice pouvait vérifier rapidement l’autorité de l’ordinateur, sans que Bob ait à révéler son mot de passe ? Par exemple, Bob peut simplement taper du doigt pour déverrouiller l’ordinateur portable avec Touch ID devant Alice comme dans la figure 3 (notez que ce n’est pas un exemple parfait pour ZKP). C’est là qu’Alice et Bob peuvent bénéficier des deux propriétés clés des ZKP : la propriété à connaissance nulle et la propriété de concision.

Figure 3 : Intuition de haut niveau de la connaissance zéro et de la concision

(Source : imgflip)

Connaissance zéro

La propriété « connaissance zéro » fait référence à un cas où la preuve générée par le vérificateur ne révèle rien sur le témoin secret (c’est-à-dire des données privées), laissant le vérificateur dans l’ignorance de quoi que ce soit sur les données, sauf la validité de la preuve. Dans la blockchain, cette propriété peut être utilisée pour préserver la vie privée des utilisateurs individuels. Si des ZKP sont appliqués pour chaque transaction, les utilisateurs peuvent prouver la légitimité de leurs actions (c’est-à-dire prouver qu’un utilisateur dispose de suffisamment de fonds pour effectuer une transaction) sans exposer les détails de leurs transactions (par exemple, les transferts, les mises à jour du solde du compte, les déploiements de contrats intelligents et les exécutions de contrats intelligents) au public.

Concision

L’autre propriété, la « concision », fait référence à la capacité de ZK à générer une preuve courte et rapide à vérifier à partir d’une affirmation de grande taille. En d’autres termes, c’est la consolidation de quelque chose de grand en quelque chose de compact. Dans la blockchain, cela est particulièrement utilisé dans les rollups. Avec les ZKP, les prouveurs en L2 peuvent revendiquer la bonne exécution des transactions en soumettant une preuve succincte au vérificateur en L1 (la validité des TB des transactions peut être représentée par 10~100 Ko de preuve). Les vérificateurs peuvent alors facilement confirmer la validité des exécutions en peu de temps (c’est-à-dire 10ms~1s) en vérifiant la preuve succincte au lieu de rejouer toutes les transactions.

ZK Rollup est génial, mais ne signifie pas confidentialité

Les caractéristiques ZKP susmentionnées sont bien utilisées dans les rollups ZK. Bien que les vérificateurs ne puissent pas déduire les données de transaction originales des ZKP reçues du prouveur, la vérification de la preuve succincte leur permet de valider efficacement la réclamation du prouveur (c’est-à-dire le nouvel état L2). Cela dit, l’affirmation selon laquelle les cumuls ZK dans leur itération actuelle adhèrent pleinement aux propriétés de connaissance zéro et de concision est trompeuse. Cela peut être vrai lorsqu’il se concentre uniquement sur l’interaction entre le prouveur et le vérificateur, mais il existe également d’autres composants dans les rollups ZK, tels que les nœuds de séquenceur, de prouveur et de rollup. Le principe de « connaissance zéro » est-il assuré pour eux aussi ?

Le défi d’obtenir une confidentialité totale avec les ZKP dans tous les cumuls ZK découle de la compromission potentielle si d’autres parties restent publiques alors que certaines sont rendues privées par ZK. Pensez au cycle de vie des transactions dans les rollups ZK : la confidentialité est-elle préservée lorsque la transaction est envoyée d’un utilisateur à des séquenceurs ? Et pour les prouveurs ? Ou la confidentialité des informations d’un compte individuel est-elle préservée lorsque le lot L2 est soumis à la couche DA ? Aucun des scénarios n’est actuellement vrai.

Figure 4 : Fuite de confidentialité dans les cumuls ZK

(Source : Recherche Presto)

Dans la plupart des rollups ZK courants, le séquenceur ou le prouveur (ou d’autres entités centralisées dotées d’une forte autorité) a une visibilité claire des détails de la transaction, notamment les montants des transferts, les mises à jour du solde du compte, les déploiements de contrats et les exécutions de contrats. À titre d’exemple simple, vous pouvez facilement observer tous les détails mentionnés en visitant l’un des explorateurs de blocs de rollup ZK. De plus, considérez une situation où le séquenceur centralisé est en quelque sorte hors service et qu’un autre nœud de rollup tente de restaurer l’état de rollup. Il récupérera les données L2 publiées publiquement à partir de la couche DA (qui est L1 Ethereum dans la plupart des cas) et reconstruira l’état L2. Dans ce processus, tout nœud capable de rejouer les transactions L2 stockées dans la couche DA peut récupérer les informations sur l’état du compte de chaque utilisateur.

Ainsi, le terme « connaissance zéro » est implémenté sous une forme fragmentée dans les rollups ZK actuels. Bien que cela ne puisse pas être considéré comme incorrect, il est évident que cela diffère de la notion communément perçue selon laquelle « ZK signifie connaissance zéro et équivaut à une vie privée totale ». La nouveauté des rollups ZK actuels est de tirer parti de la propriété « succincte » plutôt que de la « connaissance zéro », qui consiste à exécuter les transactions hors chaîne, et à générer des preuves succinctes pour que les vérificateurs vérifient la validité de l’exécution de manière rapide et évolutive sans les réexécuter.

Pour cette raison, certains rollups ZK tels que Starknet se désignent eux-mêmes comme des « Validity Rollups » pour éviter toute confusion, tandis que d’autres qui garantissent une véritable confidentialité ZK, comme Aztec, se qualifient de rollups ZK-ZK.

Pensez à l’aspect pratique des ZK Rollups

Comme mentionné ci-dessus, la confidentialité ZK n’est pas entièrement implémentée dans la plupart des cumuls ZK. Alors, quel devrait être notre prochain objectif ? Obtenir une confidentialité totale des transactions en déployant entièrement ZK dans chaque partie du rollup ? En fait, ce n’est pas un problème simple. Outre la nécessité d’avancées technologiques significatives pour faire mûrir davantage la technologie, il reste des questions litigieuses pour ZK en termes d’idéologie (par exemple, l’utilisation illégale de transactions privées) et de praticité (par exemple, est-ce vraiment utile ?). Étant donné que le débat sur la moralité de la confidentialité totale des transactions dépasse le cadre de cet article, concentrons notre attention sur les deux points pratiques des rollups ZK rencontrés par les projets blockchain.

Point #1 : La génération de ZKP peut être un goulot d’étranglement pour une finalité rapide

Discutons d’abord de l’aspect pratique des ZK rollups eux-mêmes. L’argument de vente le plus convaincant des ZK rollups est le court délai de retrait des actifs en raison de sa « finalité rapide » des transactions grâce aux ZKP. Le secteur qui exploite le plus efficacement les caractéristiques des ZK rollups est le jeu, car les dépôts et les retraits de monnaie dans le jeu sont très fréquents et un volume élevé de transactions dans le jeu est généré chaque seconde.

Mais les rollups ZK peuvent-ils vraiment être considérés comme la pile optimale pour les jeux ? Pour cela, nous devons réfléchir un peu plus au concept de « finalité rapide » dans les rollups ZK. Imaginez une situation où un utilisateur profite d’un jeu Web3 fonctionnant sur une pile basée sur le rollup ZK. L’utilisateur échange un objet du jeu contre une monnaie du jeu et tente de retirer cet actif du jeu.

Pour retirer l’actif, la transaction en jeu doit être finalisée ; cela signifie que la transaction doit être incluse dans le nouvel engagement d’état de cumul, que le ZKP correspondant doit être soumis à la L1 et qu’il y a une attente pour que la preuve soit finalisée dans L1 Ethereum afin qu’elle puisse garantir que la transaction ne peut pas être annulée. Si tous ces processus devaient se produire instantanément, alors oui, nous pourrions obtenir la « confirmation instantanée de la transaction » pour laquelle les rollups ZK sont souvent vantés, permettant à l’utilisateur de retirer l’actif immédiatement.

Cependant, la réalité est loin de cela. Selon les statistiques fournies par L2beat sur le temps de finalité pour les différents rollups ZK, zkSync Era prend environ 2 heures, Linea prend 3 heures et Starknet prend en moyenne environ 8 heures. En effet, il faut du temps pour générer un ZKP à partir d’un prouveur, et il faut plus de temps pour inclure plus de transactions dans un seul lot (c’est-à-dire une seule épreuve) afin de réduire le coût des frais de transaction. En d’autres termes, la vitesse de génération et de soumission des preuves est un goulot d’étranglement potentiel pour atteindre une finalité rapide dans les ZK rollups, ce qui peut diminuer l’expérience utilisateur dans les jeux Web3.

Figure 5 : La génération de ZKP peut être un goulot d’étranglement potentiel pour une finalité rapide dans les rollups ZK

(Source : imgflip)

D’autre part, les chaînes optimisées pour les jeux comme Ronin (alimente les jeux Web3 tels que Pixels et Axie Infinity) assurent une finalité super rapide tout en sacrifiant la décentralisation et la sécurité. Ronin n’est pas une chaîne basée sur ZK ou rollup : c’est une blockchain EVM qui fonctionne sous l’algorithme de consensus PoA (Proof of Authority) + DPoS (Delegated Proof of Stake). Il sélectionne 22 validateurs en fonction du montant de la mise déléguée, puis ces validateurs génèrent et valident simplement des blocs à la manière d’un PoA (c’est-à-dire un processus de vote uniquement parmi les 22 validateurs). Ainsi, les transactions sont finalisées rapidement sur Ronin, car il n’y a presque aucun délai pour que les transactions soient incluses dans le bloc, et prend peu de temps à être validées. Après le hardfork Shillin, il ne faut en moyenne que 6 secondes pour finaliser chaque transaction. Ronin réalise tout cela sans ZKP.

Et oui, bien sûr, Ronin a aussi des inconvénients. Le fait d’être gouverné par des validateurs centralisés le rend relativement plus vulnérable à une attaque à 51 %. De plus, comme il n’utilise pas Ethereum comme couche de règlement, il ne peut pas hériter de la sécurité d’Ethereum. Il existe également des risques de sécurité associés à l’utilisation d’un pont inter-chaînes. Mais pensez du point de vue des utilisateurs : s’en soucieront-ils ? Les rollups ZK actuels sans séquençage décentralisé souffrent également du problème du point de défaillance unique (SPOF). Ethereum leur offre une assurance car il réduit la probabilité que les transactions reviennent, mais si le séquenceur centralisé ou le prouveur tombe en panne, les rollups ZK se bloquent également. Notez à nouveau que « ZK » dans les cumuls ZK n’est utilisé que pour vérifier la validité de l’exactitude de l’exécution. S’il existe un autre projet offrant les mêmes fonctionnalités que les rollups ZK mais plus rapide et moins cher, les rollups ZK ne seront peut-être plus considérés comme la pile prioritaire par les utilisateurs et les développeurs de jeux Web3.

Point #2 : La publication des diffs d’état est une arme à double tranchant

Un autre point est l’aspect pratique des implémentations de protocole pour les rollups ZK. Parmi eux, nous nous concentrons ici sur la publication des diffs d’état, qui est l’un des moyens d’assurer la disponibilité des données (voir Déverrouiller la mise à niveau de Dencun : la vérité invisible de la mise à l’échelle des couches DA, Jaehyun Ha, 12Apr24) dans les rollups ZK.

Un moyen facile de comprendre la disponibilité des données dans les rollups est de penser à un alpiniste amateur certifiant et enregistrant son ascension du mont Everest. La méthode la plus simple consiste à enregistrer chaque étape de l’ascension du camp de base au sommet dans une vidéo. Bien que le fichier vidéo puisse être volumineux, n’importe qui peut vérifier l’ascension de l’Everest par l’alpiniste et peut-être rejouer les images. Cette analogie peut être comparée à la méthode de publication des données de transaction brutes pour assurer la disponibilité des données. Les rollups optimistes suivent cette approche afin de faire rejouer les challengers individuels et de vérifier la bonne exécution, car il n’y a rien à faire dans l’engagement de l’État du séquenceur. Parmi les rollups ZK, Polygon, zkEVM et Scroll adoptent cette approche, stockant les données brutes des transactions L2 sous une forme compressée sur le L1 afin que n’importe qui puisse rejouer les transactions L2 pour restaurer l’état du rollup en cas de besoin.

Pour revenir à l’exemple de l’alpiniste amateur, une autre méthode de vérification pourrait être qu’un alpiniste de premier plan gravisse l’Everest avec l’alpiniste amateur pour vérifier au monde que l’ascension a bien été terminée. L’ascension ayant été certifiée par une personne de confiance, le grimpeur n’a plus besoin d’enregistrer chaque pas pour la documentation. Il suffirait de prendre une photo au point de départ et une autre au sommet, et d’autres considéreraient simplement que le grimpeur a atteint le sommet. Cette analogie reflète la méthode de comparaison d’état utilisée pour garantir la disponibilité des données. Dans les rollups ZK, zkSync Era et StarkNet utilisent cette approche, en stockant uniquement la différence d’état avant et après l’exécution des transactions L2 sur le L1 afin que n’importe qui puisse calculer les différences d’état à partir de la genèse pour restaurer l’état du rollup si nécessaire.

Figure 6 : Publication de transactions brutes par rapport à la publication de diffs d’état

(Source : Recherche Presto)

Cette approche de différence d’état est sans aucun doute bénéfique en termes de coût par rapport à l’approche de publication des données de transaction brutes car elle peut ignorer le stockage des transactions intermédiaires, réduisant ainsi le coût de stockage en L1. Cependant, bien que ce ne soit pas un problème courant, il y a un inconvénient sous-jacent ici : cette approche ne permet pas de restaurer l’historique complet des transactions L2, ce qui peut être un problème pour certaines DApps.

Prenons l’exemple de Compound, le protocole de prêt DeFi, et supposons qu’il est construit sur une pile de rollup ZK basée sur une approche state-diff. Ces protocoles nécessitent l’historique complet des transactions afin de calculer l’offre et les taux d’intérêt d’emprunt chaque seconde. Mais que se passera-t-il si le séquenceur de rollup ZK tombe en panne et que d’autres nœuds de rollup tentent de restaurer le dernier état ? Il peut restaurer l’état, mais le taux d’intérêt sera restauré de manière inexacte car il ne peut suivre que les instantanés entre les lots plutôt que toutes les transactions intermédiaires.

Conclusion

Cet article affirme principalement qu’il n’y a pas de « ZK » dans la plupart des rollups ZK d’aujourd’hui, et qu’il y a beaucoup de domaines dans les DApps où l’utilisation des rollups ZKP et ZK n’est peut-être pas le choix le plus optimal. La technologie ZK peut se sentir innocente d’être blâmée ; parce qu’il n’y a rien d’intrinsèquement mauvais en soi - C’est juste qu’en tirant parti de ses avancées techniques, il peut entraîner une dégradation potentielle des performances des DApps. Cependant, cela ne veut pas dire que les technologies ZK sont inutiles pour cette industrie. Lorsque les ZKP et les ZK rollups arriveront finalement à maturité technique, ils pourront certainement fournir des solutions encore meilleures pour résoudre le trilemme de la blockchain. En fait, il existe des projets basés sur ZK qui maintiennent la confidentialité ZK ainsi que de nombreux types de DApps qui exploitent efficacement les avantages de ZKP et des rollups ZK. Nous explorerons cela plus en détail dans le prochain article - restez à l’écoute !

Démenti:

1. Cet article est reproduit de [Prestolabs]. Transmettre le titre original '[Série ZK - 1] ZK Rollups : Elephant In the Room'. Tous les droits d’auteur appartiennent à l’auteur original [Jaehyun Ha]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn , et ils s’en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.