Annonce de fusion du réseau principal | Blog de la Fondation Ethereum

• Ethereum passe à la preuve de participation ! La transition, connue sous le nom de The Merge, doit d’abord être activée sur la chaîne Beacon avec la mise à niveau Bellatrix. Après cela, la chaîne de preuve de travail migrera vers la preuve de participation lorsqu’elle atteindra un point spécifique. Difficulté totale évaluer.
• La mise à niveau de Bellatrix est prévue pour l’époque 144896 sur la chaîne Beacon — 11 h 34 min 47 s UTC le 6 septembre 2022.
• La Difficulté totale terminale valeur déclenchant La fusion est 58750000000000000000000attendu entre 10-20 septembre 2022.
• Remarque : comme annoncé plus tôt, le testnet de four est en cours de coucher. Les opérateurs fermeront le 6 septembre 2022.

Arrière plan

Après des années de travail acharné, la mise à niveau de preuve de participation d’Ethereum est enfin là ! La mise à niveau réussie de tous les réseaux de test publics est maintenant terminée et The Merge a été programmé pour le réseau principal Ethereum.

La fusion est différente des mises à niveau réseau précédentes de deux manières. Premièrement, les opérateurs de nœuds doivent mettre à jour leurs clients de la couche consensus (CL) et de la couche exécution (EL) en tandem, plutôt qu’un seul des deux. Deuxièmement, la mise à niveau s’active en deux phases : la première, nommée Bellatrix, à une hauteur d’époque sur la chaîne Beacon, et la seconde, nommée Paris, en frappant un Difficulté totale valeur sur la couche d’exécution.

Informations sur la mise à niveau

Horaire

La fusion est un processus en deux étapes. La première étape est une mise à niveau du réseau, Bellatrix, sur la couche consensus déclenchée par une hauteur d’époque. Vient ensuite le passage de la couche d’exécution du proof-of-work au proof-of-stake, Paris, déclenché par un Difficulté totale seuil appelé le Difficulté totale terminale (TTD).

La mise à niveau de Bellatrix est prévue pour l’époque 144896 sur la chaîne Beacon — 11 h 34 min 47 s UTC le 6 septembre 2022.

Paris, la partie de la couche d’exécution de la transition, sera déclenchée par le Difficulté totale terminale (TTD) de 58750000000000000000000attendu entre 10-20 septembre 2022. La date exacte à laquelle TTD est atteint dépend du taux de hachage de la preuve de travail. Les estimations de la transition sont disponibles sur bordel.wtf et 797.io/themerge.

Une fois que la couche d’exécution atteint ou dépasse la TTD, le bloc suivant sera produit par un validateur Beacon Chain. La transition de fusion est considérée comme terminée une fois que la chaîne de balises a finalisé ce bloc. Dans des conditions de réseau normales, cela se produira 2 époques (ou ~13 minutes) après la production du premier bloc post-TTD !

Une nouvelle balise de bloc JSON-RPC, finalisé, renvoie le dernier bloc finalisé ou une erreur si aucun bloc post-fusion de ce type n’existe. Cette balise peut être utilisée par les applications pour vérifier si la fusion est terminée. De même, les contrats intelligents peuvent interroger le DIFFICULTÉ code opération (0x44) (renommé en PREVRANDAO post-fusion) pour déterminer si la fusion a eu lieu. Nous recommandons aux fournisseurs d’infrastructure de surveiller la stabilité globale du réseau en plus du statut de finalisation.

Versions des clients

Les versions client suivantes prennent en charge The Merge sur le réseau principal Ethereum. Les opérateurs de nœud doivent s’exécuter tous les deux un client de couche d’exécution et de consensus pour rester sur le réseau pendant et après la fusion.

Lors du choix du client à exécuter, les validateurs doivent être particulièrement attentifs aux risques d’exécuter un client majoritaire à la fois sur EL et CL. Un explicatif de ces risques et de leurs conséquences peut être trouvé ici. Une estimation de la distribution actuelle des clients EL et CL et des guides pour passer d’un client à un autre peuvent être trouvés ici.

Couche de consensus

Couche d’exécution

Avertissement: la version geth v1.10.22 contient un problème de base de données critique, n’utilisez pas cette version, et si vous avez déjà mis à niveau, veuillez mettre à niveau vers la v1.10.23 dès que possible.

Spécifications de mise à niveau

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

• La couche de consensus change sous le Bellatrix annuaire du référentiel consensus-specs
• La couche d’exécution change sous le Paris spécification dans le référentiel de spécifications d’exécution

En plus de celles-ci, deux autres spécifications couvrent la façon dont les clients de la couche de consensus et d’exécution interagissent :

• L’API Engine, spécifiée dans le référentiel d’exécution-APIest utilisé pour la communication entre les couches de consensus et d’exécution
• Optimistic Sync, spécifié dans le synchroniser dossier du référentiel consensus-specs, est utilisé par la couche consensus pour importer des blocs pendant que le client de la couche d’exécution se synchronise et pour fournir une vue partielle de la tête de la chaîne du premier au second

Bonus de prime de bogue de fusion

Toutes les primes liées à la fusion pour les vulnérabilités ont reçu un multiplicateur 4x d’ici le 8 septembre. Les bugs critiques valent désormais jusqu’à 1 million de dollars américains.

Voir le programme de primes aux bogues pour plus de détails.

FAQ

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

Après la fusion, un nœud complet Ethereum est la combinaison d’un client de couche de consensus (CL) qui exécute la chaîne Beacon de preuve de participation et d’un client de couche d’exécution (EL) qui gère l’état de l’utilisateur et exécute les calculs associés aux transactions. . Les clients EL et CL communiquent via un port authentifié à l’aide d’un nouvel ensemble de méthodes JSON RPC appelées API du moteur. Les clients EL et CL s’authentifient mutuellement à l’aide d’un secret JWT. Les opérateurs de nœud doivent se référer à la documentation de leurs clients pour obtenir des instructions sur la façon de générer et de configurer cette valeur.

En d’autres termes, si vous exécutiez déjà un nœud sur la chaîne de balises, vous devez maintenant également exécuter un client de couche d’exécution. De même, si vous exécutiez un nœud sur le réseau de 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 du Section « Exécuter un nœud » du site Web ethereum.org décrit ces étapes plus en détail.

Il convient de souligner que bien qu’ils fassent tous deux partie des versions du client de la couche consensus, l’exécution d’un nœud balise est distincte de l’exécution d’un client validateur. Les intervenants doivent exécuter les deux, mais les opérateurs de nœud n’ont besoin que du premier. Ce post explique plus en détail la différence entre les deux composants.

Notez également que chaque couche conservera un ensemble indépendant de pairs et exposera ses propres API. La Balise et RPC JSON Les API continueront de fonctionner comme prévu.

En tant que jalonneur, que dois-je faire ?

Comme expliqué ci-dessus, les validateurs de la Beacon Chain 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, cela était fortement recommandé, mais certains validateurs ont externalisé ces fonctions auprès de fournisseurs tiers. Cela a été possible car les seules données requises sur la couche d’exécution étaient les mises à jour du contrat de dépôt.

Après la fusion, les validateurs doivent s’assurer que les transactions utilisateur et les blocs de transitions d’état qu’ils créent et attestent sont valides. Pour ce faire, chaque nœud beacon doit être couplé avec un client de la couche d’exécution. Notez que plusieurs validateurs peuvent toujours être couplés à un seul combo nœud balise et client de couche d’exécution. Cela élargit les responsabilités des validateurs mais donne également à un validateur qui propose un bloc le droit à ses frais de priorité de transaction associés (qui vont actuellement aux mineurs).

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

Après avoir mis à jour votre client de consensus, assurez-vous de définir le bénéficiaire des frais dans le cadre de vos configurations de client validateur pour vous assurer que les frais de transaction sont envoyés à une adresse que vous contrôlez. Si vous avez misé en utilisant un fournisseur tiers, il appartient à votre fournisseur sélectionné de spécifier comment ces frais sont répartis.

Le Staking Launchpad a un Liste de contrôle de préparation à la fusion que les jalonneurs peuvent utiliser pour s’assurer qu’ils sont passés par chaque étape du processus. EthStaker a également hébergé Ateliers de préparation des validateurset d’autres sont prévus.

Les acteurs qui souhaitent exécuter un validateur sur un testnet en préparation de la transition de preuve de participation du réseau principal peuvent le faire sur Goerli (maintenant fusionné avec Prater), qui a également un Implantation de l’instance Launchpad.

Pourquoi la date estimée pour le Difficulté totale terminale si large ?

La difficulté incrémentielle ajoutée par bloc dépend du taux de hachage du réseau qui est volatile. Si plus de taux de hachage rejoint le réseau, TTD sera atteint plus tôt. De même, si le taux de hachage quitte le réseau, TTD sera atteint plus tard. En cas de baisse significative des niveaux de taux de hachage, un Remplacement TTD pourraient être coordonnés comme cela a été fait le Ropsten.

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

Comme expliqué dans un post précédent, La fusion n’aura qu’un impact minime sur un sous-ensemble de contrats déployés sur Ethereum, dont aucun ne devrait être rompu. De plus, la part du lion des points de terminaison de l’API utilisateur reste stable (sauf si vous utilisez des méthodes spécifiques de preuve de travail telles que eth_getWork).

Cela dit, la plupart des applications sur Ethereum impliquent bien plus que des contrats en chaîne. C’est le moment pour vous assurer que votre code frontal, vos outils, votre pipeline de déploiement et d’autres composants hors chaîne fonctionnent comme prévu. Nous recommandons fortement aux développeurs d’effectuer un cycle complet de test et de déploiement sur Sepolia ou Goerli et de signaler tout problème avec les outils ou les dépendances aux responsables de ces projets. Si vous ne savez pas où ouvrir un problème, veuillez utiliser ce référentiel.

De plus, veuillez noter que tous les réseaux de test à l’exception de Sepolia et Goerli seront obsolètes après la fusion. Si vous êtes un utilisateur de Ropsten, Rinkeby ou Kiln, vous devriez envisager de migrer vers Goerli ou Sepolia. Plus d’informations à ce sujet peuvent être trouvées ici.

En tant qu’utilisateur d’Ethereum ou détenteur d’Ether, y a-t-il quelque chose que je dois faire ?

Que vous utilisiez des applications Ethereum en chaîne, déteniez Ether sur un échange ou dans un portefeuille en libre-service, vous n’avez rien à faire. Si une application, un échange ou un portefeuille que vous utilisez propose des instructions ou des recommandations supplémentaires, vous devez vérifier qu’elles proviennent bien d’eux. Soyez à l’affût des arnaques!

En tant que mineur, y a-t-il quelque chose que je dois faire ?

Non. Si vous minez sur le réseau principal Ethereum, vous devez savoir que le réseau fonctionnera entièrement sous preuve de participation après la fusion. À ce stade, le minage ne sera plus possible sur le réseau.

Que se passe-t-il si je suis un mineur ou un opérateur de nœud et que je ne participe pas à la mise à niveau ?

Si vous utilisez un client Ethereum qui n’est pas mis à jour vers la dernière version (énumérée ci-dessus), votre client se synchronisera avec la blockchain pré-fork une fois la mise à niveau effectuée.

Vous serez bloqué sur une chaîne incompatible suivant les anciennes règles et ne pourrez pas envoyer d’Ether ou opérer sur le réseau Ethereum post-fusion.

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

Non. La fusion est la mise à niveau la plus compliquée d’Ethereum à ce jour. Pour minimiser les risques de perturbations du réseau, une approche minimale a été adoptée qui excluait toute modification non transitoire de cette mise à niveau.

Les retraits de la chaîne Beacon seront probablement introduits dans la première mise à jour après la fusion. Spécifications pour les deux consensus et exécution couches sont en cours.

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

Rejoignez les développeurs de l’équipe client, les membres d’ETHStaker, les chercheurs et bien plus encore lors de la prochaine Fusionner l’appel de la communauté le vendredi 9 septembre à 14h00 UTC !

Merci

La transition d’Ethereum vers la preuve de participation a été un trop longtemps le temps vient. Merci à tous ceux qui ont contribué à rechercher, spécifier, développer, analyser, tester, casser, réparer ou expliquer tout ce qui nous a amenés à The Merge.

Il y a eu beaucoup trop de contributeurs au fil des ans pour être listés ici, mais vous savez qui vous êtes. Sans vous tous dans le bazar, nous n’aurions pas construit cette cathédrale.

on fusionne ? Très 🔜.

---

Merci à Joseph Schweitzer et Tomo Saito pour l’image de couverture de ce post !