La première partie de la série zkEVM : l’architecture globale et le processus d’exécution des transactions de Polygon zkEVM

Auteur : 0xhhh, Ethstorage(Twitter :@hhh69251498 )

Editeur :Red One

Le 27 mars, la version bêta du réseau principal Polygon zkEVM a été officiellement lancée, et Vitalik a effectué sa première transaction sur celui-ci.

Cet article est le premier d’une série d’articles sur Polygon zkEVM, qui décrit brièvement l’architecture globale et le processus d’exécution des transactions de Polygon zkEVM, et analyse comment Polygon zkEVM réalise une mise à l’échelle informatique tout en héritant de la sécurité d’Ethereum.

Dans les deux prochains articles, nous détaillerons également les détails de conception du pont zkEVM et du zkEVM de Polygon zkEVM, ainsi que la feuille de route du prochain séquenceur décentralisé de Polygon zkEVM.

Tout d’abord, le cumul consiste à réaliser une mise à l’échelle computationnelle pour Ethereum

Tout d’abord, nous devons être clairs sur le fonctionnement des cumuls. L’émergence du Rollup consiste à mettre à l’échelle le calcul d’Ethereum, la méthode de mise en œuvre spécifique consiste à externaliser l’exécution des transactions à Rollup, puis à stocker la transaction et l’état (État) après l’exécution de la transaction dans le contrat Ethereum.

Cumul optimiste

De manière optimiste, la transaction de cumul et l’état de cumul correspondant envoyé à Ethereum sont corrects, et n’importe qui peut contester un état de cumul qui est encore dans la période de contestation en fournissant une preuve de fraude.

Cumul à divulgation nulle de connaissance

ZK fournira une preuve de validité pour la transaction de cumul envoyée à Ethereum et l’état de cumul correspondant (vérifié par le contrat sur Ethereum pour prouver que le cumul est dans le bon état après l’exécution de la transaction correspondante).

Reportez-vous à la définition officielle d’Ethereum :

La plus grande différence entre le cumul à divulgation nulle de connaissance et le cumul optimiste est que le temps nécessaire pour atteindre la finalité est différent en raison des différentes façons de vérifier la validité de l’état.

Optimistic Rollup est optimiste quant au fait que les transactions et les statuts soumis à Ethereum sont corrects, il y a donc une période de défi de 7 jours (le temps pour atteindre la finalité est de 7 jours), au cours de laquelle toute personne qui constate que l’état correspondant d’une transaction sur Ethereum est incorrect peut contester en soumettant le statut correct.

Le temps qu’il faut pour qu’un Rollup à divulgation nulle de connaissance (zk-Rollup) atteigne la finalité dépend du temps nécessaire pour que la preuve de validité de la transaction soit soumise à Ethereum et vérifiée. À l’heure actuelle, il peut s’écouler environ 1 heure pour la finalité (en raison de la nécessité de tenir compte du coût de l’essence).

Deuxièmement, processus d’exécution de Polygon zkEVM

Jetons un coup d’œil à la façon dont Polygon zkEVM fonctionne avec un processus simple de confirmation de transaction, afin d’avoir une compréhension concrète du protocole global, et l’ensemble de son processus peut être divisé en trois étapes principales :

1. Le séquenceur regroupe plusieurs transactions utilisateur en lots et les soumet au contrat L1.

2. Prover génère une preuve de validité pour chaque transaction et agrège les preuves de validité de plusieurs transactions en une seule preuve de validité.

3. L’agrégateur soumet une preuve de validité de l’agrégateur qui a agrégé plusieurs transactions dans le contrat L1.

1 Le séquenceur regroupe les transactions utilisateur en lots et les soumet au contrat L1.

1. L’utilisateur envoie la transaction au séquenceur, et le séquenceur traitera la transaction localement dans l’ordre de réception (FRFS), lorsque le séquenceur exécute la transaction localement, si l’utilisateur estime que le séquenceur est honnête, alors il peut considérer que la transaction a atteint la finalité. Il est important de noter ici que la plupart des Mempools dans Sequencer sont actuellement privés, il y a donc relativement peu de MEV qui peuvent être obtenus pour le moment.

2. Le séquenceur regroupera plusieurs transactions dans un lot (actuellement une seule transaction dans un lot), puis enverra plusieurs lots ensemble à la transaction Calldata de L1 via la fonction SequenceBatch() de PolygonZKEvm.sol sur L1.

(Il convient de noter que plusieurs lots sont soumis à la fois afin de réduire au maximum la consommation de gaz de L1.)

3. Lorsque PolygonZkEvm.sol reçoit les lots fournis par le séquenceur, il calcule le hachage de chaque lot dans le contrat à tour de rôle, puis enregistre le hachage du lot précédent dans le lot suivant, de sorte que nous obtenons la structure du lot dans la figure suivante.

4) L’ordre des transactions dans chaque lot est également déterminé, donc lorsque l’ordre du lot est déterminé, nous considérons que l’ordre de toutes les transactions incluses dans le lot à soumettre au contrat L1 Polygon zkEVM a été déterminé.

Le processus réel ci-dessus est également le travail que L1 doit effectuer en tant que couche DA de cumul (aucun travail de vérification d’état ou d’avancement n’a été effectué pour le moment).

**2. L’agrégateur génère une preuve de validité pour plusieurs lots de transactions

1. Lorsque l’agrégateur écoute la soumission réussie de nouveaux lots dans le contrat PolyonZKEVM.sol sur L1, il synchronise ces lots avec son nœud et envoie ces transactions à zkProver.

2. Après réception de ces transactions, zkProver générera une preuve de validité pour chaque transaction, puis agrégera la preuve de validité des transactions contenues dans plusieurs lots en une preuve de validité.

3. zkProver envoie la preuve de validité de l’agrégation de plusieurs transactions à Aggregator.

3. L’agrégateur soumet le contrat d’épreuves agrégées à L1

L’agrégateur soumettra cette preuve de validité au contrat Polygon zkEvm.sol sur L1 avec l’état correspondant de l’exécution du lot en appelant la méthode suivante :

Les actions suivantes sont ensuite effectuées dans le contrat pour vérifier que la transition d’état est correcte.

Lorsque cette étape est exécutée avec succès dans le contrat L1, toutes les transactions incluses dans cette partie du lot atteindront réellement la finalité (correspondant à la fin de la période de défi de 7 jours de l’OP).

3. Le rôle d’Ethereum dans Polygon-zkEVM

Maintenant que nous avons examiné le processus global de Polygon zkEVM, passons en revue ce qu’Ethereum a fait pour le Rollup :

Dans un premier temps, Sequencer collecte les transactions de cumul et les emballe en lots, qui sont ensuite soumis au contrat L1. L1 fournit non seulement la fonctionnalité de la couche DA, mais complète également certaines des fonctions de commande des transactions, lorsque vous soumettez une transaction à Sequencer, la transaction n’est pas vraiment ordonnée, car Sequencer a le pouvoir de changer l’ordre des transactions à volonté, mais lorsque la transaction est incluse dans le lot et soumise au contrat L1, personne n’a le droit de modifier l’ordre des transactions.

Dans la deuxième étape, l’agrégateur apporte la preuve de validité au contrat L1 pour atteindre le nouvel état, l’agrégateur est un rôle de type proposant, et le contrat est similaire au rôle de validateur, et l’agrégateur fournit une preuve de validité pour prouver que le nouvel état est correct et indique au validateur la validité que je fournis Quels lots de transactions sont impliqués dans Proof et où se trouvent-ils dans L1.

Ensuite, le validateur extrait le lot correspondant du contrat et le combine avec la preuve de validité pour vérifier la légitimité de la transition d’état, et si la vérification réussit, le contrat sera effectivement mis à jour vers le nouvel état de la preuve de validité correspondante.

Quatrièmement, structurer le Smart Contract Rollup du point de vue de la modularité

Si du point de vue de la modularité, Polygon zkEVM appartient au type Smart Contract Rollup, nous pouvons essayer de déconstruire ses modules, et à partir du diagramme donné par Delphi, nous pouvons également voir que Polygon ZkEVM est en fait la couche de consensus, la couche DA et le règlement du Smart Contract Rollup Les couches sont en fait couplées au contrat PolygonZkEVM.sol, qui n’est pas bien distingué. Mais essayons de déconstruire les modules :

Couche de disponibilité des données : où les transactions de cumul sont stockées, et dans le cas de Polygon-zkEVM, lorsque Sequencer appelle la méthode SequenceBatch(), il inclut en fait l’envoi des données de transaction à la couche DA.

Couche de règlement : Fait spécifiquement référence au mécanisme de flux d’argent entre Rollup et L1, en particulier le pont officiel de Polygon-zkEVM (plus d’informations à ce sujet dans le prochain article).

Couche de consensus : contient l’ordre des transactions et la façon de déterminer le prochain état valide (sélection de duplication), Sequencer termine l’ordre des transactions lorsqu’il appelle SequenceBatch() dans le contrat L1 et confirme l’état légal suivant lorsque l’agrégateur appelle TustedVerifyBatches() dans le contrat L1.

Couche d’exécution : processus par lequel une transaction est exécutée et un nouvel état mondial est obtenu, lorsque l’utilisateur soumet une transaction au séquenceur, et le nouvel état est obtenu après l’exécution du séquenceur ( C’est pourquoi nous avons tendance à dire que les cumuls sont une mise à l’échelle computationnelle, car L1 externalise le processus d’exécution des transactions pour obtenir un nouvel état aux cumuls, et le séquenceur délègue zkProver pour aider à générer une preuve de validité via l’agrégateur.

5. Pourquoi Polygon-zkEVM hérite de la sécurité de L1

À en juger par le processus global décrit ci-dessus, Sequencer fait en fait quelque chose de similaire à Ethereum Proposer, proposant qu’un lot de transactions soient des transactions valides, et donnant le nouvel état de ce lot de transactions après l’exécution, et la logique de vérification du contrat L1 est équivalente à tous les validateurs L1 seront exécutés dans leurs propres clients Ethereum, en fait, tous les validateurs Ethereum agissent comme des validateurs de Rollup, donc nous pensons que Polygon zkEVM Hérité de la sécurité d’Ethereum.

D’autre part, étant donné que toutes les transactions et l’état des Rollups sont stockés sur Ethereum, même si l’équipe zkEVM de Polygon s’enfuit, n’importe qui aura toujours la possibilité de récupérer l’ensemble du réseau Rollup sur la base des données stockées sur Ethereum.

6. Mécanisme d’incitation Polygon zkEVM

Les incitations au cumul visent principalement à rentabiliser le séquenceur et l’agrégateur et ainsi à poursuivre le travail.

Tout d’abord, les utilisateurs doivent payer leurs propres frais de transaction sur Rollup, qui sont libellés en ETH et payés en Bridged ETH.

Le séquenceur devra payer le coût de téléchargement du lot contenant la transaction de cumul vers les données d’appel de la transaction L1 (le coût de l’appel de SequenceBatch(batches()), et le Matic devra payer un certain montant de Matic au contrat L1 en même temps que le lot est téléchargé, ce qui paiera plus tard le coût de l’agrégateur fournissant une preuve de validité pour ces lots.

Alors que l’agrégateur appelle des VerifyBatches de confiance pour fournir une preuve de validité pour les lots du contrat L1 qui n’ont pas encore été définitifs, Sequencer peut également retirer les jetons MATIC payés à l’avance par Sequencer dans le contrat en récompense de la fourniture d’une preuve de validité.

Chiffre d’affaires du séquenceur = frais de gaz pour toutes les transactions dans le cumul - frais de gaz du réseau L1 dépensés pour le chargement des lots vers L1 - frais d’attestation payés à l’agrégateur (dénomination MATIC).

Chiffre d’affaires de l’agrégateur = Récompenses MATIC payées par le séquenceur - Frais de gaz soumis à la preuve de validité à L1 - Frais de matériel dépensés pour générer des preuves de validité.

Ajustez les frais d’attestation payés à l’agrégateur, et afin d’éviter que le séquenceur ne soit rentable à frapper, le mécanisme suivant est fourni pour ajuster les frais d’attestation payés par le séquenceur à l’agrégateur.

Il existe une méthode dans le contrat qui ajuste le coût de la fourniture d’épreuves pour les lots :

fonction _updateBatchFee(uint64 newLastVerifiedBatch) interne

Il modifie une variable du contrat appelée BatchFee, qui détermine la quantité de jetons MATIC que Sequencer paie pour chaque lot.

Le mécanisme du changement est le suivant :

Le contrat conserve une variable VeryBatchTimeTarget qui représente l’état attendu de chaque lot à valider dans ce délai après avoir été validé en L1 par Sequencer.

Le contrat enregistrera tous les lots qui n’ont pas été validés après avoir dépassé la VeryBatchTimeTarget, et le nombre total de ces lots sera enregistré en tant que DiffBatches.

Par conséquent, lorsqu’un lot est en retard, les frais de lot seront ajustés avec la formule suivante :

MultiplierBatchFee est un nombre limité à la plage de 1000~1024, qui peut être modifié par l’administrateur du contrat via la fonction setMultiplierBatchFee() :

FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin

Il convient de noter que l’utilisation de MultiplierBatchFee et de 10^3 ici permet d’obtenir la précision de l’ajustement après 3 décimales.

De même, si les lots sont en avance, le mécanisme d’ajustement batchFee correspondant sera déclenché : DiffBatches indique le nombre de lots dans l’état de vérification anticipée.

Résumé

Dans cet article, nous démêlons le mécanisme de base de Polygon zkEVM et analysons sa faisabilité pour réaliser la mise à l’échelle de calcul d’Ethereum. Dans les articles suivants, nous plongerons dans les détails de la conception du pont zkEVM, la voie de décentralisation de Sequencer, l’implémentation de zkProver, et les principes de conception de zkEVM.

——À suivre——