Voir la table des matières Ne plus voir la table des matières
Matter Labs a annoncé le lancement du premier ZK Rollup compatible EVM sur le testnet public. Il s’agit d’une étape importante vers l’évolutivité sur Ethereum, car elle ouvre la possibilité de créer des DeFi (agents autonomes) sur des rollups alimentés par ZK.
Cet article est la suite de « DeFi on Bitcoin and private ZK Proofs », où nous explorerons le chaînon manquant entre les preuves à connaissance nulle (ZKP) et l’évolutivité de la couche 2, puis nous essaierons de comprendre de quoi d’autre nous avons besoin pour atteindre l’intimité.
La plupart des articles de ZKP commencent par l’exemple typique d’Alice détenant des informations secrètes précieuses et prouvant à Bob qu’elle connaît le secret sans révéler les données réelles. Ensuite, les articles techniques traitent des polynômes, des appariements de courbes elliptiques, des champs finis, des configurations de confiance, etc. Cet article restera à un niveau supérieur et se concentrera sur la façon dont ZKP peut être appliqué aux réseaux de couche 2.
Il est très rare de trouver une réponse à cette question, qui est, après tout, très pertinente, et la principale raison pour laquelle tant d’efforts ont été investis dans la recherche ZKP.
Remarque : Je suggère que le lecteur familier avec ZKP prenne un moment pour y réfléchir, puis compare les notes à la fin de la section.
Pour répondre à la question, nous analyserons une conception de réseau de couche 2 typique qui regroupe les transactions et utilise ZKP pour réduire le calcul effectué sur la chaîne principale.
Les nœuds de couche 2 reçoivent les transactions signées des utilisateurs, les traitent par lots et calculent l’état après le lot. Au lieu de simplement publier le résultat, ces nœuds calculeront un ZKP qui prouve qu’ils possèdent bien un ensemble de transactions utilisateur signées qui font avancer l’état à la nouvelle valeur valide.
Le ZKP ne peut être généré que si le prouveur a utilisé les transactions autorisées par les utilisateurs finaux comme entrée du calcul. Le prouveur peut garder les transactions elles-mêmes secrètes.
Pour le dire différemment, le nœud de couche 2 de preuve (Alice de l’exemple) a reçu un ensemble de transactions valides (signées) qui mettent à jour certains soldes. Elle calcule alors une preuve qu’elle « connaît » bien ces transactions. Ce ZKP convainc tout vérificateur (comme Bob) que l’état résultant est correct sans avoir besoin de voir les transactions. Si Alice n’avait pas utilisé ces transactions valides comme entrées, elle n’aurait pas été en mesure de créer la preuve.
La preuve est soumise à la chaîne principale avec les changements d’état. Le smart contract le vérifie ensuite (sans voir les transactions) et enregistre l’avance en l’état. La vérification de la preuve équivaut donc à exécuter les transactions réelles et à calculer l’état de sortie résultant.
Cette approche atteint l’évolutivité si la preuve est « succincte », ce qui rend moins coûteux de vérifier la preuve générée pour un lot de transactions que d’exécuter chaque transaction.
La solution décrite ci-dessus peut assurer une certaine confidentialité puisque les transactions des utilisateurs ne sont pas publiées dans la chaîne publique de couche 1. Pourtant, les transactions elles-mêmes ne sont pas privées lors du traitement par les nœuds de la couche 2, et l’état est public et visible par tout le monde.
Pouvons-nous atteindre une meilleure confidentialité?
Dans l’article précédent, nous avons essayé de créer une application DeFi (ou agent autonome) sur un réseau « verify-only », et il s’est avéré que nous ne pouvions pas la rendre évolutive.
Nous allons maintenant essayer de construire une couche 2 entièrement respectueuse de la vie privée qui prend en charge DeFi.
Rappel : Plus communément appelé « contrat intelligent », un « Agent Autonome » (AA) est un programme qui s’exécute sur une plate-forme décentralisée qui peut accumuler et contrôler n’importe quelle valeur du grand livre et, plus important encore, a le pouvoir de distribuer cette valeur uniquement sur la base d’une logique prévisible codée.
Remarque : Pour le reste de cet exercice, nous supposerons qu’une implémentation ZK VM viable qui peut générer des preuves pour n’importe quel programme est disponible. Sans lui, il est impossible d’exécuter le code de l’AA.
À un niveau élevé, le problème que nous voulons résoudre est de garder les transactions des utilisateurs et l’état qui en résulte privés. Cela signifie qu’il doit être visible uniquement pour les utilisateurs eux-mêmes et pour personne d’autre.
Il s’avère que cette tâche est très similaire à la création d’un AA sur un réseau de vérification uniquement. Veuillez passer quelques minutes à lire rapidement notre tentative de le faire.
Appliquons maintenant le même principe en utilisant la VM ZK disponible.
La configuration est que nous avons le code d’un AA (disons un DEX) exécuté sur la machine virtuelle ZK, et il existe un réseau de nœuds de couche 2.
L’approche linéaire
Le moyen le plus simple d’assurer la confidentialité consiste pour chaque utilisateur à exécuter le code AA et à créer une preuve sans connaissance sur son propre ordinateur ou téléphone. La preuve est aussi bonne que la transaction réelle, qui peut rester privée pour l’utilisateur.
Les lecteurs de l’article précédent se souviendront que nous avons décrit ce mécanisme exact et montré qu’il ne pouvait pas évoluer car les utilisateurs doivent se coordonner.
Dans notre cas, pour construire un ZKP, un utilisateur doit connaître l’état exact de l’AA tel qu’il était après l’utilisateur précédent.
Outre le problème de coordination non évolutive, le partage de l’état après chaque calcul est plus complexe car il doit également rester privé.
Il est prudent de conclure que l’approche linéaire est une impasse.
L’approche par lots
Nous avons décrit cette approche dans la première partie de l’article lors de la conception pour l’évolutivité. Nous avons conclu qu’il ne pouvait pas atteindre une confidentialité satisfaisante car les opérateurs de nœuds de couche 2 ont accès aux transactions des utilisateurs car ils doivent les traiter.
Nous pouvons l’améliorer en introduisant des opérateurs spécifiques à l’application pour éviter que tout le monde ne voie toutes les transactions.
C’est nettement mieux puisque le nombre de parties qui voient les transactions est plus faible mais encore très loin d’être idéal.
De plus, pour des raisons de disponibilité des données, les soldes des comptes doivent être publiés à la vue de tous.
L’approche par lots est également une impasse à moins que nous ne trouvions un moyen d’empêcher les nœuds de couche 2 de lire les transactions des utilisateurs.
Le cryptage est une façon d’assurer la confidentialité. Les utilisateurs finaux pourraient soumettre des transactions cryptées, et les nœuds ne devraient pouvoir calculer le ZKP que sur ces transactions et rien d’autre.
Si une telle solution technique existait, avec une machine virtuelle ZK viable, elle résoudrait à la fois la confidentialité et l’évolutivité.
Cela fonctionnerait comme suit : les utilisateurs créent des transactions cryptées pour interagir avec l’AA. Ils envoient ces transactions aux nœuds de la couche 2 qui les regroupent, les traitent sous forme chiffrée et enfin génèrent le nouvel état et le ZKP. Une fois soumis à la couche 1, le contrat intelligent cumulatif vérifiera la preuve et mettra à jour l’état sans avoir besoin de voir les transactions.
Le lecteur remarquera peut-être que cela ne suffit toujours pas pour obtenir une confidentialité totale puisque l’état (soldes des comptes) est visible par tout le monde, car il est publié sur la couche 1, même si les nœuds ne peuvent pas décrypter les transactions.
L’état doit également être chiffré lorsqu’il est soumis au réseau de couche 1 pour résoudre ce problème. Il doit être traité avec les transactions cryptées mais non visible autrement.
La bonne nouvelle est que l’informatique confidentielle basée sur le matériel peut aider à résoudre tous ces problèmes, et c’est dans cette direction que se dirige le projet sur lequel je travaille, Obscuro. Vous pouvez lire le livre blanc ici.
Outre le traitement des transactions cryptées, il existe d’autres défis importants à surmonter pour créer une solution décentralisée qui assure la confidentialité et la sécurité. Bien sûr, le défi le plus important est qu’aucun viable ZK VM est encore disponible. Obscuro s’appuiera sur des incitations crypto-économiques pour atteindre la garantie de sécurité dans la première versionsimilaires aux cumuls optimistes comme Optimisme et Arbitrum.
Cet article a commencé par clarifier comment les preuves à connaissance nulle peuvent être utilisées pour atteindre l’évolutivité de la couche 2. Ensuite, nous avons utilisé les techniques de « DeFi on Bitcoin » pour découvrir le chaînon manquant nécessaire pour assurer la confidentialité sur les couches 2.
La réponse à la question du titre est que les solutions ZKP Layer 2 ne peuvent assurer la confidentialité que lorsqu’elles sont combinées avec une solution comme Obscuro.
Rejoindre Coinmonks Chaîne de télégramme et Chaîne Youtube en savoir plus sur le trading de crypto et l’investissement
