Anular manualmente la TTD, ejecutando el siguiente comando al iniciar el cliente: --override.terminaltotaldifficulty 10000000000000000000000000000000000000000000.`

Especificaciones de la actualización

Los cambios fundamentales de consenso para la fusión se especifican en dos fases:

• Los cambios para la capa de consenso en el directorio Bellatrix de especificaciones de consenso.
• La capa de ejecución en la especificación París en el directorio de especificaciones de ejecución.

Además de estas, otras dos especificaciones cubren la forma en la que interactúan los clientes de capa de ejecución y capa de consenso:

• La API Engine, especificada en el directorio execution-apis, se utiliza para la comunicación entre el consenso y las capas de ejecución.
• La capa de consenso utiliza la Optimistic Sync, especificada en la carpeta sync del directorio consenso-especificaciones para importar bloques mientras el cliente de capa de ejecución se está sincronizando, y ofrece una visión parcial del principio de la cadena desde la primera hasta la segunda.

Preguntas frecuentes

¿Qué debo hacer como operador de nodos?

Después de la fusión, un nodo completo de Ethereum estará formado por una combinación de un cliente de capa de consenso, que ejecuta pruebas de participación en la cadena de baliza, y un cliente de capa de ejecución, que gestiona el estado de los usuarios y se encarga de los cálculos asociados a las transacciones. Estos se comunican a través de un puerto autenticado usando un nuevo conjunto de métodos JSON RPC denominado Engine API. El cliente EL y CL se autentican utilizando un secreto JWT. Los operadores de nodos deben referirse a la documentación de sus clientes para obtener instrucciones sobre cómo generar y configurar estos.

Dicho de otra forma, si antes ya ejecutaba un nodo en la cadena de baliza, ahora debe hacerlo también con un cliente de capa de ejecución. De la misma manera, si antes ejecutaba un nodo en la actual red de prueba de trabajo, ahora deberá ejecutar un cliente de capa de consenso. Para que se comuniquen de forma segura, se debe pasar un token JWT a cada cliente.

Cabe recalcar que si bien ambos son parte de las versiones de cliente de capa de consenso, ejecutar un nodo de baliza es distinto de ejecutar un cliente validador. Los participantes deben ejecutar ambos, sin embargo los operadores de nodos solo tienen que ejecutar el primero. Este artículo explica la diferencia entre ambos componentes con más detalle.

Además, tenga en cuenta que cada capa mantendrá un conjunto independiente de pares y expondrá sus propias API. La baliza y las API JSON RPC continuarán funcionando según lo previsto.

Por último, recuerde revisar el 6 y 7 de junio el anuncio que se publicará en este blog del valor final de TTD Ropsten.

¿Qué necesito hacer como participante?

Como se explicó anteriormente, validadores en la cadena de baliza necesitarán ejecutar un cliente de capa de ejecución después de la fusión, además de sus clientes de capa de consenso. Algo que se recomendaba encarecidamente hacer antes de la fusión, aunque puede que los validadores hayan externalizado estas funciones a proveedores de terceros. Esta opción era posible porque los únicos datos que se necesitaban en la capa de ejecución eran actualizaciones del contrato de depósito.

Después de la fusión, los validadores tendrán que asegurarse de que las transacciones en bloques que crean y certifican son válidas. Para ello, cada nodo de baliza debe estar emparejado con un cliente de capa de ejecución. Tenga en cuenta que varios validadores todavía pueden emparejarse con una única combinación de nodo de baliza y cliente de capa de ejecución. Aunque de este modo aumentan las responsabilidades de los validadores, el validador que propone un bloque también obtiene derecho a las comisiones de prioridad de transacciones asociadas (que actualmente se destinan a los mineros).

Mientras que las recompensas del validador se acumulan en la cadena de baliza y requieren una posterior actualización para poder retirarlas, las comisiones de transacción seguirán pagándose, registrándose y distribuyéndose en la capa de ejecución. Los validadores pueden especificar cualquier dirección de Ethereum como destinatarios de las comisiones de transacciones.

Después de actualizar su cliente de consenso, asegúrese de establecer el fee recipient (destinatario de comisión) como parte de las configuraciones de su cliente validador para asegurarse de que las comisiones de transacción se envían a una dirección que usted controla.

Si usted ha apostado usando un proveedor externo, le corresponde a su proveedor seleccionado especificar cómo se asignan estas comisiones.

Las actualizaciones de la red de prueba suponen la última oportunidad para que los validadores se aseguren de que sus configuraciones funcionan como se esperaba y resuelvan cualquier problema. Puede encontrar información sobre cómo ejecutar un validador en la cadena de baliza Ropsten en preparación para la fusión en la plataforma de lanzamiento Ropsten.

Le recomendamos encarecidamente que los validadores de red principal ejecuten la fusión en Ropsten y en otras redes de pruebas antes de las transiciones de la red principal a la prueba de participación en Ethereum.

¿Qué debo hacer como desarrollador de aplicaciones o herramientas?

Con la fusión ocurriendo en Ropsten, es el momento de asegurarse de que su producto funciona como se espera a través de la transición de la prueba de participación y en un contexto después de la fusión. Como se explica en publicado anteriormente, la función solo tendrá un impacto mínimo en un subconjunto de contratos implementado en Ethereum, ninguno de los cuales se rescindirá. Además, la mayor parte de los puntos finales de la API del usuario permanecen estables (a menos que esté usando métodos específicos de prueba de trabajo como eth_getWork).

Dicho esto, la mayoría de aplicaciones de Ethereum implican mucho más que contratos en cadena. Ahora es el momento de asegurarse de que su código front-end, herramientas, canal de implementación y otros componentes fuera de cadena funcionan como es debido. Recomendamos encarecidamente que los desarrolladores ejecuten a través de un ciclo de implementación y prueba completo en Ropsten (o Kiln) y notifiquen a quienes se encargan de esos proyectos cualquier problema con herramientas o dependencias. Si no tiene certeza sobre en qué casos debe reportar una incidencia, consulte este directorio.

Como usuario de Ethereum o titular de ethers, ¿debo hacer algo?

No. La red principal de Ethereum no se verá afectada por esta red de prueba. En este blog, iremos colgando próximamente anuncios antes de la transición de la red principal.

Como minero, ¿debo hacer algo?

No. Si está minando la red principal de Ethereum o Ropsten, deberá tener en cuenta que después de la fusión cada red funcionará completamente como prueba de participación. En ese momento, las tareas de minado en la red ya no serán posibles.

Se prevé que esto ocurra alrededor del 8 de junio de 2022 en Ropsten y a lo largo del año en la pred principal de Ethereum.

Como validador, ¿puedo retirar mi participación?

No. La Fusión es la actualización de Ethereum más complicada hasta la fecha. Para minimizar los riesgos de que se produzca una interrupción de la red, se ha adoptado un enfoque mínimo que excluye cualquier cambio no relacionado con la transición de esta actualización.

Es posible que se permitan las retiradas de la cadena de bloques en la primera actualización que se haga después de la fusión. Se están elaborando las especificaciones para ambas capas, de consenso y de ejecución.

Tengo más preguntas, ¿dónde puedo hacerlas?

Se ha programado una llamada comunitaria de fusión para el 3 de junio a las 14:00 UTC. Los desarrolladores de clientes e investigadores estarán disponibles para responder preguntas de operadores de nodos, participantes, infraestructura y proveedores de herramientas y miembros de la comunidad.

Fecha de la fusión

A fecha de publicación de esta notificación, la transición de la prueba de participación de la red principal de Ethereum aún no se ha fijado. Cualquier fuente que afirme lo contrario puede ser un engãno. Publicaremos las actualizaciones en este blog. ¡Tenga cuidado!

Presuponiendo que no surja ningún problema con Ropsten y una vez que concluyan las pruebas de cliente, las demás redes de pruebas de Ethereum se ejecutarán a través de la fusión. Una vez que la transición de Goerli y Sepolia se haya realizado con éxito y se hayan estabilizado, se elegirá una altura de ranura para la actualización de Bellatrix en la cadena de baliza y se establecerá un valor de dificultad para la transición de la red principal. Los clientes podrán entonces hacer versiones que permitan la fusión en la red principal. Estas se anunciarán en este blog y en otras publicaciones comunitarias.

Esto presupone que no hay problemas. Sin embargo, si se encuentran problemas en cualquier momento del proceso o la cobertura de la prueba se considera insuficiente, se abordará antes de continuar con el proceso de implementación.

Solo entonces podremos estimar una fecha exacta para La Fusión.

Es decir, 🔜 (pronto).

---

Lancement de La Fusion de Ropsten

• Ropsten sera le premier réseau de test de longue date à fusionner
• Une nouvelle chaîne phare Ropsten sera lancée le 30 mai 2022 pour qu’il y ait consensus autour du réseau
• Le 2 juin 2022, la chaîne phare Ropsten devrait ensuite être mise à niveau pour intégrer des règles de protocole compatibles avec la fusion au créneau 24000
• Après cela, une valeur Terminal Total Difficulty (TTD) sera définie pour activer la fusion sur la chaîne de preuve de travail. Les opérateurs de nœuds devront définir manuellement cette valeur pour leurs clients.
• Une autre annonce avec la valeur Terminal Total Difficulty exacte à utiliser pour la Fusion de Ropsten sera postée sur ce blog le 3 juin 2022. Les utilisateurs doivent s’attendre à ce que cette valeur TTD soit atteinte quelques jours après avoir été définie, et devrait être prêts à configurer leurs clients en conséquence dans un délai très court.

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 !

Ayant testé les implémentations client sur Kintsugi 🍵, Kiln 🔥🧱 et de nombreuses fourches fantômes, les équipes clients sont maintenant prêtes, grâce à La Fusion, à exécuter Ropsten, le seul réseau qui permet d’effectuer des tests de preuve de travail. Pour préparer le réseau à cette fin, une Chaîne phare Ropsten sera lancée afin qu’il y ait un consensus autour du réseau.

Si la transition se déroule en douceur sur Ropsten, deux autres réseaux de test (Goerli et Sepolia) passeront par la case preuve d’enjeu avant que ce ne soit le tour du réseau principal. D’autres réseaux de tests, comme Rinkeby et Kovan, peuvent être mis à niveau séparément par la communauté, mais les développeurs clients n’assureront plus leur suivi.

La Fusion se distingue des précédentes mises à niveau Ethereum de deux façons. Premièrement, 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. Deuxièmement, la mise à niveau s’opère en deux phases : la première à une hauteur de créneau sur la Chaîne phare et la seconde en sélectionnant une valeur Total Difficulty sur la couche d’exécution.

Compte tenu de ces circonstances, le réseau Ropsten, qui est voué à devenir obsolète après La Fusion, procèdera à la mise à niveau plus tôt dans le processus de développement que les mises à niveau réseau précédentes. La communauté aura ainsi plus de temps pour se familiariser avec le processus de mise à niveau.

Remarque **: Les versions client listées ci-dessous **ne sont pas compatibles avec la transition du réseau principal Ethereum vers la preuve d’enjeu.

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 de créneau. 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).

Le 2 juin 2022, au créneau 24000, la mise à niveau de Bellatrix préparera la Chaîne phare Ropsten à La Fusion. À ce stade, les clients CL pourront commencer à s’attendre à ce qu’une valeur TTD soit atteinte sur la chaîne de preuve de travail.

Parce que le taux de hachage des réseaux de test de preuve de travail est très volatil, la valeur TTD sera d’abord définie sur une valeur extrêmement élevée, 10000000000000000000. Au taux de hachage actuel de Ropsten, il faudrait environ 250 ans pour l’atteindre.

Une fois la mise à niveau de Bellatrix faite sur la Chaîne phare, une nouvelle valeur de TTD, qui devrait être atteinte quelques jours plus tard, sera définie et annoncée. Les utilisateurs devront alors configurer leur noeud en s’appuyant sur cette nouvelle valeur. Les instructions pour le faire avec chaque client sont disponibles ici.

Lorsque ce nouveau TTD est atteint ou dépassé sur Ropsten, la partie correspondant à la couche d’exécution de la transition répondant au nom de code Paris, sera activée. Notez une fois encore que le taux de hachage sur Ropsten est réputé être variable et que l’heure réelle à laquelle la valeur Terminal Total Difficulty sera connue peut donc fluctuer.

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 le réseau de test Ropsten. 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.

Comme mentionné ci-dessus, les versions suivantes ont une valeur Terminal Total Difficulty égale à 100000000000000000000000 qui devra être mise à niveau manuellement après activation de la mise à niveau de Bellatrix sur la Chaîne phare.

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.

Remarque: si vous aviez précédemment téléchargé une version client avec un TTD Ropsten de 43531756765713534, vous devez actualiser votre version ou remplacer manuellement le TTD par 100000000000000000000000 comme précisé ici.

Couche de consensus

Nom	Version	Lien
Lighthouse	Baby Wizard (2.3.0)	Télécharger
Lodestar	Voir « Remarque concernant Lodestar » ci-dessous	Voir « Remarque concernant Lodestar » ci-dessous
Prysm	v2.1.3-rc.2	Télécharger
Nimbe
Teku	v22.5.2	Télécharger

Remarque concernant Lodestar : la dernière version de Lodestar, v0.37.0, a une valeur TTD Ropsten obsolète de 43531756765713534. Pour être compatible avec la fusion de Ropsten, qui utilise maintenant une valeur TTD de 100000000000000000000000, les utilisateurs Lodestar devront remplacer cette valeur manuellement. Des instructions à ce sujet sont disponibles dans l’article de l’équipe annonçant la publication.

Couche d’exécution

Nom	Version	Lien
Besu	v22.4.2	Télécharger
Erigon	v2022.06.01-alpha	Télécharger
go-ethereum (geth)	Voir « Remarque concernant Geth » ci-dessous	Voir « Remarque concernant Geth » ci-dessous
Nethermind	v1.13.1	Télécharger

Remarque concernant Lodestar : la dernière version de go-ethereum (geth), Sharblu (v1.10.18), a une valeur TTD Ropsten obsolète de 43531756765713534. Pour être compatible avec la fusion de Ropsten, qui utilise maintenant une valeur TTD de 100000000000000000000000, les utilisateurs de geth devront remplacer cette valeur manuellement:

• Partir de la source sur la dernière branche master branch
• Utiliser la dernière image Docker
• Remplacer manuellement la valeur TTD, en exécutant la commande ci-après au démarrage du client : --override.terminaltotaldifficulty 10000000000000000000.

Mise à niveau des spécifications

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

• Au niveau de la couche de consensus, dans le répertoire bellatrix du référentiel consensus-specs
• Au niveau de la couche d’exécution, sous la spécification Paris 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

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, qui exécutera une preuve d’enjeu sur la chaîne phare, et un client de couche d’exécution, 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 PoW 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 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.

Enfin, n’oubliez pas de vous reconnecter les 6 et 7 juin pour découvrir la valeur TTD Ropsten définitive sur ce blog.

En tant que validateur, que dois-je faire?

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’une mise à niveau ultérieure sera nécessaire 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 avoir mis à jour votre client de consensus, veillez à associer le fee recipient aux 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 comment ces frais sont alloués.

Les mises à niveau du réseau de test offrent aux validateurs une dernière chance de s’assurer que leurs configurations fonctionnent comme prévu et de résoudre les problèmes. Des informations sur l’exécution d’un validateur sur la chaîne phare Ropsten en prévision de la fusion sont disponibles ici.

Nous recommandons vivement aux validateurs du réseau principal de passer par La Fusion sur Ropsten et d’autres réseaux de test avant la transition du réseau principal Ethereum vers la preuve d’enjeu.

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

Avec la mise en ligne de Kiln, 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 interrompu. 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 [PoW], telles que eth_getWork).

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

En tant qu’utilisateur d’Ethereum ou que 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 ou sur Ropsten, 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.

Ceci à partir du 8 juin 2022 environ sur Ropsten 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 d’Ethereum la plus complexe à ce jour. Pour réduire au maximum les risques de perturbation du réseau, une approche minimale a été adoptée.

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.

J’ai d’autre question, à qui puis-je les poser ?

Une réunion en ligne dédiée à la Fusion est prévue le 3 juin à 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é.

Quand La Fusion aura-t-elle lieu ?

À la date de publication de cet article, la date de la transition du réseau principal Ethereum vers la preuve d’enjeu 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 prudents !

En supposant qu’aucun problème ne soit détecté avec Ropsten, une fois les tests clients terminés, les autres réseaux de test Ethereum fusionneront. Lorsque la transition de ces réseaux de test sera terminée et qu’ils seront stabilisés, et, à nouveau, en supposant qu’aucun problème ne soit décelé, une valeur difficulty 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.

Ceci suppose qu’aucun problème n’a été trouvé. 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, 🔜.

---

रोपस्टेन मर्ज की घोषणा

• रोपस्टेन, मर्ज के ज़रिए लंबे समय तक चलने वाला पहला टेस्टनेट होगा
• नेटवर्क को कॉन्सेंसस प्रदान करने के लिए 30 मई, 2022 को नई रॉप्सटन बीकन चेन लॉन्च की गई थी
• रॉप्सटन बीकन चेन, 2 जून, 2022, को संगत प्रोटोकॉल नियमों (बेलाट्रिक्स) को मर्ज करने के लिए संभावित रूप से स्लॉट 24000 पर अपग्रेड होगी
• इसके बाद, टर्मिनल टोटल डिफ़िकल्टी (TTD) को प्रूफ़-ऑफ़-वर्क चेन पर मर्ज को ऐक्टिवेट करने के लिए चुना जाएगा। नोड ऑपरेटर को अपने क्लाइंट पर इस मूल्य को मैन्युअल रूप से सेट करना होगा।
• रॉप्सटन मर्ज के लिए उपयोग करने हेतु सटीक टर्मिनल टोटल डिफ़िकल्टी के संबंध में दूसरी घोषणा इस ब्लॉग पर 3 जून, 2022 को पोस्ट की जाएगी। उपयोगकर्ताओं को यह TTD मूल्य के चुने जाने के कुछ दिनों बाद हिट होने की अपेक्षा करनी चाहिए और कम समय की सूचना पर उसके अनुसार अपने क्लाइंट को कॉन्फ़िगर करने के लिए तैयार रहना चाहिए।

बैकग्राउंड

एथेरियम में प्रूफ़-ऑफ़-स्टेक को लाने के वर्षों के प्रयास के बाद, अब हम आखिरी टेस्टिंग स्टेज में प्रवेश कर रहे हैं: जो टेस्टनेट डिप्लॉयमेंट है!

किंटसुगी 🍵, किन 🔥🧱 और कई शैडो फ़ोर्क्स पर क्लाइंट इम्प्लिमेंटेशन का परीक्षण करने के बाद, क्लाइंट टीमें अब प्रूफ़-ऑफ़-वर्क के सबसे पुराने टेस्टनेट रॉप्सटन – को मर्ज के ज़रिए रन करने के लिए तैयार हैं। तैयारी में, नेटवर्क से कॉन्सेंसस प्रदान करने के लिए रॉप्सटन बीकन चेन लॉन्च की गई है।

रॉप्सटन ट्रांज़ीशन के बाद, मेननेट पर फ़ोकस शिफ़्ट के पहले दो और टेस्टनेट (गोएरली और सेपोलिया) का ट्रांज़ीशन, प्रूफ़-ऑफ़-स्टेक पर किया जाएगा। अन्य टेस्टनेट, जैसे कि रिंकेबी और कोवान को कम्युनिटी अलग से बनाए रख सकती है और अपग्रेड कर सकती है, लेकिन इनकी निगरानी अब क्लाइंट डेवेलपर नहीं करेंगे।

यह मर्ज पिछले एथेरियम अपग्रेड से दो तरह से अलग है। पहला, नोड ऑपरेटर्स को अपने कॉन्सेंसस और एक्ज़ीक्यूशन लेयर क्लाइंट दोनों में से किसी एक के बजाय दोनों को एक साथ अपडेट करना होगा। दूसरा, अपग्रेड दो चरणों में एक्टिवेट होता है: पहला बीकन चेन पर स्लॉट हाइट और दूसरा एक्ज़ीक्यूशन लेयर पर टोटल डिफ़िकल्टी मान तक पहुँचने पर।

इन परिस्थितियों को देखते हुए, रोपस्टेन नेटवर्क, जिसे मर्ज के बाद बंद कर दिया जाएगा, पिछले नेटवर्क अपग्रेड की तुलना में डेवलपमेंट प्रोसेस की शुरुआत में ही अपग्रेड करेगा। इससे कम्युनिटी को अपग्रेड प्रोसेस के बारे में जानने के लिए अधिक समय मिल जाएगा।

ध्यान दें: नीचे बताई गई क्लाइंट रिलीज़, प्रूफ़-ऑफ़-स्टेक पर मेननेट के ट्रांज़िशन के लिए उपयुक्त नहीं होंगीं।

जानकारी अपग्रेड करें

समय

मर्ज, दो चरणों की प्रक्रिया है। यह कॉन्सेंसस लेयर पर नेटवर्क अपग्रेड के साथ शुरू होता है, जो स्लॉट हाइट से ट्रिगर होता है। इसके बाद एक्ज़ीक्यूशन लेयर का ट्रांज़िशन प्रूफ़-ऑफ़-वर्क से प्रूफ़-ऑफ़-स्टेक में होता है, जो एक विशिष्ट टोटल डिफ़िकल्टी सीमा से ट्रिगर होता है, जिसे टर्मिनल टोटल डिफ़िकल्टी (TTD) कहा जाता है।

2 जून, 2022 को, स्लॉट 24000 पर, बेलाट्रिक्स अपग्रेड, रॉप्सटन बीकन चेन को मर्ज के लिए तैयार करेगा। उस समय, CL क्लाइंट, प्रूफ़-ऑफ़-वर्क चेन पर हिट के लिए TTD मूल्य प्राप्त करना शुरू करेंगे।

चूंकि प्रूफ़-ऑफ़-वर्क टेस्टनेट की हैश दर बहुत अस्थिर होती है, इसलिए TTD मूल्य को पहले सीमा से बहुत अधिक उच्च मूल्य, 100000000000000000000000 पर सेट किया जाएगा। रॉप्सटन की मौजूदा हैश दर पर, उसे प्राप्त करने में ~250 वर्ष लगेंगे।

बीकन चेन पर बेलाट्रिक्स अपग्रेड हो जाने के बाद, एक नया TTD मूल्य, जो कि कुछ दिन बाद प्राप्त होने की उम्मीद है, चुना जाएगा और उसकी घोषणा की जाएगी। इसके बाद उपयोगकर्ताओं को अपने नोड को इस नए मान के अनुसार कॉन्फ़िगर करना होगा। ऐसा करने के निर्देश, जिसके साथ प्रत्येक क्लाइंट उपलब्ध है, यहां दिए गए हैं।

जब रॉप्सटन पर यह नया TTD हिट होगा या इससे अधिक हो जाएगा, तो ट्रांज़िशन पेरिस कोडनाम वाला निष्पादन परत का भाग शुरू हो जाएगा। फिर से, ध्यान रखें कि रॉप्सटन पर हैश दर काफ़ी परिवर्तनीय है, इसलिए वह असल समय, जिस पर टर्मिनल टोटल डिफ़िकल्टी होती है, अलग-अलग हो सकता है।

निष्पादन परत के TTD से अधिक हो जाने पर, अगला ब्लोक, बीकन चेन सत्यापनकर्ता द्वारा पूरी तरह अकेले बनाया जाता है। हमारा मानना है कि मर्ज तभी पूरा होता है, जब बीकन चेन ने इस ब्लॉक को फ़ाइनलाइज़ कर दिया हो। नेटवर्क की सामान्य स्थितियों में, ऐसा फ़र्स्ट पोस्ट TTD ब्लॉक तक पहुँचने के बाद 2 ईपोक या लगभग 13 मिनट में हो जाना चाहिए!

फ़ाइनलाइज़ किया गया, नया JSON-RPC ब्लॉक टैग, फ़ाइनलाइज़ किया गया नवीनतम ब्लॉक रिटर्न करता है या अगर मर्ज के बाद ऐसा कोई ब्लॉक मौजूद नहीं हो, तो एक त्रुटि दिखाता है। इस टैग का उपयोग एप्लीकेशन में यह चेक करने के लिए किया जा सकता है कि मर्ज पूरा हो गया है या नहीं। इसी तरह, स्मार्ट कॉन्ट्रैक्ट, डिफ़िकल्टी ऑप्टकोड (0x44) की क्वेरी कर सकते हैं, जिसका नाम बदल कर प्रीवरांडाओ पोस्ट मर्ज कर दिया गया है, ताकि यह पता लगाया जा सके कि क्या मर्ज हो गया है। हमारा सुझाव है कि इंफ़्रास्ट्रक्चर प्रोवाइडर फ़ाइनलाइज़ेशन स्टेटस के अलावा नेटवर्क की पूरी स्टेबिलिटी पर भी नज़र रखें।

क्लाइंट रिलीज़

निम्नलिखित क्लाइंट रिलीज़, रोपस्टेन टेस्टनेट पर मर्ज को सपोर्ट करती हैं। मर्ज के दौरान और बाद में नेटवर्क पर बने रहने के लिए नोड ऑपरेटर्स को एक्ज़ीक्यूशन और कॉन्सेंसस लेयर क्लाइंट दोनों को चलाना होगा।

जैसा कि ऊपर उल्लिखित किया गया है, नीचे दी गई रिलीज़ में टर्मिनल टोटल डिफ़िकल्टी के 100000000000000000000000 मान को हार्डकोड किया गया है, जिसे बीकन चेन पर बेलाट्रिक्स अपग्रेड सक्रिय होने के बाद मैन्युअल रूप से अपडेट करने की ज़रूरत होती है।

कौन सा क्लाइंट चलाना है, यह चुनते समय वैलिडेटर्स को EL और CL दोनों पर ज़्यादातर क्लाइंट चलाने के जोखिमों के प्रति विशेष रूप से सावधान रहना चाहिए। इन जोखिमों और उनके परिणामों के बारे में अधिक जानकारी यहाँ दी गई है। मौजूदा EL और CL क्लाइंट वितरण का अनुमान और एक क्लाइंट से दूसरे क्लाइंट पर स्विच करने की जानकारी यहाँ दी गई है।

ध्यान दें: अगर आपने 43531756765713534 की रॉप्सटन TTD रिलीज़ का क्लाइंट पहले डाउनलोड किया है, तो आपको अपनी रिलीज़ को अपडेट करना चाहिए या TTD को मैन्युअल रूप से 100000000000000000000000 निर्दिष्ट किए अनुसार यहां ओवरराइड करना चाहिए।

कॉन्सेंसस लेयर

लोडस्टार नोट: नवीनतम लोडस्टार रिलीज़, v0.37.0, में पुराना रॉप्सटन TTD मान 43531756765713534 है। रॉप्सटन मर्ज के साथ सुसंगत होने के लिए, जो कि अब 100000000000000000000000 के TTD का उपयोग करता है, लोडस्टार के उपयोगकर्ताओं को इस मान को मैन्युअल रूप से ओवरराइड करना होगा। ऐसा करने के निर्देश टीम की रिलीज़ घोषणा नोट में मिल सकते हैं।

एक्ज़ीक्यूशन लेयर

गेथ नोट: नवीनतम गो-इथेरियम (गेथ) रिलीज़, शारब्लू (सं1.10.18), में रॉप्सटन TTD का पुराना 43531756765713534 मूल्य है। रॉप्सटन मर्ज के साथ सुसंगत होने के लिए, जो कि अब 100000000000000000000000 के TTD का उपयोग करता है, गेथ के उपयोगकर्ताओं को:

• नवीनतम मास्टर ब्रांच पर स्रोत से निर्माण करना होगा
• नवीनतम डॉकर इमेज का उपयोग करना होगा
• क्लाइंट को शुरू करते समय नीचे दी गई कमांड को चलाकर TTD को मैन्युअल रूप से ओवरराइड करना: --override.terminaltotaldifficulty 100000000000000000000000।

अपग्रेड की विशेषताएँ

मर्ज के लिए सहमति-क्रिटिकल परिवर्तन, दो स्थानों पर निर्दिष्ट किए गए हैं:

इनके अलावा, दो अन्य विनिर्देश यह कवर करते हैं कि सहमति और निष्पादन परत क्लाइंट किस तरह इंटरैक्ट करते हैं:

• एक्ज़ीक्यूशन-एपिस रिपॉज़िटरी में बताए गए इंजन API का इस्तेमाल, कॉन्सेंसस और एक्ज़ीक्यूशन लेयर के बीच कम्युनिकेशन के लिए किया जाता है
• सहमति विशिष्ट रिपॉज़िटरी के सिंक फ़ोल्डर में निर्दिष्ट ऑप्टिमिस्टिक सिंक का उपयोग निष्पादन परत क्लाइंट सिंक करते समय सहमति परत द्वारा ब्लॉक को इम्पोर्ट करने के लिए और पहले से लेकर बाद के हेड ऑफ़ द चेन का आंशिक दृश्य दिखाने के लिए किया जाता है

आम सवाल

नोड ऑपरेटर के तौर पर, मुझे क्या करना चाहिए?

मर्ज के बाद, एथेरियम फ़ुल नोड, प्रूफ़-ऑफ़-स्टेक बीकन चेन को रन करने वाले सहमति परत क्लाइंट को और यूज़र स्थिति का प्रबंधन करने वाले और लेनदेनों से संबद्ध गणनाओं को रन करने वाले निष्पादन परत क्लाइंट को संयोजित करेगा। ये JSON RPC विधियों के एक नए सेट, इंजन API का उपयोग करके एक प्रमाणित पोर्ट पर कम्युनिकेट करते हैं। EL और CL क्लाइंट, JWT सीक्रेट का उपयोग करके एक दूसरे को प्रमाणीकृत करता है। नोड ऑपरेटर को इन्हें जनरेट करने और कॉन्फ़िगर करने के तरीके के निर्देशों के लिए उनके क्लाइंट प्रलेखन को देखना चाहिए।

दूसरे शब्दों में, अगर आप पहले से ही बीकन चेन पर कोई नोड चला रहे थे, तो अब आपको एक एक्ज़ीक्यूशन लेयर क्लाइंट भी चलाना होगा। इसी तरह, अगर आप मौजूदा कार्य-का-प्रमाण नेटवर्क पर कोई नोड चला रहे थे, तो आपको एक कॉन्सेंसस लेयर क्लाइंट चलाना होगा। वे सुरक्षित रूप से संचार कर सकें, इसके लिए JWT टोकन प्रत्येक क्लाइंट में पास किया जाना चाहिए।

यहाँ ध्यान दिया जाना चाहिए कि हालाँकि ये दोनों ही कॉन्सेंसस लेयर क्लाइंट रिलीज़ का हिस्सा हैं, लेकिन फिर भी बीकन नोड चलाना, वैलिडेटर क्लाइंट चलाने से अलग होता है। स्टेकर को ये दोनों चलाना चाहिए, लेकिन नोड ऑपरेटर्स को केवल पहले वाले की ही ज़रूरत होती है। यह पोस्ट दोनों घटकों के बीच के अंतर को और अधिक विस्तार से समझाती है।

यह भी ध्यान रखें कि हर लेयर, पियर्स का एक अलग सेट बनाए रखेगी और अपने API दिखाएगी। इस प्रकार बीकन और JSON RPC API दोनों अपेक्षानुसार काम करना जारी रखेंगे।

आखिरी में, अंतिम रॉप्सटन TTD मूल्य के इस ब्लॉग पर घोषणा के लिए 6-7 को देखना याद रखें।

स्टेकर के तौर पर, मुझे क्या करना होगा?

जैसा कि ऊपर बताया गया है, बीकन चेन पर मौजूद सत्यापनकर्ताओं को मर्ज के बाद अपने कॉन्सेंसस लेयर क्लाइंट्स के अलावा एक्ज़ीक्यूशन लेयर क्लाइंट को भी चलाना होगा। मर्ज से पहले, इसकी पुरज़ोर अनुशंसा की गई थी, लेकिन सत्यापनकर्ता ये कार्य तृतीय-पक्ष के प्रदाताओं को आउटसोर्स कर सकते थे। यह इसलिए संभव था, क्योंकि एक्ज़ीक्यूशन लेयर पर जिस डेटा की ज़रूरत थी, वह केवल डिपॉज़िट अनुबंध के अपडेट का डेटा था।

मर्ज के बाद, सत्यापनकर्ताओं को यह सुनिश्चित करना होगा कि उनके द्वारा बनाए गए और प्रमाणित किए गए ब्लॉक में किए जाने वाले लेन-देन वैध हों। ऐसा करने के लिए, प्रत्येक बीकन नोड को एक्ज़ीक्यूशन लेयर क्लाइंट के साथ जोड़ा जाना चाहिए। ध्यान रखें कि एक से ज़्यादा सत्यापनकर्ताओं को एकल बीकन नोड और निष्पादन परत क्लाइंट कॉम्बो में अभी भी पेयर किया जा सकता है। हालाँकि इससे सत्यापनकर्ताओं की ज़िम्मेदारी बढ़ जाती है, लेकिन इससे ब्लॉक का प्रस्ताव देने वाले सत्यापनकर्ता को उससे संबंधित लेन-देन का प्राथमिकता शुल्क (जो अभी माइनर्स को मिलता है) लेने का अधिकार भी मिलता है।

जहाँ वैलिडेटर्स के रिवॉर्ड, बीकन चेन पर एकत्रित होंगे और उनकी निकासी के लिए एक और नेटवर्क अपग्रेड ज़रूरी होगा, वहीं लेनदेन शुल्क का भुगतान, बर्निंग और वितरण एक्ज़ीक्यूशन लेयर पर ही जारी रहेगा। इस प्रकार वैलिडेटर, किसी भी एथेरियम पते को लेनदेन शुल्क का प्राप्तकर्ता सेट कर सकते हैं।

आपके सहमति क्लाइंट को अपडेट करने के बाद, आपके सत्यापनकर्ता क्लाइंट कॉन्फ़िगरेशन के भाग के रूप में फ़ी प्राप्तकर्ता को ज़रूर सेट करें ताकि यह सुनिश्चित हो सके कि लेनदेन फ़ी आपके नियंत्रण के पते पर भेजी जाए।

यदि आपने किसी तृतीय-पक्ष प्रदाता का उपयोग करके दांव लगाया है, तो यह तय करना आपके चयनित प्रदाता पर निर्भर करता है कि ये शुल्क कैसे आवंटित किए जाएँगे।

टेस्टनेट अपग्रेड वैलिडेटर्स के लिए यह सुनिश्चित करने का आखिरी मौका है कि उनका सेटअप अपेक्षानुरूप काम कर रहा है और समस्याओं को हल कर रहा है। मर्ज की तैयारी में रॉप्सटन बीकन चेन पर सत्यापनकर्ता रन करने के बारे में जानकारी रॉप्सटन स्टैकिंग लॉन्चपैड पर मिल सकती है।

हमारा सुझाव है कि मेननेट वैलिडेटर, एथेरियम मेननेट के प्रूफ़-ऑफ़-स्टेक में ट्रांज़िशन से पहले रोपस्टेन और अन्य टेस्टनेट पर मर्ज चलाकर ज़रूर देख लें।

एप्लिकेशन या टूलिंग डेवलपर के तौर पर, मुझे क्या करना चाहिए?

अभी रोपस्टेन पर मर्ज लाइव हो रहा है, इसलिए अब यह सुनिश्चित करने का समय आ गया है कि आपका उत्पाद प्रूफ़-ऑफ़-स्टेक ट्रांज़िशन करके और मर्ज के बाद सही ढंग से काम करे। जैसा कि पिछली पोस्ट में बताया गया है, मर्ज का एथेरियम पर डिप्लॉय किए गए अनुबंधों के सबसेट पर बहुत ही कम प्रभाव पड़ेगा, जिनमें से कोई भी टूटना नहीं चाहिए। इसके अलावा, यूज़र API एंडपॉइंट में लॉयन का हिस्सा एक जैसा बना रहेगा (बशर्ते कि आप प्रूफ़-ऑफ़-वर्क विशिष्ट तरीकों जैसे eth_getWork का उपयोग नहीं कर रहे हों)।

इस तरह इथेरियम पर अधिकांश एप्लिकेशन में चेन में मौजूद अनुबंधों से कहीं ज़्यादा चीज़ें शामिल होती है। अब आपको यह सुनिश्चित करना चाहिए कि आपका फ्रंट एंड कोड, टूलिंग, डिप्लॉयमेंट पाइपलाइन और चेन से बाहर के अन्य घटक, मनचाहे तरीके से काम करें। हमारा सुझाव है कि डेवलपर्स किल्न पर एक पूरी टेस्टिंग और डिप्लॉयमेंट साइकल ज़रूर चलाएँ और टूल्स या डिपेंडेंसी में कोई भी समस्या होने पर प्रोजेक्ट के मेंटेनर्स को उसकी रिपोर्ट करें। अगर आप इस बारे में निश्चित नहीं हैं कि आपको किसी समस्या की रिपोर्ट कहाँ करनी चाहिए, तो कृपया इस रिपोज़िटरी का इस्तेमाल करें।

इथेरियम यूज़र या ईथर धारक के रूप में, क्या मुझे कुछ करना होगा?

नहीं। इथेरियम मेननेट इस टेस्टनेट से प्रभावित नहीं होता है। मेननेट के ट्रांज़िशन से पहले इस ब्लॉग पर आगे की कुछ घोषणाएँ की जाएँगी।

माइनर के तौर पर क्या मुझे कुछ करना होगा?

नहीं। यदि आप एथेरियम मेननेट या रोपस्टेन पर माईनिंग कर रहे हैं, तो आपको पता होना चाहिए कि मर्ज के बाद प्रत्येक नेटवर्क पूरी तरह से प्रूफ़-ऑफ़-स्टेक के अंतर्गत काम करेगा। तब नेटवर्क पर माइनिंग करना संभव नहीं रह जाएगा।

ऐसा रोपस्टेन पर संभवतः 8 जून, 2022 के आसपास और एथेरियम मेननेट के लिए इस साल के अंत तक हो जाएगा।

सत्यापनकर्ता के तौर पर क्या मैं अपनी हिस्सेदारी वापस ले सकता हूँ?

नहीं। मर्ज इथेरियम का अब तक का सबसे जटिल अपग्रेड है। नेटवर्क की रुकावटों के जोखिम को कम करने के लिए, एक न्यूनतम दृष्टिकोण अपनाया गया, जिसमें इस अपग्रेड से सभी नॉन-ट्रांज़िशन बदलावों को हटा दिया गया।

मर्ज के बाद के पहले अपग्रेड में शायद बीकन चेन से निकासी की सुविधा उपलब्ध होने की संभावना है। कॉन्सेंसस और एक्ज़ीक्यूशन दोनों लेयरों के लिए स्पेसिफ़िकेशन तैयार किए जा रहे हैं।

मेरे और भी प्रश्न हैं, मैं उन्हें कहां पूछ सकता/सकती हूं?

मर्ज कम्युनिटी कॉल को 3 जून, 14:00 UTC पर शेड्यूल किया जाएगा। क्लाइंट के डेवलपर और शोधकर्ता, नोड ऑपरेटर, स्टैकर, इन्फ़्रास्ट्रक्चर और टूलींग प्रोवाइडर और कम्युनिटी के सदस्यों के प्रश्नों का उत्तर देने के लिए उपलब्ध रहेंगे।

मर्ज कब होगा?

इस पोस्ट के प्रकाशन के समय, एथेरियम मेननेट प्रूफ़-ऑफ़-स्टेक ट्रांज़िशन की तारीख तय नहीं की गई थी। किसी तारीख का दावा करने वाला कोई भी स्रोत, स्कैम हो सकता है। अपडेट इस ब्लॉग पर पोस्ट किए जाएँगे। कृपया सुरक्षित रहें!

यह मानते हुए कि रोपस्टेन में कोई समस्या नहीं मिली है, क्लाइंट टेस्टिंग पूरी हो जाने के बाद, एथेरियम के अन्य टेस्टनेट, मर्ज से होकर गुज़रेंगे। गोएर्ली और सेपोलिया का ट्रांज़िशन सफलतापूर्वक हो जाने और इनमें स्टेबिलिटी आ जाने के बाद, बीकन चेन पर बेलाट्रिक्स अपग्रेड के लिए स्लॉट हाइट चुनी जाएगी और मेननेट ट्रांज़िशन के लिए एक डिफ़िकल्टी मान तय किया जाएगा। इसके बाद, क्लाइंट रिलीज़ जारी करेंगे, जिससे मेननेट पर मर्ज सक्षम होगा। इनकी घोषणा इस ब्लॉग और अन्य कम्युनिटी पब्लिकेशन में की जाएगी।

लगता है कि कोई समस्या नहीं मिली है। हालाँकि, अगर इस प्रोसेस में कहीं पर भी कोई समस्या आती है या टेस्ट का कवरेज अपर्याप्त माना जाता है, तो डिप्लॉयमेंट प्रोसेस को जारी रखने से पहले इन समस्याओं का समाधान किया जाएगा।

इसके बाद ही मर्ज की सही तारीख का अनुमान लगाना संभव होगा।

दूसरे शब्दों में, 🔜।

---

Pengumuman Penggabungan Ropsten

• Ropsten akan menjadi jaringan percobaan lama pertama yang dijalankan melalui Penggabungan
• Rantai Suar Ropsten yang baru diluncurkan pada 30 Mei 2022 untuk menyediakan konsensus bagi jaringan
• Rantai Suar Ropsten akan ditingkatkan ke aturan protokol yang kompatibel dengan penggabungan (Bellatrix) di ruang 24000, diperkirakan pada 2 Juni 2022
• Setelah ini, Total Tingkat Kesulitan Terminal (TTD) akan dipilih untuk mengaktifkan Penggabungan di rantai bukti kerja. Operator simpul perlu mengatur nilai ini secara manual di klien mereka.
• Pengumuman lain dengan Total Tingkat Kesulitan Terminal yang tepat untuk digunakan pada Penggabungan Ropsten akan diposting ke blog ini pada 3 Juni 2022. Pengguna berharap nilai TTD ini akan dicapai dalam beberapa hari setelah dipilih, dan juga harus siap untuk mengonfigurasi klien mereka dalam waktu singkat.

Latar Belakang

Setelah bertahun-tahun berusaha menghadirkan bukti taruhan ke Ethereum, sekarang kami memasuki tahap percobaan akhir: penyebaran jaringan percobaan!

Setelah mencoba implementasi klien di Kintsugi 🍵, Kiln 🔥🧱 dan beberapa shadow fork, tim klien sekarang siap untuk menjalankan Ropsten – jaringan percobaan bukti kerja terlama – melalui Penggabungan. Sebagai persiapan, Rantai Suar Ropsten telah diluncurkan untuk menyediakan konsensus bagi jaringan.

Setelah transisi Ropsten, dua lagi jaringan percobaan (Goerli dan Sepolia) akan dialihkan ke bukti taruhan sebelum fokus beralih ke jaringan utama. Jaringan percobaan lainnya, seperti Rinkeby dan Kovan, mungkin akan dipertahankan dan ditingkatkan secara terpisah oleh komunitas tetapi tidak lagi akan dipantau oleh pengembang klien.

Penggabungan berbeda dari peningkatan Ethereum sebelumnya dalam dua cara. Pertama, operator simpul perlu memperbarui klien lapisan konsensus dan eksekusi secara bersamaan, bukan hanya salah satu dari keduanya. Kedua, peningkatan diaktifkan dalam dua fase: yang pertama pada ketinggian ruang di Rantai Suar dan yang kedua setelah mencapai nilai Total Tingkat Kesulitan pada lapisan eksekusi.

Mengingat keadaan ini, jaringan Ropsten, yang dimaksudkan untuk tidak lagi digunakan setelah Penggabungan, akan dijalankan melalui peningkatan lebih awal dalam proses pengembangan daripada peningkatan jaringan sebelumnya. Ini akan memberi lebih banyak waktu bagi komunitas untuk lebih mengenal proses peningkatan ini.

Catatan: Rilis klien yang dicantumkan di bawah ini tidak akan cocok untuk transisi jaringan utama Ethereum ke bukti taruhan.

Informasi Peningkatan

Pengaturan waktu

Penggabungan merupakan proses dua langkah. Dimulai dengan peningkatan jaringan pada lapisan konsensus, yang dipicu oleh ketinggian ruang. Ini diikuti oleh transisi lapisan eksekusi dari bukti kerja ke bukti taruhan, yang dipicu oleh ambang batas Total Tingkat Kesulitan tertentu, yang disebut Total Tingkat Kesulitan Terminal (TTD).

Pada 2 Juni 2022, pada ruang 24000, peningkatan Bellatrix akan mempersiapkan Rantai Suar Ropsten untuk Penggabungan. Pada saat itu, klien CL akan mulai mendengarkan nilai TTD yang akan dicapai di rantai bukti kerja.

Karena hash rate jaringan percobaan bukti kerja sangat fluktuatif, pertama-tama nilai TTD akan diatur ke nilai yang sangat tinggi, 100000000000000000000000. Pada hash rate Ropsten saat ini, butuh waktu ~250 tahun untuk mencapainya.

Setelah peningkatan Bellatrix terjadi di Rantai Suar, nilai TTD baru, yang diharapkan akan dicapai dalam beberapa hari kemudian, akan dipilih dan diumumkan. Pengguna kemudian perlu mengonfigurasi simpul mereka dengan nilai baru ini. Instruksi untuk melakukannya dengan setiap klien tersedia di sini.

Ketika TTD baru ini dicapai atau terlampaui di Ropsten, bagian lapisan eksekusi transisi, dengan nama kode Paris, akan dimulai. Sekali lagi, perhatikan bahwa hash rate di Ropsten sangat bervariasi, sehingga waktu sebenarnya saat Total Tingkat Kesulitan Terminal berlangsung mungkin berfluktuasi.

Setelah lapisan eksekusi melampaui TTD, blok berikutnya akan diproduksi sepenuhnya oleh validator Rantai Suar. Kami menganggap Penggabungan telah selesai setelah Rantai Suar menyelesaikan blok ini. Dengan asumsi kondisi jaringan normal, ini akan terjadi dalam 2 jangka waktu, atau sekitar 13 menit, setelah blok pasca-TTD pertama dicapai!

Label blok JSON-RPC yang baru, selesai, mengembalikan blok yang terakhir selesai atau kesalahan jika tidak ada blok pasca penggabungan seperti itu. Label ini dapat digunakan untuk aplikasi guna memeriksa apakah Penggabungan telah selesai. Demikian juga, kontrak pintar dapat meminta kode operasi TINGKAT KESULITAN (0x44), diganti namanya menjadi PREVRANDAO pasca-penggabungan, untuk menentukan apakah Penggabungan telah terjadi. Kami menyarankan agar penyedia infrastruktur memantau stabilitas jaringan keseluruhan selain status finalisasi.

Rilis Klien

Rilis klien berikut mendukung Penggabungan di jaringan percobaan Ropsten. Operator simpul harus menjalankan baik klien lapisan eksekusi maupun konsensus agar tetap berada di jaringan selama dan setelah Penggabungan.

Seperti yang disebutkan di atas, rilis berikut memiliki nilai Total Tingkat Kesulitan Terminal hardcode 100000000000000000000000 yang perlu diperbarui secara manual setelah peningkatan Bellatrix diaktifkan di Rantai Suar.

Saat memilih klien mana yang akan dijalankan, validator harus memperhatikan secara khusus risiko menjalankan klien mayoritas baik di EL dan CL. Penjelasan tentang risiko ini dan konsekuensinya dapat ditemukan di sini. Perkiraan distribusi klien EL dan CL saat ini serta panduan untuk beralih dari satu klien ke klien lainnya dapat ditemukan di sini.

Catatan: jika sebelumnya Anda telah mengunduh rilis klien dengan TTD Ropsten 43531756765713534, Anda harus memperbarui rilis atau mengganti TTD secara manual menjadi 100000000000000000000000 seperti yang ditentukan di sini.

Lapisan Konsensus

Nama	Versi	Tautan
Lighthouse	Baby Wizard (2.3.0)	Unduh
Lodestar	Lihat “Catatan Lodestar” di bawah ini	Lihat “Catatan Lodestar” di bawah ini
Prysm	v2.1.3-rc.2	Unduh
Nimbus
Teku	v22.5.2	Unduh

Catatan Lodestar: rilis Lodestar terbaru, v0.37.0, memiliki nilai TTD Ropsten yang sudah usang 43531756765713534. Agar kompatibel dengan Penggabungan Ropsten, yang sekarang menggunakan TTD 100000000000000000000000, pengguna Lodestar perlu mengganti nilai ini secara manual. Instruksi tentang melakukannya dapat ditemukan di postingan pengumuman rilis tim.

Lapisan Eksekusi

Nama	Versi	Tautan
Besu	v22.4.2	Unduh
Erigon	v2022.06.01-alpha	Unduh
go-ethereum (geth)	Lihat “Catatan Geth” di bawah ini	Lihat “Catatan Geth” di bawah ini
Nethermind	v1.13.1	Unduh

Catatan Geth: rilis go-ethereum (geth) terbaru, Sharblu (v1.10.18), memiliki nilai TTD Ropsten yang telah usang 43531756765713534. Agar kompatibel dengan Penggabungan Ropsten, yang sekarang menggunakan TTD 100000000000000000000000, pengguna geth harus:

• Membangun dari sumber di cabang utama terbaru
• Menggunakan gambar Docker terbaru
• Mengganti TTD secara manual, dengan menjalankan perintah berikut saat memulai klien: --override.terminaltotaldifficulty 100000000000000000000000.

Spesifikasi Peningkatan

Perubahan penting konsensus untuk Penggabungan ditetapkan di dua tempat:

• Perubahan lapisan konsensus, di bawah direktori bellatrix dari repositori spesifikasi konsensus
• Lapisan eksekusi berubah, di bawah spesifikasi Paris di repositori spesifikasi eksekusi

Selain itu, dua spesifikasi lainnya mencakup bagaimana klien lapisan konsensus dan eksekusi berinteraksi:

• API Mesin, yang ditetapkan dalam repositori api-eksekusi, digunakan untuk komunikasi antara lapisan konsensus dan eksekusi
• Optimistic Sync, ditetapkan dalam folder sinkronisasi di repositori spesifikasi konsensus, yang digunakan oleh lapisan konsensus untuk mengimpor blok sebagai klien lapisan eksekusi disinkronkan, dan untuk memberikan tampilan parsial kepala rantai dari yang pertama hingga yang terakhir

PERTANYAAN YANG SERING DITANYAKAN

Sebagai operator simpul, apa yang harus saya lakukan?

Setelah penggabungan, simpul penuh Ethereum akan menggabungkan klien lapisan konsensus, yang menjalankan Rantai Suar bukti taruhan, dan klien lapisan eksekusi, yang mengelola state pengguna dan menjalankan komputasi yang terkait dengan transaksi. Simpul ini berkomunikasi melalui port yang diautentikasi menggunakan kumpulan baru metode JSON RPC, yang disebut API Mesin. Klien EL dan CL saling mengautentikasi menggunakan rahasia JWT. Operator simpul harus merujuk pada dokumentasi klien mereka untuk mendapatkan instruksi tentang cara membuat dan mengonfigurasinya.

Dengan kata lain, jika Anda sudah menjalankan simpul di Rantai Suar, sekarang Anda juga perlu menjalankan klien lapisan eksekusi. Demikian juga, jika Anda menjalankan simpul di jaringan bukti kerja saat ini, Anda perlu menjalankan klien lapisan konsensus. Agar mereka berkomunikasi dengan aman, token JWT harus diteruskan ke setiap klien.

Perlu ditekankan bahwa meskipun keduanya merupakan bagian dari rilis klien lapisan konsensus, menjalankan Simpul Suar berbeda dari menjalankan Klien Validator. Penaruh harus menjalankan keduanya, tetapi operator simpul hanya memerlukan yang pertama. Postingan ini menjelaskan perbedaan di antara kedua komponen secara lebih rinci.

Selain itu, perhatikan bahwa setiap lapisan akan mempertahankan kumpulan peer independen dan mengekspos API-nya sendiri. API Suar dan JSON RPC keduanya akan terus berfungsi seperti yang diharapkan.

Terakhir, ingatlah untuk memeriksanya kembali pada tanggal 6-7 Juni untuk melihat pengumuman di blog ini tentang nilai akhir TTD Ropsten.

Sebagai penaruh, apa yang perlu saya lakukan?

Seperti yang dijelaskan di atas, validator di Rantai Suar perlu menjalankan klien lapisan eksekusi setelah Penggabungan, selain klien lapisan konsensus mereka. Sebelum penggabungan, hal ini sangat direkomendasikan, tetapi validator dapat mengalihdayakan fungsi ini ke penyedia pihak ketiga. Hal ini dimungkinkan karena satu-satunya data yang diperlukan di lapisan eksekusi adalah pembaruan kontrak deposit.

Setelah penggabungan, validator perlu memastikan bahwa transaksi di blok yang mereka buat dan buktikan adalah valid. Untuk melakukannya, setiap simpul suar harus dipasangkan dengan klien lapisan eksekusi. Perhatikan bahwa beberapa validator masih tetap bisa dipasangkan ke satu simpul suar & kombo klien lapisan eksekusi. Meskipun hal ini memperluas tanggung jawab validator, juga memberi hak kepada validator yang mengusulkan blok atas biaya prioritas transaksi (yang saat ini diberikan kepada penambang).

Meskipun imbalan validator bertambah di Rantai Suar dan akan memerlukan peningkatan jaringan berikutnya untuk ditarik, biaya transaksi akan terus dibayarkan, dibakar, dan didistribusikan di lapisan eksekusi. Validator dapat menentukan alamat Ethereum mana saja sebagai penerima untuk biaya transaksi.

Setelah memperbarui klien konsensus Anda, pastikan untuk menentukan penerima biaya sebagai bagian dari konfigurasi klien validator Anda untuk memastikan bahwa biaya transaksi dikirimkan ke alamat yang Anda kendalikan.

Jika Anda telah bertaruh menggunakan penyedia pihak ketiga, terserah penyedia yang Anda pilih untuk menentukan cara mengalokasikan biaya ini.

Peningkatan jaringan percobaan merupakan kesempatan terakhir bagi validator untuk memastikan bahwa pengaturan mereka berfungsi seperti yang diharapkan dan menyelesaikan masalah. Informasi tentang menjalankan validator di Rantai Suar Ropsten dalam persiapan untuk Penggabungan dapat ditemukan di landasan peluncuran penaruhan Ropsten.

Kami sangat merekomendasikan agar validator jaringan utama dijalankan melalui Penggabungan di Ropsten dan jaringan percobaan lainnya sebelum transisi jaringan utama Ethereum ke bukti taruhan.

Sebagai pengembang aplikasi atau perangkat, apa yang harus saya lakukan?

Dengan ditayangkannya Penggabungan di Ropsten, sekarang adalah saatnya untuk memastikan bahwa produk Anda berfungsi seperti yang diharapkan melalui transisi bukti taruhan dan dalam konteks pasca penggabungan. Seperti yang dijelaskan dalam postingan sebelumnya, Penggabungan hanya akan memiliki dampak minimal pada subkumpulan kontrak yang disebarkan di Ethereum, tidak ada yang akan dilanggar. Selain itu, bagian terbesar dari titik akhir API pengguna akan tetap stabil (kecuali Anda menggunakan metode khusus bukti kerja seperti eth_getWork).

Meskipun demikian, sebagian besar aplikasi di Ethereum melibatkan lebih dari sekadar kontrak di dalam rantai. Sekarang adalah saatnya untuk memastikan bahwa kode front-end, perangkat, saluran penyebaran, dan komponen di luar rantai Anda berfungsi sebagaimana yang dimaksudkan. Kami sangat menyarankan agar pengembang menjalankan silus percobaan & penyebaran penuh di Ropsten (atau Kiln) serta melaporkan masalah apa pun pada perangkat atau dependensi terhadap pengelola proyek tersebut. Jika Anda tidak yakin tempat untuk membuka suatu masalah, gunakan repositori ini.

Sebagai pengguna Ethereum atau pemegang Ether, apakah ada yang perlu saya lakukan?

Tidak. Jaringan utama Ethereum tidak terpengaruh oleh jaringan percobaan ini. Pengumuman berikutnya akan dibuat di blog ini sebelum transisi jaringan utama.

Sebagai penambang, apakah ada yang perlu saya lakukan?

Tidak. Jika Anda menambang di jaringan utama Ethereum atau Ropsten, Anda harus menyadari bahwa setiap jaringan akan beroperasi sepenuhnya di bawah bukti taruhan setelah Penggabungan. Pada saat itu, penambangan tidak lagi dapat dilakukan di jaringan.

Ini diharapkan sekitar 8 Juni 2022 di Ropsten dan akhir tahun ini untuk jaringan utama Ethereum.

Sebagai validator, bisakah saya menarik taruhan saya?

Tidak. Penggabungan adalah peningkatan ke Ethereum yang paling rumit untuk saat ini. Untuk meminimalkan risiko gangguan jaringan, pendekatan minimal diambil yang mengecualikan perubahan non-transisi dari peningkatan ini.

Penarikan dari Rantai Suar kemungkinan akan diperkenalkan sebagai peningkatan pertama setelah Penggabungan. Spesifikasi baik untuk lapisan konsensus dan eksekusi sedang dalam proses.

Saya masih punya pertanyaan, ke mana saya harus menanyakannya?

Panggilan Komunitas Penggabungan dijadwalkan pada 3 Juni, pukul 14.00 UTC. Pengembang dan peneliti klien akan tersedia untuk menjawab pertanyaan dari operator simpul, penaruh, penyedia infrastruktur & perangkat, serta anggota komunitas.

kapan penggabungan?

Sejak dipublikasikannya postingan ini, tanggal untuk transisi bukti taruhan jaringan utama Ethereum belum ditetapkan. Sumber mana pun yang mengklaim sebaliknya kemungkinan adalah penipuan. Pembaruan akan diposting di blog ini. Tetap aman!

Dengan asumsi tidak ditemukan masalah dengan Ropsten, setelah percobaan klien selesai, jaringan percobaan Ethereum lainnya, akan dijalankan melalui Penggabungan. Setelah Goerli dan Sepolia berhasil ditransisikan dan distabilkan, ketinggian ruang akan dipilih untuk peningkatan Bellatrix di Rantai Suar dan nilai tingkat kesulitan akan ditetapkan untuk transisi jaringan utama. Kemudian klien akan membuat rilis yang memungkinkan Penggabungan di jaringan utama. Hal ini akan diumumkan di blog ini dan di publikasi komunitas lainnya.

Ini dianggap tidak ditemukan masalah. Namun, jika ditemukan masalah pada titik mana pun di dalam prosesnya atau cakupan percobaan dinilai tidak mencukupi, hal ini akan diselesaikan sebelum melanjutkan proses penyebaran.

Hanya dengan demikianlah dimungkinkan untuk memperkirakan tanggal pasti Penggabungan.

Dengan kata lain, 🔜.

---

ロプステンのマージ実施の発表

• ロプステンでマージを実施します。これは、長期稼働中のテストネットでは初めての試みとなります
• ネットワークに合意形成(コンセンサス)機能を導入するため、2022年5月30日にロプステンの新たなビーコンチェーンがローンチされました
• ロプステンのビーコンチェーンは、2022年6月2日のスロット24000で、マージに対応したプロトコルルール(ベラトリックス)にアップグレードされる予定です
• その後、このプルーフ・オブ・ワークでマージをアクティベートするための最終合計難易度(TTD)が決定されます。 ノードオペレーターは、手動でクライアントにこの値を設定する必要があります
• ロプステンのマージで使用される正確な最終合計難易度は、2022年6月3日にこのブログで発表される予定です。 このTTD値は、決定されてから数日のうちに到達すると予想されています。そのため、ユーザーは、発表後すぐにクライアントの設定を行えるよう、あらかじめ準備を整えておく必要があります

背景

わたしたちはイーサリアムにプルーフ・オブ・ステークを導入するための長い取り組みを経て、ついにテストの最終段階であるテストネットのデプロイメントを開始しました。

クライアントチームは、すでにキンツギ🍵、キルン🔥🧱 、および多くののシャドーフォークでクライアント実装をテスト済みです。そして今回いよいよ、もっとも古いプルーフ・オブ・ワークのテストネットであるロプステンでマージを実施します。 そしてそのための準備として、ロプステンのビーコンチェーンをローンチしてこのネットワークに合意形成(コンセンサス)機能を導入しました。

ロプステンの移行が完了した後、さらに2つのテストネット(ゴエリとセポリア)をプルーフ・オブ・ステークに移行する予定です。その後、メインネットにフォーカスをシフトします。 リンケビーやコヴァンなどのその他のテストネットについては、コミュニティによって別途メンテナンスやアップグレードが行われる可能性はありますが、クライアントの開発者による監視はなくなります。

マージは、従来のイーサリアムのアップグレードとは2つの点で異なります。 まず、ノードオペレーターは、合意レイヤーと実行レイヤーのいずれか一方のみのクライアントではなく、両方についてアップデートを実行する必要があります。 さらに、アップグレードは2つのフェーズでアクティベートされます。フェーズのトリガーはそれぞれ、ビーコンチェーンのスロットの高さと実行レイヤーの合計難易度の到達値です。

上記の点から、マージ後に非推奨となるロプステンのネットワークでは、これまでのネットワークアップグレードと比較して、開発プロセスのより早い段階でアップグレードが実行されることになります。 そのため、コミュニティはより多くの時間をかけて、アップグレードプロセスについて知識を深めることができます。

注：以下のクライアントリリースは、イーサリアムメインネットのプルーフ・オブ・ステークへの移行には適していません。

アップグレード情報

時期

_マージ_は、2段階のプロセスです。 最初に、合意レイヤーのネットワークのアップグレードが行われます。これは、スロットの高さによってトリガーされます。 続いて、実行レイヤーがプルーフ・オブ・ワークからプルーフ・オブ・ステークに移行します。これは、最終合計難易度(TTD)と呼ばれる特定の合計難易度しきい値によってトリガーされます。

2022年6月2日のスロット24000に行われるベラトリックスアップグレードにより、ロプステンのビーコンチェーンのマージの準備が整います。 その時点で、合意レイヤー(CL)クライアントはプルーフ・オブ・ワーク・チェーン上でヒットするTTD値のリッスンを開始します。

プルーフ・オブ・ワークのテストネットのハッシュレートは非常に変動しやすいため、最初のTTD値は、100000000000000000000000という非常に高い値に設定されます。 ロプステンの現在のハッシュレートでは、この値に到達するまでに最長250年かかります。

ビーコンチェーンのベラトリックスアップグレード完了後、新たなTTD値が決定され、発表されます。この値は、数日の間に到達すると予想されています。 ユーザーは、この新しい値を使用してノードを構成する必要があります。 クライアントごとの構成方法は、こちらに記載されています。

ロプステンで、このTTD値に到達したとき、またはこの値を超えたとき、実行レイヤーでの移行段階(パリというコードネームが付けられています)が開始されます。 しかし、ロプステンのハッシュレートは変動しやすいことで知られています。そのため、最終合計難易度に到達する実際の時間は、上記の予想とは異なる可能性があります。

実行レイヤーがTTDを超えると、次のブロックはビーコンチェーンのバリデータのみによって生成されます。 ビーコンチェーンがこのブロックを確定すると、マージは完了したと見なされます。 通常のネットワークの状態を想定した場合、これはTTD到達後の最初のブロックがヒットした後の2エポック(つまり、約13分間)に発生します。

新規のJSON-RPCブロックタグであるfinalizedは、確定された最後のブロックを返します。マージ後のブロックが存在しない場合は、エラーを返します。 このタグをアプリケーションで使用して、マージが完了しているかどうかを確認できます。 また、スマートコントラクトでオペコードDIFFICULTY (0x44)を照会することでも、マージが行われたかどうかを知ることができます。このオペコードの名称は、マージ後はPREVRANDAOに変更されます。 インフラプロバイダーは、確定状況に加えて全体的なネットワークの安定性も監視することが強く推奨されます。

クライアントリリース

以下のクライアントリリースで、ロプステンテストネットでのマージがサポートされています。 ノードオペレーターは、合意レイヤーと実行レイヤーの両方のクライアントでアップデートを実行する必要があります。そうしない場合、マージ中またはマージの完了後にネットワークから除外されます。

上記のとおり、以下のリリースでは、最終合計難易度の値として 100000000000000000000000がハードコーディングされています。この値は、ビーコンチェーンでベラトリックスアップグレードがアクティベートされた後に、手動でアップデートする必要があります。

実行するクライアントを選択する際には、バリデータは、実行レイヤー(EL)と合意レイヤー(CL)の両方でマジョリティクライアントを実行するリスクについて、特に留意する必要があります。 そのリスクと影響については、こちらに説明があります。 現時点での実行レイヤー(EL)と合意レイヤー(CL)のクライアント分布の推定値、およびクライアントの切り替えのガイドについては、こちらをご参照ください。

注：すでに、ロプステンのTTD値が43531756765713534となっているクライアントリリースをダウンロードしている場合は、リリースをアップデートするか、こちらの手順に従って、TTD値を100000000000000000000000に上書きする必要があります。

合意レイヤー

名前	バージョン	リンク
ライトハウス	ベイビーウィザード(2.3.0)	ダウンロード
ロードスター	下記の「ロードスターに関する注」を参照	下記の「ロードスターに関する注」を参照
プリズム	v2.1.3-rc.2	ダウンロード
ニンバス
テク	v22.5.2	ダウンロード

ロードスターに関する注：ロードスターの最新リリースであるv0.37.0のロプステンのTTD値は、古い43531756765713534です。 ロードスターのユーザーは、このTTD値を上書きして、現時点でTTD値100000000000000000000000を使用しているロプステンのマージに対応させる必要があります。 上書き方法については、チームのリリースについての発表の投稿記事をご覧ください。

実行レイヤー

名前	バージョン	リンク
ベス	v22.4.2	ダウンロード
エリゴン	v2022.06.01-alpha	ダウンロード
ゴー・イーサリアム(ゲス)	下記の「ゲスに関する注」を参照	下記の「ゲスに関する注」を参照
ネザーマインド	v1.13.1	ダウンロード

ゲスに関する注：ゴー・イーサリアム(ゲス)の最新リリースであるシャ―ブルー(v1.10.18)のロプステンのTTD値は、古い43531756765713534です。 ゲスのユーザーは、以下のいずれかの方法を使用して、現時点でTTD値100000000000000000000000を使用しているロプステンのマージに対応させる必要があります。

• 最新のマスターブランチのソースからビルドする
• 最新のDockerイメージを使用する
• クライアントの開始時に、コマンド--override.terminaltotaldifficulty 100000000000000000000000を実行して、手動でTTD値を上書きする

アップグレードの仕様

マージのための、合意形成(コンセンサス)機能に関連した重要な変更は、以下の2カ所で行われます。

上記に加え、次の2つの仕様によって、合意レイヤーと実行レイヤーの相互作用の方法が指定されます。

• エンジンAPI：execution-apisリポジトリで指定され、合意レイヤーと実行レイヤーの通信に使用する
• オプティミスティック同期：consensus-specsリポジトリのsyncフォルダで指定され、実行レイヤークライアントの同期中に合意レイヤーがブロックをインポートするために、および合意レイヤーからのチェーンの先頭の部分的なビューを実行レイヤーに提供するために使用する

よくある質問

ノードオペレーターは、何をすればよいでしょうか?

マージ後、イーサリアムのフルノードは、ビーコンチェーンでプルーフ・オブ・ステークを実行する合意レイヤークライアントと、ユーザー状態を管理し、トランザクションに関連する計算を行う実行レイヤークライアントの2つを合わせたものになります。 これらは、エンジンAPIと呼ばれる新しいJSON-RPC方式を使用して、認証されたポートを介して通信します。 実行レイヤー(EL)クライアントと合意レイヤー(CL)クライアントは、JWTシークレットを使用して互いを認証します。 ノードオペレーターは、その生成方法と構成方法について、クライアントのドキュメントを確認する必要があります。

言い換えると、ビーコンチェーンですでにノードを実行している場合は、実行レイヤークライアントも実行する必要があります。 同様に、現在のプルーフ・オブ・ワーク・ネットワークでノードを実行していた場合は、合意レイヤークライアントを実行する必要があります。 2つのクライアントが安全に通信するためには、それぞれのクライアントにJWTトークンを渡す必要があります。

ビーコンノードとバリデータクライアントはどちらも合意レイヤーの一部ですが、ビーコンノードの実行とバリデータクライアントの実行は、明確に異なるものであることに留意してください。 ステーカーは両方を実行する必要がありますが、ノードオペレーターが実行しなければならないのは、ビーコンノードのみです。 この2つのコンポーネントの詳細は、この投稿で説明しています。

また、各レイヤーは独立したピアを維持し、独自のAPIを公開します。 ビーコンとJSON-RPC APIは、どちらも期待どおりに機能し続けます。

6月6日から7日にかけて、ロプステンの最新のTTD値が発表されていないか、このブログを再度確認するようにしてください。

ステーカーは、何をすればよいでしょうか?

上記で説明したように、ビーコンチェーン上のバリデータは、マージ後は合意レイヤークライアントだけでなく、実行レイヤークライアントも実行する必要があります。 マージ前は、推奨されてはいませんでしたが、サードパーティーのプロバイダーに委託することが可能でした。 これが可能だったのは、実行レイヤーで必要なデータは、預入コントラクトへの更新だけだったためです。

マージ後は、作成および証明するブロックのトランザクションが有効であることをバリデータが確認する必要があります。 そのためには、各ビーコンノードと実行レイヤークライアントをペアリングする必要があります。 単一のビーコンノードと実行レイヤークライアントのペアに、複数のバリデータをペアリングすることも可能です。 バリデータの責任が拡大しますが、ブロックを提案するバリデータには、現在はマイナーに支払われている、関連するトランザクションのプライオリティーフィーが与えられます。

ビーコンチェーン上で発生したバリデータ報酬は、次回のネットワークのアップグレードまで引き出せません。しかし、トランザクションフィーは引き続き支払われ、焼却され、実行レイヤー上で配布されます。 バリデータは、トランザクションフィーの受領先として任意のイーサリアムアドレスを指定できます。

合意レイヤークライアントのアップデート後は、必ずバリデータクライアントの設定の一部としてフィーの受領者を設定して、管理するアドレスにトランザクションフィーが確実に送付されるようにしてください。

サードパーティーのプロバイダーを使用してステークを行っている場合は、フィーの割り当て先の指定は選択したプロバイダーに応じて異なります。

テストネットのアップグレードは、バリデータにとってセットアップを確認して問題を解決する最後のチャンスです。 マージのための準備としての、ロプステンのビーコンチェーンでのバリデータの実行について詳しくは、ロプステンのステーキングローンチパッドをご参照ください。

イーサリアムメインネットのバリデータは、メインネットがプルーフ・オブ・ステークに移行される前にロプステンおよびその他のテストネットでマージを試されることを強くお勧めします。

アプリケーション/ツール開発者は何をすればよいでしょうか?

ロプステンでマージが実行される今こそ、プルーフ・オブ・ステークへの移行時およびマージ後にアプリケーションやツールが意図するとおりに機能するかどうかを確認する最適なタイミングです。 以前の投稿で説明したとおり、マージはイーサリアムに展開されたサブセットコントラクトには、最小限の影響しか与えないため、破損の恐れはないはずです。 さらに、ユーザーAPIエンドポイントの大部分は安定しています(eth_getWorkなどのプルーフ・オブ・ワーク固有のメソッドを使用している場合を除く)。

とはいえ、イーサリアム上のほとんどのアプリケーションは、オンチェーン・コントラクトよりもはるかに複雑です。 今こそ、フロントエンドコード、ツール、展開パイプライン、およびその他のオフチェーン・コンポーネントが意図したとおりに機能することを確認するときです。 ロプステン(またはキルン)でフルテストと展開サイクルをすべて実施し、ツールや依存関係に関する問題をプロジェクトの管理者に報告することを強くお勧めします。 問題をオープンする場所をご存知ない場合は、こちらのリポジトリを使用してください。

イーサリアムユーザー、またはイーサ所有者がしなければいけないことはありますか?

いいえ。 イーサリアムメインネットは、このテストネットの影響を受けません。 今後、メインネットの移行前に、このブログでアナウンスを行う予定です。

マイナーがしなければいけないことはありますか?

いいえ。 イーサリアムメインネットまたはロプステンでマイニングを行っている場合は、マージ後はどちらのネットワークも完全にプルーフ・オブ・ステークで稼働するようになることに注意してください。 その時点で、マイニングできなくなります。

ロプステンのマージは2022年6月8日前後に、イーサリアムメインネットのマージは今年後半になると予想されています。

バリデータは自分のステークを引き出すことはできますか?

いいえ。 マージは、これまでのイーサリアムのアップグレードで最も複雑なものになります。 ネットワーク障害のリスクを最小限に抑えるため、今回は移行以外の変更を除外した最小限のアップグレードとすることが採択されました。

ビーコンチェーンからの引き出しが可能となるのは、おそらく、マージ後の最初のアップグレード時になります。 合意レイヤーと実行レイヤーの仕様については、現在進行中です。

ほかに質問がある場合は、どうすればよいですか?

6月3日14:00 UTCに、マージ・コミュニティコールの開催が予定されています。 クライアントの開発者や研究者が参加し、ノードオペレーター、ステーカー、インフラプロバイダー、ツールプロバイダー、コミュニティメンバーからの質問に回答します。

マージの時期

この投稿の公開時点で、イーサリアムメインネットのプルーフ・オブ・ステークへの移行日は決定していません。 「移行時期が決まっている」などと語る情報源は、詐欺である恐れがあります。 今後のアップデートはこのブログに掲載しますので、 これらの詐欺には十分ご注意ください!

ロプステンで問題が見つからなければ、クライアントテストの完了後にイーサリアムのその他のテストネットでマージが実施されます。 ゴエリとセポリアが正常に移行して安定した場合は、ベラトリックスのアップグレードのためにビーコンチェーンのスロットの高さが選択され、メインネットの移行に難易度が設定されます。 次に、クライアントはメインネットでのマージを可能にするリリースを作成します。 これらについては、ブログやその他のコミュニティの出版物で発表が行われます。

上記は、すべてが順調に進むことを前提としています。 プロセスのいずれかの時点で問題が見つかった場合、またはテストカバレッジが不十分であると判断された場合、展開プロセスは一時中断し、問題の解決後に再開します。

その時点で初めて、マージの具体的な実施日を見積もることができます。

つまりは、🔜ということです。

---

‘Anúncio da fusão da rede de testes Ropsten’

• Ropsten será a primeira rede de testes de longa duração executada na Fusão
• Uma nova Beacon Chain Ropsten foi lançada em 30 de maio de 2022 para fornecer consenso à rede
• A data prevista da atualização da Beacon Chain Ropsten com as regras de protocolo compatíveis (Bellatrix) no slot 24000 é 2 de junho de 2022
• Depois disso, um valor de Terminal Total Difficulty (TTD) será definido para ativar a Fusão na cadeia de prova de trabalho. Os operadores de nós deverão definir esse valor para seus clientes manualmente.
• Um outro anúncio com o valor de Terminal Total Difficulty exato a ser usado para a Fusão da Ropsten será feito nesse blog no dia 3 de junho. Os usuários devem esperar que este valor de TTD seja alcançado alguns dias depois de ter sido definido, e deverão estar preparados para configurar seus respectivos clientes em seguida.

História

Depois de anos trabalhando sobre a prova de participação no Ethereum, agora estamos na etapa final de testes: as implantações da rede de testes.

Depois de ter testado implementações de clientes na Kintsugi 🍵, Kiln 🔥🧱 e em diversos shadow forks, graças à Fusão, as equipes dos clientes estão prontas para executar a Ropsten, a rede de testes de prova de trabalho mais antiga. Para isso, foi lançada uma Beacon Chain Ropsten para fornecer consenso à rede.

Depois da transição da Ropsten, mais duas redes de testes (Goerli e Sepolia) passarão à prova de participação antes que isso também seja feito com a rede principal. Outras redes de testes, como Rinkeby e Kovan, podem ser mantidas e atualizadas separadamente pela comunidade, mas não serão mais monitoradas pelos desenvolvedores do cliente.

A Fusão é diferente das melhorias anteriores feitas no Ethereum porque: primeiro, os operadores de nós precisam atualizar tanto os clientes de camada de consenso quanto os clientes de camada de execução, não somente um deles; segundo, a melhoria é ativada em duas fases: a primeira em uma altura de slot na Beacon Chain e a segunda ao atingir um valor de Total Difficulty na camada de execução.

Dadas estas circunstâncias, e em comparação às melhorias realizadas anteriormente, a rede Ropsten, que vai ser descontinuada depois da Fusão, será executada durante a melhoria e logo no início do processo de desenvolvimento. Isso dará à comunidade mais tempo para se familiarizar com o processo de melhoria.

Observação: as versões de clientes enumeradas abaixo não serão adequadas para a transição da rede principal do Ethereum para a prova de participação.

Informações sobre a melhoria

Sincronia

A Fusão é um processo de duas etapas. Começa com uma melhoria de rede na camada de consenso, acionada por uma altura de slot, seguida pela transição da camada de execução de prova de trabalho para prova de participação, acionada por um limite de Total Difficulty específico, conhecido como Terminal Total Difficulty (TTD).

Em 2 de junho de 2022, no slot 24000, a melhoria Bellatrix vai preparar a Beacon Chain Ropsten para a Fusão. Nesse momento, os clientes de camada de consenso (CL, na sigla em inglês) já podem esperar que um valor de TTD seja alcançado na cadeia de prova de trabalho.

Como a taxa de hash das redes de testes de prova de trabalho é muito volátil, o valor de TTD será primeiramente estabelecido a um valor extremamente alto, 100000000000000000000000000000. Ao ritmo da taxa de hash atual da Ropsten, seriam necessários cerca de 250 anos para alcançá-lo.

Depois que a melhoria Bellatrix tiver sido feita na Beacon Chain, um novo valor de TTD, que deveria ser alcançado alguns dias depois, será definido e anunciado. Os usuários terão que configurar o nó deles com este novo valor. As instruções para fazer isso com cada cliente estão disponíveis aqui.

Depois que esse novo TTD é alcançado ou ultrapassado na Ropsten, a parte correspondente à camada de execução da transição, que responde pelo codinome Paris, será ativada. Como dito anteriormente, a taxa de hash na Ropsten é altamente volátil, por isso o momento exato em que o valor de Terminal Total Difficulty é atingido pode variar.

Quando a camada de execução tiver superado o valor de TTD, o próximo bloco será integralmente produzido pelo validador da Beacon Chain. Uma vez que a Beacon Chain tiver finalizado esse bloco, consideraremos a Fusão concluída. Em condições normais de rede, isso deveria acontecer em 2 épocas, ou aproximadamente 13 minutos, depois que o bloco pós-TTD é atingido.

Uma nova tag do bloco JSON-RPC, finalized, retorna o último bloco finalizado ou um erro se não existirem blocos depois da fusão. Esta tag pode ser usada por aplicativos para verificar se a Fusão foi concluída. Da mesma forma, os contratos inteligentes podem consultar o opcode DIFFICULTY (0x44), renomeado PREVRANDAO depois da fusão, para determinar se a Fusão foi realizada. Recomendamos que os provedores de infraestrutura monitorem a estabilidade global da rede, além do estado de finalização.

Versões de clientes

As seguintes versões de clientes são compatíveis com a Fusão na rede de testes Ropsten. Os operadores de nós devem executar tanto um cliente de camada de execução quanto um cliente de camada de consenso para permanecer na rede durante e depois da Fusão.

Como mencionado anteriormente, as versões seguintes têm um valor de Terminal Total Difficulty igual a 100000000000000000000000, que deverá ser atualizado manualmente depois da melhoria Bellatrix na Beacon Chain.

Ao escolher qual cliente executar, os validadores devem estar particularmente atentos aos riscos de executar um cliente principal tanto na camada de execução quanto na de consenso. Veja aqui uma explicação sobre esses riscos e suas consequências. Veja aqui uma estimativa da distribuição de clientes de camada de execução e de camada de consenso, e orientações para mudar de um cliente a outro.

Observação: se você tiver feito download de uma versão de cliente com um TTD Ropsten de 43531756765713534, será necessário atualizar sua versão ou substituir manualmente o TTD para 100000000000000000000000, como especificado aqui.

Camada de consenso

Nome	Versão	Link
Lighthouse	Baby Wizard (2.3.0)	Baixar
Lodestar	Ver «Observação sobre Lodestar» abaixo	Ver «Observação sobre Lodestar» abaixo
Prysm	v2.1.3-rc.2	Baixar
Nimbus
Teku	v22.5.2	Baixar

Observação sobre Lodestar: a última versão da Lodestar, v0.37.0, tem um valor de TTD Ropsten obsoleto de 43531756765713534. Para que seja compatível com a fusão da Ropsten, que utiliza agora um TTD de 100000000000000000000000, os usuários de Lodestar deverão substituir esse valor de maneira manual. As instruções sobre como fazer isso estão disponíveis no artigo sobre o lançamento.

Camada de execução

Nome	Versão	Link
Besu	v22.4.2	Baixar
Erigon	v2022.05.08	Baixar
go-ethereum (geth)	Ver «Observação sobre Geth» abaixo	Ver «Observação sobre Geth» abaixo
Nethermind	v1.13.1	Baixar

Observação sobre Geth: a versão go-ethereum (geth) mais recente, Sharblu (v1.10.18), tem um valor de TTD Ropsten obsoleto de 43531756765713534. Para que seja compatível com a fusão da Ropsten, que utiliza agora um TTD de 1000000000000000000000000000, os usuários de Geth devem realizar uma destas opções:

• Criar desde a origem na última

ramificação<code> master</li>

• Usar a última imagem Docker
• Substituir manualmente o valor de TTD ao executar o comando a seguir no momento da inicialização do cliente: --override.terminaltotaldifficulty 10000000000000000000.</ul>

Especificações da melhoria

As mudanças fundamentais de consenso para a Fusão são especificadas em dois lugares:

• Mudanças na camada de consenso: diretório bellatrix do repositório de especificações de consenso
• Mudanças na camada de execução: na especificação Paris localizada no repositório de especificações de execução

Além disso, duas outras especificações tratam como os clientes das camadas de consenso e execução interagem:

• A Engine API, especificada no repositório execution-apis, é usada para comunicação entre as camadas de consenso e execução
• O Optimistic Sync, especificado na pasta sincronização do repositório de especificações de consenso, é usado pela camada de consenso para importar blocos durante a sincronização do cliente da camada de execução e para fornecer uma visão parcial do cabeçalho da cadeia, do primeiro ao último

Perguntas frequentes

Como operador de nó, o que devo fazer?

Depois da Fusão, um nó completo do Ethereum será uma combinação de um cliente de camada de consenso, que executa a prova de participação na Beacon Chain, e um cliente de camada de execução, que gerencia o estado dos usuários e se encarrega dos cálculos associados às transações. Esses dois clientes se comunicam via uma porta autenticada usando um novo conjunto de métodos JSON RPC chamado Engine API. Os clientes de camada de execução (EL, na sigla em inglês) e de camada de consenso (CL, na sigla em inglês) se autenticam utilizando um segredo JWT. Os operadores de nós devem consultar a documentação de seus clientes para ver instruções de como gerar e configurar esses clientes.

Em outras palavras, se você já executa um nó na Beacon Chain, agora também precisará executar um cliente de camada de execução. Da mesma forma, se antes você executava um nó na rede de prova de trabalho atual, agora deverá executar um cliente de camada de consenso. Para que se comuniquem de forma segura, cada cliente deve receber um token JWT.

Vale a pena salientar que, embora ambos façam parte das versões do cliente de camada de consenso, executar um nó de sinalizador é diferente de executar um cliente validador. Os participantes devem executar os dois, mas os operadores de nós só precisam executar o primeiro. Este post explica a diferença entre esses componentes em mais detalhes.

E vale observar que cada camada vai manter um conjunto independente de pares e expor suas próprias APIs. As APIs Beacon e JSON RPC continuarão funcionando como esperado.

Por último, não se esqueça de que o valor de TTD Ropster definitivo será anunciado neste blog entre os dias 6 e 7 de junho.

Como participante, o que preciso fazer?

Como explicado acima, os validadores na Beacon Chain precisarão executar um cliente de camada de execução depois da Fusão, além de seus clientes de camada de consenso. Antes da Fusão, isso era altamente recomendado, mas os validadores podem ter terceirizado essas funções a outros provedores. Essa opção era possível porque os únicos dados necessários na camada de execução eram atualizações do contrato de depósito.

Depois da Fusão, os validadores devem garantir que as transações em blocos que criam e certificam são válidas. Para fazer isso, cada nó de sinalizador deve ser vinculado a um cliente de camada de execução. Observe que ainda é possível associar vários validadores a uma combinação única de nó de sinalizador e cliente de camada de execução. Embora esse cenário aumente as responsabilidades dos validadores, ele também permite que um validador que propõe um bloco tenha direito às taxas de transação prioritária associadas (atualmente atribuídas aos mineradores).

Embora as recompensas do validador se acumulem na Beacon Chain e exijam uma melhoria posterior na rede para serem retiradas, as taxas de transação seguirão sendo pagas, registradas e distribuídas na camada de execução. Os validadores podem especificar qualquer endereço Ethereum como destinatário das taxas da transação.

Depois de atualizar seu cliente de consenso, certifique-se de definir o fee recipient como parte das configurações de seu cliente validador para garantir que as taxas de transação sejam enviadas para um endereço que você controla.

Se você fez staking usando um provedor de terceiros, cabe a seu provedor selecionado especificar como essas taxas são alocadas.

As melhorias da rede de testes são a última oportunidade para que os validadores garantam que suas configurações funcionem como esperado e solucionem qualquer problema. Informações sobre como executar um validador na Beacon Chain Ropsten em preparação para a Fusão podem ser encontradas na plataforma de lançamento Ropsten.

Recomendamos que os validadores da rede principal executem a Fusão na Ropsten e em outras redes de testes antes da transição da rede principal do Ethereum para a prova de participação.

Como desenvolvedor de apps ou ferramentas, o que devo fazer?

Com a Fusão acontecendo na rede de testes Ropsten, agora é o momento de garantir que seu produto funcione como esperado por meio da transição para a prova de participação e em um contexto de pós-fusão. Como explicamos em um post anterior, a Fusão causará um impacto mínimo em um subconjunto de contratos implementados no Ethereum, nenhum dos quais será rescindido. Além disso, a maior parte dos endpoints da API do usuário permanece estável (a menos que você esteja usando métodos específicos de prova de trabalho como eth_getWork).

Dito isso, a maioria dos aplicativos no Ethereum envolve muito mais do que os contratos on-chain. Agora é quando você quer se certificar de que seu código front-end, ferramentas, pipeline de implantação e outros componentes off-chain funcionem como pretendido. Recomendamos de maneira enfática que os desenvolvedores realizem um ciclo completo de teste e implantação na Ropsten (ou na Kiln) e que informem qualquer problema relacionado a ferramentas ou dependências aos responsáveis desses projetos. Se você não sabe onde informar um problema, utilize este repositório.

Como usuário do Ethereum ou proprietário de Ether, há algo que eu precise fazer?

Não. A rede principal do Ethereum não é afetada por essa rede de testes. Outros anúncios serão publicados neste blog antes da transição à rede principal.

Como minerador, há algo que eu precise fazer?

Não. Se você está minerando na rede principal do Ethereum ou na Ropsten, saiba que depois da Fusão a operação de cada rede será inteiramente feita sob a prova de participação. A partir desse momento, a mineração deixará de ser possível na rede.

Espera-se que isso aconteça por volta de 8 de junho de 2022 na Ropsten e, mais para o final deste ano, na rede principal Ethereum.

Como validador, posso retirar minha participação?

Não. A Fusão é a melhoria do Ethereum mais complexa até hoje. Para minimizar os riscos de interrupções na rede, foi adotada uma abordagem mínima, que excluiu desta melhoria qualquer mudança não transitória.

É provável que a partir da primeira melhoria depois da Fusão você já possa retirar sua participação da Beacon Chain. As especificações para as camadas de consenso e de execução estão sendo definidas.

Tenho mais perguntas. Onde posso fazê-las?

Haverá um encontro online dedicado à Fusão no dia 3 de junho às 14 horas (UTC). Desenvolvedores de clientes e pesquisadores estarão disponíveis para responder a perguntas de operadores de nós, participantes, provedores de infraestrutura e ferramentas, e membros da comunidade.

Quando será a fusão?

A data da transição para o sistema de prova de participação da rede principal do Ethereum ainda não tinha sido definida no momento da publicação deste artigo. É provável que qualquer fonte que afirme o contrário seja uma fraude. As atualizações serão publicadas neste blog. Tenha cuidado!

Supondo que nenhum erro seja encontrado na Ropsten, e quando os testes de clientes sejam finalizados, as demais redes de testes do Ethereum serão executadas durante a Fusão. Uma vez que a transição das redes de testes Goerli e Sepolia tenha terminado e que elas se encontrem estáveis, se selecionará uma altura de slot para a melhoria da Bellatrix na Beacon Chain e um valor de dificuldade será definido para a transição da rede principal. Os clientes farão, então, lançamentos que habilitem a Fusão na rede principal. Estes serão anunciados neste blog e em outras publicações da comunidade.

Isso pressupõe que não haverá problemas. No entanto, se em qualquer momento do processo se detectarem problemas ou caso a cobertura dos testes seja considerada insuficiente, estas questões serão tratadas antes de prosseguir com o processo de implantação.

Somente então poderemos determinar uma data exata para a Fusão.

Em outras palavras, em breve (🔜).

---

Объявление о слиянии Ropsten

• Ropsten станет первой продолжительной по времени тестовой сетью, проходящей через слияние.
• 30 мая 2022 года была запущена новая сеть Ropsten Beacon Chain для достижения консенсуса в сети.
• Ориентировочно 2 июня 2022 года сеть Ropsten Beacon Chain будет обновлена в соответствии с правилами совместимого со слиянием протокола (Bellatrix) в ячейке 24000.
• После этого будет выбрана конечная общая сложность (TTD) для активации слияния в сети с доказательством работы. Операторы узлов должны будут вручную задать это значение в своих клиентах.
• Еще одно объявление с конкретной конечной общей сложностью для слияния Ropsten будет опубликовано в этом блоге 3 июня 2022 года. Пользователям стоит ждать этого значения TTD через несколько дней после его выбора и быть готовыми к настройке своих клиентов соответствующим образом в кратчайшие сроки.

Контекст

После долгих лет работы по внедрению доказательства владения в Ethereum мы приступаем к финальной стадии тестирования — запуску тестовой сети.

Протестировав клиентские реализации на сетях Kintsugi 🍵, Kiln 🔥🧱 и нескольких теневых ветвлениях, клиентские команды теперь готовы провести слияние в самой старой тестовой сети с моделью доказательства работы — Ropsten. При подготовке для обеспечения консенсуса в сети была запущена цепь Ropsten Beacon Chain.

После перехода Ropsten на модель доказательства владения будут переведены еще две тестовые сети (Goerli и Sepolia), и только затем — основная сеть. Другие тестовые сети, Rinkeby и Kovan, могут поддерживаться и обновляться сообществом по отдельности, но больше не будут контролироваться разработчиками клиентов.

Два способа принципиально отличают это слияние от предыдущих обновлений Ethereum. Во-первых, операторам узлов необходимо обновлять свои клиенты слоя и консенсуса, и исполнения одновременно, а не по одиночке. Во-вторых, обновление активируется в два этапа: первый на высоте ячейки в Beacon Chain, а второй — при достижении значения общей сложности на слое исполнения.

Учитывая эти обстоятельства, сеть Ropsten, которая должна быть признана устаревшей после процесса слияния, будет проходить через обновления раньше, чем прежде, то есть в процессе разработки. Таким образом сообщество получит больше времени на ознакомление с процессом обновления.

Примечание. Перечисленные ниже выпуски клиентов не будут подходить для перехода основной сети Ethereum на модель доказательства владения.

Информация об обновлении

Сроки

Процесс слияния будет состоять из двух этапов. Он начнется с обновления сети на слое консенсуса, запускаемого высотой ячейки. За этим следует переход слоя исполнения от доказательства работы к доказательству владения, который запускается определенным пороговым значением общей сложности под названием конечная общая сложность (Terminal Total Difficulty) (TTD).

2 июня 2022 года в ячейке 24000 обновление Bellatrix подготовит Ropsten Beacon Chain к слиянию. К тому времени клиенты CL начнут получать значение TTD для сети с доказательством работы.

Cкорость хэширования в тестовых сетях с доказательством работы очень переменчива, поэтому значение TTD сначала будет установлено на завышенном уровне — 100000000000000000000000. При текущей скорости хэширования Ropsten на достижение такого значения потребуется примерно 250 лет.

По выполнении обновления Bellatrix в сети Beacon Chain будет выбрано и объявлено новое значение TTD, которое ожидается через несколько дней после этого. Затем пользователям потребуется настроить это новое значение на своем узле. Соответствующие инструкции для каждого клиента доступны здесь.

Когда это новое значение TTD будет достигнуто или превзойдено в Ropsten, начнется часть слоя исполнения в рамках перехода с кодовым именем Paris. Еще раз напомним: скорость хэширования Ropsten, как известно, изменчива, поэтому фактическое время достижения значения конечной общей сложности может колебаться.

Как только слой исполнения превысит значение TTD, следующий блок будет создан полностью валидатором сети Beacon Chain. Слияние будет считаться оконченным сразу после того, как сеть Beacon Chain завершит создание этого блока. При нормальных условиях работы сети это должно произойти в течение 2 эпох (или приблизительно через 13 минут) после попадания в первый блок, созданный после достижения TTD!

Новый завершенный тег блока JSON-RPC возвращает последний оконченный блок или ошибку, если такого блока после слияния не существует. Этот тег может использоваться для приложений, чтобы проверять завершенность слияния. Аналогично, умные контракты могут запрашивать опкод DIFFICULTY (0x44), который после слияния получит имя PREVRANDAO, чтобы определить, произошло ли слияние. Мы рекомендуем поставщикам инфраструктуры следить не только за завершением процесса, но и за общей стабильностью сети.

Выпуски клиентов

Следующие выпуски клиентов поддерживают слияние в тестовой сети Ropsten. Операторы узлов должны запускать клиент и слоя исполнения, и консенсуса, чтобы оставаться в сети во время процесса слияния и после него.

Как упоминалось выше, следующие релизы имеют жестко закодированное значение конечной общей сложности 100000000000000000000000, которое нужно будет обновить вручную после обновления Bellatrix в сети Beacon Chain.

При выборе клиента для запуска валидаторы должны уделять особое внимание рискам запуска большинства клиентов, как на EL, так и на CL. Пояснение этих рисков и их последствий можно найти здесь. С оценкой текущего распространения клиентов EL и CL, а также руководством для перехода от одного клиента к другому можно ознакомиться здесь.

Примечание. Если вы ранее загрузили выпуск клиента с Ropsten со значением TTD 43531756765713534, вам нужно обновить выпуск или вручную заменить TTD на 100000000000000000000000, как указано здесь.

Слой консенсуса

Название	Версия	Ссылка
Lighthouse	Baby Wizard (2.3.0)	Скачать
Lodestar	См. «Примечание для Lodestar» ниже	См. «Примечание для Lodestar» ниже
Prysm	v2.1.3-rc.2	Скачать
Nimbus
Teku	v22.5.2	Скачать

Примечание для Lodestar. В последней версии Lodestar v0.37.0 установлено устаревшее значение Ropsten TTD 43531756765713534. Для совместимости с сетью Ropsten после слияния, использующей значение TTD 100000000000000000000000, пользователям Lodestar нужно будет вручную переопределить это значение. Инструкции о том, как это сделать, можно найти в публикации с объявлением о выпуске.

Слой исполнения

Название	Версия	Ссылка
Besu	v22.4.2	Скачать
Erigon	v2022.06.01-alpha	Скачать
go-ethereum (geth)	См. «Примечание для Geth» ниже	См. «Примечание для Geth» ниже
Nethermind	v1.13.1	Скачать

Примечание для Geth. Последняя версия go-ethereum (geth), Sharblu (v1.10.18), использует устаревшее значение Ropsten TTD 43531756765713534. Для совместимости с сетью Ropsten после слияния, использующей значение TTD 100000000000000000000000, пользователям geth нужно будет выполнить одно из действий ниже.

• Использовать исходный код на последней ветке master.
• Использовать последний образ Docker.
• Вручную переписать значение TTD, запустив следующую команду при запуске клиента: --override.terminaltotaldifficulty 100000000000000000000000.

Спецификации обновлений

Критические изменения консенсуса для слияния указаны в двух местах:

• Слой консенсуса изменяется в каталоге bellatrix репозитория consensus-specs.
• Слой исполнения изменяется в репозитории со спецификациями исполнения Paris spec.

В дополнение к этому две другие спецификации охватывают способы взаимодействия клиентов слоя консенсуса и слоя исполнения:

• Интерфейс Engine API, указанный в репозитории execution-apis, используется для коммуникации между слоями консенсуса и исполнения.
• Спецификация Optimistic Sync, указанная в папке sync репозитория consensus-specs, используется слоем консенсуса для импорта блоков по мере синхронизации клиента слоя исполнения и обеспечивает частичный обзор головы цепочки от первого до последнего значения.

Часто задаваемые вопросы

Что нужно делать оператору узла?

После слияния полный узел Ethereum будет объединять в себе клиент уровня консенсуса, запущенный по модели доказательства владения в сети Beacon Chain, и клиент слоя исполнения, который управляет пользовательским состоянием и запускает вычисления, связанные с транзакциями. Слаженность их работы достигается с помощью аутентифицированного порта и нового набора методов удаленного вызова процедур (RPC) JSON под названием Engine API. Клиенты EL и CL аутентифицируют друг друга с помощью секрета JWT. Операторы узлов могут найти инструкции по их созданию и настройке в документации своих клиентов.

Другими словами, если вы уже управляете узлом в Beacon Chain, теперь вам также нужно будет управлять клиентом слоя исполнения. Аналогично, если вы управляете узлом в текущей сети с доказательством выполнения работы, вам будет необходимо управлять клиентом уровня консенсуса. Для их безопасной связи необходимо передать на каждый клиент токен JWT.

Стоит подчеркнуть: хотя они оба являются частью выпусков клиентов слоя консенсуса, запуск узла Beacon отличается от запуска клиента валидатора. Дольщики должны запускать оба узла, но операторам нужен только первый. В этой публикации более подробно объясняется разница между обоими компонентами.

Также обратите внимание, что каждый слой будет содержать независимый набор пиров и собственный программный интерфейс API. Поэтому программные интерфейсы API Beacon и удаленного вызова процедур (RPC) JSON продолжат работать так, как ожидается.

И не забудьте проверить 6–7 июня объявление в этом блоге с окончательным значением Ropsten TTD.

Что нужно делать дольщику?

Как уже говорилось выше, после слияния валидаторам сети Beacon Chain необходимо будет запустить клиент слоя исполнения, а также клиенты слоя консенсуса. Это настоятельно рекомендовалось до слияния, но валидаторы могли передавать эти обязанности третьим сторонам. Это было возможно, потому что единственными данными, необходимыми для уровня выполнения, были обновления депозитного контракта.

После слияния валидаторы должны удостовериться в том, что транзакции в блоках, которые они создают и подтверждают, действительны. Для этого каждый узел Beacon должен быть связан с клиентом слоя исполнения. Обратите внимание, что несколько валидаторов могут быть связаны с одним узлом передачи сигнала и комбинацией клиентов слоя исполнения. Это расширяет круг обязанностей валидаторов, но также дает валидатору, предлагающему блок, право приоритетного получения комиссии за соответствующие транзакции (которые в настоящее время поступают майнерам).

Вознаграждение для валидатора начисляется в сети Beacon Chain и для снятия требует последующего обновления сети, но комиссии за транзакции будут и далее выплачиваться, сжигаться и распределяться на слое исполнения. Валидаторы могут указывать любой адрес Ethereum в качестве получателя комиссий за транзакции.

После обновления клиента консенсуса в настройках клиента валидатора обязательно установите значение fee recipient, чтобы убедиться, что комиссия за транзакцию отправляется на управляемый вами адрес.

Если вы внесли свою долю с помощью третьей стороны, именно она должна указать способ распределения комиссий.

Обновления тестовой сети — последняя возможность для валидаторов убедиться, что настройки работают должным образом, и решить проблемы. Информацию о запуске валидатора в сети Ropsten Beacon Chain в рамках подготовки к слиянию можно найти на панели запуска стейкинга Ropsten.

Мы настоятельно рекомендуем, чтобы валидаторы основной сети запускали слияние в Ropsten и других тестовых сетях, прежде чем основная сеть Ethereum перейдет на доказательство владения.

Что делать разработчику приложений или инструментов?

С запуском слияния на Ropsten настало время удостовериться в том, что ваш продукт будет работать надлежащим образом при переходе к доказательству владения и в среде после слияния. Как говорилось в предыдущей публикации, слияние окажет лишь минимальное воздействие на подмножество контрактов, развернутых в Ethereum, и ни один из них не должен быть нарушен. Кроме того, львиная доля пользовательских конечных точек программного интерфейса API остается стабильной (если вы не используете особые методы доказательства работы, такие как eth_getWork).

Тем не менее большинство приложений в Ethereum охватывает гораздо больше, чем контракты в цепи. Теперь вам пора убедиться, что ваш код интерфейса, инструментарий, конвейер развертывания и другие не входящие в цепь компоненты работают так, как задумано. Мы настоятельно рекомендуем разработчикам выполнить полный цикл тестирования и развертывания на Ropsten (или Kiln) и сообщить соответствующим сопроводителям проектов о любых проблемах с инструментами или зависимостями. Если вы не уверены, где следует сообщить о проблеме, используйте этот репозиторий.

Требуются ли какие-либо действия от пользователя Ethereum или владельца эфира?

Нет. Эта тестовая сеть не повлияет на основную сеть Ethereum. До перехода основной сети в этом блоге будут публиковаться последующие объявления.

Требуются ли какие-либо действия от майнера?

Нет. Если вы занимаетесь майнингом в основной сети Ethereum или Ropsten, вам нужно знать, что после слияния она будет функционировать полностью по принципу доказательства владения. После слияния майнинг в ней будет невозможен.

Слияние запланировано примерно на 8 июня 2022 года в Ropsten и позднее в этом году для основной сети Ethereum.

Может ли валидатор снять свою долю?

Нет. Слияние — самое сложное изменение среды Ethereum за все время ее существования. Чтобы свести к минимуму риски нарушения работы сети, был принят минимальный подход, исключающий во время данного обновления любые изменения, не связанные с переходом.

Снятие доли с Beacon Chain, вероятно, будет введено с первым обновлением после слияния. Спецификации для слоев консенсуса и исполнения находятся в процессе разработки.

У меня есть еще вопросы. К кому с ними обратиться?

Созвон сообщества по вопросам слияния запланирован на 3 июня (14:00 UTC). Исследователи и разработчики клиентов смогут ответить на вопросы операторов узлов, стейкеров, поставщиков инструментов и инфраструктуры, а также членов сообщества.

Когда произойдет слияние?

На момент этой публикации дата перехода основной сети Ethereum на доказательство владения еще не определена. Если кто-то утверждает противоположное, то это, скорее всего, мошенник. Обновления будут публиковаться в этом блоге. Будьте бдительными!

Если никаких проблем с Ropsten не возникнет, другие тестовые сети Ethereum будут проходить через слияние после завершения тестирования клиента. После успешного перехода и стабилизации сетей Goerli и Sepolia будет выбрана высота ячейки для обновления Bellatrix в сети Beacon Chain, а также будет установлено значение сложности для перехода основной сети. Затем клиенты создают выпуски, которые включают слияние на основной сети. Они будут объявлены в этом блоге и других публикациях сообщества.

Предполагается, что никаких проблем не возникнет. Но если на каком-либо этапе процесса появятся проблемы или тестовое покрытие будет недостаточным, эти вопросы будут решены до продолжения развертывания.

Только после этого можно будет определить точную дату слияния.

Иными словами, 🔜.

---

Ropsten 合并公告

• Ropsten 将是第一个执行合并的老牌测试网
• 新的 Ropsten 信标链已在 2022 年 5 月 30 日启动，为网络提供共识
• Ropsten 信标链预计将在 2022 年 6 月 2 日升级到兼容合并的协议规则 (Bellatrix)（位于时隙 24000）
• 此后，Terminal Total Difficulty (TTD) 将被选中，以触发工作量证明链上的合并。 节点运营商将需要在其客户端上手动设置该值。
• 本博客将在 2022 年 6 月 3 日发布另一项公告，并提供用于 Ropsten 合并的具体 Terminal Total Difficulty。 在被选中几天后将达到该 TTD 值，而用户应准备好在短时间内对其客户端进行相应配置。

背景

为了在以太坊中引进权益证明，我们经过多年努力，现在终于进入到最后的测试阶段：测试网部署！

在 Kintsugi 🍵、Kiln 🔥🧱 及多个影子分叉上对客户端实现进行测试后，客户端团队已经准备好让 Ropsten 这个最老牌的工作量证明测试网执行合并。 在准备期间，我们已启动 Ropsten 信标链，为网络提供共识。

在完成 Ropsten 过渡以后，另外两个测试网（Goerli 和 Sepolia）也将过渡到权益证明，然后把重点转移到主网上。 社区可能会单独维护并升级其他测试网，如 Rinkeby 和 Kovan 等，它们不再受客户端开发者的监控。

合并与以往以太坊升级的区别体现在两个方面。 首先，节点运营商需要协同更新他们的共识层和执行层客户端，而不仅限于其中一个。 其次，升级将分两个阶段触发：首先要在信标链的时隙高度，然后要达到执行层的 Total Difficulty 值。

鉴于这些情况，在开发流程当中，Ropsten 网络（合并后弃用）将比以往的网络升级更早地执行升级。 社区将因此获得更多时间，以熟悉该升级流程。

注意：下面列出的客户端版本将不适用于以太坊主网过渡到权益证明。

升级信息

时间安排

_合并_分两个步骤进行。 刚开始时，它将由一个时隙高度触发，在共识层进行网络升级。 随后是执行层从工作量证明过渡到权益证明，由特定的 Total Difficulty（即 Terminal Total Difficulty (TTD)）阈值触发。

2022 年 6 月 2 日，在时隙 24000，Bellatrix 升级将使 Ropsten 信标链做好合并的准备。 届时，共识层客户端将开始侦听在工作量证明链上是否达到 TTD 值。

由于工作量证明测试网的哈希率具有很大波动性，TTD 值在刚开始时被设置得非常高，具体为 100000000000000000000000。 按 Ropsten 的当前哈希率，要达到该值将需要大约 250 年时间。

如果在信标链上进行 Bellatrix 升级，将选中并公布新的 TTD 值，而且预计将在几天后达到该值。 然后，用户将需要使用这个新值配置他们的节点。 如需查看有关对每个客户端执行此项操作的说明，请见此处。

当在 Ropsten 上达到或超过这个新的 TTD 时，过渡的执行层部分（代号为 Paris）将会开始。 同样，请注意 Ropsten 上的哈希率极为易变，因此达到 Terminal Total Difficulty 的实际时间可能发生波动。

如果执行层超过 TTD，下一个区块将完全由信标链验证者生成。 在信标链最终确定该区块后，我们将视合并已完成。 假设网络状况正常，此过程应在达到第一个 TTD 后区块之后的 2 个时段或大约 13 分钟左右发生！

新的 JSON-RPC 区块标签 finalized 将返回最近确定的区块，或者如果不存在此类合并后区块，则会返回错误。 此标签可被用于应用，以检查合并是否已完成。 类似地，智能合约可能会查询 DIFFICULTY 操作码 (0x44) 以确定是否发生合并，该操作码将在合并后被重命名为 PREVRANDAO。 除检查最终确定状态以外，我们还建议基础设施提供商监控整体网络稳定性。

客户端版本

以下客户端版本支持 Ropsten 测试网上的合并。 节点运营商必须同时运行执行层和共识层客户端，以确保在合并期间及合并后留在网络当中。

如上文所述，以下版本的 Terminal Total Difficulty 值将被硬编码为 100000000000000000000000。在信标链上触发 Bellatrix 升级以后，这个值将需要被手动更新。

在选择要运行哪个客户端时，验证者应尤其注意同时在执行层和共识层上运行大多数客户端将会引发的风险。 您可以点击此处以了解关于这些风险及其影响的详细说明。 有关当前执行层和共识层客户端分发的估计情形和在客户端间切换的指南，请见此处。

注意：如果之前下载过 Ropsten TTD 为 43531756765713534 的客户端版本，您必须更新您的版本或手动将 TTD 覆盖为 100000000000000000000000，具体请见此处。

共识层

名称	版本	链接
Lighthouse	Baby Wizard (2.3.0)	下载
Lodestar	参见下方的“Lodestar 说明”	参见下方的“Lodestar 说明”
Prysm	v2.1.3-rc.2	下载
Nimbus
Teku	v22.5.2	下载

Lodestar 说明：最新的 Lodestar 版本 v0.37.0 使用过时的 Ropsten TTD 值，43531756765713534。 要与现在使用 100000000000000000000000 作为 TTD 的 Ropsten 合并兼容，Lodestar 用户将需要手动覆盖该值。 有关此项操作的具体说明，请见团队的发布公告博文。

执行层

名称	版本	链接
Besu	v22.4.2	下载
Erigon	v2022.06.01-alpha	下载
go-ethereum (geth)	参见下方的“Geth 说明”	参见下方的“Geth 说明”
Nethermind	v1.13.1	下载

Geth 说明：最新的 go-ethereum (geth) 版本 Sharblu (v1.10.18) 使用过时的 Ropsten TTD 值，43531756765713534。 要与现在使用 100000000000000000000000 作为 TTD 的 Ropsten 合并兼容，geth 用户必须：

• 使用最新 master 分支上的源进行构建
• 使用最新的 Docker 镜像
• 在启动客户端时运行以下命令，以手动覆盖 TTD：--override.terminaltotaldifficulty 100000000000000000000000。

升级规范

指定在两个地方执行合并的共识关键型更改：

除了这些以外，还有其他两项规范涉及到共识层和执行层客户端的交互方式：

• 在 execution-apis 存储库中指定的引擎应用程序接口可用来实现共识层与执行层间的通信。
• 在执行层客户端进行同步时，共识层使用在共识规范存储库的 sync 文件夹中指定的乐观同步来导入区块，并按前后顺序提供区块链头部的部分视图

常见问题

作为节点运营商，我应该做什么？

合并后，以太坊完整节点将整合共识层客户端（运行权益证明信标链）和执行层客户端（管理用户状态并运行交易相关的计算）。 它们使用一组新的 JSON RPC 方法（称为引擎应用程序接口）通过已验证端口进行通信。 执行层和共识层客户端会使用 JWT 密钥相互验证。 节点运营商应参考其客户端的相关文档，以了解有关如何生成并设置这些客户端的说明。

换言之，如果您已经在信标链上运行节点，现在还需要运行执行层客户端。 同样，如果您正在当前工作量证明网络上运行节点，则还需要运行共识层客户端。 为使其能够安全通信，必须向每个客户端传送 JWT 代币。

值得强调的是，如果它们两个都是共识层客户端版本的一部分，则运行信标节点不同于运行验证者客户端。 质押人必须运行两者，但节点运营商只需要运行前者。 本博客更详细地解释了这两个组件之间的差异。

另外还要注意，每一层都将维护一组独立的对等点并公开自己的应用程序接口。 信标应用程序接口和 JSON RPC 应用程序接口都将继续按预期运行。

最后，别忘了在 6 月 6-7 日再次查看本博客上的公告，了解最终的 Ropsten TTD 值。

作为质押人，我需要做些什么？

前文解释过，合并后信标链上的验证者除了运行其共识层客户端外，还需要运行执行层客户端。合并前，强烈建议验证者运行两种客户端，但验证者可以将这些职能外包给第三方提供商。 这是因为执行层所需的唯一数据就是对存款合约的更新。

合并后，验证者需要确保他们创建并证明的区块中的交易有效。 为此，每个信标节点必须与一个执行层客户端配对。 请注意，多个验证者也可与单个信标节点及执行层客户端组合配对。 虽然这会加大验证者的责任，但同时也让提出区块的验证者有权获取相关交易优先费（目前该权利为矿工所有）。

尽管验证者获得的奖励会在信标链上累积，需要后续网络升级才能提取，但手续费的支付、销毁和分配将继续在执行层上进行。 验证者可以指定任何以太坊地址作为手续费的接收地址。

在更新您的共识客户端后，务必将 fee recipient 设置为您的验证者客户端配置的一部分，以确保交易费发送到由您控制的地址。

如果您是通过第三方提供商质押，则由您选择的提供商指定这些费用的分配方式。

测试网升级是验证者确保其设置正确无误并解决存在的问题的最后机会。 有关在 Ropsten 信标链上运行验证者以便为合并做好准备的更多信息，请见 Ropsten 质押启动板。

在以太坊主网过渡到权益证明前，我们强烈建议主网验证者在 Ropsten 和其他测试网上执行合并。

作为应用或工具开发者，我应该做什么？

随着合并在 Ropsten 上线，现在是时候确保您的产品能在向权益证明过渡期间和合并后的环境中如预期运行。 如之前的博文所述，合并只会对以太坊上部署的合约子集产生非常微弱的影响，应该不会破坏任何合约。 此外，大部分用户的应用程序接口端点仍将保持稳定（除非使用 eth_getWork 等工作量证明的特定方法）。

尽管如此，以太坊上的大多数应用程序涉及的远不止链上合约。 现在您要确保前端代码、工具、部署管道和其他链下组件能够按预期运行。 我们强烈建议开发者在 Ropsten（或 Kiln）上执行一个完整的测试和部署周期，并向这些项目的维护者报告任何工具或依赖项存在的问题。 如果不确定在哪里提出问题，请使用此存储库。

作为以太坊用户或以太币持有者，我需要做什么？

不需要。 以太坊主网不受此测试网的影响。 在主网过渡之前，我们将在此博客中发布后续公告。

作为矿工，我需要做什么？

不需要。 如果在以太坊主网或 Ropsten 上挖矿，您应该了解在合并后，每个网络将完全采用权益证明机制运营。 届时，以太坊网络上将无法再挖矿。

针对 Ropsten 和以太坊主网，此项安排分别将于 2022 年 6 月 8 日和今年稍晚时候生效。

作为验证者，我能否取回质押物？

不需要。 合并是迄今为止最复杂的以太坊升级。 为了尽量降低网络中断的风险，我们采取了最精简的方法，在本次升级中不会包含任何非过渡更改。

合并后的首次升级可能会推出从信标链中取回质押物的功能。 共识层和执行层的规范都在制定中。

我还有其他问题，我可以在哪里提问？

我们计划在 6 月 3 日 14:00（协调世界时）举行有关合并的社区电话会议。 客户端开发者和研究人员将在会上回答由节点运营商、质押人、基础设施和工具提供商，以及社区成员提出的问题。

何时合并？

截止到本博客发布时，以太坊主网的权益证明过渡日期还未确定。 任何来源发布其他相关言论都可能不实。 相关信息更新将通过本博客发布。 请注意网络信息安全！

如果 Ropsten 不存在任何问题，在完成客户端测试后，以太坊的其他测试网也将执行合并。 当 Goerli 和 Sepolia 成功完成过渡并稳定运行后，将为信标链上的 Bellatrix 升级选择一个时隙高度，并且为主网过渡设置一个难度值。 然后，客户端将发布在主网上支持合并的版本。 我们将在此博客以及其他社区出版物上宣布相关消息。

以上均以未发现问题作为前提。 如果在此过程的任何时间点发现问题，或测试范围被判定不够全面，我们将解决这些问题，然后再继续推进部署进程。

只有到这时，才可能估计合并的确切日期。

也就是说，我们会快马加鞭🔜。