Titre original : "OP+ZK, Hybrid Rollup deviendra-t-il le futur ultime de l'expansion d'Ethereum ?" "
Message original par @kelvinfichter
Compilation originale : Jaleel, BlockBeats
Je suis récemment devenu assez convaincu que l'avenir d'Ethereum Rollup est en fait un hybride des deux approches principales, ZK et Optimistic. Dans cet article, je vais essayer d'exposer les bases de ce que j'imagine être cette architecture, et pourquoi je pense que c'est la direction que nous devrions prendre. Notez que je passe la plupart de mon temps à travailler sur Optimism, alias Optimistic Rollup, mais je ne suis pas un expert ZK. Si j'ai fait des erreurs en parlant de ZK, n'hésitez pas à me contacter et je les corrigerai.
Je n'ai pas l'intention de décrire en détail le principe de fonctionnement de ZK et des Rollups optimistes dans cet article. Si je passe du temps à expliquer l'essence des Rollups, alors cet article sera trop long. Cet article est donc basé sur le fait que vous avez déjà une certaine compréhension de ces technologies.Bien sûr, vous n'avez pas besoin d'être un expert, mais vous devez au moins savoir ce que sont ZK et Optimistic Rollups et leur mécanisme de fonctionnement général. En tout cas, bonne lecture de cet article.
Commençons par le cumul optimiste
Le système qui mélangeait ZK et Optimistic Rollup était à l'origine basé sur Optimistic Rollup basé sur l'architecture Bedrock d'Optimism. Bedrock est conçu pour être compatible au maximum ("équivalent EVM") avec Ethereum en exécutant un client d'exécution presque identique au client Ethereum. Bedrock tire parti du prochain modèle de partage client consensus/exécution d'Ethereum, réduisant considérablement l'écart par rapport à l'EVM (bien sûr, il y aura toujours des changements en cours de route, mais nous pouvons le gérer).
Comme tous les bons Rollups, Optimism extrait les données de bloc/transaction d'Ethereum, puis trie ces données de manière déterministe dans le client de consensus, et transmet ces données au client d'exécution L2 pour exécution. Cette architecture résout la première moitié du puzzle du « cumul idéal » et nous donne un équivalent L2 à l'EVM.
Bien sûr, le problème que nous devons encore résoudre maintenant est de dire à Ethereum ce qui s'est passé à l'intérieur d'Optimism de manière vérifiable. Si ce problème n'est pas résolu, les contrats intelligents ne peuvent pas prendre de décisions basées sur l'état d'optimisme. Cela signifie que les utilisateurs peuvent déposer sur Optimism, mais ne peuvent pas retirer leurs actifs. Bien que le cumul unidirectionnel soit possible dans certains cas, dans la plupart des cas, le cumul bidirectionnel est plus efficace.
En fournissant une sorte d'engagement à cet état et une preuve que cet engagement est correct, nous pouvons communiquer l'état de tous les Rollups à Ethereum. En d'autres termes, nous prouvons que le "programme Rollup" a été exécuté correctement. La seule différence substantielle entre ZK et Optimistic Rollups est la forme de cette preuve. Dans ZK Rollup, vous devez fournir une preuve explicite de connaissance nulle pour prouver l'exécution correcte du programme. Dans Optimistic Rollup, vous pouvez faire une déclaration sur la promesse sans fournir de preuves claires. En contestant et en remettant en question votre déclaration, d'autres utilisateurs peuvent vous forcer à participer à un "jeu" de délibération et de défi pour déterminer qui est finalement Oui.
Je ne vais pas entrer dans les détails des défis de Optimistic Rollup. Il convient de noter que l'état de l'art à ce stade consiste à compiler votre programme (Geth EVM + quelques bits marginaux dans le cas d'Optimism) sur une architecture de machine simple comme MIPS. Nous faisons cela parce que nous devons construire un interpréteur de programme en chaîne, et il est beaucoup plus facile de construire un interpréteur MIPS qu'un interpréteur EVM. L'EVM est également une cible mouvante (nous avons des fourches de mise à niveau régulières) et ne couvre pas entièrement les programmes que nous voulons prouver (il y a aussi des éléments non-EVM).
Une fois que vous avez créé un interpréteur en chaîne pour votre architecture de machine simple et créé des outils hors ligne, vous devriez disposer d'un cumul optimal entièrement fonctionnel.
Passez à ZK Rollup
Dans l'ensemble, je crois fermement que les cumuls optimistes domineront au cours des prochaines années. Certaines personnes pensent que ZK Rollups finira par dépasser les Optimistic Rollups, mais je ne suis pas d'accord avec ce point de vue. Je pense que la simplicité et la flexibilité relatives actuelles des Optimistic Rollups signifient qu'ils peuvent être progressivement transformés en ZK Rollups. Si nous pouvons trouver un modèle pour effectuer cette transition, alors au lieu d'essayer de construire un écosystème ZK plus rigide et fragile, nous pouvons simplement nous déployer dans un écosystème Optimistic Rollup déjà existant.
Mon objectif est donc de créer une architecture et une voie de migration qui permettent à un écosystème OP moderne existant (comme Bedrock) de passer de manière transparente à un écosystème ZK. Je crois que ce n'est pas seulement possible, mais un moyen d'aller au-delà de l'approche zkEVM actuelle.
Commençons par l'architecture Bedrock que j'ai décrite précédemment. Notez que j'ai expliqué (brièvement) que Bedrock a un jeu de défi pour vérifier la validité de certaines exécutions de programmes L2 (programmes MIPS exécutant l'EVM + quelques trucs supplémentaires). Un inconvénient majeur de cette approche est que nous devons accorder une période de temps aux utilisateurs pour avoir une chance de détecter et de contester avec succès une proposition de résultat de programme erronée. Cela ajoute un temps considérable au processus de retrait des actifs (7 jours sur le réseau principal actuel d'Optimism).
Cependant, notre L2 n'est rien de plus qu'un programme exécuté sur une machine simple telle que MIPS. Il nous est tout à fait possible de construire un circuit ZK pour un mécanisme aussi simple. Nous pouvons alors utiliser ce circuit pour prouver sans ambiguïté l'exécution correcte du programme L2. Sans apporter de modifications à la base de code actuelle de Bedrock, vous pouvez commencer à publier des preuves de validité pour Optimism. C'est aussi simple que cela en pratique.
Pourquoi cette méthode est-elle fiable ?
Juste une petite clarification : bien que dans cette section, je mentionne « zkMIPS », je l'entends en fait comme un terme pour toutes les machines virtuelles sans connaissance générales et simplifiées (zkVM).
zkMIPS est plus facile que zkEVM
Construire un zkMIPS (ou tout autre type de machine virtuelle zk) présente un avantage majeur par rapport à zkEVM : l'architecture de la machine cible est simple et statique. L'EVM change fréquemment, les prix du gaz s'ajustent, les opcodes changent et des éléments sont ajoutés ou supprimés. Et MIPS-V n'a pas changé depuis 1996. Concentrez-vous sur zkMIPS et vous avez affaire à un espace à problème fixe. Vous n'avez pas besoin de modifier ni même de ré-auditer votre circuit à chaque mise à jour de l'EVM.
zkMIPS est plus flexible que zkEVM
Une autre idée clé est que zkMIPS est plus flexible que zkEVM. Avec zkMIPS, vous pouvez modifier le code client à volonté, effectuer diverses optimisations ou améliorer l'expérience utilisateur sans mises à jour de circuit correspondantes. Vous pouvez même créer un composant de base qui transforme n'importe quelle blockchain en un ZK Rollup, pas seulement Ethereum.
Votre mission se transforme en temps d'épreuve
Le temps des preuves à connaissance nulle évolue selon deux axes : le nombre de contraintes et la taille du circuit. En nous concentrant sur les circuits d'une machine simple comme MIPS (plutôt que sur une machine plus complexe comme l'EVM), nous avons pu réduire considérablement la taille et la complexité du circuit. Cependant, le nombre de contraintes dépend du nombre d'instructions machine exécutées. Chaque opcode EVM est décomposé en plusieurs opcodes MIPS, ce qui signifie que le nombre de contraintes augmente considérablement, tout comme votre temps de preuve global.
Cependant, la réduction des temps de preuve est également un problème profondément enraciné dans le domaine Web2. Étant donné qu'il est peu probable que l'architecture de la machine MIPS change de sitôt, nous pouvons optimiser fortement le circuit et le prouveur indépendamment des modifications futures de l'EVM. Je me sens assez confiant dans l'embauche d'un ingénieur matériel senior pour optimiser un problème bien défini, peut-être dix ou même cent fois le nombre d'ingénieurs construisant et examinant une cible zkEVM mobile. Une entreprise comme Netflix a probablement un grand nombre d'ingénieurs en matériel optimisant les puces de transcodage, et ils sont probablement prêts à dépenser un tas de fonds de capital-risque pour relever cet intéressant défi ZK.
Le temps de preuve initial pour un circuit comme celui-ci peut dépasser la période de retrait de 7 jours Optimistic Rollup. Ce temps de preuve ne fera que diminuer avec le temps. En introduisant des ASIC et des FPGA, nous pouvons considérablement accélérer le temps de preuve. Avec un objectif statique, nous pouvons construire des démonstrateurs plus optimaux.
Finalement, le temps de preuve pour ce circuit sera inférieur à la période de retrait actuelle de 7 jours pour l'optimisme, et nous pouvons commencer le processus de défi pour envisager de supprimer l'optimisme. Faire fonctionner un prouveur pendant 7 jours est probablement encore trop cher, nous pourrions donc souhaiter attendre un peu plus longtemps, mais le point est tenable. Vous pouvez même exécuter les deux systèmes de preuve en même temps, afin que nous puissions commencer à utiliser les preuves ZK aussi rapidement que possible et revenir aux preuves Optimisme si le prouveur échoue pour une raison quelconque. Lorsqu'elles sont prêtes, les épreuves Optimisme peuvent être supprimées d'une manière totalement transparente pour l'application, de sorte que votre cumul optimiste devient un cumul ZK.
Vous pouvez aller vous occuper d'autres problèmes importants
L'exécution d'une blockchain est un problème complexe qui implique plus que la simple écriture de beaucoup de code backend. Chez Optimism, une grande partie de notre travail est axée sur l'amélioration de l'expérience utilisateur et développeur en fournissant des outils utiles côté client. Nous consacrons également beaucoup de temps et d'énergie aux problèmes "soft": avoir des conversations avec les projets, comprendre leurs points faibles et concevoir des incitations. Plus vous passez de temps sur le logiciel de la chaîne, moins vous avez de temps pour vous occuper de ces autres choses. Bien que vous puissiez toujours essayer d'embaucher plus de personnes, les organisations n'évoluent pas de manière linéaire et chaque nouvelle embauche augmente les coûts de communication interne.
Étant donné que le travail du circuit de connaissance zéro peut être directement appliqué à la chaîne qui est déjà en cours d'exécution, vous pouvez construire la plate-forme principale et développer le logiciel de preuve en même temps. Comme le client peut être modifié sans changer le circuit, vous pouvez découpler votre client et votre équipe de preuve. Un cumul optimiste de cette manière pourrait avoir des années d'avance sur les concurrents sans connaissance en termes d'activité réelle sur la chaîne.
en conclusion
Franchement, je ne vois aucun inconvénient significatif au prouveur zkMIPS, à moins qu'il ne puisse pas être optimisé de manière significative au fil du temps. Le seul impact réel que je vois sur l'application est que le coût du gaz de différents opcodes peut devoir être ajusté pour refléter l'augmentation du temps de preuve pour ces opcodes. S'il n'est vraiment pas possible d'optimiser ce prouveur à un niveau raisonnable, alors j'avoue que j'ai échoué. Mais s'il est possible d'optimiser ce prouveur, alors l'approche zkMIPS/zkVM peut complètement remplacer l'approche zkEVM actuelle. Cela peut sembler une déclaration radicale, mais il n'y a pas si longtemps, les preuves d'échec optimistes en une étape ont été complètement remplacées par des preuves en plusieurs étapes.
Lien d'origine
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Le mélange de ZK et OP sera-t-il l'avenir d'Ethereum Rollup ?
Titre original : "OP+ZK, Hybrid Rollup deviendra-t-il le futur ultime de l'expansion d'Ethereum ?" "
Message original par @kelvinfichter
Compilation originale : Jaleel, BlockBeats
Je suis récemment devenu assez convaincu que l'avenir d'Ethereum Rollup est en fait un hybride des deux approches principales, ZK et Optimistic. Dans cet article, je vais essayer d'exposer les bases de ce que j'imagine être cette architecture, et pourquoi je pense que c'est la direction que nous devrions prendre. Notez que je passe la plupart de mon temps à travailler sur Optimism, alias Optimistic Rollup, mais je ne suis pas un expert ZK. Si j'ai fait des erreurs en parlant de ZK, n'hésitez pas à me contacter et je les corrigerai.
Je n'ai pas l'intention de décrire en détail le principe de fonctionnement de ZK et des Rollups optimistes dans cet article. Si je passe du temps à expliquer l'essence des Rollups, alors cet article sera trop long. Cet article est donc basé sur le fait que vous avez déjà une certaine compréhension de ces technologies.Bien sûr, vous n'avez pas besoin d'être un expert, mais vous devez au moins savoir ce que sont ZK et Optimistic Rollups et leur mécanisme de fonctionnement général. En tout cas, bonne lecture de cet article.
Commençons par le cumul optimiste
Le système qui mélangeait ZK et Optimistic Rollup était à l'origine basé sur Optimistic Rollup basé sur l'architecture Bedrock d'Optimism. Bedrock est conçu pour être compatible au maximum ("équivalent EVM") avec Ethereum en exécutant un client d'exécution presque identique au client Ethereum. Bedrock tire parti du prochain modèle de partage client consensus/exécution d'Ethereum, réduisant considérablement l'écart par rapport à l'EVM (bien sûr, il y aura toujours des changements en cours de route, mais nous pouvons le gérer).
Comme tous les bons Rollups, Optimism extrait les données de bloc/transaction d'Ethereum, puis trie ces données de manière déterministe dans le client de consensus, et transmet ces données au client d'exécution L2 pour exécution. Cette architecture résout la première moitié du puzzle du « cumul idéal » et nous donne un équivalent L2 à l'EVM.
Bien sûr, le problème que nous devons encore résoudre maintenant est de dire à Ethereum ce qui s'est passé à l'intérieur d'Optimism de manière vérifiable. Si ce problème n'est pas résolu, les contrats intelligents ne peuvent pas prendre de décisions basées sur l'état d'optimisme. Cela signifie que les utilisateurs peuvent déposer sur Optimism, mais ne peuvent pas retirer leurs actifs. Bien que le cumul unidirectionnel soit possible dans certains cas, dans la plupart des cas, le cumul bidirectionnel est plus efficace.
En fournissant une sorte d'engagement à cet état et une preuve que cet engagement est correct, nous pouvons communiquer l'état de tous les Rollups à Ethereum. En d'autres termes, nous prouvons que le "programme Rollup" a été exécuté correctement. La seule différence substantielle entre ZK et Optimistic Rollups est la forme de cette preuve. Dans ZK Rollup, vous devez fournir une preuve explicite de connaissance nulle pour prouver l'exécution correcte du programme. Dans Optimistic Rollup, vous pouvez faire une déclaration sur la promesse sans fournir de preuves claires. En contestant et en remettant en question votre déclaration, d'autres utilisateurs peuvent vous forcer à participer à un "jeu" de délibération et de défi pour déterminer qui est finalement Oui.
Je ne vais pas entrer dans les détails des défis de Optimistic Rollup. Il convient de noter que l'état de l'art à ce stade consiste à compiler votre programme (Geth EVM + quelques bits marginaux dans le cas d'Optimism) sur une architecture de machine simple comme MIPS. Nous faisons cela parce que nous devons construire un interpréteur de programme en chaîne, et il est beaucoup plus facile de construire un interpréteur MIPS qu'un interpréteur EVM. L'EVM est également une cible mouvante (nous avons des fourches de mise à niveau régulières) et ne couvre pas entièrement les programmes que nous voulons prouver (il y a aussi des éléments non-EVM).
Une fois que vous avez créé un interpréteur en chaîne pour votre architecture de machine simple et créé des outils hors ligne, vous devriez disposer d'un cumul optimal entièrement fonctionnel.
Passez à ZK Rollup
Dans l'ensemble, je crois fermement que les cumuls optimistes domineront au cours des prochaines années. Certaines personnes pensent que ZK Rollups finira par dépasser les Optimistic Rollups, mais je ne suis pas d'accord avec ce point de vue. Je pense que la simplicité et la flexibilité relatives actuelles des Optimistic Rollups signifient qu'ils peuvent être progressivement transformés en ZK Rollups. Si nous pouvons trouver un modèle pour effectuer cette transition, alors au lieu d'essayer de construire un écosystème ZK plus rigide et fragile, nous pouvons simplement nous déployer dans un écosystème Optimistic Rollup déjà existant.
Mon objectif est donc de créer une architecture et une voie de migration qui permettent à un écosystème OP moderne existant (comme Bedrock) de passer de manière transparente à un écosystème ZK. Je crois que ce n'est pas seulement possible, mais un moyen d'aller au-delà de l'approche zkEVM actuelle.
Commençons par l'architecture Bedrock que j'ai décrite précédemment. Notez que j'ai expliqué (brièvement) que Bedrock a un jeu de défi pour vérifier la validité de certaines exécutions de programmes L2 (programmes MIPS exécutant l'EVM + quelques trucs supplémentaires). Un inconvénient majeur de cette approche est que nous devons accorder une période de temps aux utilisateurs pour avoir une chance de détecter et de contester avec succès une proposition de résultat de programme erronée. Cela ajoute un temps considérable au processus de retrait des actifs (7 jours sur le réseau principal actuel d'Optimism).
Cependant, notre L2 n'est rien de plus qu'un programme exécuté sur une machine simple telle que MIPS. Il nous est tout à fait possible de construire un circuit ZK pour un mécanisme aussi simple. Nous pouvons alors utiliser ce circuit pour prouver sans ambiguïté l'exécution correcte du programme L2. Sans apporter de modifications à la base de code actuelle de Bedrock, vous pouvez commencer à publier des preuves de validité pour Optimism. C'est aussi simple que cela en pratique.
Pourquoi cette méthode est-elle fiable ?
Juste une petite clarification : bien que dans cette section, je mentionne « zkMIPS », je l'entends en fait comme un terme pour toutes les machines virtuelles sans connaissance générales et simplifiées (zkVM).
zkMIPS est plus facile que zkEVM
Construire un zkMIPS (ou tout autre type de machine virtuelle zk) présente un avantage majeur par rapport à zkEVM : l'architecture de la machine cible est simple et statique. L'EVM change fréquemment, les prix du gaz s'ajustent, les opcodes changent et des éléments sont ajoutés ou supprimés. Et MIPS-V n'a pas changé depuis 1996. Concentrez-vous sur zkMIPS et vous avez affaire à un espace à problème fixe. Vous n'avez pas besoin de modifier ni même de ré-auditer votre circuit à chaque mise à jour de l'EVM.
zkMIPS est plus flexible que zkEVM
Une autre idée clé est que zkMIPS est plus flexible que zkEVM. Avec zkMIPS, vous pouvez modifier le code client à volonté, effectuer diverses optimisations ou améliorer l'expérience utilisateur sans mises à jour de circuit correspondantes. Vous pouvez même créer un composant de base qui transforme n'importe quelle blockchain en un ZK Rollup, pas seulement Ethereum.
Votre mission se transforme en temps d'épreuve
Le temps des preuves à connaissance nulle évolue selon deux axes : le nombre de contraintes et la taille du circuit. En nous concentrant sur les circuits d'une machine simple comme MIPS (plutôt que sur une machine plus complexe comme l'EVM), nous avons pu réduire considérablement la taille et la complexité du circuit. Cependant, le nombre de contraintes dépend du nombre d'instructions machine exécutées. Chaque opcode EVM est décomposé en plusieurs opcodes MIPS, ce qui signifie que le nombre de contraintes augmente considérablement, tout comme votre temps de preuve global.
Cependant, la réduction des temps de preuve est également un problème profondément enraciné dans le domaine Web2. Étant donné qu'il est peu probable que l'architecture de la machine MIPS change de sitôt, nous pouvons optimiser fortement le circuit et le prouveur indépendamment des modifications futures de l'EVM. Je me sens assez confiant dans l'embauche d'un ingénieur matériel senior pour optimiser un problème bien défini, peut-être dix ou même cent fois le nombre d'ingénieurs construisant et examinant une cible zkEVM mobile. Une entreprise comme Netflix a probablement un grand nombre d'ingénieurs en matériel optimisant les puces de transcodage, et ils sont probablement prêts à dépenser un tas de fonds de capital-risque pour relever cet intéressant défi ZK.
Le temps de preuve initial pour un circuit comme celui-ci peut dépasser la période de retrait de 7 jours Optimistic Rollup. Ce temps de preuve ne fera que diminuer avec le temps. En introduisant des ASIC et des FPGA, nous pouvons considérablement accélérer le temps de preuve. Avec un objectif statique, nous pouvons construire des démonstrateurs plus optimaux.
Finalement, le temps de preuve pour ce circuit sera inférieur à la période de retrait actuelle de 7 jours pour l'optimisme, et nous pouvons commencer le processus de défi pour envisager de supprimer l'optimisme. Faire fonctionner un prouveur pendant 7 jours est probablement encore trop cher, nous pourrions donc souhaiter attendre un peu plus longtemps, mais le point est tenable. Vous pouvez même exécuter les deux systèmes de preuve en même temps, afin que nous puissions commencer à utiliser les preuves ZK aussi rapidement que possible et revenir aux preuves Optimisme si le prouveur échoue pour une raison quelconque. Lorsqu'elles sont prêtes, les épreuves Optimisme peuvent être supprimées d'une manière totalement transparente pour l'application, de sorte que votre cumul optimiste devient un cumul ZK.
Vous pouvez aller vous occuper d'autres problèmes importants
L'exécution d'une blockchain est un problème complexe qui implique plus que la simple écriture de beaucoup de code backend. Chez Optimism, une grande partie de notre travail est axée sur l'amélioration de l'expérience utilisateur et développeur en fournissant des outils utiles côté client. Nous consacrons également beaucoup de temps et d'énergie aux problèmes "soft": avoir des conversations avec les projets, comprendre leurs points faibles et concevoir des incitations. Plus vous passez de temps sur le logiciel de la chaîne, moins vous avez de temps pour vous occuper de ces autres choses. Bien que vous puissiez toujours essayer d'embaucher plus de personnes, les organisations n'évoluent pas de manière linéaire et chaque nouvelle embauche augmente les coûts de communication interne.
Étant donné que le travail du circuit de connaissance zéro peut être directement appliqué à la chaîne qui est déjà en cours d'exécution, vous pouvez construire la plate-forme principale et développer le logiciel de preuve en même temps. Comme le client peut être modifié sans changer le circuit, vous pouvez découpler votre client et votre équipe de preuve. Un cumul optimiste de cette manière pourrait avoir des années d'avance sur les concurrents sans connaissance en termes d'activité réelle sur la chaîne.
en conclusion
Franchement, je ne vois aucun inconvénient significatif au prouveur zkMIPS, à moins qu'il ne puisse pas être optimisé de manière significative au fil du temps. Le seul impact réel que je vois sur l'application est que le coût du gaz de différents opcodes peut devoir être ajusté pour refléter l'augmentation du temps de preuve pour ces opcodes. S'il n'est vraiment pas possible d'optimiser ce prouveur à un niveau raisonnable, alors j'avoue que j'ai échoué. Mais s'il est possible d'optimiser ce prouveur, alors l'approche zkMIPS/zkVM peut complètement remplacer l'approche zkEVM actuelle. Cela peut sembler une déclaration radicale, mais il n'y a pas si longtemps, les preuves d'échec optimistes en une étape ont été complètement remplacées par des preuves en plusieurs étapes.
Lien d'origine