- Goerli fusionnera avec Prater pour la dernière transition du réseau de test vers la preuve d'enjeu. Le réseau fusionné Goerli/Prater continuera de s'appeler Goerli après la fusion.
- Bellatrix, la mise à niveau de Prater le préparant à La Fusion aura lieu à la période 112260, attendue à 12h24 UTC le 4 août 2022.
- Après l'activation de Bellatrix, la fusion Goerli/Prater interviendra lorsque Goerli atteindra une valeur de difficulté totale de 10790000, prévue entre le 6 et le 12 août 2022.
- Après la fusion, la chaîne de validateurs de Goerli restera ouverte afin que des stalkers individuels puissent faire appel à des validateurs de réseaux de test. Les stakers qui souhaitent lancer un validateur Goerli/Prater peuvent le faire sur la plateforme de lancement Prater.
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 !
Après plusieurs devnets, des fourches fantômes et des fusions sur des réseaux de test obsolètes, Sepolia a récemment opéré une transition vers la preuve d'enjeu. Il ne reste plus désormais qu'un réseau de test : Goerli, et sa Chaîne phare, Prater.
La Fusion se distingue des précédentes mises à niveau Ethereum sur deux points. Pour commencer, 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. 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 sélectionnant 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 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, déclenchée par un seuil Total Difficulty spécifique, appelé Terminal Total Difficulty (TTD).
La mise à niveau de Bellatrix est programmée pour l'époque 112260 sur la chaîne phare Prater, prévue à 12h24 UTC le 4 août 2022. Paris, la portion de la transition de la couche d'exécution, sera déclenchée lorsque sera atteinte une valeur de Terminal Total Difficulty (TTD) de 10790000 sur Goerli, attendue entre le 6 et le 12 août 2022.
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 les réseaux de test Goerli & Prater. 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
| Nom | Version | Lien |
|---|---|---|
| Lighthouse | Geardude Clockberg (v2.4.0) | Télécharger |
| Lodestar | v0.41.0 | Télécharger |
| Nimbus | v22.7.0 | Télécharger |
| Prysm | v2.1.4-rc.0 | Télécharger |
| Teku | 22.7.0 | Télécharger |
Couche d'exécution
| Nom | Version | Lien |
|---|---|---|
| Besu | 22.7.0-RC3 | Télécharger |
| Erigon | 2022.07.03-alpha | Télécharger |
| go-ethereum (geth) | v1.10.21 | Télécharger |
| Nethermind | 1.13.5 | Télécharger |
Mise à niveau des spécifications
Les changements 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
- Les changements au niveau de la couche d'exécution, dans la spécification Paris spec du 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ée 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, le 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 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 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 sommaires pour exécuter un noeud sur le réseau Goerli/Prater sont disponibles ici.
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 ?
La fusion Goerli/Prater est votre dernière occasion de vous assurer que vos validateurs sont correctement configurés avant la transition du réseau principal. Il est fortement recommandé de passer par la transition pour éviter tout problème inattendu sur le réseau principal.
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'il faudra procéder à une mise à niveau ultérieure 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 de mise Prater 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. L'équipe EthStaker anime également un atelier de préparation des validateurs à la fusion le 29 juillet.
Pourquoi la date estimée pour la valeur Terminal Total Difficulty est-elle si large ?
La volatilité de la valeur relative à la difficulté incrémentale par bloc rend l'estimation d'une fenêtre pour la TTD plus difficile à définir qu'avec un bloc ou une hauteur d'époque. La plage prévue est donc plus large. Les utilisateurs sont prévenus que cela sera également le cas pour la transition du réseau principal en raison de changements dans le taux de hachage de la preuve de travail.
En tant que développeur d'applications ou d'outils, que dois-je faire ?
À l'approche de la fusion avec Goerli, 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 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, 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.
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 ?
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, vous devez savoir que chaque réseau fonctionnera entièrement sous sa preuve d'enjeu après La Fusion. À ce stade, il ne sera alors plus possible de miner sur le réseau.
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'autre question, à qui puis-je les poser ?
La communauté EthStaker a mis en place un canal communautaire pour répondre aux questions des stakers et des opérateurs de nœuds. Vous pouvez rejoindre cette communauté ici puis utiliser le canal #goerli-prater pour obtenir de l'aide. Comme indiqué plus haut, l'équipe EthStaker anime également un atelier de préparation des validateurs à la fusion le 29 juillet.
Une réunion en ligne dédiée à la Fusion est prévue le 12 août à 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é. Veuillez noter que cette visio communautaire devrait avoir lieu après la fusion de Goerli/Prater.
Quand La Fusion aura-t-elle lieu ?
À la date de publication de cet article, la date de la transition sous preuve d'enjeu du réseau principal Ethereum **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 attentifs !
Une fois que les clients auront des versions complètes et en supposant qu'aucun problème ne soit décelé lors de la fusion Goerli/Prater, une hauteur de créneau sera choisie pour la mise à niveau Bellatrix sur la chaîne phare du réseau principal et une valeur de difficulté totale 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.
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, 🔜.