Lumoz complète la mise à niveau majeure d'Etrog
TechFlow SélectionTechFlow Sélection
Lumoz complète la mise à niveau majeure d'Etrog
Cette mise à jour améliore la compatibilité entre Polygon zkEVM et Ethereum, apporte d'importantes optimisations en matière d'exécution et d'efficacité des requêtes pour les nœuds, et élargit également les possibilités au sein de l'écosystème Polygon CDK.
Dédié à des analyses Web3 approfondies
Aperçu de la mise à niveau Etrog
En tant que composant clé de l'écosystème Polygon CDK, Lumoz suit attentivement chaque mise à jour de Polygon CDK, effectue des recherches approfondies, développe et optimise en continu, tout en expliquant au grand public les détails techniques de ces mises à jour de manière accessible. L'objectif est de clarifier complètement le chemin de migration des premières versions de CDK Validium vers la version Etrog, élargissant ainsi efficacement les frontières du développement non seulement de Polygon CDK mais aussi de l'industrie blockchain dans son ensemble.
La mise à niveau Etrog de Polygon zkEVM a été finalisée en février 2024. Il s'agit de la mise à jour la plus importante depuis le lancement du réseau principal de Polygon zkEVM. Elle ajoute le support de plusieurs contrats précompilés au niveau du circuit sous-jacent, optimise les mécanismes d’empaquetage et de production de blocs de la chaîne, et restructure entièrement l’architecture des contrats intelligents. Cette mise à jour pose les bases nécessaires pour les fonctionnalités futures de l’écosystème Polygon CDK, notamment AggLayer et Unified Bridge. Globalement, cette mise à jour améliore la compatibilité entre Polygon zkEVM et Ethereum, apporte d’importantes optimisations en termes d’exécution et d’efficacité des requêtes pour les nœuds, et élargit les possibilités offertes par l’écosystème Polygon CDK.
Cet article analyse en profondeur les détails techniques de cette mise à jour à partir des perspectives des contrats intelligents et du code des nœuds de Polygon zkEVM. Il présente également, sur la base de solutions open source de mise à niveau de Rollup, un aperçu complet du processus de migration des premières versions de CDK Validium vers la version Etrog.
Restructuration des contrats
Avant la mise à niveau Etrog, les contrats intelligents de Polygon zkEVM étaient principalement divisés en deux parties : les contrats de consensus et les contrats de pont.
Contrat de consensus
Le contrat de consensus enregistre la majorité des informations de la chaîne de niveau 2, y compris des données basiques comme l’identifiant de chaîne, la version, ainsi que l’état en temps réel tel que les lots (batches) et les soumissions de preuves. Pour ce qui est du mode Validium, les données brutes des transactions ne sont pas stockées dans ce contrat, mais conservées hors chaîne par un groupe de nœuds DA via un contrat supplémentaire appelé « committee ». En combinant ces informations de base et l’état actuel, toute personne peut entièrement reconstruire l’état de la chaîne de niveau 2.
Contrat de pont
Le contrat de pont gère l’état racine des retraits (exit root), enregistrant tous les états inter-chaînes entre la couche 1 et la couche 2, et permettant le transfert d’actifs entre ces deux couches selon un modèle Lock/Mint. Les nœuds fils de l’exit root sont mis à jour conjointement par le contrat de pont et le contrat de consensus : le premier maintient l’état des dépôts (deposit) de la couche 1 vers la couche 2, tandis que le second met à jour l’état des retraits (withdraw) de la couche 2 vers la couche 1 grâce aux preuves ZK soumises.
La modification la plus significative apportée par la mise à niveau Etrog au niveau des contrats est l’introduction d’un schéma multi-réseaux. Une même suite de contrats peut désormais gérer plusieurs réseaux de niveau 2 au lieu d’un seul, et grâce au nouveau Unified Bridge, assurer l’interopérabilité des actifs entre ces réseaux, posant ainsi une base solide pour l’évolution future de l’écosystème.
Comme l’architecture initiale des contrats ne supportait pas le déploiement multi-réseaux, la mise à niveau Etrog a entraîné une refonte complète de la structure contractuelle :
-
Introduction du contrat RollupManager pour gérer les informations de tous les réseaux de niveau 2 ;
-
Modification de la structure du contrat de pont et de GlobalExitRoot afin qu’ils puissent maintenir les états inter-chaînes de tous les réseaux, garantissant ainsi l’interopérabilité des actifs entre différents réseaux de niveau 2.
Pour plus de détails sur la structure des contrats, voir ici
Pour les réseaux de niveau 2 Polygon zkEVM fonctionnant avec une version antérieure à Etrog, ces modifications ont un impact important sur les données contractuelles, rendant la stratégie de mise à niveau particulièrement complexe. Nous allons donc détailler séparément les aspects spécifiques de cette mise à jour, en nous concentrant sur les contrats de consensus et de pont.
Contrat de consensus
La modification la plus notable du contrat de consensus dans la mise à niveau Etrog est l’introduction du nouveau contrat RollupManager. Comme la plupart des opérations de gestion des permissions sont désormais centralisées dans ce contrat, la procédure officielle de mise à jour consiste à remplacer l’implémentation du proxy Polygon zkEVM existant par le contrat RollupManager. Un nouveau contrat de sous-réseau, PolygonZkEVMExistentEtrog, est alors déployé comme nouveau contrat de consensus du réseau initial. Lors de l’initialisation du nouveau contrat RollupManager, les informations globales du réseau Rollup sont inscrites. Comparé au contrat standard de niveau 2 post-Etrog (PolygonZkEVMEtrog), PolygonZkEVMExistentEtrog implémente une méthode supplémentaire, initializeUpgrade, destinée à gérer la logique de transition durant la mise à niveau.
Afin de préserver la cohérence des emplacements (slots) des variables dans le proxy après mise à jour, RollupManager hérite du contrat LegacyZKEVMStateVariables, conçu spécifiquement pour stocker les variables de l’ancienne version. Par ailleurs, pour garantir la continuité de l’état des batches avant et après la mise à jour, RollupManager effectue lors de son initialisation une série d’opérations visant à réaffecter les données historiques dans les nouveaux contrats. Une batch forcée (forcedBatch) est également générée sur la couche 1 selon les nouvelles règles, servant de transition pour la mise à niveau Etrog et devant être traitée par les nœuds.
Contrat de pont
La mise à niveau Etrog confère au contrat de pont la capacité de définir un jeton personnalisé pour le gas. Elle modifie également le schéma de génération du globalExitRoot, garantissant la compatibilité avec la mise à jour des racines de sortie de plusieurs chaînes de niveau 2 tout en préservant la cohérence des données existantes, permettant ainsi l’interopérabilité des actifs entre plusieurs réseaux de niveau 2.
Mise à jour des nœuds
Du côté des nœuds, la mise à niveau Etrog met principalement à jour les modules sequencer et synchronizer, et inclut également une mise à jour de l’ABI des contrats afin d’interagir avec les nouvelles versions des contrats.
Module sequencer
-
Cette mise à jour modifie la logique d’empaquetage des blocs et des batches. Avant Etrog, chaque bloc de niveau 2 contenait une seule transaction, et le temps du bloc coïncidait avec celui du batch auquel il appartenait. Ce modèle, très différent de celui d’Ethereum, était peu compatible avec les applications courantes qui parcourent les transactions par bloc. À partir d’Etrog, la logique d’empaquetage a été revue : les blocs sont désormais produits à intervalles fixes et peuvent contenir plusieurs transactions, résolvant ainsi les problèmes d’incompatibilité présents dans les versions antérieures.
-
Module synchronizer
Les modifications apportées au module synchronizer se divisent en deux volets. Le premier concerne l’adaptation aux événements des nouveaux contrats et à leur traitement, notamment la gestion du batch de transition, des nouveaux événements de soumission de batch/preuve, et de la mise à jour de l’info_tree. Le second volet porte sur une refonte complète de la logique de synchronisation. Dans les versions précédentes à Etrog, la synchronisation était entièrement séquentielle : pour les nœuds permissionless, la synchronisation des données manquantes depuis le nœud principal ne pouvait commencer qu’après avoir complètement reçu toutes les données de la couche 1, ordonnées par batch. Cela introduisait systématiquement un délai entre les nœuds. La mise à niveau Etrog repense entièrement cette logique, en dissociant les tâches de synchronisation de la couche 1 et de la couche 2 dans des threads distincts. Cela résout le problème de latence tout en accélérant la synchronisation des données de la couche 1.
Mise à niveau CDK Validium par Lumoz
Les réseaux zkEVM standards peuvent utiliser directement le code open source du dépôt officiel pour effectuer la mise à jour. Toutefois, aucune solution officielle n’est fournie pour la mise à jour des réseaux Validium. Après recherche et développement, l’équipe Lumoz a élaboré une solution complète pour la mise à jour Validium, et a réussi à mettre à jour plusieurs testnets basés sur CDK Validium ainsi que le réseau principal Merlin. Cette section décrit en détail le chemin spécifique de mise à jour pour Validium.
Implémentation du code
Côté contrats
La stratégie de mise à jour pour Validium s’inspire largement des modifications apportées aux Rollups officiels, avec la création d’un contrat PolygonValidiumExistentEtrog adapté au consensus Validium. Ce contrat s’appuie sur le contrat original CDKValidium et, comme zkEVMExistentEtrog, implémente une méthode initializeUpgrade. Lors de l’exécution de la transaction de mise à jour, les données historiques sont transférées, et un batch de transition est généré pour être traité par les nœuds. Contrairement à zkEVM, dans la nouvelle version de CDK Validium, l’adresse du DataCommittee est gérée par le contrat nouvellement déployé PolygonValidiumExistentEtrog. Ainsi, lors de la mise à jour, il faut réaffecter l’adresse originale du CDKDataCommittee à la variable dataAvailabilityProtocol.
Côté nœuds
Le nouveau code officiel des nœuds Validium ne prend pas en charge le traitement de l’événement updateEtrogSequence, ce qui empêche une utilisation directe. Toutefois, il est possible d’implémenter cette logique en s’inspirant du traitement utilisé pour les Rollups. Par ailleurs, il est nécessaire de modifier les ABI des contrats utilisés dans le code afin de les adapter aux interfaces des contrats Validium, remplaçant ainsi celles des contrats Rollup.
Attention : si l’on choisit de sauter Etrog pour passer directement à une version supérieure à Eldberry, certaines modifications supplémentaires doivent être apportées aux nœuds, car la façon de traiter les données des batches diffère. Pendant la mise à jour du contrat, le forcedBatch généré sur la couche 1 est encore produit selon le format Etrog. Lors du traitement de ce batch, le nœud ne doit pas utiliser le processeur par défaut d’Eldberry, mais bien revenir temporairement au processeur de la version Etrog, faute de quoi des incompatibilités surviendraient.
Procédure de mise à niveau
Avant la mise à niveau, il est nécessaire de déployer au préalable tous les nouveaux contrats sur la couche 1 et sur le réseau de niveau 2, notamment RollupManager, ValidiumExistentEtrog, GlobalExitRootV2 et BridgeV2. On peut suivre les scripts officiels de mise à jour en remplaçant simplement les contrats zkEVM par leurs équivalents Validium. Une fois les contrats déployés, on pré-génère la transaction de mise à jour du proxy CDKValidium sur la couche 1, en appelant la nouvelle méthode initialize pour réaffecter les données et générer le batch de transition. Ensuite, une adresse autorisée du contrat Timelock appelle la méthode schedule pour planifier la transaction, puis attend la période de verrouillage du contrat. De manière similaire, sur la couche 2, on pré-génère également la transaction de mise à jour du contrat de pont, qui est programmée via le contrat Timelock local.
Étant donné que la logique d’initialisation de RollupManager vérifie que la dernière preuve a bien été soumise — afin d’assurer que l’exécution des batches et des preuves reste cohérente avant et après la mise à niveau — certains ajustements doivent encore être effectués sur les nœuds de confiance après l’expiration du délai. Pour minimiser le temps d’arrêt, on peut préconfigurer le paramètre StopSequencerOnBatchNum dans le service sequencer, afin qu’il cesse d’empaqueter les transactions dès qu’un certain numéro de batch est atteint, laissant ainsi suffisamment de temps pour soumettre le batch et sa preuve correspondante. Par ailleurs, comme les fichiers de migration de pool_db ont été modifiés entre les anciennes et nouvelles versions de Validium, il est nécessaire de supprimer manuellement ou via le code des nœuds les enregistrements liés à 'supernets-0001.sql' dans la base de données, afin d’harmoniser la structure avec celle attendue par la nouvelle version du nœud.
Une fois que la preuve est à jour et que la base de données est nettoyée, une adresse autorisée du contrat Timelock sur la couche 1 peut appeler la méthode execute pour réaliser la mise à jour planifiée, mettre à jour tous les fichiers de configuration, et simultanément mettre à jour toutes les instances des services des nœuds de confiance. Dès que ces nœuds retrouvent leur fonctionnement normal et recommencent à empaqueter les transactions, tous les nœuds permissionless doivent également mettre à jour leurs configurations et redémarrer leurs services avec la nouvelle version du code. Enfin, la mise à jour du contrat de pont sur la couche 2 peut être exécutée une fois le délai défini par Timelock écoulé, en appelant la méthode execute.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@LumozOrg
