Annonce de fusion du réseau principal

• Ethereum passe à la preuve d'enjeu ! La transition, connue sous le nom de « Fusion », doit d'abord être activée sur la Chaîne phare avec la mise à niveau de Bellatrix. Après cela, la chaîne de preuve de travail migrera vers la preuve d'enjeu après avoir atteint une valeur Total Difficulty spécifique.
• La mise à niveau Bellatrix est prévue pour l'époque 144896, attendue sur la Chaîne phare - 11 h 34 min 47 s UTC le 6 septembre 2022.
• La valeur Terminal Total Difficulty qui déclenche La fusion est de 58750000000000000000000. Elle est attendue entre les 10 et 20 sept. 2022.
• Remarque : comme annoncé plus tôt, le réseau de test Kiest est en passe d'être obsolète. Les opérateurs le fermeront le 6 septembre 2022.

Contexte

Après des années de dur labeur, la mise à niveau vers la preuve d'enjeu d'Ethereum est enfin là ! Tous les réseaux de test publics ont désormais été mis à niveau et l'heure de La Fusion du réseau principal Ethereum a sonné.

La Fusion se distingue des précédentes mises à niveau sur deux points. Pour commencer, les opérateurs de nœuds doivent mettre à niveau leurs clients de couche de consensus (CL) et leurs clients de couche d'exécution (EL) en parallèle, et non un seul des deux. Ensuite, la mise à niveau s'opère en deux phases : la première, appelée Bellatrix, à une hauteur d'époque sur la chaîne phare et la seconde, appelée Paris, en atteignant une valeur Total Difficulty sur la couche d'exécution.

Informations sur la mise à niveau

Étapes

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

La mise à niveau Bellatrix est prévue pour l'époque 144896 sur la Chaîne phare - 11 h 34 min 47 s UTC le 6 septembre 2022.

Paris, la portion de la transition de la couche d'exécution, sera déclenchée par la valeur de Terminal Total Difficulty (TTD) de 58750000000000000000000, attendue entre les 10 et 20 sept. 2022. La date exacte à laquelle la valeur TTD est atteinte dépend du taux de hachage de preuve de travail. Des estimations relatives à la transition sont disponibles à bordel.wtf et 797.io/themerge.

Lorsque la couche d'exécution atteindra ou dépassera la valeur TTD, le bloc suivant sera produit par un validateur sur la chaîne phare. La transition vers la fusion est considérée comme terminée lorsque la Chaîne phare finalise ce bloc. Dans des conditions de réseau normales, cela produira 2 époques, soit environ 13 minutes, après que le premier bloc post-TTD a été produit !

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 terminée. De même, les contrats intelligents peuvent interroger l'opcode DIFFICULTY (0x44), renommé PREVRANDAO après La 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 principal Ethereum. 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.

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.

Couche de consensus

Couche d'exécution

Warning : la version v1.10. 2 de geth présente un problème notable au niveau de la base de données, n'utilisez pas cette version, et si vous avez déjà procédé à la mise à niveau, veuillez effectuer une nouvelle mise à jour et passer à la version 1.10.23 dès que possible.

Spécifications relatives à la mise à niveau

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

• Les changements au niveau de la couche de consensus, dans le dossier Bellatrix du référentiel consensus-specs
• Au niveau de la couche d'exécution, sous la spécification Paris spec 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

Fusionner le Bonus de Prime au signalement de bugs

Toutes les primes pour signalement de vulnérabilités liées à la Fusion sont multipliées par 4 jusqu'au 8 septembre. Les bugs critiques valent maintenant jusqu'à 1 million USD.

Pour en savoir plus, voir le programme de primes au signalement de bugs.

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 (CL), qui exécutera une preuve d'enjeu sur la chaîne phare, et un client de couche d'exécution (EL), 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 cette valeur.

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 preuve de travail 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. Une mise à jour de la section « Exécuter un nœud » du site ethereum.org explicite ces étapes plus en détail.

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.

En tant que staker, que dois-je faire ?

Comme expliqué ci-dessus, les validateurs sur 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 des utilisateurs et les blocs de transitions d'état 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 phare & client de couche d'exécution. Bien que cela implique davantage de responsabilités de la part des 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 continuent de s'accumuler sur la chaîne phare et qu'une mise à niveau ultérieure s'immpose 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 mise à jour de votre client de consensus, veillez à définir le fee recipient dans le cadre des 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 de quelle manière ces frais sont alloués.

La plateforme de lancement est dotée d'une Liste de vérification de la préparation à la Fusion que les stakers peuvent utiliser pour s'assurer qu'ils ont parcouru chaque étape du processus. EthStaker a par ailleurs accueilli des ateliers de préparation des validateurs, et d'autres sont prévus.

Les Stakers qui souhaitent exécuter un validateur sur un réseau de test en vue de la transition de la preuve d'enjeu du réseau principal peuvent le faire sur Goerli (qui a maintenant fusionné avec Prater), car il dispose également d'une plateforme de lancement de mise en jeu.

Pourquoi la date estimée pour la valeur Terminal Total Difficulty est-elle si large ?

La valeur relative à la difficulté incrémentale ajoutée par bloc dépend du taux de hachage du réseau, qui est volatile. La valeur TTD sera atteinte d'autant plus tôt que le taux de hachage associé au réseau sera élevé. De même, la valeur TTD sera atteinte d'autant plus tôt que le taux de hachage disparaîtra du réseau. En cas de baisse sensible du taux de hachage une TTD Override pourrait être coordonnée, comme cela a été fait sur Ropsten.

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

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 rompu. 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, telles que eth_getWork).

Cela étant, la plupart des applications sur Ethereum concernent 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 testing & de déploiement complet sur Sepolia ou Goerli 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.

De plus, veuillez noter que tous les réseaux de tests en dehors de Sepolia et de Goerli seront obsolètes après la fusion. Si vous utilisez Ropsten, Rinkeby ou Kiln, vous devez prévoir de migrer vers Goerli ou Sepolia. Un complément d'informations à ce sujet est disponible ici.

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

Que vous utilisiez des applications Ethereum en chaîne, déteniez de l'Ether dans le cadre d'un échange ou dans un portefeuille protégé, vous n'avez rien à faire. Si une application, un échange ou un portefeuille que vous utilisez propose des instructions supplémentaires ou des recommandations, vous devriez vérifier que celles-ci proviennent véritablement de ces applications, échanges ou portefeuilles. Soyez vigilants face aux arnaques !

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

Non. Si vous minez sur le réseau principal Ethereum, 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.

Que se passe-t-il si en tant que mineur ou opérateur de nœuds je ne participe pas à la mise à niveau ?

Si vous utilisez un client Ethereum qui n'a pas migré vers la dernière version (listée ci-dessus), votre client se synchronisera à la blockchain pré-fourche une fois la mise à niveau effectuée.

Vous serez bloqué dans une chaîne incompatible qui suit les anciennes règles et ne pourrez ni envoyer d'Ether ni opérer sur le réseau Ethereum après La Fusion.

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

Non. La Fusion est la mise à niveau d'Ethereum la plus complexe à ce jour. Afin de réduire au maximum les risques de perturbation du réseau, une approche minimale a été adoptée. Cette approche a exclu de cette mise à niveau tout changement ne concernant pas la transition.

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 de finalisation.

J'ai d'autres questions, à qui puis-je les poser ?

Rejoignez les développeurs de l'équipe client, les membres d'ETHStaker, les chercheurs, et plus encore sur le prochain Fusionner l'appel communautaire le vendredi 9 septembre à 14:00 UTC !

Merci

La transition d'Ethereum vers la preuve d'enjeu a été loooongue à venir. Merci à tous ceux qui ont contribué aux recherches, à la définition des spécifications, au développement, à l'analyse, aux tests, aux ruptures, aux réparations ou à l'explication de tout ce qui nous menés vers La Fusion.

Les contributeurs ont été beaucoup trop nombreux au fil des ans pour pouvoir tous être cités ici, mais ils se reconnaîtront. Sans votre participation, nous n'aurions pas édifié cette cathédrale.

quand La Fusion aura-t-elle lieu ? Très 🔜.

Merci à Joseph Schweitzer et Tomo Saito pour l'image de couverture de cet article !