Annonce de fusion Sepolia | Blog de la Fondation Ethereum

• Sepolia sera le deuxième des trois réseaux de test publics à passer par The Merge.
• Le réseau passera à la preuve de participation lorsque la difficulté totale sur la chaîne de preuve de travail dépassera 17,000,000,000,000,000qui devrait se produire dans les prochains jours.
• Après la fusion, Sepolia disposera d’un ensemble de validateurs autorisés, comme les réseaux de test de preuve d’autorité existants. Goerli/Prater, qui fusionnera à une date ultérieure, maintiendra un ensemble de validateurs ouverts pour permettre aux jalonneurs de tester la transition.

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 !

Ropsten étant déjà passé à la preuve de participation et les fourches fantômes se poursuivant régulièrement, Sepolia est maintenant prête pour The Merge. Après Sepolia, seuls Goerli/Prater devront être fusionnés avant de passer au réseau principal. D’autres réseaux de test seront considérés comme obsolètes après la fusion, comme expliqué dans un article récent.

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 à une hauteur d’époque sur la chaîne de balises et la seconde en frappant un Total Difficulty valeur sur la couche d’exécution.

Sepolia a déjà effectué la mise à niveau de Bellatrix sur la chaîne Beacon. Nous annonçons maintenant les détails de la deuxième phase de la transition : frapper le Terminal Total Difficulty.

Informations sur la mise à niveau

Horaire

La fusion est un processus en deux étapes. Cela commence par une mise à niveau du réseau sur la couche consensus, déclenchée par une hauteur d’époque. Vient ensuite la transition de la couche d’exécution de la preuve de travail à la preuve de participation, déclenchée par un Total Difficulty seuil, appelé le Terminal Total Difficulty (TTD).

Sur 20 juin 2022à l’époque 100, la mise à jour de Bellatrix a préparé la Sepolia Beacon Chain pour The Merge. À ce moment-là, les clients CL ont commencé à écouter un TTD valeur à atteindre sur la chaîne de preuve de travail.

Étant donné que le taux de hachage des réseaux de test de preuve de travail est très volatil, le TTD valeur a d’abord été fixée à une valeur excessivement élevée, 100000000000000000000000. Au taux de hachage actuel de Sepolia, il faudrait des centaines d’années pour atteindre cette valeur.

Avec Bellatrix maintenant en ligne, une mise à jour TTD valeur de 17000000000000000 a été choisi pour la transition. Il devrait être touché dans les prochains jours. Quand ce nouveau TTD est atteinte ou dépassée, la partie couche d’exécution de la transition, dont le nom de code est Paris, démarre. Encore une fois, notez que le taux de hachage sur Sepolia est notoirement variable, donc le moment réel auquel le Terminal Total Difficulty a lieu peut fluctuer.

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 le testnet Sepolia. 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

Nom	Version	Lien
Besu	Voir « Remarque Besu » ci-dessous	Voir « Remarque Besu » ci-dessous
Érigon	Voir « Erigon Note » ci-dessous	Voir ci-dessous la « note d’Erigon »
go-ethereum (geth)	v1.10.20	Télécharger
Nethermind	1.13.4	Télécharger

Remarque : pour être compatible avec la fusion Sepolia, les utilisateurs de Besu devront effectuer un manuel Terminal Total Difficulty passer outre. Pour ce faire, les utilisateurs doivent exécuter la dernière version de Besu, 22.4.3 à compter de la publication de cet article, et procéder comme suit :

• Si vous utilisez des fichiers de configuration TOML, ajoutez la ligne suivante : override-genesis-config=["terminalTotalDifficulty=17000000000000000"]
• Si vous démarrez le nœud à l’aide de la CLI, ajoutez l’indicateur suivant : --override-genesis-config="terminalTotalDifficulty=17000000000000000"

Remarque d’Erigon : pour être compatible avec la fusion Sepolia, les utilisateurs d’Erigon devront effectuer une Terminal Total Difficulty passer outre. Pour ce faire, les utilisateurs doivent exécuter la version 2022.06.06-alpha et ajouter l’indicateur suivant lors du démarrage du nœud --override.terminaltotaldifficulty=17000000000000000 should be good for Sepolia.

Plus d’informations sur le remplacement du TTD peuvent être trouvées dans l’annonce Ropsten TTD.

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, qui exécute la chaîne Beacon de preuve de participation, et un client de couche d’exécution, qui gère l’état de l’utilisateur et exécute les calculs associés aux 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.

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 ?

L’ensemble de validateurs de Sepolia est autorisé, donc à moins que vous n’ayez déjà été inclus en tant que validateur Sepolia, aucune action n’est requise.

La transition de Goerli/Prater vers la preuve de participation, qui sera annoncée ultérieurement, sera ouverte à tous les validateurs. Vous trouverez ci-dessous quelques notes pour vous y préparer. Encore une fois, aucune action n’est requise maintenant.

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.

Si vous souhaitez tester l’exécution d’un validateur sur Ethereum post-fusion, des instructions sont disponibles sur le tableau de bord de jalonnement de Ropsten.

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

Avec la mise en ligne de The Merge sur Sepolia, il est maintenant temps 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 de suivre un cycle complet de test et de déploiement sur Ropsten (ou Kiln) et de signaler tout problème avec les outils ou les dépendances aux mainteneurs 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 ou Sepolia, vous devez savoir que chaque 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.

Cela est attendu dans les prochains jours sur Sepolia 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 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 ?

Un appel communautaire de fusion est prévu pour le 15 juillet à 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é.

on fusionne ?

Au moment de la publication de cet article, la date de la transition de la preuve de participation du réseau principal Ethereum a ne pas é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é avec Sepolia, une fois les tests client terminés, l’autre testnet EL d’Ethereum, Goerli, passera par The Merge avec le testnet Prater CL. Une fois que Goerli/Prater aura réussi la transition et la stabilisation, une époque sera choisie pour la mise à niveau de Bellatrix sur la chaîne de balises du réseau principal et une valeur de difficulté 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.

Cela suppose qu’aucun problème n’est détecté. 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, 🔜.