ZK Rollups : l'éléphant dans la pièce
TechFlow SélectionTechFlow Sélection
ZK Rollups : l'éléphant dans la pièce
Pour les différents types de DApps, les rollups ZK pourraient ne pas être le choix optimal de pile de développement.
Dédié à des analyses Web3 approfondiesRédaction : Jaehyun Ha
Traduction : TechFlow
Résumé
-
Bien que les preuves à connaissance nulle (ZKPs) promettent un écosystème blockchain plus privé et plus évolutif, de nombreux aspects du zéro-connaissances (ZK) sont mal compris ou diffèrent des méthodes d'implémentation communément perçues.
-
Les ZKPs présentent deux aspects principaux : « connaissance nulle » et « concision ». Bien que cela ne soit pas faux, la plupart des rollups ZK exploitent uniquement la propriété de concision, tandis que les données transactionnelles et les informations de compte ne restent pas entièrement à l'abri de la connaissance ou privées.
-
Pour divers types de DApps, les rollups ZK pourraient ne pas constituer le meilleur choix de pile technique. Par exemple, la génération de ZKPs pourrait devenir un goulot d'étranglement pour une finalité rapide, réduisant ainsi les performances des jeux Web3, tandis qu'une méthode de garantie de disponibilité des données basée sur la publication des différences d'état pourrait nuire aux services des protocoles de prêt DeFi.
Figure 1 : ZK est un excellent mot à la mode
Source : imgflip
L’état actuel de l’industrie blockchain peut être comparé à l’ère du zéro-connaissances (ZK). Où que vous alliez, le ZK est omniprésent, et il devient de plus en plus rare de trouver un projet blockchain de nouvelle génération qui n’intègre pas ZK dans son nom. D’un point de vue technique, indéniablement, le ZK est une technologie prometteuse pouvant contribuer à un écosystème blockchain plus évolutif et plus privé. Toutefois, en raison du contexte technique complexe du ZK, de nombreux investisseurs, particuliers comme institutionnels, investissent souvent dans des projets ZK sur la base de la croyance que cela semble cool, nouveau et susceptible de résoudre le dilemme de la blockchain, sans pleinement comprendre comment la technologie ZK bénéficie à chaque projet.
Dans cette série consacrée au ZK, nous examinerons les inconvénients incontournables (défauts et désavantages) des rollups ZK ainsi que leurs applications bénéfiques. Tout d’abord, nous analyserons les deux propriétés fondamentales des preuves à connaissance nulle (ZKPs) dans la blockchain : « connaissance nulle » et « concision ». Ensuite, nous verrons pourquoi la grande majorité des rollups ZK actuellement opérationnels n’utilisent pas réellement l’aspect « connaissance nulle ». Puis, nous étudierons les domaines où l’application d’un rollup ZK serait plus nuisible que bénéfique, en évitant les problèmes bien connus liés à la complexité de mise en œuvre. Enfin, nous mettrons en lumière certains projets remarquables qui incarnent efficacement les principes ZK et tirent clairement avantage de l’utilisation de cette technologie.
Rappel : Le cycle de vie des transactions dans les rollups ZK
Un rollup est une solution d’évolutivité qui résout la limitation du débit de la couche 1 (L1) en exécutant des lots de transactions hors chaîne, puis en stockant sur la L1 les données résumant l’état le plus récent de la couche 2 (L2). Parmi eux, les rollups ZK se distinguent par leur capacité à permettre un retrait rapide des fonds grâce à la soumission sur chaîne d’une preuve de validité des calculs hors chaîne. Avant d’approfondir les problèmes des rollups ZK, passons rapidement en revue le cycle de vie des transactions.
Figure 2 : Cycle de vie des transactions dans les rollups ZK
Source : Presto Research Center
-
Chaque utilisateur L2 génère et soumet ses transactions au séquenceur.
-
Le séquenceur agrège et ordonne plusieurs transactions, puis les exécute hors chaîne afin de calculer le nouvel état du rollup. Ensuite, il soumet cet état mis à jour sous forme de « lots » au contrat intelligent d’état sur chaîne, tout en compressant les données transactionnelles L2 correspondantes en blocs de données pour assurer la disponibilité.
-
Ce lot est envoyé à un prouveur, qui crée une preuve de validité (ou ZKP) pour l’exécution de ce lot. Cette preuve de validité est ensuite transmise avec des données supplémentaires (comme la racine d’état précédente) au contrat intelligent de vérification sur la L1, permettant ainsi au vérificateur d’identifier précisément ce qu’il valide.
-
Une fois que le contrat de vérification a confirmé la validité de la preuve, l’état du rollup est mis à jour, et les transactions L2 incluses dans le lot soumis sont considérées comme finalisées.
(Notez que cette explication est une version simplifiée du processus des rollups ZK ; chaque implémentation peut varier selon les protocoles. Si l’on distingue davantage les rôles, la L2 pourrait inclure davantage d’entités telles que des agrégateurs, des exécuteurs ou des proposants. La hiérarchie des blocs de données peut également différer — blocs, groupes de blocs ou lots — selon leur usage. L’explication ci-dessus suppose un scénario où un séquenceur centralisé dispose d’une autorité forte pour exécuter les transactions et produit un format uniforme de blocs de données appelés lots.)
Contrairement aux rollups optimistes, grâce aux ZKPs (par exemple ZK-SNARKs ou ZK-STARKs), les rollups ZK peuvent valider la bonne exécution de milliers de transactions en vérifiant une simple preuve, sans avoir à rejouer toutes les transactions. Mais alors, qu’est-ce qu’un ZKP exactement, et quelles sont ses caractéristiques ?
Deux attributs des ZKPs : connaissance nulle et concision
Comme leur nom l’indique, un ZKP est fondamentalement une preuve. Une preuve peut être n’importe quelle information suffisante pour appuyer la déclaration du fournisseur. Supposons que Bob (le fournisseur) veuille convaincre Alice (le vérificateur) qu’il possède bien les droits d’accès à son ordinateur portable. La manière la plus simple de prouver cela serait que Bob donne simplement son mot de passe à Alice, qui le tape ensuite sur l’ordinateur pour vérifier que Bob a effectivement accès. Cependant, ce processus de vérification est insatisfaisant pour Alice et Bob. Si Bob utilise un mot de passe très long et complexe, il sera extrêmement difficile pour Alice de le saisir correctement (en supposant qu’elle ne puisse pas copier-coller). Plus réaliste encore, Bob pourrait ne pas vouloir divulguer son mot de passe à Alice pour prouver ses droits.
Et s’il existait un moyen de vérification où Alice pourrait rapidement confirmer l’accès à l’ordinateur sans que Bob ne révèle son mot de passe ? Par exemple, Bob pourrait déverrouiller l’ordinateur devant Alice via reconnaissance d’empreinte digitale, comme illustré à la figure 3 (notez que ce n’est pas un exemple parfait de ZKP). C’est là que les deux propriétés clés des ZKPs entrent en jeu : l’attribut de connaissance nulle et l’attribut de concision.
Figure 3 : Intuition générale de la connaissance nulle et de la concision
Source : imgflip
Connaissance nulle (ZK)
La propriété de connaissance nulle signifie que la preuve générée par le fournisseur ne révèle aucune information sur les données secrètes (le témoin privé), à l’exception de la validité même de la preuve, laissant ainsi le vérificateur ignorant des données. Dans la blockchain, cette propriété peut servir à protéger la confidentialité des utilisateurs individuels. Si les ZKPs sont appliqués à chaque transaction, un utilisateur peut prouver la légitimité de ses actions (par exemple, disposer de fonds suffisants pour une transaction) sans exposer les détails de sa transaction (transferts, mises à jour de solde, déploiement et exécution de contrats intelligents) au public.
Concision
La propriété de concision signifie que les ZK peuvent produire une preuve courte et rapidement vérifiable à partir d’une déclaration volumineuse — autrement dit, ils compactent des éléments volumineux. Dans la blockchain, cette propriété est particulièrement utile pour les rollups. Grâce aux ZKPs, un validateur L2 peut soumettre à un vérificateur L1 une preuve concise attestant de l’exécution correcte des transactions (la validité de transactions atteignant le téraoctet peut être prouvée par une preuve de 10 à 100 Ko). Le vérificateur peut alors confirmer facilement la validité de l’exécution en quelques instants (entre 10 millisecondes et 1 seconde), sans avoir à rejouer toutes les transactions.
Les rollups ZK sont excellents, mais pas synonymes de confidentialité
Les caractéristiques des ZKPs mentionnées ci-dessus sont bien exploitées dans les rollups ZK. Bien que les vérificateurs ne puissent pas déduire les données transactionnelles initiales à partir des ZKPs reçus, la vérification d’une preuve concise leur permet de valider efficacement les affirmations du fournisseur (c’est-à-dire le nouvel état L2). Autrement dit, affirmer que les rollups ZK actuels respectent pleinement les propriétés de « connaissance nulle » et de « concision » est trompeur. Cela pourrait être vrai si l’on se concentre uniquement sur l’interaction entre fournisseur et vérificateur, mais les rollups ZK comportent d’autres composants, tels que le séquenceur, le fournisseur et les nœuds du rollup. La règle de « connaissance nulle » s’applique-t-elle aussi à eux ?
Le défi de garantir une confidentialité totale via des ZKPs dans n’importe quel rollup ZK vient du fait que des compromis peuvent survenir si certaines parties deviennent privées via ZK tandis que d'autres restent publiques. En repensant au cycle de vie des transactions dans les rollups ZK, la confidentialité est-elle préservée lorsque la transaction passe de l’utilisateur au séquenceur ? Et pour le fournisseur ? Ou encore, lorsque les lots L2 sont soumis à la couche DA, la confidentialité des informations de comptes individuels est-elle protégée ? Actuellement, ces conditions ne sont pas remplies.
Figure 4 : Fuites de confidentialité dans les rollups ZK
Source : Presto Research
Dans la plupart des rollups ZK dominants, le séquenceur ou le fournisseur (ou toute autre entité centralisée disposant d’autorisations élevées) voit clairement les détails des transactions, y compris les montants transférés, les mises à jour de soldes, les déploiements et exécutions de contrats. Pour donner un exemple simple, vous pouvez observer tous ces détails simplement en consultant l’explorateur de blocs de n’importe quel rollup ZK. En outre, imaginons qu’un séquenceur centralisé cesse brutalement ses activités, et qu’un autre nœud du rollup tente de restaurer l’état. Il récupérerait les données L2 publiées publiquement sur la couche DA (dans la plupart des cas, Ethereum L1) et reconstruirait l’état L2. Au cours de ce processus, tout nœud capable de rejouer les transactions L2 stockées sur la couche DA pourrait retrouver les informations relatives à l’état des comptes de chaque utilisateur.
Par conséquent, le terme « connaissance nulle » est actuellement mis en œuvre de façon fragmentée dans les rollups ZK. Bien que cela ne puisse pas être considéré comme erroné, il est clair que c’est différent de la perception courante selon laquelle « ZK signifie connaissance nulle égale à confidentialité totale ». Ce qui rend novateurs les rollups ZK actuels, c’est surtout l’utilisation de la propriété de « concision » plutôt que celle de « connaissance nulle » — à savoir exécuter des transactions hors chaîne et générer pour les vérificateurs une preuve concise leur permettant de valider rapidement et de manière évolutive l’exécution, sans avoir à la rejouer.
Pour cette raison, certains rollups ZK, comme Starknet, préfèrent s’appeler eux-mêmes « rollups d’efficacité » (validity rollups) afin d’éviter toute confusion, tandis que d’autres, comme Aztec, qui assurent une véritable confidentialité ZK, s’identifient comme des ZK-ZK rollups.
Examen approfondi de l'utilité des rollups ZK
Comme mentionné précédemment, la plupart des rollups ZK n’assurent pas pleinement la confidentialité ZK. Quel est donc notre prochain objectif ? Déployer massivement le ZK à chaque étape du rollup pour atteindre une confidentialité transactionnelle complète ? En réalité, ce n’est pas une question simple. Outre les progrès techniques importants nécessaires pour que la technologie mûrisse davantage, le ZK soulève encore des questions controversées tant sur le plan idéologique (par exemple, utilisation illégale de transactions privées) que pratique (est-ce vraiment utile ?). Étant donné que le débat sur les implications morales de la confidentialité transactionnelle complète sort du cadre de cet article, nous allons nous concentrer sur deux problèmes pratiques rencontrés par les rollups ZK dans les projets blockchain.
Premier point : la génération de ZKP peut constituer un goulot d’étranglement pour la finalité rapide
Abordons d’abord l’utilité intrinsèque des rollups ZK. Le principal argument de vente des rollups ZK est leur délai réduit de retrait d’actifs grâce à la « finalité rapide » des transactions, permise par les ZKP. Un TPS amélioré et des frais transactionnels faibles sont des avantages supplémentaires. Le domaine qui exploite le mieux ces caractéristiques des rollups ZK est celui du jeu, car les dépôts et retraits de monnaies internes sont fréquents, générant chaque seconde un grand volume de transactions.
Mais les rollups ZK peuvent-ils vraiment être considérés comme la meilleure pile technologique pour les jeux ? Pour répondre, nous devons approfondir le concept de « finalité rapide » dans les rollups ZK. Imaginons un utilisateur jouant à un jeu Web3 fonctionnant sur une pile technologique basée sur un rollup ZK. L'utilisateur échange un objet de jeu contre une monnaie virtuelle et souhaite 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 un nouvel engagement d’état du rollup, que le ZKP correspondant doit être soumis à la L1, et que la finalité de la preuve sur Ethereum L1 doit être attendue pour garantir l’irréversibilité de la transaction. Si tous ces processus pouvaient se produire instantanément, nous pourrions atteindre la « confirmation immédiate » vantée par les rollups ZK, permettant aux utilisateurs de retirer leurs actifs immédiatement.
Cependant, la réalité est loin de là. Selon les statistiques sur les temps de finalité fournies par L2beat pour différents rollups ZK, zkSync Era nécessite environ 2 heures, Linea environ 3 heures, et Starknet en moyenne environ 8 heures. La raison en est que la génération d’un ZKP prend du temps, et qu’inclure davantage de transactions dans un lot (c’est-à-dire une seule preuve) afin de réduire les frais entraîne un délai supplémentaire. Autrement dit, la vitesse de génération et de soumission des preuves constitue un goulot d’étranglement potentiel pour la finalité rapide des rollups ZK, ce qui pourrait nuire à l’expérience utilisateur dans les jeux Web3.
Figure 5 : La génération de ZKP peut être un goulot d’étranglement potentiel pour la finalité rapide des rollups ZK
Source : imgflip
En revanche, des chaînes optimisées pour les jeux comme Ronin (supportant des jeux Web3 tels que Pixels et Axie Infinity) offrent une finalité ultra-rapide, au prix d’une décentralisation et d’une sécurité réduites. Ronin n’est ni une chaîne basée sur ZK ni un rollup : c’est une blockchain EVM fonctionnant sous un algorithme de consensus PoA (Proof of Authority) + DPoS (Delegated Proof of Stake). Vingt-deux validateurs sont sélectionnés selon la quantité de parts déléguées, puis ces validateurs génèrent et valident les blocs selon un processus de vote exclusif entre eux (mode PoA). Ainsi, sur Ronin, les transactions atteignent très rapidement la finalité, sont presque instantanément incluses dans un bloc, et le temps de validation est très court. Après le hard fork Shillin, chaque transaction nécessite en moyenne 6 secondes pour être finalisée. Ronin parvient à tout cela sans utiliser de ZKP.
Bien sûr, Ronin présente aussi des inconvénients. Géré par des validateurs centralisés, il est relativement plus vulnérable aux attaques à 51 %. De plus, n’utilisant pas Ethereum comme couche de règlement, il ne bénéficie pas de la sécurité d’Ethereum. L’utilisation de ponts cross-chain comporte également des risques de sécurité. Mais du point de vue de l’utilisateur : cela leur importe-t-il vraiment ? Les rollups ZK actuels sans séquencement décentralisé ont aussi un point de défaillance unique (SPOF). Ethereum leur apporte une garantie en réduisant la probabilité de rollback des transactions, mais si le séquenceur ou le vérificateur centralisé tombe en panne, les rollups ZK peuvent geler. Encore une fois, le « ZK » dans les rollups ZK sert uniquement à valider la correction de l’exécution. S’il existait un autre projet offrant la même fonctionnalité mais plus rapidement et à moindre coût, les rollups ZK pourraient ne plus être la technologie de prédilection pour les utilisateurs et développeurs de jeux Web3.
Deuxième point : la publication des différences d’état est une arme à double tranchant
Un autre aspect concerne l’utilité pratique des protocoles de rollup ZK. Ici, nous nous concentrons sur la publication des différences d’état, une méthode utilisée dans les rollups ZK pour assurer la disponibilité des données (voir Unlocking Dencun Upgrade: Unseen Truth of Scaling DA Layers, Jaehyun Ha, 12Avr24).
Une manière simple de comprendre la disponibilité des données dans les rollups consiste à imaginer un alpiniste amateur qui veut prouver et enregistrer son ascension de l’Everest. La méthode la plus simple serait d’enregistrer en vidéo chaque pas depuis le camp de base jusqu’au sommet. Bien que le fichier vidéo puisse être volumineux, n’importe qui pourrait vérifier l’ascension et potentiellement rejouer l’enregistrement. Cette analogie correspond à la méthode de publication des données transactionnelles brutes. Les rollups optimistes suivent cette approche afin qu’un challenger puisse rejouer et vérifier l’exécution correcte, car l’engagement d’état du séquenceur ne peut pas être entièrement fiable. Dans les rollups ZK, Polygon zkEVM et Scroll adoptent cette méthode, stockant sous forme compressée sur la L1 les données brutes des transactions L2, afin que quiconque puisse, si nécessaire, rejouer les transactions L2 pour restaurer l’état du rollup.
Toujours dans l’analogie de l’alpiniste amateur, une autre méthode de vérification pourrait consister à ce qu’un alpiniste célèbre accompagne l’amateur lors de l’ascension, prouvant ainsi au monde que l’exploit a bien eu lieu. Comme l’ascension est attestée par une personne de confiance, l’alpiniste n’a plus besoin d’enregistrer chaque pas. Il lui suffit de prendre une photo au départ et une autre au sommet, et les autres croiront qu’il a atteint le sommet. Cette analogie illustre la méthode de publication des différences d’état. Dans les rollups ZK, zkSync Era et StarkNet utilisent cette méthode, stockant uniquement sur la L1 les différences d’état avant et après l’exécution des transactions L2, permettant à quiconque de recalculer l’état à partir de l’état initial si nécessaire.
Figure 6 : Publication des données brutes vs publication des différences d’état
Source : Presto Research
Cette méthode par différences d’état est indéniablement avantageuse en termes de coût par rapport à la publication des données brutes, car elle évite de stocker les transactions intermédiaires, réduisant ainsi les coûts de stockage sur la L1. Cependant, elle comporte un défaut potentiel : elle n’autorise pas la restauration de l’historique complet des transactions L2, ce qui peut poser problème pour certains DApps.
Prenons l’exemple du protocole DeFi Compound, hypothétiquement construit sur une pile technologique de rollup ZK basée sur les différences d’état. Ces protocoles ont besoin de l’historique complet des transactions pour calculer chaque seconde les taux d’offre et d’emprunt. Mais que se passe-t-il si le séquenceur du rollup ZK tombe en panne et qu’un autre nœud tente de restaurer l’état le plus récent ? Il pourrait restaurer l’état, mais les taux seraient alors restaurés de manière inexacte, car il ne pourrait suivre que les instantanés entre les lots, et non chaque transaction intermédiaire.
Conclusion
Cet article affirme principalement que le « ZK » est largement absent de la plupart des rollups ZK actuels, et que dans de nombreux cas, l'utilisation de ZKP et de procédés ZK dans les DApps n'est pas le meilleur choix. La technologie ZK pourrait sembler injustement accusée, car elle-même n’a rien de problématique ; c’est plutôt dans son application que peuvent surgir des baisses de performance pour les DApps. Cependant, cela ne signifie pas que la technologie ZK est inutile pour le secteur. Lorsque les ZKPs et les rollups ZK atteindront leur maturité technique, ils pourront certainement offrir de meilleures solutions au dilemme de la blockchain. En réalité, certains projets basés sur ZK assurent déjà une confidentialité conforme au principe ZK, et de nombreux types de DApps tirent déjà avantage efficacement des ZKP et des rollups ZK.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@presto_labs
