Annonce de fusion de Ropsten

• Ropsten sera le premier réseau de test de longue date à fusionner
• Une nouvelle chaîne phare Ropsten sera lancée le 30 mai 2022 pour qu'il y ait consensus autour du réseau
• Le 2 juin 2022, la chaîne phare Ropsten devrait ensuite être mise à niveau pour intégrer des règles de protocole compatibles avec la fusion au créneau 24000
• Après cela, une valeur Terminal Total Difficulty (TTD) sera définie pour activer la fusion sur la chaîne de preuve de travail. Les opérateurs de nœuds devront définir manuellement cette valeur pour leurs clients.
• Une autre annonce avec la valeur Terminal Total Difficulty exacte à utiliser pour la Fusion de Ropsten sera postée sur ce blog le 3 juin 2022. Les utilisateurs doivent s'attendre à ce que cette valeur TTD soit atteinte quelques jours après avoir été définie, et devrait être prêts à configurer leurs clients en conséquence dans un délai très court.

Contexte

Après des années de travail pour conférer des preuves d’enjeu à Ethereum, nous allons maintenant entrer dans la phase finale de test avec les déploiements des réseaux de test !

Ayant testé les implémentations client sur Kintsugi 🍵, Kiln 🔥🧱 et de nombreuses fourches fantômes, les équipes clients sont maintenant prêtes, grâce à La Fusion, à exécuter Ropsten, le seul réseau qui permet d'effectuer des tests de preuve de travail. Pour préparer le réseau à cette fin, une Chaîne phare Ropsten sera lancée afin qu'il y ait un consensus autour du réseau.

Si la transition se déroule en douceur sur Ropsten, deux autres réseaux de test (Goerli et Sepolia) passeront par la case preuve d'enjeu avant que ce ne soit le tour du réseau principal. D'autres réseaux de tests, comme Rinkeby et Kovan, peuvent être mis à niveau séparément par la communauté, mais les développeurs clients n'assureront plus leur suivi.

La Fusion se distingue des précédentes mises à niveau Ethereum de deux façons. Premièrement, les opérateurs de nœuds doivent mettre à niveau leurs clients de couche de consensus et leurs clients de couche d'exécution en parallèle, et non un seul des deux. Deuxièmement, la mise à niveau s'opère en deux phases : la première à une hauteur de créneau sur la Chaîne phare et la seconde en sélectionnant une valeur Total Difficulty sur la couche d'exécution.

Compte tenu de ces circonstances, le réseau Ropsten, qui est voué à devenir obsolète après La Fusion, procèdera à la mise à niveau plus tôt dans le processus de développement que les mises à niveau réseau précédentes. La communauté aura ainsi plus de temps pour se familiariser avec le processus de mise à niveau.

**Remarque **: Les versions client listées ci-dessous ne sont pas compatibles avec la transition du réseau principal Ethereum vers la preuve d'enjeu.

Informations sur la mise à niveau

Étapes

La Fusion se déroule en deux étapes. Elle commence par une mise à niveau du réseau sur la couche de consensus, déclenchée par une hauteur de créneau. Elle est suivie par la transition de la couche d'exécution de la preuve de travail vers la preuve d'enjeu, déclenchée par un seuil Total Difficulty spécifique, appelé Terminal Total Difficulty (TTD).

Le 2 juin 2022, au créneau 24000, la mise à niveau de Bellatrix préparera la Chaîne phare Ropsten à La Fusion. À ce stade, les clients CL pourront commencer à s'attendre à ce qu'une valeur TTD soit atteinte sur la chaîne de preuve de travail.

Parce que le taux de hachage des réseaux de test de preuve de travail est très volatil, la valeur TTD sera d'abord définie sur une valeur extrêmement élevée, 10000000000000000000. Au taux de hachage actuel de Ropsten, il faudrait environ 250 ans pour l'atteindre.

Une fois la mise à niveau de Bellatrix faite sur la Chaîne phare, une nouvelle valeur de TTD, qui devrait être atteinte quelques jours plus tard, sera définie et annoncée. Les utilisateurs devront alors configurer leur noeud en s'appuyant sur cette nouvelle valeur. Les instructions pour le faire avec chaque client sont disponibles ici.

Lorsque ce nouveau TTD est atteint ou dépassé sur Ropsten, la partie correspondant à la couche d'exécution de la transition répondant au nom de code Paris, sera activée. Notez une fois encore que le taux de hachage sur Ropsten est réputé être variable et que l'heure réelle à laquelle la valeur Terminal Total Difficulty sera connue peut donc fluctuer.

Une fois que la couche d'exécution a dépassé la valeur TTD, le bloc suivant sera entièrement produit par un validateur de chaîne phare. Nous considérons que La Fusion est terminée une fois que la Chaîne phare a finalisé ce bloc. En se basant sur des conditions de réseau normales, cela devrait se produire 2 époques, ou environ 13 minutes, après que le premier bloc post-TTD a été atteint !

Une nouvelle balise de bloc JSON-RPC, finalized, renvoie le dernier bloc finalisé ou une erreur s'il n'y a aucun bloc après la fusion. Les applications peuvent se servir de cette balise pour s'assurer que La Fusion est bien terminée. De même, les contrats intelligents peuvent interroger l'opcode DIFFICULTY (0x44), renommé PREVRANDAO post-fusion, pour déterminer si la fusion a eu lieu. Nous recommandons aux fournisseurs d'infrastructures de surveiller la stabilité globale du réseau en plus du statut de finalisation.

Versions client

Les versions clients suivantes sont compatibles avec La fusion sur le réseau de test Ropsten. Les opérateurs de nœuds doivent exécuter à la fois un client de couche de consensus et un client de couche d'exécution pour rester sur le réseau pendant et après La Fusion.

Comme mentionné ci-dessus, les versions suivantes ont une valeur Terminal Total Difficulty égale à 100000000000000000000000 qui devra être mise à niveau manuellement après activation de la mise à niveau de Bellatrix sur la Chaîne phare.

Lorsqu'ils choisissent le client à exécuter, les validateurs doivent être particulièrement attentifs aux risques liés à l'exécution d'un client majoritaire sur l'EL et le CL. Ces risques et leurs conséquences sont expliqués ici. Une estimation de la répartition actuelle des clients EL et CL ainsi que des guides pour le passage d'un client à un autre sont disponibles ici.

Remarque: si vous aviez précédemment téléchargé une version client avec un TTD Ropsten de 43531756765713534, vous devez actualiser votre version ou remplacer manuellement le TTD par 100000000000000000000000 comme précisé ici.

Couche de consensus

Remarque concernant Lodestar : la dernière version de Lodestar, v0.37.0, a une valeur TTD Ropsten obsolète de 43531756765713534. Pour être compatible avec la fusion de Ropsten, qui utilise maintenant une valeur TTD de 100000000000000000000000, les utilisateurs Lodestar devront remplacer cette valeur manuellement. Des instructions à ce sujet sont disponibles dans l'article de l'équipe annonçant la publication.

Couche d'exécution

Remarque concernant Lodestar : la dernière version de go-ethereum (geth), Sharblu (v1.10.18), a une valeur TTD Ropsten obsolète de 43531756765713534. Pour être compatible avec la fusion de Ropsten, qui utilise maintenant une valeur TTD de 100000000000000000000000, les utilisateurs de geth devront remplacer cette valeur manuellement:

• Partir de la source sur la dernière branche master branch
• Utiliser la dernière image Docker
• Remplacer manuellement la valeur TTD, en exécutant la commande ci-après au démarrage du client : --override.terminaltotaldifficulty 10000000000000000000.

Mise à niveau des spécifications

Les changements en vue d'un consensus crucial autour de La Fusion sont spécifiés en deux endroits :

• Au niveau de la couche de consensus, dans le répertoire bellatrix du référentiel consensus-specs
• Au niveau de la couche d'exécution, sous la spécification Paris dans le référentiel execution-specs

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

• L'API Moteur, spécifiée dans le référentiel execution-apis, est utilisée pour la communication entre les couches de consensus et les couches d'exécution
• La synchronisation optimiste, spécifiée dans le dossier sync du référentiel consensus-specs, est utilisé par la couche de consensus pour importer des blocs lorsque le client de la couche d'exécution est en phase de synchronisation et pour fournir une vue partielle de la tête de la chaîne de la première à la dernière

FAQ (Questions fréquemment posées)

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écutera une preuve d'enjeu sur la chaîne phare, et un client de couche d'exécution, qui gérera l'état utilisateur et effectuera les calculs associés aux transactions. Ces deux clients communiqueront via un port authentifié en utilisant un nouvel ensemble de méthodes RPC JSON appelé Engine API. Les clients EL et CL s'authentifient mutuellement en utilisant un secret JWT. Les opérateurs de noeuds doivent se référer à la documentation de leurs clients pour obtenir des instructions sur la manière de générer et configurer ceux-ci.

En d'autres termes, si vous exécutiez déjà un nœud sur la chaîne phare, il vous faudra désormais également exécuter un client de couche d'exécution. De même, si vous exécutiez un nœud sur le réseau PoW actuel, vous devrez exécuter un client de couche de consensus. Pour qu'ils puissent communiquer en toute sécurité, un jeton JWT doit être transmis à chaque client.

Il est utile de souligner que, bien qu'ils fassent tous deux partie des versions client de couche de consensus et client de couche d'exécution, exécuter un Nœud phare et exécuter un Client Validateur sont deux choses distinctes. Les validateurs doivent exécuter les deux, mais les opérateurs de nœuds n'ont besoin que du premier. Cet article explique la différence entre les deux composantes de manière plus détaillée.

À noter également que chaque couche conservera un ensemble indépendant de pairs et présentera ses propres API. Les API phares et RPC JSON continueront donc à fonctionner comme prévu.

Enfin, n'oubliez pas de vous reconnecter les 6 et 7 juin pour découvrir la valeur TTD Ropsten définitive sur ce blog.

En tant que validateur, que dois-je faire?

Comme expliqué ci-dessus, les validateurs de la Chaîne phare devront exécuter un client de couche d'exécution après La Fusion, en plus de leurs clients de couche de consensus avant la fusion. C'est ce qui a été vivement recommandé, mais les validateurs auraient pu sous-traiter ces fonctions à des prestataires tiers. Ceci parce que les mises à jour du contrat de dépôt étaient les seules données requises sur la couche d'exécution.

Après La Fusion, les validateurs devront s'assurer que les transactions dans les blocs qu'ils créent et approuvent sont valides. Pour ce faire, chaque noeud de balise doit être associé à un client de couche d'exécution. Notez que même s'il y a plusieurs validateurs, ils ne peuvent être associés qu'à une seule combinaison de nœud de balise & client de couche d'exécution. Bien que cette configuration implique davantage de responsabilités pour les validateurs, elle permet également au validateur qui propose un bloc d'avoir droit aux frais de transaction prioritaire associés (actuellement attribuées aux mineurs).

Si les récompenses du validateur s'accumulent sur la chaîne phare et qu'une mise à niveau ultérieure sera nécessaire pour les récupérer, les frais de transaction continueront pour leur part à être payés, brûlés et distribués sur la couche d'exécution. Las validateurs pourront ainsi renseigner n'importe quelle adresse Ethereum comme destinataire des frais de transaction.

Après avoir mis à jour votre client de consensus, veillez à associer le fee recipient aux configurations de votre client validateur afin de vous assurer que les frais de transaction sont bien envoyés à une adresse sur laquelle vous avez la main.

Si vous avez misé sur un fournisseur tiers, il appartient au fournisseur que vous avez sélectionné de préciser comment ces frais sont alloués.

Les mises à niveau du réseau de test offrent aux validateurs une dernière chance de s'assurer que leurs configurations fonctionnent comme prévu et de résoudre les problèmes. Des informations sur l'exécution d'un validateur sur la chaîne phare Ropsten en prévision de la fusion sont disponibles ici.

Nous recommandons vivement aux validateurs du réseau principal de passer par La Fusion sur Ropsten et d'autres réseaux de test avant la transition du réseau principal Ethereum vers la preuve d'enjeu.

En tant que développeur d'applications ou d'outils, que dois-je faire?

Avec la mise en ligne de Kiln, l'heure est venue de vérifier que votre produit fonctionnera comme il se doit lors de la transition vers la preuve d'enjeu et dans une configuration post-fusion. Comme expliqué dans un article précédent, La Fusion n'aura que des répercussions minimes sur un sous-ensemble de contrats déployés sur Ethereum, dont aucun ne devrait être interrompu. De plus, la majeure partie des points de terminaison d'API utilisateur resteront stables (à condition que vous n'utilisiez pas de méthodes propres à la preuve de travail [PoW], telles que eth_getWork).

Cela étant, la plupart des applications sur Ethereum impliquent bien plus que des contrats en chaîne. Le moment est venu de vous assurer que votre code front-end, vos outils, votre pipeline de déploiement et vos autres composants hors chaîne fonctionnent correctement. Nous recommandons vivement aux développeurs d'effectuer un cycle de test & de déploiement complet sur Ropsten (ou Kiln), et de signaler tout problème d'outils ou de dépendances aux responsables de ces projets. Si vous n'êtes pas sûr de savoir où signaler un problème, veuillez utiliser ce référentiel.

En tant qu'utilisateur d'Ethereum ou que détenteur d'Ether, dois-je faire quoi que ce soit ?

Non. Le réseau principal Ethereum n'est pas affecté par ce réseau de test. D'autres annonces seront publiées sur ce blog avant la transition du réseau principal.

En tant que mineur, dois-je faire quoi que ce soit ?

Non. Si vous minez sur le réseau principal Ethereum ou sur Ropsten, vous devez savoir que chaque réseau fonctionnera entièrement sous sa preuve d'enjeu après La Fusion. Il ne sera alors plus possible de miner sur le réseau.

Ceci à partir du 8 juin 2022 environ sur Ropsten et plus tard cette année pour le réseau principal Ethereum.

En tant que validateur, puis-je retirer ma mise ?

Non. La Fusion est la mise à niveau d'Ethereum la plus complexe à ce jour. Pour réduire au maximum les risques de perturbation du réseau, une approche minimale a été adoptée.

Les retraits de la chaîne phare seront très probablement intégrés à la première mise à niveau qui suivra La Fusion. Les spécifications des couches de consensus et d'exécution sont en cours.

J'ai d'autre question, à qui puis-je les poser ?

Une réunion en ligne dédiée à la Fusion est prévue le 3 juin à 14h00 UTC. Des développeurs de clients et des chercheurs répondront aux questions des opérateurs de nœuds, des validateurs, des fournisseurs d'infrastructure & d'outillage et des membres de la communauté.

Quand La Fusion aura-t-elle lieu ?

À la date de publication de cet article, la date de la transition du réseau principal Ethereum vers la preuve d'enjeu n'a pas été définie. Toute source qui prétendrait le contraire relèverait vraisemblablement de l'escroquerie. Des mises à jour de l'évolution de la situation seront publiées sur ce blog. Soyez prudents !

En supposant qu'aucun problème ne soit détecté avec Ropsten, une fois les tests clients terminés, les autres réseaux de test Ethereum fusionneront. Lorsque la transition de ces réseaux de test sera terminée et qu'ils seront stabilisés, et, à nouveau, en supposant qu'aucun problème ne soit décelé, une valeur difficulty sera définie en vue de la transition du réseau principal. Les clients proposeront alors des versions qui activent La Fusion sur le réseau principal. Celles-ci seront annoncées sur ce blog et dans d'autres publications communautaires.

Ceci suppose qu'aucun problème n'a été trouvé. Si toutefois des problèmes venaient à être décelés à quelque moment du processus que ce soit ou si la couverture de test était jugée insuffisante, ces problèmes seront traités avant de poursuivre le processus de déploiement.

Ce n'est qu'alors qu'il sera possible d'estimer une date précise pour La Fusion.

En d'autres termes, 🔜.