Annonce de fusion Goerli/Prater | Blog de la Fondation Ethereum

Lecture 20 minutes
  • Pour la dernière transition testnet proof-of-stake, Goerli fusionnera avec Prater. Le réseau combiné Goerli/Prater conservera le nom de Goerli après la fusion.
  • Bellatrix, la mise à niveau Prater le préparant pour The Merge se produira à l’époque 112260attendu à 12:24PM UTC on August 4, 2022.
  • Après l’activation de Bellatrix, la fusion Goerli/Prater se produira lorsque Goerli atteindra une difficulté totale de 10790000attendu entre August 6-12, 2022.
  • Après la fusion, l’ensemble de validateurs de Goerli restera ouvert aux jalonneurs individuels pour exécuter des validateurs de testnets. Les intervenants qui souhaitent démarrer un validateur Goerli/Prater peuvent le faire au Prater Launchpad.

Arrière plan

Après des années de travail pour apporter la preuve de participation à Ethereum, nous sommes maintenant bien entrés dans la phase finale des tests : les déploiements de testnet !

Après plusieurs devnets, shadow forks et fusions sur des testnets obsolètes, Sepolia est récemment passé à la preuve de participation. Maintenant, il ne reste plus qu’un seul testnet : Goerli, et sa chaîne Beacon associée, Prater.

La fusion est différente des mises à niveau précédentes d’Ethereum 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 Total Difficulty valeur sur la couche d’exécution.

Informations sur la mise à niveau

Horaire

La fusion est un processus en deux étapes. Cela commence par 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 Total Difficulty seuil, appelé le Terminal Total Difficulty (TTD).

La mise à niveau de Bellatrix est prévue pour l’époque 112260 sur la Prater Beacon Chain, attendu à 12:24PM UTC on August 4, 2022. Paris, la partie de la couche d’exécution de la transition, sera déclenchée en atteignant un Terminal Total Difficulty (TTD) de 10790000 sur Goerli, attendu entre August 6-12, 2022.

Une fois que la couche d’exécution a dépassé la TTD, le bloc suivant sera uniquement produit par un validateur Beacon Chain. Nous considérons que la fusion est terminée une fois que la chaîne Beacon a finalisé ce bloc. En supposant des conditions de réseau normales, cela devrait se produire 2 époques, soit 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 si aucun bloc post-fusion de ce type n’existe. Cette balise peut être utilisée pour les applications afin de vérifier si la fusion est terminée. De même, les contrats intelligents peuvent interroger le DIFFICULTY 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 les réseaux de test Goerli & Prater. 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. Une explication de ces risques et de leurs conséquences peut être trouvée 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

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 la bellatrix répertoire du référentiel consensus-specs
  • La couche d’exécution change, sous le Paris spec 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 execution-apis, est utilisée pour la communication entre les couches de consensus et d’exécution
  • Optimistic Sync, spécifié dans le sync 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

FAQ

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

Après la fusion, un nœud complet Ethereum combinera un client de couche de consensus (CL), qui exécute la chaîne Beacon de preuve de participation, et un client de couche d’exécution (EL), qui gère l’état de l’utilisateur et exécute les calculs associés à transactions. Celles-ci communiquent via un port authentifié à l’aide d’un nouvel ensemble de méthodes JSON RPC appelée API Engine. 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 les générer et de les configurer.

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. Des instructions récapitulatives pour l’exécution d’un nœud sur le réseau Goerli/Prater sont disponibles here.

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. Cet article 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. Les API Beacon et JSON RPC continueront de fonctionner comme prévu.

En tant que jalonneur, que dois-je faire ?

La fusion Goerli/Prater est votre dernière opportunité de vous assurer que vos validateurs sont correctement configurés avant la transition du réseau principal. Exécuter la transition maintenant est fortement recommandé pour éviter tout problème inattendu sur le réseau principal.

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 les validateurs auraient pu sous-traiter ces fonctions à des 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 dans les blocs 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. Bien que cela élargisse les responsabilités des validateurs, cela 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 sur la chaîne Beacon et nécessiteront une mise à niveau ultérieure du réseau 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 en tant que destinataire des frais de transaction.

Après avoir mis à jour votre client de consensus, assurez-vous de définir le fee recipient 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 Prater Staking Launchpad dispose d’une liste de contrôle de préparation à la fusion que les jalonneurs peuvent utiliser pour s’assurer qu’ils ont suivi chaque étape du processus. L’équipe EthStaker organise également un atelier de préparation du validateur de fusion le 29 juillet.

Pourquoi l’estimation de la Terminal Total Difficulty date si large?

La volatilité de la difficulté incrémentielle par bloc rend l’estimation d’une fenêtre pour le TTD plus dur qu’avec une hauteur de bloc ou d’époque, d’où la plage attendue plus large. Les utilisateurs doivent noter que ce sera également le cas pour la transition du réseau principal en raison des modifications du taux de hachage de la preuve de travail.

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

Avec la mise en ligne de The Merge sur Goerli, c’est maintenant votre dernière chance de vous assurer que votre produit fonctionne comme prévu grâce à la transition de preuve de participation et dans un contexte post-fusion. Comme expliqué dans un article précédent, The Merge n’aura qu’un impact minimal 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, Ropsten ou Kiln 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, vous devez 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. Vous trouverez plus d’informations à ce sujet ici.

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

Non. Le réseau principal Ethereum n’est pas affecté par ce testnet. Des annonces ultérieures seront faites sur ce blog avant la transition du réseau principal.

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.

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. Les spécifications pour les couches de consensus et d’exécution sont en cours.

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

La communauté EthStaker a mis en place un canal Discord pour répondre aux questions des jalonneurs et des opérateurs de nœuds. Vous pouvez rejoindre leur discord ici et ensuite utiliser le #goerli-prater canal d’assistance. Comme mentionné ci-dessus, EthStaker organisera également un atelier de préparation du validateur de fusion le 29 juillet.

De plus, un appel communautaire de fusion est prévu pour le 12 août à 14h00 UTC. Les développeurs clients et les chercheurs seront disponibles pour répondre aux questions des opérateurs de nœuds, des intervenants, des fournisseurs d’infrastructure et d’outillage et des membres de la communauté. Notez que cet appel communautaire devrait avoir lieu après la fusion Goerli/Prater.

on fusionne ?

Depuis la publication de cet article, le temps de la transition de la preuve de participation du réseau principal Ethereum a not été fixé. Toute source prétendant le contraire est susceptible d’être une arnaque. Des mises à jour seront publiées sur ce blog. Veuillez rester en sécurité !

En supposant qu’aucun problème n’est trouvé lors de la fusion Goerli/Prater, une fois que les clients auront des versions complètes, une hauteur d’emplacement sera choisie pour la mise à niveau de Bellatrix sur la chaîne Beacon du réseau principal et une valeur de difficulté totale sera définie pour la transition du réseau principal. Les clients feront ensuite des versions qui activeront The Merge sur le réseau principal. Ceux-ci seront annoncés sur ce blog et dans d’autres publications communautaires.

Toutefois, si des problèmes sont détectés à un moment quelconque du processus ou si la couverture des tests est jugée insuffisante, ces problèmes seront résolus avant de poursuivre le processus de déploiement.

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

Autrement dit, ?.

Source https://blog.ethereum.org/2022/07/27/goerli-prater-merge-announcement/

Crypto Week

Avertissement : Crypto Week ne fournit pas de conseils financiers de quelque manière que ce soit. Nous ne vous recommandons pas d'investir de l'argent dans une crypto-monnaie ou un actif financier sans avoir effectué des recherches approfondies. Nous ne sommes pas responsables de vos décisions financières de quelque manière que ce soit.

Derniers articles de Featured Posts