Opside : Provers décentralisés pionniers pour les rollups ZK de nouvelle génération

Pourquoi avons-nous besoin de démonstrateurs décentralisés ?

Actuellement, plusieurs ZK-Rollups s'exécutent sur le réseau principal Ethereum. Cependant, la conception de ZK-Rollups décentralisés en est encore à ses débuts. Nous nous concentrons actuellement sur la question des séquenceurs décentralisés, mais la plupart des gens oublient le fait qu'actuellement, la plupart des projets ZK-Rollup n'ont pas implémenté de prouveurs décentralisés.

Pour ZK-Rollups, un prouveur centralisé est toujours sûr et n'apporte pas les mêmes problèmes de censure qu'un séquenceur centralisé. Cependant, un prouveur centralisé peut également poser de nombreux problèmes. Premièrement, s'il n'y a qu'un seul prouveur, une défaillance d'un seul nœud peut empêcher l'ensemble du ZK-Rollup de soumettre sa preuve de validité, affectant ainsi la finalité des transactions.

Deuxièmement, le coût d'un prouveur centralisé est élevé et il est incapable de répondre à la demande de calcul de ZK-Rollups massifs à l'avenir.

Enfin, d'un point de vue économique, un prouveur centralisé bénéficie à lui seul d'une partie des bénéfices, ce qui, d'un point de vue économique symbolique, est en réalité injuste.

Défis des démonstrateurs décentralisés

Les démonstrateurs décentralisés peuvent résoudre efficacement les problèmes ci-dessus, mais cela pose également certains défis. C'est l'une des raisons pour lesquelles plusieurs schémas zkEVM récemment lancés ont adopté un schéma de prouveur centralisé. Par exemple, le réseau principal bêta du Polygon zkEVM s'appuie sur un agrégateur de confiance pour soumettre les ZKP, et l'ère zkSync est similaire à cet égard.

D'un point de vue technique, lorsque le contrat intelligent d'un ZK-Rollup vérifie le ZKP, il a besoin des données de preuve d'origine. Cela peut potentiellement déclencher divers comportements d'attaque en chaîne. Par exemple, lorsqu'un certain prouveur soumet le ZKP calculé au contrat au niveau de la chaîne, il doit envoyer une transaction L1. Lorsque cette transaction est diffusée dans le pool de transactions, les attaquants peuvent voir les données de preuve d'origine et ils peuvent définir des frais de gaz plus élevés pour envoyer une transaction, étant ainsi les premiers à être regroupés dans un bloc et à gagner des récompenses PoW.

De plus, étant donné que les prouveurs se font concurrence sur la base de la puissance de calcul, il n'existe pas de mécanisme de reconnaissance d'identité fiable et il est également difficile d'établir un mécanisme de communication. Différents mineurs peuvent effectuer un travail en double, ce qui entraîne un gaspillage de puissance de calcul.

Soumission en deux étapes de ZKP

Étape 1 : Soumettre le hachage

• Après qu'un prouveur a calculé un ZKP pour une certaine séquence, il calcule d'abord le hachage de (preuve/adresse) et soumet le hachage et l'adresse au contrat intelligent au niveau de la chaîne. Ici, la preuve est une preuve à connaissance nulle pour une certaine séquence, et l'adresse est l'adresse du prouveur.

  
  

• En supposant que le premier prouveur soumet le hachage du ZKP au bloc T, il est accepté jusqu'au bloc T+10 sans aucune limite. A partir du bloc T+11, les nouveaux prouveurs ne peuvent plus soumettre le hash.

  
  

Étape 2 : soumettre ZKP

• Après le bloc T+11, tout prouveur peut soumettre un ZKP. Tant qu'un ZKP réussit la vérification, il peut être utilisé pour vérifier tous les hachages soumis. Les prouveurs validés reçoivent des récompenses PoW en fonction du ratio des montants misés par les mineurs.

  
  

• Si aucun ZKP ne passe la vérification avant le bloc T + 20, tous les prouveurs qui ont soumis des hachages seront amputés. La séquence est ensuite rouverte et de nouveaux hachages peuvent être soumis, en revenant à l'étape 1.

  
  

Voici un exemple : supposons que chaque bloc ait une récompense PoW de 128 IDE sur le réseau Opside, et qu'il y ait actuellement 64 emplacements de déploiement disponibles. Par conséquent, chaque séquence de déploiement se voit attribuer une récompense PoW de 2 IDE. Si trois mineurs, A, B et C, soumettent avec succès le ZKP correct pour une séquence successive, les enjeux de mineur des trois mineurs (IDE) sont respectivement de 200 000, 500 000 et 300 000. Ensuite, A, B et C peuvent chacun gagner une récompense PoW de 0,4 IDE, 1 IDE et 0,6 IDE, respectivement.

Le pieu symbolique et la punition du prouveur

Pour empêcher un comportement malveillant de la part du prouveur, celui-ci doit s'inscrire auprès d'un contrat système spécial et miser un certain nombre de jetons. Si le montant de la mise actuelle est inférieur au seuil, le prouveur ne peut pas soumettre le hachage et le ZKP. La récompense pour la soumission du ZKP par le prouveur sera distribuée en fonction du ratio du montant de la mise, empêchant le prouveur de soumettre plusieurs ZKP.

Si le prouveur commet les actions suivantes, différents niveaux de sanction seront appliqués :

• Le prouveur soumet un hachage incorrect.
• Pour une certaine séquence, si aucun ZKP correspondant ne passe la vérification, tous les prouveurs qui ont soumis des hachages seront punis.
• Le jeton perdu sera brûlé.

Pour plus de détails et de considérations sur le mécanisme de soumission en deux étapes du ZKP, les lecteurs sont encouragés à se référer aux documents officiels d'Opside. Les numéros spécifiques de l'enjeu et de la punition du prouveur peuvent être modifiés à l'avenir.

Plusieurs considérations :

• Pourquoi autoriser plusieurs prouveurs à soumettre des hachages ? Si seul le premier prouveur à soumettre un hachage est récompensé, les autres prouveurs peuvent ne pas être incités à soumettre une preuve après que le premier prouveur a soumis un hachage. Si un attaquant malveillant tarde à soumettre la preuve pendant une longue période après avoir soumis un hachage, cela peut ralentir la vérification de la séquence entière. Par conséquent, il est nécessaire de permettre à plusieurs prouveurs de soumettre indépendamment et simultanément des hachages pour éviter un monopole de la vérification ZKP par un seul attaquant.

  
  

• Pourquoi y a-t-il une fenêtre temporelle ? Si quelqu'un peut soumettre une preuve immédiatement après avoir soumis un hachage, la preuve peut toujours être volée. Les attaquants peuvent immédiatement soumettre un hachage associé à leur adresse, puis soumettre une preuve pour gagner des récompenses. En fixant une fenêtre de temps, les prouveurs qui ont soumis des hachages n'ont aucune incitation à soumettre des preuves dans la fenêtre, évitant ainsi la possibilité d'être couru.

  
  

• Pourquoi la récompense est-elle attribuée en fonction de la mise ? Plusieurs prouveurs peuvent soumettre des hachages pour la même séquence dans une fenêtre de temps. En fait, les mineurs peuvent soumettre plusieurs hachages en utilisant leur preuve générée (ne nécessite que plusieurs adresses). Cela peut conduire à ce que la majorité ou même la totalité des récompenses PoW soient prises par les mineurs. Pour éviter cette attaque, la récompense pour une séquence sera attribuée en fonction du ratio du montant de la mise du mineur.

  
  

Résumé et planification

L'algorithme de soumission en deux étapes pour les ZKP proposé dans cet article réalise la décentralisation du prouveur tout en évitant efficacement les attaques raciales et en encourageant davantage de mineurs à fournir une puissance de calcul ZKP stable et continue. La version initiale de l'algorithme sera lancée sur le testnet pré-alpha d'Opside.

À l'avenir, Opside introduira également des idées plus innovantes dans le domaine de l'exploitation minière ZKP, telles que :

• Ajustement dynamique du ratio d'attribution des récompenses entre PoS et PoW en fonction de la demande et de l'offre de puissance de calcul ZKP sur l'ensemble du réseau.
• Mécanisme de tarification personnalisé pour les lots Rollup en fonction du type de ZK-Rollup, du nombre de transactions Rollup et de la consommation de gaz du Rollup.
• Subventions aux développeurs d'applications pour générer des ZKP pour leurs Rollups associés afin d'encourager les mineurs à fournir une puissance de calcul.