Explication détaillée du validateur de bloc Ethereum Zeth : le premier zkEVM de type 0

Titre original : Annonce de Zeth : le premier Type Zero zkEVM

Avec Tim Cartens, Victor Graf, Rami Khalil, Steven Li, Parker Thompson, Wolfgang Welz, Zeth Collaboration

Construction : bayemon.eth, ChainCatcher

Le 25 août, Zeth, le validateur de bloc ZK open source Ethereum basé sur RISC Zero zkVM, a été rendu public. Zeth effectue tout le travail nécessaire pour créer de nouveaux blocs dans zkVM sans compter sur des validateurs ou des comités de synchronisation. Zeth a été vérifié sur plusieurs blocs réels du réseau principal Ethereum et a réussi tous les tests pertinents de la suite de tests officielle Ethereum. Zeth a pu implémenter le support Rust basé sur zkVM et des cartes solides comprenant revm, éthers et alliage en 4 semaines. Grâce à la prise en charge par zkVM des services de continuité et de preuve Bonsai, Zeth peut générer ces preuves en quelques minutes. Grâce à la prise en charge de Zeth pour la vérification en chaîne, n'importe qui peut vérifier ces preuves en chaîne à faible coût. Dans cet article, nous entrerons plus en détail, mais si vous souhaitez approfondir le code, consultez le code source et visitez le portail des développeurs RISC Zero.

Résumé

Il y a environ un an, Vitalik a développé les différents types de zkEVM :

Ethereum n'a pas été conçu à l'origine pour être compatible avec ZK, de nombreuses parties du protocole Ethereum nécessitent donc beaucoup de calculs pour la vérification ZK. Un EVM de type 1 vise à répliquer entièrement Ethereum, il ne peut donc pas atténuer ces inefficacités. Actuellement, les preuves de blocs Ethereum prennent des heures.

Bien qu'il y ait eu des cas dans l'histoire d'Ethereum où cela a été possible, nous sommes ravis d'annoncer aujourd'hui que les preuves de blocage d'Ethereum utilisant les services zkVM et Bonsai de RISC Zero prennent quelques minutes, et non des heures.

Zeth : génération de blocs Ethereum vérifiables

Aujourd'hui, nous avons publié Zeth, un validateur de bloc ZK open source pour Ethereum sur RISC Zero zkVM.

Zeth peut prouver qu'un bloc Ethereum donné est valide sans s'appuyer sur des validateurs ou des comités de synchronisation. En effet, Zeth effectue tout le travail nécessaire pour générer de nouveaux blocs dans zkVM, notamment :

• Vérifier la signature de la transaction
• Validez le compte et l'état de stockage par rapport à la racine d'état du bloc parent.
• Transactions de candidature
• Payer des frais pour bloquer les auteurs.
• Mettre à jour la racine du statut
• Autres travaux nécessaires pour générer des blocs

Une fois un nouveau bloc généré, Zeth calcule et génère son hachage. En exécutant ce processus dans zkVM, nous pouvons obtenir des preuves ZK que les nouveaux blocs sont valides.

En tirant parti du zkVM de RISC Zero et des caisses Rust populaires telles que revm, ether et alliage, nous avons écrit la première version de Zeth en moins de 4 semaines. Avec la prise en charge de la continuité par zkVM et le service de preuve Bonsai, la génération de preuves peut être effectuée en quelques minutes seulement. Grâce à la prise en charge de la vérification en chaîne, nous pouvons vérifier ces preuves en chaîne à faible coût.

Zeth a été vérifié sur plusieurs blocs réels du réseau principal Ethereum et a réussi tous les tests pertinents de la suite de tests officielle Ethereum.

Puisque Zeth construit des blocs Ethereum standard, il peut être considéré comme un zkEVM de type 1. Mais c'est bien plus que cela : comme Zeth est construit à l'aide de tableaux de codes Rust standard (les mêmes tableaux de codes utilisés par les nœuds complets populaires comme Reth), nous préférons le considérer comme un zkEVM de classe 0 : compatibilité totale avec les protocoles et beaucoup de réutilisation du code. . **

Cette étape représente un grand pas en avant pour la technologie ZK et l’écosystème Ethereum. Dans cet article, nous discutons de la manière d'écrire la première version de Zeth dans quelques semaines, de ses performances, de son fonctionnement et de ce que cela signifie pour le projet ZK.

RISC Zero facilite la création de rollups zk, de zkEVM, de clients légers et de ponts

Nous avons écrit Zeth pour deux raisons :

1. Aidez les autres équipes à créer plus facilement leur propre infrastructure basée sur ZK : rollup ZK, zkEVM, client léger ZK, pont ZK, etc. Zeth fournit tout le nécessaire pour générer des preuves ZK pour les blocs basés sur EVM. Il s'agit d'un composant clé de tout zkEVM ou pont. Zeth est open source basé sur revm, les développeurs de projets peuvent donc facilement le modifier ou l'utiliser. Les preuves peuvent être vérifiées en chaîne (idéal pour les ponts et L2) ou dans une application locale (idéal pour les nœuds complets et les clients légers).
2. Mener des recherches connexes sur les performances EVM dans le zkVM de Zeth, en particulier les tâches liées à Ethereum. (Voir ci-dessous pour l’analyse des résultats de l’enquête).

zk rollup et zkEVM

En tant que zkEVM de type 0, Zeth permet aux développeurs de créer des cumuls zk avec une compatibilité EVM et Ethereum entièrement native. Couplé à la prise en charge de Zeth pour la vérification des preuves en chaîne, la création d'une solution d'extension L2 pilotée par ZK deviendra extrêmement simple.

Les cumuls ZK et les circuits zkEVM existants sont monolithiques de par leur conception et ne peuvent pas être mis à niveau sans qu'un développeur ait une compréhension approfondie de la cryptographie ZK. En revanche, l'approche Zeth basée sur zkVM permet à tout développeur de la personnaliser et de la modifier en fonction de ses besoins.

Zeth est open source basé sur revm, et peaufiner pour prendre en charge d'autres chaînes compatibles zkEVM et EVM est une tâche relativement simple. Par conséquent, Zeth aura une réponse relativement plus rapide aux futures mises à jour d’EIP. De plus, Zeth offre également une modularité, permettant aux développeurs d'y créer leur propre logique de construction de blocs.

Nous espérons que les efforts de Zeth démocratiseront zk rollup et zkEVM, sachant que les solutions L2 basées sur zk nécessitaient auparavant des années de recherche et de développement et plus de 100 millions de dollars de financement, ce qui est une consommation que la plupart des projets ne peuvent pas se permettre.

Client léger et pont

Il ne fait aucun doute que l’introduction de la chaîne de balises est une aubaine pour les clients légers et les ponts. Ces techniques s'appuient sur le modèle PoS désormais mature d'Ethereum, permettant aux clients légers et aux ponts de vérifier facilement les blocs récents sans les reconstruire, à condition que tout le monde respecte les règles.

Bien entendu, l’intérêt du jalonnement est de fournir des incitations économiques aux nœuds pour qu’ils respectent les règles. Cependant, la menace que Slashing impose aux nœuds ne peut pas complètement éviter le mal – les incitations externes au mal feront toujours pencher la « balance » des intérêts vers le mal – et il est très important de concevoir un client ou un pont léger capable de gérer correctement ces comportements malveillants. dur.

Avec des outils comme Zeth, le risque que les nœuds fassent du mal est considérablement réduit. Les clients légers peuvent s'intégrer à Zeth en ajoutant simplement quelques appels à zkVM ; les applications en chaîne telles que les ponts peuvent s'intégrer à Zeth à l'aide de notre contrat de vérification de preuve de preuve en chaîne.

Dans un futur proche, nous pouvons imaginer des clients légers et des ponts utilisant des preuves ZK pour déterminer si un bloc donné est valide. Cette approche réduirait considérablement les risques sans augmenter significativement le coût de validation des blocs.

Ceci est particulièrement important pour les chaînes d’applications, les écosystèmes modulaires et les nouvelles chaînes qui n’ont pas encore le même niveau de sécurité qu’offre la grande communauté de nœuds complets d’Ethereum.

Une bonne base simplifie le processus de développement de projet

Basé sur RISC Zero zkVM et alimenté par l'architecture de jeu d'instructions RISC-V, Zeth peut offrir aux développeurs une expérience de programmation familière. Mais notre zkVM est plus qu'un simple noyau RISC-V. Nous disposons également de circuits d'accélération pour les tâches cryptographiques courantes telles que le hachage et la vérification de signature.

Cette approche hybride (combinaison de cœurs CPU à usage général avec des circuits d'accélération) nous offre le meilleur des deux mondes :

• Prend en charge les langages de programmation traditionnels.
• Les performances des opérations cryptographiques critiques ne sont pas compromises.

En conséquence, nous avons pu créer rapidement Zeth en utilisant les packages de code Rust existants de revm, ether et alliage. En réutilisant des cartes existantes, nous avons réalisé la première version de Zeth en moins de 4 semaines. Ce type de vitesse n’est pas possible dans les écosystèmes moins matures.

En termes de performances, Zeth exploite nos circuits accélérateurs pour la vérification de la signature ECDSA ainsi que la continuité - une nouvelle fonctionnalité de notre framework ZK qui facilite l'utilisation de clusters de GPU fonctionnant en parallèle (en utilisant nVidia CUDA ou Apple Metal) pour prouver rapidement de grandes performances. calculs. Les continuations sont faciles à utiliser : cette fonctionnalité est fournie de manière transparente à tous les programmes invités exécutés dans zkVM, c'est-à-dire qu'aucune modification de code n'est requise pour qu'elle fonctionne correctement.

Avec notre zkVM, nous sommes en mesure de générer rapidement des preuves ZK de validité des blocs Ethereum en quelques minutes, et non en quelques heures.

Performance

Nous couvrirons les performances du générateur de blocs Zeth. Zeth est encore un nouveau produit, ces chiffres sont donc susceptibles de changer ; cependant, nous voulions fournir des chiffres concrets pour servir de base pour les travaux futurs.

En matière de performances, plusieurs facteurs doivent être pris en compte :

• Ressources informatiques nécessaires pour générer des preuves.
• Le « temps mur » nécessaire pour générer la preuve (c'est-à-dire combien de temps l'utilisateur doit attendre que la preuve soit disponible).
• Le coût total de génération des preuves (USD).

Continuité

Le zkVM de Zeth peut être optimisé pour ses performances en utilisant une exécution continue. Nous devons donc nous arrêter un instant et discuter du fonctionnement du « fonctionnement continu ».

Notre zkVM implémente des processeurs RISC-V standard. Par conséquent, l’exécution se mesure en cycles. (Dans notre circuit, la plupart des instructions RISC-V s'exécutent en 1 cycle, bien qu'il existe des exceptions). Les programmes simples ne nécessitent généralement que quelques centaines de milliers de cycles pour être exécutés, mais les programmes plus complexes peuvent nécessiter des milliards de cycles.

Dans un système ZK typique, ces cycles d'exécution sont regroupés dans une preuve ; à mesure que le nombre de cycles augmente, le temps et la mémoire requis pour générer la preuve augmentent également. Mais notre zkVM ne suit pas ces stéréotypes et, plus tôt cette année, nous avons lancé une nouvelle fonctionnalité de continuité qui améliore les inconvénients de la génération traditionnelle de schémas de preuve.

En termes de continuité, le processus de preuve est divisé en trois phases :

Nous effectuons les calculs requis dans un simulateur non-preuve. En cours de route, nous comptons le nombre de fois que la boucle a été exécutée jusqu'à présent. À intervalles configurables, nous prenons des instantanés de l'état du programme. Cela divise efficacement l’exécution en plusieurs parties. Chaque segment est petit et représente généralement 1 million de cycles ou moins.

Ces pièces sont affectées à un ensemble de travailleurs de génération de preuves. Ils génèrent des preuves ZK pour leurs segments de programme donnés. Surtout, ils peuvent le faire en parallèle. Tant qu'il y a suffisamment de travailleurs, tous les segments du programme peuvent être prouvés dans le temps requis pour prouver un segment du programme. En raison de la petite taille du segment de réseau, le temps nécessaire est généralement court (quelques dizaines de secondes).

Lorsque des preuves de segments sont générées, elles finissent par être cumulées. Chaque opération de « cumul » prend une paire de preuves segmentées consécutives et produit une nouvelle preuve pour la combinaison de ces segments. Par exemple, si le segment 1 prouve que le programme est passé de l'état A à l'état B et que le segment 2 prouve que le programme est passé de l'état B à l'état C, alors le cumul prouve que le programme est passé de l'état A à l'état C. Avec suffisamment de travailleurs, cela peut être fait en un temps log(N), où N est le nombre de fragments.

Nous verrons ces étapes en action lorsque nous examinerons les chiffres.

**Est-il difficile de construire un bloc Ethereum ? **

Examinons d’abord la complexité de la construction d’un bloc Ethereum. Dans le tableau ci-dessous, nous prenons quelques blocs Ethereum du monde réel et les reconstruisons à l'aide de Zeth dans zkVM.

Par exemple, le bloc 17606771 produit 2131 extensions. Chaque segment représente au plus 2^20 cycles d'exécution, donc l'ensemble du calcul prend au plus 2 234 515 456 cycles d'exécution.

En général, la construction d’un bloc Ethereum typique prend entre 2 et 400 millions de cycles, mais parfois jusqu’à 9,5 milliards de cycles. (Au début, nous avons été surpris de constater que ces différences ne se reflétaient pas dans le gaz de la transaction. Mais après y avoir réfléchi davantage, cela avait du sens : le système de gaz a été conçu dans un souci d'exécution régulière, et non de preuves ZK).

Avec continuité, cette échelle est facile à gérer. Selon ces chiffres, un réseau peer-to-peer de 10 000 nœuds exécutant des validateurs zkVM est suffisant pour atteindre les performances de validation parallèle les plus élevées pour les plus gros blocs, ce qui représente une fraction des 700 000 validateurs dont dispose actuellement Ethereum.

**Combien de temps faut-il pour générer une preuve ? **

Pour collecter des données de performances de base, nous avons lancé une instance de test Bonsai avec 64 GPU Workers. Nous lui avons ensuite demandé d'attester du bloc 17735424 (182 transactions, 3242 segments, soit environ 3,4 milliards de cycles) à l'aide de Zeth.

Pour générer des preuves, zkVM doit d'abord diviser l'exécution en segments. Dans la capture d'écran ci-dessous, ce processus a été capturé par la tâche utor, qui a duré 10 minutes. (La plupart de ce temps est consacré à des tâches AWS telles que l'écriture sur le stockage réseau). Sur la machine locale, la même tâche prend moins de 6 minutes. Nous espérons réduire considérablement ce délai au cours de l'année prochaine).

L'exécuteur testamentaire divise finalement l'exécution en 3242 morceaux. Cela représente beaucoup de fragmentation pour seulement 64 GPU. Par conséquent, chaque nœud travailleur doit générer 50 preuves de segments. Comme le montre la figure ci-dessous, cela prend 35 minutes. Si nous avons 50 fois plus de nœuds de travail, cela ne prend que 42 secondes.

Une fois la preuve de segment terminée, le cumul commence. Puisqu'il y a 3242 segments, nous devons effectuer un processus de cumul de log_2(3242) = 12 tours. Dans les premières étapes du cumul, il y a plus de travailleurs que de travailleurs ; la première étape prend donc 1 minute, la deuxième étape prend 35 secondes, la troisième étape prend 25 secondes, et ainsi de suite. Dès la septième étape, le temps s'est stabilisé à un peu plus de 5 secondes. De même, si nous avions plus de travailleurs, chaque étape ne prendrait que 5 secondes.

Une fois le cumul terminé, les résultats sont finalisés, ce qui prend encore une minute.

En conséquence, nous avons pu générer des épreuves en 50 minutes environ (vitesse effective de 1,1 MHz) avec une taille de cluster insuffisante. Si le cluster est correctement dimensionné, nous estimons que la génération des preuves sera plus rapide :

Dans le cas entièrement parallélisé, l'étape de preuve peut être complétée en 42 + 12 * 5 + 60 secondes ou 2 minutes et 42 secondes.

Si nous arrondissons prudemment et incluons le temps de l'exécuteur, le temps se situe entre 9 et 12 minutes (vitesse effective 4,7 MHz - 6,3 MHz).

Alors que nous continuons à améliorer nos exécuteurs testamentaires et notre cadre de preuve, nous sommes optimistes que ce temps sera considérablement réduit au cours de la prochaine année.

Consommation de ressources pour générer des preuves

Le cluster de test ci-dessus a été déployé sur AWS. Il se compose de 64 nœuds de preuve g5.xlarge et de 1 nœud d'exécution m5zn.xlarge. Selon Amazon, chaque nœud g5.xlarge possède

• 1 GPU avec 24 Go de mémoire GPU
• 4 vCPU avec une capacité mémoire de 16 Gio

Au moment d'écrire ces lignes, le prix à la demande pour ces instances est de 1,006 $/heure et celui des instances réservées est de 0,402 $/heure. Pendant ce temps, la fiche technique d'Amazon montre que notre nœud m5zn.xlarge a

• 4 processeurs virtuels, 16 Go de RAM

Au moment d'écrire ces lignes, le prix à la demande pour cette instance est de 0,3303 $/heure.

Nous pouvons utiliser ces chiffres pour estimer approximativement le coût de la preuve pour le bloc 17735424 décrit ci-dessus.

Rappelons que nous avons déployé 64 nœuds de preuve et dans ce déploiement il a fallu 50 minutes (de bout en bout) pour générer une preuve. En ignorant le temps d'inactivité des travailleurs, 64 nœuds de preuve plus un nœud d'exécution coûtent 50/60 * (64 * 0,402 + 0,3303) = 21,72 $ pour 50 minutes. Il s’agit d’une surestimation car cela suppose que nous payons des travailleurs inactifs. Si nous ne prenons pas en compte le coût de la mise au ralenti des travailleurs (par exemple, leur fermeture ou leur affectation à d'autres emplois), le coût est d'environ 19,61 $.

• Ce bloc contient 182 transactions, soit 0,11 $ par transaction.
• La valeur totale de la transaction est de 1,125045057 Eth, soit environ 2 137,59 $. Ainsi, chaque dollar de preuve rapporte 109,01 dollars de fonds aux utilisateurs.
• La récompense payée pour le même bloc est de 0,117623263003047027 Eth (hors frais de transaction). Au moment de la rédaction, cela représente environ 223,48 $. Par conséquent, nos épreuves coûtent environ 8,7 % de la récompense globale.
• Les frais de transaction s'élèvent à 0,03277635 Eth, soit 62,28 $, soit plus de 3 fois le coût de notre preuve.

Il convient de noter que ces estimations en dollars sont indépendantes de la taille de la grappe ! Ce qui compte, c'est le nombre de segments. En effet, 1 machine effectuant 2 tâches en séquence coûte le même prix que 2 machines effectuant 1 tâche en parallèle. Par conséquent, si la taille du cluster est plus grande, les preuves seront générées plus rapidement, mais pas plus cher.

Il existe plusieurs façons de réduire davantage les coûts. En plus de continuer à améliorer les performances de zkVM, en ajoutant peut-être un accélérateur Keccak, nous pouvons également rechercher des instances moins chères. Il est important de noter que, étant donné les machines peu performantes que nous utilisons (et notre zkVM prend en charge nVidia Cuda et Apple Metal), ce travail peut être facilement effectué sur un réseau p2p de PC et Mac grand public ordinaires.

Vérification en chaîne

Comme mentionné ci-dessus, nous avons vérifié les preuves Zeth sur Sepolia à l'aide du validateur RISC Zero Groth16. Il s'agit d'une partie relativement nouvelle de la pile de protocoles RISC Zero, publiée plus tôt ce mois-ci. Il fonctionne en utilisant Bonsai pour convertir la preuve STARK native de zkVM en une preuve SNARK équivalente et en soumettant cette preuve à un validateur SNARK en chaîne.

Si nous considérons l'entrée de transaction sous forme de données UTF-8, nous voyons que la preuve correspond au bloc 17735424.

En utilisant Bonsai, la conversion de STARK en SNARK prend environ 40 secondes. La vérification du SNARK en chaîne coûte 245 129 gaz (~ 5,90 $ au moment de la rédaction).

Bien entendu, l’un des avantages de zkVM est qu’il peut combiner plusieurs preuves en une seule. Avec cette fonctionnalité, tout un ensemble de preuves peuvent être vérifiées en chaîne sans utiliser de gaz supplémentaire. De cette façon, le coût de la vérification en chaîne peut être réparti sur l’ensemble des preuves, réduisant ainsi le coût pour tout le monde.

Ce que cela signifie pour Ethereum

Comme mentionné précédemment, Ethereum n’a pas été conçu dans un souci de compatibilité ZK. Comme le montre le cas des zkEVM, de nombreuses choses peuvent être faites de différentes manières, notamment en ce qui concerne les opcodes, les signatures numériques et les fonctions de hachage.

Même si ces changements ont amélioré les performances, nous avons quand même pu obtenir de solides performances sans ces changements. Lorsque Vitalik a écrit sur différents types de zkEVM l'année dernière, il fallait des heures pour prouver la validité d'un bloc Ethereum ; maintenant, nous pouvons le faire en quelques minutes. Les performances de ZK s’améliorent rapidement et nous avons des raisons de croire que cette tendance se poursuivra au cours des prochaines années.

Annexe : Comment fonctionne Zeth

Cette section est destinée aux développeurs.

En gros, Zeth construit des blocs de la même manière qu'un nœud complet : nous commençons par le bloc parent, la liste des transactions et l'auteur du bloc, puis effectuons beaucoup de calculs (vérifier les signatures, exécuter des transactions, mettre à jour l'état global, etc.), et enfin renvoyer la nouvelle valeur de hachage du bloc.

Mais contrairement aux nœuds complets, nous faisons cela dans zkVM. Cela signifie que nous obtenons une preuve ZK qu'un bloc avec un hachage donné est valide.

Bien sûr, cela n’est pas sans défis. Dans cette section, nous présentons ces défis et la manière dont nous les relevons.

Cryptographie

Le premier défi est la cryptographie. Construire un bloc Ethereum nécessite beaucoup de travail, dont les plus importants sont le hachage (Keccak-256) et la vérification de signature (ECDSA et secp256k1).

Notre zkVM a accéléré la prise en charge des courbes elliptiques, la vérification de la signature ECDSA n'est donc pas difficile.

Mais en matière de hachage, nous n’avons pas cette chance. Notre zkVM a accéléré la prise en charge de Sha2-256, mais pas (au moment de la rédaction) de Keccak-256. Par conséquent, nous n’utilisons actuellement que l’implémentation Keccak dans la caisse sha3 Rust. Grâce au profilage, nous savons que cela prend beaucoup de cycles. Ce n'est pas optimal, mais notre zkVM peut le gérer, et nous pouvons recycler et ajouter des accélérateurs Keccak plus tard.

Comptes et stockage : performances et sécurité

Dans Ethereum, les comptes et le stockage sont suivis par un Merkle Patricia Trie (MPT) mondial.

Au moment de la rédaction de cet article, l'arbre contenait l'état de près de 250 000 000 d'adresses Ethereum uniques, selon Etherscan. Cela ne représente pas une énorme quantité de données dans l’ensemble, mais c’est suffisant pour nous inciter à faire attention à la manière dont nous les stockons et les utilisons. En particulier, les performances du MPT sont critiques.

Mais la performance n’est pas le seul facteur, il faut aussi penser à la sécurité.

Le générateur de blocs de Zeth fonctionne en tant que client dans zkVM. Cela signifie qu’il ne peut pas accéder directement au réseau Ethereum p2p ou à d’autres fournisseurs RPC. Au lieu de cela, il doit s'appuyer sur des données fournies par des programmes distincts exécutés en dehors de zkVM.

Lors de l'analyse de la sécurité d'une application ZK, nous devons supposer que les programmes externes sont malveillants et peuvent donc diffuser des données malveillantes. Pour éviter cela, les applications ZK doivent vérifier que les données qui leur sont fournies sont valides.

Pour les générateurs de blocs Zeth, cela signifie vérifier l'état de tous les comptes et stockages pertinents (c'est-à-dire les comptes et le stockage requis pour exécuter une liste donnée de transactions).

Heureusement, un tel mécanisme est fourni par EIP-1186, qui définit un moyen standard de prouver l'état d'un compte donné (et son stockage) via l'inclusion Merkle.

En principe, les générateurs de blocs de Zeth pourraient vérifier l'état du compte et du stockage en vérifiant un ensemble de preuves d'inclusion EIP-1186. Mais cette approche n’est pas idéale.

Au lieu de cela, il est préférable d'utiliser les données de la preuve d'inclusion EIP-1186 pour construire un MPT partiel. Il s'agit d'un type de MPT qui inclut uniquement les nœuds pertinents pour une liste de transactions donnée ; les branches non liées sont simplement représentées par les hachages correspondants. Vous pouvez considérer les MPT partiels comme une sorte d'« union » de preuves d'inclusion de Merkle ; ou, si vous préférez, comme des preuves de sous-ensembles de Merkle.

Le processus de vérification d'un MPT partiel est fondamentalement le même que celui d'une preuve EIP-1186 normale : le hachage racine est calculé et comparé à la racine de l'état du bloc parent. Si les deux sont égaux, l’intégrité des comptes et le stockage qu’ils contiennent sont fiables.

Une fois le MPT partiel vérifié, la transaction peut être appliquée et le MPT partiel mis à jour. La nouvelle racine d'état peut être obtenue en calculant la nouvelle valeur de hachage racine du MPT partiel.

1. Avant d'exécuter le générateur de blocs Zeth, nous exécutons la liste des transactions dans le bac à sable pour déterminer quels comptes et stockage sont pertinents. (Ce processus nous permet également de déterminer le bloc prédécesseur associé le plus ancien, qui est requis pour prendre en charge les requêtes blockhash()).
2. Nous obtenons une preuve d'inclusion EIP-1186 pour chaque compte et stockage concerné. (Nous obtenons également les blocs prédécesseurs correspondants).
3. Nous utilisons ces preuves d'inclusion pour créer un MPT partiel qui inclut toutes les données pertinentes.
4. Nous démarrons zkVM, le laissons exécuter le générateur de blocs Zeth et fournissons du MPT et d'autres entrées (bloc parent, liste de transactions, etc.).

Dans zkVM, le générateur de blocs Zeth :

1. Vérifiez que la racine MPT partielle correspond à la racine d'état du bloc parent.
2. Vérifiez la chaîne de hachage du bloc précédent jusqu'au bloc parent.
3. Opérations de candidature.
4. Mettez à jour certains MPT.
5. Utilisez le nouveau hachage racine du MPT partiel comme racine d'état du nouveau bloc.

Une fois le générateur de bloc Zeth terminé, il affichera la valeur de hachage du nouveau bloc.

Ce hachage inclut un engagement envers le bloc parent, et donc la racine d'état du bloc parent (utilisée pour vérifier le MPT partiel d'origine). Cela signifie qu'un validateur malveillant ne peut pas fournir aux comptes et au stockage des données invalides sans fournir un bloc parent invalide.

Autrement dit : si le bloc parent est valide, alors le nouveau bloc généré par Zeth est également valide.

Ainsi, si quelqu'un vous donne un nouveau bloc et une preuve ZK générée par Zeth, vous pouvez vérifier la validité du bloc en vérifiant les trois choses suivantes :

1. Assurez-vous que la preuve ZK est valide et provient de Zeth. Pour les applications hors chaîne, les fonctions fournies par la caisse zkVM Rust peuvent être utilisées pour l'inspection. Pour les applications en chaîne, cela peut être vérifié à l'aide de notre validateur de preuves en chaîne.
2. Assurez-vous que le ZK prouve que le hachage du nouveau bloc a été validé.
3. Assurez-vous que le bloc parent contient le hachage souhaité.

Si ceux-ci sont vérifiés, alors le nouveau bloc est valide.

Limites et améliorations futures

Le but de notre projet est d'étudier les performances de la construction en blocs. Pour cette raison, nous avons décidé de limiter la portée aux blocs fusionnés.

De plus, même si Zeth est capable de prouver qu’un bloc donné est valide, il ne peut actuellement pas prouver le consensus (c’est-à-dire que le bloc est effectivement inclus dans la chaîne canonique). Cela pourrait changer à l'avenir, peut-être en ajoutant des vérifications des signatures du validateur ou du comité de synchronisation dans zkVM.

Enfin, Zeth est un nouveau logiciel. Bien que nous ayons effectué quelques tests (y compris la suite de tests Ethereum et divers blocs du monde réel), Zeth peut encore contenir quelques bugs. Au moment d’écrire ces lignes, il doit être considéré comme un logiciel expérimental.