Analyse technique sur ZKBase : un ZK-Rollup haute performance pour des transactions ETH évolutives et sécurisées

ZKBase est un ZK-Rollup hautes performances basé sur ZK Stack et un prouveur multi-GPU. Cette solution améliore la capacité de traitement des transactions et offre une expérience réseau rentable. Son principal avantage réside dans l'adoption de la technologie Zero Knowledge Proof (ZKP), permettant de vérifier et de confirmer rapidement les transactions hors chaîne tout en préservant la confidentialité des transactions et l'intégrité des données. Puisque toutes les preuves de validité sont vérifiées sur Ethereum, les utilisateurs peuvent bénéficier des mêmes garanties de sécurité qu’en L1. ZKBase fonctionne de manière similaire à Ethereum mais avec un débit plus élevé et des frais inférieurs. Les contrats intelligents sont écrits en Solidity/Vyper et peuvent être invoqués en utilisant les mêmes clients que les autres chaînes compatibles EVM. Cet article présentera l'ingénierie de base et la mise en œuvre technique de ZKBase.

1. Composants clés de ZKBase

Tree et TreeBackup : Ces composants utilisent RocksDB pour conserver des copies locales de l'arborescence de stockage L2. La base de données reste synchronisée avec le dernier hachage racine d'état, reflétant en permanence l'état actuel du système.

StateKeeper/VM : exécute les transactions et stocke en toute sécurité les blocs inclus dans la base de données RocksDB locale, garantissant l'intégrité des données et des mises à jour continues de l'état.

Contrat intelligent : déployés sur le réseau principal Ethereum, ces contrats intelligents vérifient les preuves de connaissance nulle (ZKP) soumises hors chaîne. Une fois la vérification réussie, ces contrats mettent à jour les états des comptes sur le réseau Ethereum.

GPU Prover : Une technologie ZK-Rollup qui garantit une vérification sécurisée et efficace des transactions grâce à des preuves sans connaissance. Lorsqu'un lot de transactions se produit hors du réseau principal Ethereum, le système d'agrégation ZK compresse plusieurs transactions en une seule « preuve de validité » calculée par le Prover, démontrant l'exactitude du lot. Cette preuve est ensuite soumise au réseau Ethereum, permettant la confirmation rapide et sécurisée d'un grand volume de transactions hors chaîne.

Bridge : ZKBase fournit un mécanisme de transition pour transférer en toute sécurité des actifs entre ZKBase et le réseau principal Ethereum, garantissant ainsi l'interopérabilité et la liquidité des actifs entre les deux plates-formes.

2. Flux de travail ZKBase

Les utilisateurs peuvent lancer des requêtes L2 via une interface de programmation d'application (API) ou via des contrats déployés sur L1. Une fois soumises, ces requêtes entrent dans un pool de mémoire, en attente d'exécution. Notamment, les transactions provenant de L1 (telles que les dépôts) sont stockées dans une file d'attente prioritaire L1 dédiée pour garantir qu'elles sont traitées rapidement.

La structure de stockage mempool est un btreeset (un ensemble implémenté par un btree). La structure d'indexation est la suivante :

Ici, fee_data n'est pas impliqué dans le calcul du score réel mais aide à filtrer les transactions qui ne répondent pas aux exigences en matière de frais. Le score est trié par horodatage, et si les horodatages sont identiques, alors par adresse.

Les transactions dans le pool de mémoire sont gérées par le composant de récupération du pool de mémoire au sein de State Keeper. À l'exception des transactions expirées, les transactions standard sont récupérées du pool de mémoire dans l'ordre défini par le parcours btree et enregistrées dans la base de données. Ils sont ensuite traités par le State Keeper/VM, exécutés et utilisés pour mettre à jour l’arborescence des états.

Le diagramme de disposition des blocs montre l'organisation des transactions au sein d'un bloc et la disposition des blocs L2 au sein d'un lot L1.

Pour lancer chaque lot L1, l'opérateur doit saisir des détails clés : l'horodatage du lot, sa position dans la séquence et la valeur de hachage du lot précédent.

Le hachage racine de l'arbre Merkle sert de hachage racine fondamental dans ce processus pour garantir la validité du lot et l'authenticité des transactions. Simultanément, le State Keeper a le pouvoir de décider quand finaliser un bloc L2 ou un lot L1 spécifique, déterminant ainsi son état. Cette décision est régie par un ensemble de critères prédéfinis gérés par le module conditional_sealer. Ces critères incluent des paramètres tels que le nombre de transactions, les limites de taille et les seuils d'utilisation du gaz. Après avoir traité une transaction, le gardien de l'État vérifie quelle condition de scellement est remplie.

Le conditional_sealer gère un registre SealCriteria qui comprend :

• Limites du nombre de transactions,

• Limites de gaz L2,

• Limites supérieures de la quantité de données publiées, entre autres réglementations.

Il existe quatre scénarios de décision : NoSeal, IncludeAndSeal, ExcludeAndSeal et Uneexecutable. Dans les deux premiers cas, le processus est le même, l'état post-exécution étant mis à jour dans le State Keeper. ExcludeAndSeal gère les transactions qui dépassent les limites de lots prédéfinies en annulant l'exécution de la transaction et en la replaçant dans la file d'attente pour être incluse dans le bloc L2 suivant. Si une situation non exécutable se produit, la transaction ne pourra pas être exécutée et sera rejetée.

À la fin de chaque lot, le chargeur de démarrage génère un bloc d'espace réservé L2 pour terminer les transactions et préparer le cycle suivant. Bien qu'en grande partie vide, ce bloc est crucial pour les opérations internes et comprend un journal des événements de transfert pour enregistrer les mouvements de frais entre le chargeur de démarrage et l'opérateur. Pour garantir l'exactitude du temps, les horodatages du lot et du dernier sous-bloc sont recoupés avec le délai L1 attendu afin d'améliorer la résilience du système aux problèmes liés au temps.

Une fois un lot finalisé, le prouveur génère une preuve cryptographique pour vérifier l'exécution du bloc. Dans ZKBase, la responsabilité du prouveur est de prouver l'exécution précise de la machine virtuelle ZKBase Ethereum (EVM). Cette preuve est ensuite vérifiée par un contrat intelligent sur le réseau Ethereum. Une fois la preuve générée, le prouveur la regroupe dans une transaction L1 et l'envoie à ETH_Sender. L'ETH_Sender transmet la transaction au contrat ZKBase déployé sur le réseau principal Ethereum pour un traitement ultérieur.

Le réseau principal Ethereum vérifie l'exactitude de la preuve et, une fois la vérification réussie, met à jour l'état en conséquence.

Tout au long du processus, EthWatcher surveille en permanence les événements L1 spécifiques, tels que les dépôts et les mises à niveau du système, pour garantir la synchronisation avec le réseau principal Ethereum.

3. Architecture de prouveurs GPU multiples

L'architecture exploite une base de données Postgres pour partager des données, permettant ainsi des calculs parallèles sur plusieurs GPU Provers afin d'améliorer l'efficacité de la génération de preuves. Les composants clés comprennent :

Opérateur : Le serveur qui fournit les services de couche 2.

Prover Gateway : un module de communication qui connecte l'opérateur au sous-système de preuve.

Générateur de témoins : génère des tâches de calcul de preuve et stocke les artefacts intermédiaires.

Générateur de vecteurs : regroupe toutes les tâches de calcul dans un format vectoriel adapté au calcul GPU et les envoie aux prouveurs.

Prouveur : effectue le calcul réel et la vérification des preuves.

Compresseur : compresse la preuve finale sous la forme SNARK.

Flux de travail de génération de preuves

Génération de lots : L'Opérateur collecte les transactions et génère un nouveau lot.

Réception de lots : la passerelle Prover récupère le nouveau lot auprès de l'opérateur et commence à se préparer à générer la preuve sans connaissance.

Insertion de base de données : Prover Gateway insère les informations de lot dans la base de données Postgres. Le traitement ultérieur des données interagit directement avec la base de données, récupérant les données des tables d'entrée correspondantes et plaçant les données traitées dans les tables de sortie pertinentes.

Génération de témoin : cette étape initiale se produit lorsqu'un utilisateur initie une transaction, générant un témoin. Le témoin prouve la validité de la transaction sur la base des règles de consensus du réseau sans révéler aucun détail de la transaction. Les nouveaux témoins de transaction sont collectés et traités par lots. Chaque lot subit les processus suivants :

• BasicCircuitsWitnessGenerator

• LeafAggregationWitnessGenerator

• Agrégation de nœuds

• Planificateur

Génération de vecteurs : Le générateur de vecteurs consolide les circuits pour produire des vecteurs témoins, optimisant ainsi l'utilisation de la puissance de calcul du GPU.

Calcul de preuve : les prouveurs utilisent des GPU pour calculer les preuves sans connaissance, vérifiant ainsi l'exactitude des calculs de preuve.

Compression : Le module Compresseur compresse la preuve pour réduire la taille des données, la transformant au format SNARK.

4. Conclusion

ZKBase, construit sur ZK Stack et Multi-GPU Prover, atteint une évolutivité de couche 2 hautes performances. Cependant, la solution de mise à l’échelle Ethereum ZK-Rollup est encore confrontée à de nombreux défis techniques. À l'avenir, ZKBase continuera à rechercher et à explorer la mise en œuvre d'un séquençage décentralisé et d'un réseau de puissance de calcul ZK décentralisé.