Opside ZK-PoW V2.0 : un réseau de preuves décentralisé multi-chaînes et multi-rollup

Opside ZK-PoW Introduction

Opside est une plate-forme décentralisée ZK-RaaS (ZK-Rollup as a Service) et un réseau de premier plan pour le minage ZKP (Zero-Knowledge Proof). ZK-RaaS fournit un service en un clic pour générer des ZK-Rollups à n'importe qui. Opside propose une base de lancement universelle ZK-Rollup, permettant aux développeurs de déployer facilement différents types de ZK-Rollups sur différentes chaînes de base.

• Chaînes de base : chaîne Ethereum/Opside/chaîne BNB/Polygon PoS et autres chaînes publiques.
• Types de ZK-Rollup : zkSync, Polygon zkEVM, Scroll, StarkNet et d'autres variantes de ZK-Rollups.

Dans la conception d'Opside, les développeurs peuvent déployer des ZK-Rollups sur ces différentes chaînes de base. Au fur et à mesure que la technologie ZK-Rollup mûrit, il pourrait y avoir des centaines, voire des milliers de ZK-Rollups à l'avenir, ce qui créera une demande importante de puissance de calcul ZKP. Opside utilise le mécanisme ZK-PoW pour inciter les mineurs à fournir une puissance de calcul ZKP, fournissant ainsi une infrastructure matérielle complète pour ZK-Rollups.

Architecture ZK-PoW V2.0

L'architecture globale de ZK-PoW V2.0 se compose de plusieurs composants clés :

1. ZK-PoW Cloud : Il s'agit de l'infrastructure cloud fournie par Opside pour le calcul ZKP. Il est déployé sur plusieurs chaînes, notamment Ethereum, BNB Chain, Polygon PoS et Opside Chain. Le ZK-PoW Cloud est responsable de la coordination et de la gestion des tâches de calcul ZKP.

   
   

2. Miner Nodes : Ce sont les nœuds exploités par les mineurs qui apportent leur puissance de calcul pour effectuer des calculs ZKP. Les mineurs peuvent participer au réseau ZK-PoW en exécutant un logiciel spécialisé sur leur matériel minier.

   
   

3. Distribution des tâches ZKP : Le ZK-PoW Cloud distribue les tâches de calcul ZKP aux nœuds mineurs. La distribution se fait de manière décentralisée pour assurer l'équité et l'efficacité. Les tâches ZKP incluent la génération et la vérification de preuves à connaissance nulle pour divers ZK-Rollups.

   
   

4. Calcul ZKP : les nœuds mineurs reçoivent des tâches de calcul ZKP et effectuent les calculs nécessaires pour générer les preuves requises. Cela implique l'exécution d'algorithmes cryptographiques et la réalisation de calculs complexes.

   
   

5. Soumission et vérification des preuves : une fois les calculs ZKP terminés, les nœuds mineurs soumettent les preuves générées au ZK-PoW Cloud pour vérification. L'infrastructure cloud vérifie l'exactitude des preuves pour garantir leur validité et leur intégrité.

   
   

6. Mécanisme d'incitation : Les mineurs sont incités à participer au réseau ZK-PoW en gagnant des récompenses pour leurs contributions informatiques. Le système de récompense est conçu pour motiver les mineurs et maintenir la sécurité et la stabilité du réseau.

Dans l'ensemble, ZK-PoW V2.0 combine la puissance des ressources de calcul des mineurs avec une infrastructure cloud pour fournir un calcul ZKP efficace et évolutif pour une large gamme de ZK-Rollups.

L'agrégateur est un composant important du prouveur dans le système ZK-PoW V2.0. Il est responsable de la distribution des tâches d'épreuve ZKP, de la réception des résultats des tâches (épreuves ZKP), de la gestion des épreuves et de leur soumission à la chaîne de base pour gagner des récompenses. En fonction de leurs fonctions, la nouvelle version de l'agrégateur est divisée en trois sous-modules : Proof Generator, Proof Manager et Proof Sender.

• Le module Proof Generator est chargé d'attribuer des tâches de preuve au prouveur (mineur PoW), de recevoir les résultats des tâches (preuves ZKP) et de stocker les preuves ZKP dans la base de données DB.

• Le Proof Manager est chargé de gérer les épreuves ZKP terminées et de conditionner les épreuves prêtes à être soumises en chaîne en tant que tâches pour le module Proof Sender.

• Le module Proof Sender gère la soumission en chaîne des preuves ZKP en les soumettant au contrat zkEVM déployé sur la chaîne de base.

  
  

Voici les introductions de ces trois modules :

Générateur de preuves

Rollup Chain regroupe un certain nombre de transactions dans un lot, puis plusieurs lots (basés sur des facteurs tels que la fréquence des transactions) sont combinés en une séquence. La séquence est ensuite soumise à la chaîne de base, ce qui en fait l'unité de soumission des données pour chaque opération en chaîne. Chaque séquence consiste en un ou plusieurs lots, et la preuve ZKP vérifie la validité de la séquence soumise. Par conséquent, le lot est la plus petite unité de la tâche de preuve. Selon le nombre de lots inclus dans une séquence, les tâches de preuve requises varient comme suit :

• Si le nombre de lots est 1, le processus de vérification implique BatchProofTask suivi de FinalProofTask, et les tâches sont exécutées de manière séquentielle.

• Si la séquence contient plus d'un lot, le processus de vérification implique plusieurs BatchProofTasks, une AggregatorProofTask et une FinalProofTask, et les tâches sont exécutées de manière séquentielle.

  
  

Pour maximiser l'efficacité de la génération de preuves et augmenter les récompenses minières pour les mineurs PoW, nous visons à générer des preuves simultanément. Ceci est réalisé sous deux aspects :

• La génération de preuves pour différentes séquences peut être effectuée simultanément car il n'y a pas de dépendance contextuelle ou d'état.

• Dans la même séquence, plusieurs BatchProofTasks peuvent être exécutées simultanément.

  
  

Cette approche utilise les ressources de calcul des prouveurs plus efficacement, ce qui se traduit par une génération de preuves plus efficace.

Gestionnaire de preuve

Ce module est principalement responsable de la gestion des preuves ZKP et du contrôle de leur vérification en chaîne. Il se compose de trois modules principaux :

• submitPendingProof : Ce module n'est exécuté qu'une seule fois au démarrage de l'agrégateur. Son but est de terminer la soumission des épreuves ZKP inachevées du service Aggregator précédent. Cela gère la situation où proofHash a été soumis mais d'autres mineurs ont déjà soumis leurs preuves. Pour plus d'informations sur proofHash, veuillez vous référer au module Proof Sender.
• tryFetchProofToSend : ce module s'exécute comme une coroutine et ajoute la dernière preuve ZKP générée, ainsi que sa séquence non vérifiée correspondante, au cache de l'expéditeur de la preuve, en attendant la soumission en chaîne.
• processResend : Ce module fonctionne comme une coroutine et vise à resoumettre les séquences qui n'ont pas été vérifiées avec succès dans une fenêtre de temps donnée. Son but est de s'assurer que les séquences qui dépassent le temps de vérification sont soumises à nouveau pour un traitement en chaîne.

Expéditeur de la preuve

Opside a proposé un algorithme de soumission ZKP en deux étapes pour parvenir à la décentralisation du prouveur. Cet algorithme empêche les attaques frontales ZKP et permet à davantage de mineurs de recevoir des récompenses, encourageant ainsi davantage de mineurs à participer et à fournir une puissance de calcul ZKP stable et continue.

• Étape 1 : Lors de la production d'une preuve PoW pour une séquence spécifique (appelée preuve), le prouveur calcule d'abord le hachage de "preuve / adresse" et le soumet au contrat. Si aucun proofHash n'a été soumis pour cette séquence auparavant, une fenêtre de temps de soumission de proofHash, T1, est ouverte. Les mineurs sont éligibles pour soumettre la séquence dans les blocs T1, et la preuve ne peut être soumise qu'après les blocs T1.

  
  

• Etape 2 : Après les blocs T1, la fenêtre de soumission de preuve s'ouvre pour les blocs T2. Si aucune des preuves soumises ne réussit la vérification dans les blocs T2, tous les mineurs qui ont précédemment soumis proofHash seront pénalisés. Si proofHash est soumis avec succès dans la fenêtre temporelle T1 mais que la preuve ne peut pas être soumise avec succès dans la fenêtre temporelle T2, et que d'autres mineurs soumettent avec succès leurs preuves dans la fenêtre temporelle T2, le prouveur peut toujours continuer à soumettre cette preuve. Dans d'autres scénarios, le processus de soumission en deux étapes est redémarré.

Le diagramme suivant illustre comment Proof Sender implémente la soumission en deux étapes à l'aide de trois caches thread-safe et triés par priorité. Ces caches sont triés en fonction de la hauteur de départ des séquences, garantissant qu'à chaque fois qu'un élément est extrait de ces caches, il correspond à la hauteur de séquence la plus basse. De plus, les éléments de ces caches sont dédupliqués. Plus la hauteur de la séquence correspondante est faible, plus la priorité de traitement est élevée.

• finalProofMsgCache : Stocke les messages finalProof envoyés par le Proof Manager, indiquant l'achèvement des épreuves ZKP.
• monitPHTxCache : stocke les transactions proofHash à surveiller.
• ProofHashCache : stocke les messages de preuve pour la soumission en chaîne.

Une fois le module Proof Sender lancé, trois coroutines sont lancées pour consommer les données des trois caches. Le processus simplifié est le suivant :

1. Coroutine 1 consomme les messages finalProof du finalProofMsgCache, calcule le proofHash, et s'il remplit les conditions de soumission en chaîne (dans la fenêtre T1), il soumet le proofHash à la chaîne et ajoute la transaction proofHash au monitPHTxCache.

2. Coroutine 2 consomme les messages de transaction proofHash du monitPHTxCache. Si le proofHash remplit les conditions de soumission en chaîne dans la fenêtre T2, il construit le message de preuve et le stocke dans le ProofHashCache.

3. Coroutine 3 consomme les messages de preuve du ProofHashCache et soumet les preuves à la chaîne.

   
   

Par rapport au module précédent, cette structure est plus claire et permet d'économiser sur les ressources.

Résumé

Comparaison avec la version 1.0

• La version 2.0 divise le service d'origine en trois sous-modules, chacun responsable de la génération de preuves, de la gestion des preuves et de la soumission des preuves, ce qui se traduit par une structure plus claire, un couplage inférieur et une robustesse accrue.
• Le module de génération de preuves, Proof Generator, a ajouté le paramètre startBatch par rapport à l'ancienne version, ce qui permet aux nouveaux mineurs de rattraper plus facilement la progression du minage.
• Le module de gestion des preuves, Proof Manager, a été amélioré par rapport à l'ancienne version. Il renvoie rapidement les preuves en cas de redémarrage du service de mineur ou d'autres raisons d'échec de la soumission de preuve, garantissant les intérêts du mineur. Le mécanisme de renvoi traite non seulement les cas d'échec de soumission de preuve, mais gère également tous les cas d'échec ou de non-soumission de preuve, garantissant la sécurité de la chaîne de cumul.
• Le module de soumission de preuve, Proof Sender, implémente une soumission de transaction en deux étapes à l'aide de trois caches de priorité thread-safe. Il réduit l'utilisation de verrous globaux par rapport aux versions précédentes, garantissant que les épreuves avec des hauteurs inférieures sont soumises rapidement et protégeant les intérêts des mineurs. De plus, le flux de service global est plus clair, avec un nombre de threads réduit et une consommation de ressources réduite pendant l'exécution du programme.

Résultats des tests de résistance :

• Dans la version 2.0, utilisant 10 machines avec 64 cœurs chacune, 566 épreuves par lots ont été réalisées en 7 heures, 38 minutes et 40 secondes, avec un temps moyen de 48,62 secondes par épreuve. Dans un scénario multi-mineurs, par rapport à la version 1.0, l'efficacité de la génération de preuves zk dans la version 2.0 s'est globalement améliorée de 50 %.

  
  

En conclusion, Opside ZK-PoW V2.0 a optimisé le processus de plusieurs mineurs participant aux calculs ZKP, améliorant l'utilisation du matériel, améliorant la disponibilité des services et étant plus convivial pour les mineurs. Il est important de noter que dans un scénario multi-mineurs, le temps de calcul pour ZKP a été réduit à moins d'une minute, accélérant considérablement le temps de confirmation des transactions ZK-Rollup.