Discussion sur ZK/Optimistic Hybrid Rollup

Auteur : kelvinfichter ; Compilateur : MarsBit, MK

Je suis récemment devenu convaincu que l'avenir d'Ethereum Rollups est en fait un hybride des deux approches principales (ZK et Optimistic). Dans cet article, je vais essayer d'expliquer l'architecture de base de ce que j'envisage et d'expliquer pourquoi je pense que c'est la meilleure voie à suivre.

Je ne vais pas passer trop de temps à discuter de la nature de ZK ou Optimistic Rollups. Cet article suppose que vous avez déjà une compréhension décente de la façon dont ces choses fonctionnent. Vous n'avez pas besoin d'être un expert, mais vous devez au moins savoir ce qu'ils sont et comment ils fonctionnent à un niveau élevé. Si j'essayais de vous expliquer les Rollups, ce post serait très, très long. Bref, bonne lecture !

Commencez avec le cumul optimiste

Hybrid ZK/Optimistic Rollup a commencé comme Optimistic Rollup, qui est très similaire à l'architecture Bedrock d'Optimism. Bedrock vise une compatibilité maximale avec Ethereum ("EVM Equivalent"), et y parvient en exécutant un client d'exécution presque identique à un client Ethereum normal. Bedrock utilise le prochain modèle de séparation consensus/exécution client d'Ethereum, réduisant considérablement la variance de l'EVM (certaines modifications seront toujours nécessaires, mais nous pouvons gérer cela). Au moment où j'écris ceci, le diff Bedrock Geth est un commit +388 -30.

Comme tout bon Rollup, Optimism prend les données de bloc/transaction d'Ethereum, trie ces données de manière déterministe dans le client de consensus, puis 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 », nous donnant un équivalent EVM L2.

Bien sûr, nous devons maintenant également résoudre le problème de savoir comment dire de manière prouvable ce qui se passe à l'intérieur d'Ethereum Optimism. Sans cette fonctionnalité, les contrats ne peuvent pas prendre de décisions basées sur l'état d'optimisme. Cela signifierait que les utilisateurs peuvent déposer dans Optimism mais ne jamais pouvoir retirer leurs actifs. Bien que dans certains cas, un cumul unidirectionnel puisse être utile, en général, un cumul bidirectionnel est plus utile.

Nous pouvons dire à Ethereum l'état de tout Rollup en donnant un engagement à cet état et en prouvant que l'engagement a été généré correctement. Une autre façon de dire cela est que nous prouvons que le "programme Rollup" a été exécuté correctement. La seule vraie différence entre ZK et Optimistic Rollups est la forme de cette preuve. Dans ZK Rollup, vous devez donner une preuve ZK explicite que le programme est exécuté correctement. Dans Optimistic Rollup, vous faites des déclarations sur les promesses, mais pas de preuves explicites. D'autres utilisateurs peuvent contester vos affirmations et vous forcer à jouer à un jeu itératif où vous finirez par découvrir qui a raison.

Je n'entrerai pas dans trop de détails sur le jeu de défi Optimistic Rollup. Il convient de noter que l'état de l'art dans ce jeu consiste à compiler votre programme (Geth EVM + quelques parties marginales dans le cas d'Optimism) sur une architecture de machine simple comme MIPS. Nous le faisons parce que nous devons créer un interpréteur pour notre programme en chaîne, et il est beaucoup plus facile de créer 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 tout à fait 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 chaîne, vous devriez disposer d'un cumul optimal entièrement fonctionnel.

Converti en cumul ZK

Dans l'ensemble, je pense que les cumuls optimistes domineront pendant au moins les prochaines années. Certaines personnes pensent que les cumuls ZK finiront par dépasser les cumuls optimistes, mais je pense que cela peut être faux. Je pense que la simplicité et la flexibilité relatives des cumuls optimistes signifient aujourd'hui qu'ils peuvent être transformés en cumuls ZK au fil du temps. Si nous pouvons trouver un modèle qui le réalise, il n'y a vraiment aucune incitation forte à en déployer un moins flexible et plus fragile lorsque vous pouvez simplement le déployer sur un système Optimistic existant et l'appeler système ZK d'une journée de travail.

Par conséquent, mon objectif est de créer une architecture et une voie de migration afin que les systèmes Optimistic modernes existants (tels que Bedrock) puissent être transformés de manière transparente en systèmes ZK. Voici comment je pense que c'est non seulement possible, mais d'une manière qui va au-delà de l'approche zkEVM actuelle.

Nous commençons avec l'architecture de style Bedrock que j'ai décrite ci-dessus. Notez que j'ai (brièvement) expliqué comment Bedrock a un jeu de défi qui affirme le programme L2 (exécuter l'EVM + quelques trucs supplémentaires pour le transformer en un ZK Rollup

Dans l'ensemble, je pense que les cumuls optimistes domineront au cours des prochaines années. Il y a une opinion que ZK Rollup finira par dépasser Optimistic Rollup, mais je pense que cela peut être faux. Je pense que la simplicité et la flexibilité relatives des cumuls optimistes signifient qu'ils peuvent être transformés en cumuls ZK au fil du temps. Si nous pouvons trouver un modèle pour que cette transition se produise, il n'y a vraiment aucune incitation forte à déployer vers des systèmes ZK moins flexibles et plus sujets aux problèmes.

Par conséquent, mon objectif est de créer une architecture et une voie de migration qui permettent aux systèmes Optimistic modernes existants (tels que Bedrock) de passer de manière transparente aux systèmes ZK. Voici, je crois, un moyen non seulement de réaliser cette transition, mais de le faire d'une manière qui va au-delà de l'approche zkEVM d'aujourd'hui.

Nous commençons avec l'architecture de style Bedrock que j'ai décrite précédemment. Notez que j'ai (brièvement) expliqué comment Bedrock a un jeu de défi qui peut affirmer la validité de l'exécution d'un programme L2 (un programme MIPS exécutant l'EVM + quelques extras). L'un des principaux inconvénients de cette approche est que nous devons laisser un certain temps à un utilisateur pour détecter et contester avec succès une fausse proposition de résultat de programme. Cela ajoute un temps considérable au processus de retrait des actifs (actuellement 7 jours sur le réseau principal Optimism).

Cependant, notre L2 n'est qu'un programme exécuté sur une machine simple (MIPS). Il est tout à fait possible de construire un circuit ZK pour une machine 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 ça.

Pourquoi cette méthode fonctionne si bien

Note rapide : dans cette section, j'ai mentionné "zkMIPS", mais je l'utilise vraiment pour faire référence à n'importe quel zkVM "simple" générique.

zkMIPS est plus simple que zkEVM

Un énorme avantage de la construction d'un zkMIPS (ou zk[insérer un autre nom de machine]) au lieu de zkEVM est que l'architecture de la machine cible est simple et statique. EVM change fréquemment. Les prix du gaz changeront, les opcodes seront ajustés et des choses seront ajoutées ou supprimées. Et MIPS-V n'a pas changé depuis 1996. En ciblant zkMIPS, vous travaillez sur un espace à problème fixe. Vous n'avez pas besoin de modifier et éventuellement de ré-auditer votre circuit à chaque mise à jour de l'EVM.

zkMIPS est plus flexible que zkEVM

Un autre point de discorde clé est que zkMIPS est plus flexible que zkEVM. Avec zkMIPS, vous avez plus de flexibilité pour modifier le code client à volonté pour réaliser diverses optimisations ou améliorations de l'expérience utilisateur. Les mises à jour du client n'ont plus besoin d'être fournies avec les mises à jour du circuit. Vous pouvez également créer un composant de base qui peut être utilisé pour transformer n'importe quelle blockchain en un ZK Rollup, pas seulement Ethereum.

Votre question se transforme en temps de preuve

Le temps de preuve ZK é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 le temps de preuve global.

Mais la réduction des temps de preuve est un problème bien ancré dans l'espace Web2. Etant donné que l'architecture de la machine MIPS ne changera pas dans un avenir proche, nous pouvons fortement optimiser nos circuits et programmes de preuve sans nous soucier des changements EVM à un stade ultérieur. Je suis presque sûr que le bassin d'embauche d'ingénieurs en matériel capables d'optimiser un programme bien défini est au moins 10 (sinon 100) fois plus grand que le bassin d'embauche pour la construction et l'audit d'une cible zkEVM en constante évolution. Une entreprise comme Netflix a probablement beaucoup d'ingénieurs en matériel travaillant sur l'optimisation des puces de transcodage, et ils accepteraient volontiers un tas d'argent VC pour relever un défi ZK intéressant.

Le temps de preuve initial pour un tel circuit peut dépasser la période de retrait de 7 jours du Rollup Optimiste. 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 Optimistic Rollup actuelle de 7 jours, et nous pouvons commencer le processus de défi pour envisager d'annuler Optimistic. Exécuter une preuve pendant 7 jours peut encore être trop cher, nous pourrions donc vouloir attendre un peu plus longtemps, mais le point est toujours valable. 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 immédiatement, et si pour une raison quelconque le programme de preuve échoue, nous pouvons revenir aux preuves optimistes. Une fois prêt, il est facile de passer aux épreuves ZK d'une manière totalement transparente pour l'application. Aucun autre système n'offre cette flexibilité et cette migration fluide.

Vous pouvez vous concentrer sur d'autres problèmes importants

Exécuter une blockchain est une tâche difficile, et cela implique non seulement d'écrire beaucoup de code backend. Une grande partie de ce que nous faisons chez Optimism est axée sur l'amélioration de l'expérience utilisateur et développeur grâce à des outils utiles côté client. Nous avons également passé beaucoup de temps et d'énergie à nous occuper des choses "douces": discuter des projets, comprendre les points faibles, concevoir des incitations. Plus vous passez de temps sur un logiciel blockchain, moins vous passez de temps à penser à ces autres choses. Vous pouvez toujours essayer d'embaucher plus de personnes, mais les organisations n'évoluent pas de manière linéaire et chaque nouvelle embauche ajoute au fardeau de la communication interne.

Étant donné que le travail de circuit ZK peut être ajouté à une chaîne de fonctionnement existante, vous pouvez travailler sur la construction de la plate-forme principale et du logiciel de preuve en parallèle. De plus, comme le client peut être modifié sans changer le circuit, vous pouvez séparer vos équipes client et attestation. Un cumul optimiste qui adopte cette approche pourrait avoir de nombreuses années d'avance sur les concurrents de ZK en termes d'activité réelle en chaîne.

** A **** QUELQUES CONCLUSIONS **

Pour être tout à fait franc, je ne vois aucun inconvénient significatif à cette approche en supposant que le prouveur zkMIPS puisse être optimisé de manière substantielle au fil du temps. Le seul impact réel que je vois sur l'application est que les coûts de gaz pour différents opcodes peuvent devoir être ajustés pour refléter le temps de preuve ajouté par ces opcodes. S'il est vraiment impossible d'optimiser ce prouveur à un niveau raisonnable, alors j'avoue être vaincu. S'il est réellement possible d'optimiser ce prouveur, alors l'approche zkMIPS/zkVM semble être tellement meilleure que l'approche zkEVM actuelle qu'elle pourrait complètement rendre cette dernière obsolète. 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.