Annonce du Merge sur Ropsten : Une étape clé pour l’avenir d’Ethereum !

Ropsten et la Révolution de The Merge

• Ropsten deviendra le premier testnet pérenne à traverser The Merge.
• Une nouvelle Ropsten Beacon Chain a été lancée le 30 mai 2022 pour assurer le consensus du réseau.
• La Ropsten Beacon Chain sera mise à niveau pour adopter les règles de protocole compatibles avec The Merge (Bellatrix) au slot 24000, prévu pour le 2 juin 2022.
• Par la suite, une difficulté totale terminale (TTD) sera définie pour activer The Merge sur la chaîne proof-of-work. Les opérateurs de nœuds devront manuellement paramétrer cette valeur sur leurs clients.
• Mise à jour du 3 juin : la difficulté totale terminale exacte pour le Merge de Ropsten est 50000000000000000. Un communiqué ultérieur expliquera comment les opérateurs de nœuds et les stakers peuvent préparer leurs clients pour la mise à niveau. Merci d’actualiser la TTD de votre client avant le 7 juin 2022.

Contexte

Après des années de travail pour intégrer le proof-of-stake à Ethereum, nous entrons enfin dans la phase ultime de test : les déploiements sur testnet !

Après avoir testé des implémentations sur Kintsugi 🍵, Kiln 🔥🧱 et de nombreuses shadow forks, les équipes de clients sont désormais prêtes à faire passer Ropsten – le plus ancien testnet proof-of-work – par The Merge. En préparation, une Ropsten Beacon Chain a été lancée pour garantir le consensus du réseau.

À l’issue de la transition de Ropsten, deux autres testnets (Goerli et Sepolia) seront également migrés vers le proof-of-stake avant que l’attention ne se concentre sur le mainnet. D’autres testnets, comme Rinkeby et Kovan, pourront être maintenus et mis à jour séparément par la communauté, mais ne seront plus sous la surveillance des développeurs de clients.

The Merge se distingue des précédentes mises à niveau d’Ethereum sur deux points. Tout d’abord, les opérateurs de nœuds doivent mettre à jour à la fois leurs clients de consensus et d’exécution simultanément, plutôt que l’un des deux. Ensuite, cette mise à niveau se déroule en deux phases : la première lors d’un certain slot sur la Beacon Chain et la seconde lorsque la valeur de la difficulté totale est atteinte sur la couche d’exécution.

Dans ces conditions, le réseau Ropsten, prévu pour être décommissionné après The Merge, sera mis à niveau plus tôt dans le processus de développement que les précédentes mises à niveau réseau. Cela permettra à la communauté de mieux s’acclimater à ce processus de mise à niveau.

Informations sur la Mise à Niveau

Calendrier

The Merge s’effectue en deux étapes. Il débute par une mise à niveau du réseau au niveau de la couche de consensus, déclenchée par un niveau de slot. Il est ensuite suivi par la transition de la couche d’exécution, qui passe du proof-of-work au proof-of-stake, étant déclenchée par un seuil de difficulté totale, appelé difficulté totale terminale (TTD).

Le 2 juin 2022, au slot 24000, la mise à niveau Bellatrix préparera la Ropsten Beacon Chain pour The Merge. À ce moment-là, les clients de consensus commenceront à écouter une valeur de TTD à atteindre sur la chaîne proof-of-work.

Étant donné que le taux de hachage des testnets proof-of-work est très volatile, la valeur de la TTD sera initialement fixée à une valeur très élevée, 100000000000000000000000. Avec le taux de hachage actuel de Ropsten, il faudrait environ 250 ans pour y parvenir.

Une fois la mise à niveau Bellatrix effectuée sur la Beacon Chain, une nouvelle valeur de TTD, qui devrait être atteinte quelques jours plus tard, sera sélectionnée et annoncée. Les utilisateurs devront alors configurer leur nœud avec cette nouvelle valeur. Les instructions pour ce faire avec chaque client sont disponibles.

Lorsque cette nouvelle TTD sera atteinte ou dépassée sur Ropsten, la partie de la transition relative à la couche d’exécution, nommée Paris, débutera. À noter que le taux de hachage sur Ropsten est notoirement variable, donc le moment exact de la difficulté totale terminale peut fluctuer.

Une fois que la couche d’exécution aura dépassé la TTD, le prochain bloc sera produit uniquement par un validateur de la Beacon Chain. Nous considérons que The Merge est complet une fois que la Beacon Chain a finalisé ce bloc. Dans des conditions normales de réseau, cela devrait se produire 2 epochs, soit environ 13 minutes, après le premier bloc post-TTD !

Un nouveau tag JSON-RPC de bloc, finalized, retourne le dernier bloc finalisé ou une erreur si aucun bloc post-merge n’existe. Ce tag peut être utilisé pour que les applications vérifient si The Merge a été complété. De plus, les contrats intelligents peuvent interroger l’opcode DIFFICULTY (0x44), renommé en PREVRANDAO après la fusion, pour déterminer si The Merge a eu lieu. Nous recommandons aux fournisseurs d’infrastructures de surveiller la stabilité générale du réseau en plus de l’état de finalisation.

Versions des Clients

Les versions suivantes des clients prennent en charge The Merge sur le testnet Ropsten. Les opérateurs de nœuds doivent exécuter à la fois un client d’exécution et un client de consensus pour rester sur le réseau durant et après The Merge.

Note Lodestar : la dernière version de Lodestar, v0.37.0, possède une valeur TTD obsolète pour Ropsten de 43531756765713534. Pour être compatible avec le Merge de Ropsten, qui utilise maintenant une TTD de 100000000000000000000000, les utilisateurs de Lodestar devront manuellement remplacer cette valeur. Les instructions pour ce faire se trouvent dans le post d’annonce de l’équipe.

Couche d’Exécution

Note Geth : la dernière version de go-ethereum (geth), Sharblu (v1.10.18), a une valeur TTD obsolète pour Ropsten de 43531756765713534. Pour être compatible avec le Merge de Ropsten, qui utilise maintenant une TTD de 100000000000000000000000, les utilisateurs de geth doivent soit :

• Compiler à partir de la source sur la dernière branche master
• Utiliser la dernière image Docker
• Remplacer manuellement la TTD, en utilisant la commande suivante lors du démarrage du client : –override.terminaltotaldifficulty 100000000000000000000000.

Spécifications de la Mise à Niveau

Les changements critiques de consensus pour The Merge sont spécifiés à deux endroits :

• Les modifications de la couche de consensus, sous le répertoire bellatrix du dépôt consensus-specs
• Les modifications de la couche d’exécution, sous la spécification Paris dans le dépôt execution-specs

En plus de cela, deux autres spécifications couvrent la manière dont les clients de la couche de consensus et de la couche d’exécution interagissent :

• L’API Engine, spécifiée dans le dépôt execution-apis, utilisée pour la communication entre les couches de consensus et d’exécution
• Optimistic Sync, spécifié dans le dossier sync du dépôt consensus-specs, utilisée par la couche de consensus pour importer des blocs pendant que le client de la couche d’exécution se synchronise, fournissant ainsi une vue partielle de la tête de la chaîne.

FAQ

En tant qu’opérateur de nœud, que dois-je faire ?

Après la fusion, un nœud Ethereum complet combinera un client de couche de consensus, qui exécute la Beacon Chain proof-of-stake, et un client de couche d’exécution, qui gère l’état utilisateur et exécute les calculs associés aux transactions. Ces deux éléments communiqueront via un port authentifié en utilisant un nouvel ensemble de méthodes JSON RPC appelées API Engine. Les clients de la couche d’exécution et de la couche de consensus s’authentifient mutuellement à l’aide d’un secret JWT. Les opérateurs de nœuds doivent se référer à la documentation de leurs clients pour des instructions sur la manière de générer et de configurer ces composants.

Autrement dit, si vous exécutez déjà un nœud sur la Beacon Chain, vous devrez également exécuter un client de couche d’exécution. De même, si vous exécutiez un nœud sur le réseau proof-of-work actuel, vous devrez exécuter un client de couche de consensus. Pour garantir leur communication sécurisée, un token JWT devra être transmis à chaque client.

Il est important de noter que bien qu’ils fassent tous deux partie des versions de clients de la couche de consensus, l’exécution d’un nœud Beacon est distincte de celle d’un client validateur. Les stakers doivent exécuter les deux, mais les opérateurs de nœuds ont seulement besoin du premier. Ce post détaille la différence entre ces deux composants.

Enfin, chaque couche maintiendra un ensemble de pairs indépendant et exposera ses propres API. Les API Beacon et JSON RPC continueront de fonctionner comme prévu.

Assurez-vous de vérifier le 3 juin pour une annonce sur ce blog concernant la valeur finale de TTD pour Ropsten.

En tant que staker, que dois-je faire ?

Comme expliqué précédemment, les validateurs sur la Beacon Chain devront exécuter un client de couche d’exécution après The Merge, en plus de leurs clients de couche de consensus. Avant la fusion, cela était fortement recommandé, mais les validateurs pouvaient externaliser ces fonctions à des fournisseurs tiers car uniquement les mises à jour concernant le contrat de dépôt étaient nécessaires sur la couche d’exécution.

Post-fusion, les validateurs doivent s’assurer que les transactions dans les blocs qu’ils créent et attestent sont valides. Pour cela, chaque nœud Beacon doit être associé à un client de couche d’exécution. Notez que plusieurs validateurs peuvent toujours être associés à une combinaison unique de nœud Beacon et de client de couche d’exécution. Bien que cela élargisse les responsabilités des validateurs, cela offre également à celui qui propose un bloc le droit de percevoir des frais de priorité associés aux transactions (qui vont actuellement aux mineurs).

Alors que les récompenses de validation s’accumulent sur la Beacon Chain et nécessiteront une mise à niveau réseau ultérieure pour être retirées, les frais de transaction continueront d’être payés, brûlés et distribués sur la couche d’exécution. Les validateurs peuvent spécifier n’importe quelle adresse Ethereum comme destinataire des frais de transaction.

Après avoir mis à jour votre client de consensus, assurez-vous de définir le destinataire de frais dans les configurations de votre client valideur pour s’assurer que les frais de transaction sont envoyés à une adresse que vous contrôlez.

Si vous avez staké par l’intermédiaire d’un fournisseur tiers, il appartient à ce fournisseur de spécifier comment ces frais seront alloués.

Les mises à niveau du testnet sont la dernière occasion pour les validateurs de s’assurer que leurs configurations fonctionnent comme prévu et de résoudre les problèmes le cas échéant. Des informations sur l’exécution d’un valideur sur la Ropsten Beacon Chain en préparation de The Merge peuvent être trouvées sur le lanceur de staking Ropsten.

Nous recommandons fortement aux validateurs du mainnet de passer par The Merge sur Ropsten et sur d’autres testnets avant que le mainnet Ethereum ne bascule vers le proof-of-stake.

En tant que développeur d’application ou d’outils, que dois-je faire ?

Avec le lancement de The Merge sur Ropsten, il est temps de s’assurer que votre produit fonctionne comme prévu durant la transition vers le proof-of-stake et dans un contexte post-fusion. Comme expliqué dans un post antérieur, The Merge n’aura qu’un impact minimal sur un sous-ensemble de contrats déployés sur Ethereum, aucun d’entre eux ne devrait poser de problème. De plus, la plupart des points de terminaison d’API utilisateur restent stables (à moins que vous n’utilisiez des méthodes spécifiques au proof-of-work telles que eth_getWork).

Cela dit, la plupart des applications sur Ethereum impliquent bien plus que des contrats on-chain. Le moment est venu de s’assurer que votre code front-end, vos outils, votre pipeline de déploiement et autres composants off-chain fonctionnent comme prévu. Nous recommandons vivement aux développeurs de passer par un cycle de test et de déploiement complet sur Ropsten (ou Kiln) et de signaler tout problème avec les outils ou dépendances aux mainteneurs de ces projets. Si vous ne savez pas où soumettre un problème, veuillez utiliser ce dépôt.

En tant qu’utilisateur Ethereum ou détenteur d’Ether, dois-je faire quelque chose ?

Non. Le mainnet Ethereum n’est pas affecté par ce testnet. D’autres annonces seront faites sur ce blog avant la transition du mainnet.

En tant que mineur, dois-je faire quelque chose ?

Non. Si vous minez sur le mainnet Ethereum ou Ropsten, sachez que chaque réseau fonctionnera entièrement sous proof-of-stake après The Merge. À ce moment-là, le minage ne sera plus possible sur le réseau.

Cela est prévu autour du 8 juin 2022 sur Ropsten et plus tard cette année pour le mainnet Ethereum.

En tant que valideur, puis-je retirer mon stake ?

Non. The Merge est la mise à niveau la plus complexe d’Ethereum à ce jour. Pour minimiser les risques de perturbation de réseau, une approche minimale a été adoptée, excluant tout changement non relatif à la transition de cette mise à niveau.

Les retraits de la Beacon Chain seront probablement introduits lors de la première mise à niveau après The Merge. Les spécifications pour les couches consensus et exécution sont en cours de développement.

J’ai d’autres questions, où puis-je les poser ?

Une appel communautaire Merge est programmé pour le 3 juin à 14h00 UTC. Les développeurs de clients et les chercheurs seront disponibles pour répondre aux questions des opérateurs de nœuds, des stakers, des fournisseurs d’infrastructure et d’outils ainsi que des membres de la communauté.

Quand aura lieu The Merge ?

Au moment de la publication de ce post, la date de transition du mainnet Ethereum vers le proof-of-stake n’a pas été fixée. Toute source prétendant le contraire est probablement une escroquerie. Des mises à jour seront publiées sur ce blog. Veuillez rester vigilant !

En supposant qu’aucun problème ne soit détecté avec Ropsten, une fois que les tests des clients seront complétés, d’autres testnets d’Ethereum, passeront par The Merge. Une fois que Goerli et Sepolia auront réussi leur transition et stabilisé, un slot sera choisi pour la mise à niveau Bellatrix sur la Beacon Chain et une valeur de difficulté sera définie pour la transition du mainnet. Les clients effectueront alors des mises à jour permettant The Merge sur le mainnet. Ces annonces seront publiées sur ce blog et dans d’autres publications communautaires.

Cela suppose qu’aucun problème ne soit trouvé. Cela dit, si des problèmes sont détectés à n’importe quel moment du processus ou si la couverture des tests est jugée insuffisante, ces éléments seront traités avant de continuer le processus de déploiement.

Ce n’est qu’ainsi qu’il sera possible d’estimer la date exacte de The Merge.

En d’autres termes, 🔜.