Notificación de la fusión de Ropsten

• Ropsten será la primera red de prueba duradera que se ejecute a través de la fusión.
• El 30 de mayo de 2022 se lanzó una nueva cadena de baliza Ropsten para proporcionar consenso a la red.
• La cadena de baliza Ropsten se actualizará según las reglas de protocolo compatibles con la fusión (Bellatrix) en la ranura 24000, lo que se espera que ocurra el 2 de junio de 2022
• Después de esto, se elegirá una Terminal Total Difficulty (TTD) para activar la fusión en la cadena de prueba de trabajo. Los operadores de nodos tendrán que establecer manualmente este valor en sus clientes.
• El 3 de junio de 2022, se publicará en este blog otro anuncio con la Terminal Total Dificulty que se utilizará para la fusión de Ropsten. Los usuarios deben esperar que se alcance este valor de TTD unos días después elegirlo, y debería estar listo para configurarse acordemente en sus clientes en breve.

Contexto

Tras años de trabajo para llevar la prueba de participación a Ethereum, ahora entramos en la fase final de pruebas, es decir, en las implementaciones de la red de prueba.

Tras haber probado implementaciones de cliente en Kintsugi 🍵, Kiln 🔥🧱 y múltiples bifurcaciones en paralelo, ahora ya estamos listos para ejecutar Ropsten, la unidad red de prueba de trabajo más antigua, a través de la fusión. En preparación, se ha lanzado una cadena de baliza Ropsten para proporcionar consenso a la red.

Después de la transición de Ropsten, dos redes de pruebas más (Goerli y Sepolia) pasarán a la prueba de participación antes de que el foco se traslade a la red principal. La comunidad mantendrá y actualizará por separado otras redes de prueba, como Rinkeby y Kovan, aunque dejarán de estar monitorizadas por desarrolladores del cliente.

La fusión se distingue de anteriores actualizaciones de Ethereum en dos aspectos fundamentalmente: en primer lugar, los operadores de nodo tienen que actualizar tanto sus clientes de capa de ejecución, como de consenso a la par, en vez de uno de los dos. Y en segundo, la actualización se activa en dos fases, la primera a la altura de la ranura en la cadena de baliza, y la segunda al llegar a un valor de Dificultad Total en la capa de ejecución.

A tenor de estas circunstancias, la red Ropsten —que se espera que quede obsoleta tras la fusión— se ejecutará a través de la actualización realizada anteriormente en el proceso de desarrollo en vez de actualizaciones anteriores de la red. De esta manera, la comunidad tendrá más tiempo para familiarizarse con el proceso de actualización.

Nota: Los lanzamientos de clientes listados a continuación no serán adecuados para la transición de la red principal de Ethereum a la prueba de participación.

Información acerca de la actualización

Sincronización

La fusión es un proceso de dos pasos. Empieza con la actualización de la red en la capa de consenso, desencadenada por una altura de la ranura. Seguida de la transición de la capa de ejecución de una prueba de trabajo a una prueba de participación, provocada por un umbral de Dificultad Total específico, conocido como Dificultad Total del Terminal (TTD).

El 2 de junio de 2022, en la ranura 24000, la actualización Bellatrix preparará a la cadena de baliza Ropsten para la fusión. En ese momento, los clientes de CL empezarán a oír que se alcanza un valor de TTD en la cadena de prueba de trabajo.

Debido a que la tasa hash de las redes de prueba de trabajo es muy volátil, el valor TTD se establecerá primero a un valor extremadamente elevado, 100000000000000000000000000000. Al ritmo de hash actual de Ropsten, tardaría aproximadamente 250 años en alcanzarlo.

Una vez que se haya producido la actualización de Bellatrix en la cadena de baliza, se elegirá y anunciará un nuevo valor de TTD , que se espera que se alcance unos días más tarde. Los usuarios tendrán que configurar su nodo con este nuevo valor. Las instrucciones para hacerlo con cada cliente están disponibles en aquí.

Cuando se alcance o supere este nuevo TTD en Ropsten, la parte de la capa de ejecución de la transición, cifrada como París, se iniciará. Recuerde que la tasa de hash en Ropsten es altamente variable, por lo que la hora real a la que se alcance la Terminal Total Difficulty (Dificultad Total del Terminal) puede variar.

Una vez que la capa de ejecución haya superado la TTD, un validador de cadena de baliza producirá por completo el siguiente bloque. Consideramos que la fusión se ha completado una vez que la cadena de baliza haya concluido con este bloque. Presuponiendo que se den las condiciones de red normales, esto debería suceder en dos épocas, o aproximadamente 13 minutos después de llegar al primer bloque posterior a la TTD.

Una nueva etiqueta de bloque JSON-RPC finalizado devuelve el último bloque finalizado, o un error si no existe ningún bloque tras la fusión. Esta etiqueta sirve para que las aplicaciones comprueben si se ha completado la fusión. Del mismo modo, los contratos inteligentes pueden consultar el opcode DIFFICULTY (0x44), rebautizado como PREVRANDAO tras la fusión, para determinar si se ha producido la fusión. Recomendamos que los proveedores de infraestructuras controlen la estabilidad total de la red, además del estado de finalización.

Versiones del cliente

Las siguientes versiones del cliente son compatibles con la fusión en la red de prueba Ropsten. Los operadores de nodo deben ejecutar tanto un cliente de capa de ejecución y como de capa de consenso para permanecer en la red durante y después de la fusión.

Como se ha mencionado anteriormente, las siguientes versiones tienen un valor cifrado TTDl de 1000000000000000000000000000 que tendrá que actualizarse manualmente después de que la actualización de Bellatrix se haya activado en la cadena de baliza.

A la hora de elegir el cliente de ejecución, los validadores deben prestar especial atención a los riesgos derivados de gestionar un cliente principal, tanto en la EL como en la CL. Aquí encontrará una explicación detallada de tales riesgos y de las consecuencias que acarrean. Y aquí encontrará un cálculo estimado de la distribución actual de cliente de las capas EL y CL, además de indicaciones para pasar de un cliente a otro.

Nota: si ha descargado previamente una versión del cliente con un TTD de Ropsten de 43531756765713534, debe actualizar su versión o anular manualmente la TTD a 1000000000000000000000000000000000 como se especifica aquí.

Capa de consenso

Nota de Lodestar: la última versión de Lodestar, v0.37.0, tiene un valor TTD de Ropsten desactualizado de 43531756765713534. Para ser compatible con la fusión Ropsten, que ahora usa una TTD de 100000000000000000000000000000, los usuarios de Lodestar tendrán que reemplazar manualmente este valor. Las instrucciones para hacerlo se pueden encontrar en la publicación del anuncio de lanzamiento del equipo.

Capa de ejecución

Nota Geth: la última versión de go-ethereum (geth), Sharblu (v1.10.18), tiene un valor TTD de Ropsten desfasado de 43531756765713534. Para que sea compatible con la fusión de Ropsten, que ahora usa una TTD de 1000000000000000000000000000, los usuarios de Geth deben realizar una de estas opciones:

• Construir desde la fuente en la última rama maestra`
• Utilizar la última imagen de Docker
• Anular manualmente la TTD, ejecutando el siguiente comando al iniciar el cliente: --override.terminaltotaldifficulty 100000000000000000000000.

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).