Anuncio de fusión Goerli/Prater

• Para la última transición de la red de prueba de participación, Goerli se fusionará con Prater. La red combinada Goerli/Prater conservará el nombre de Goerli después de la fusión.
• Bellatrix, la actualización del Prater que lo prepara para la fusión se producirá en la época 112260, esperada a las 12:24PM UTC el 4 de agosto de 2022.
• Después de activar la Bellatrix, la fusión Goerli/Prater se producirá cuando Goerli alcance una dificultad total de 10790000, se espera que ocurra entre el 6 y 12 de agosto de 2022.
• Después de la fusión, el conjunto de validadores de Goerli permanecerá abierto para que los participantes individuales ejecuten validadores de redes de pruebas. Los participantes que deseen iniciar un validador de Goerli/Prater pueden hacerlo en la plataforma de lanzamiento de Prater.

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.

Después de varias devnet, bifurcaciones paralelas y fusiones en redes de pruebas obsoletas, Sepolia ha pasado recientemente a la prueba de participación. Ahora, solo queda una red de prueba más, Goerli, y su cadena de baliza asociada, Prater.

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, llamada Bellatrix, a la altura de una época la cadena de baliza y, la segunda, llamada París, al llegar a un valor de Dificultad Total en la capa de ejecució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, Bellatrix, en la capa de consenso, desencadenada por una altura de época. Seguida de la transición de la capa de ejecución de una prueba de trabajo a una prueba de participación, París, provocada por un umbral de Dificultad Total específico, conocido como Dificultad Total del Terminal (TTD).

La actualización Bellatrix está programada para la época 112260 en la cadena de baliza del Prater, esperada a las 12:24PM UTC del 4 de agosto de 2022. París, la porción de la capa de ejecución de la transición, se activará al alcanzar una Dificuldad Total del Terminal (TTD) de 10790000 en Goerli, se espera que ocurra entre el 6 y el 12 de agosto de 2022.

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. Asumiendo que se den las condiciones normales de la red, esto debería suceder 2 épocas, o aproximadamente 13 minutos, después de alcanzar el primer bloque después de 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

Los siguientes lanzamientos de cliente soportan la fusión a través de las redes de prueba Goerli y Prater. Los operadores de nodo deben ejecutar tanto un cliente de capa de ejecución y de capa de consenso para permanecer en la red durante y después de la fusión.

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. Se puede encontrar una estimación de la distribución actual de los clientes EL y CL y guías para cambiar de un cliente a otro aquí.

Capa de consenso

Capa de ejecución

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.
• Los cambios de 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 Engine API, especificada en el directorio execution-apis, se utiliza para la comunicación entre las capas de consenso y 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 (CL), que ejecuta pruebas de participación en la cadena de baliza, y un cliente de capa de ejecución (EL), 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 generarlos y configurarlos.

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 red actual 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. Las instrucciones de resumen para ejecutar un nodo en la red Goerli/Prater se pueden encontrar aquí..

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.

¿Qué necesito hacer como participante?

La fusión Goerli/Prater es su última oportunidad para asegurarse de que sus validadores estén correctamente configurados antes de la transición a la red principal. Se recomienda encarecidamente que se ejecute la transición para evitar cualquier problema inesperado en la red principal.

Tal y como se ha explicado anteriormente, los 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 las 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 destinatario de comisión como parte de las configuraciones de su cliente validador para asegurar que las comisiones de transacción se envían a una dirección que usted controla. Si usted ha apostado usando un proveedor de terceros, corresponde a su proveedor seleccionado especificar cómo se asignan estas cuotas.

La plataforma de lanzamiento de participación Prater tiene una Lista de comprobación de preparación para la fusión que los participantes pueden usar para asegurarse de que han pasado por cada paso del proceso. El equipo de EthStaker también ha organizado un taller de preparación del validador para la fusión el 29 de julio.

¿Por qué es tan amplia la fecha de Diferencia Total del Terminal?

La volatilidad de la dificultad incremental por bloque hace que la estimación de una ventana para la TTD sea más difícil que con un bloque o una altura de épocas, de ahí que el rango esperado sea más amplio. Los usuarios deben tener en cuenta que este también será el caso de la transición de la red principal debido a cambios en la tasa de hash de prueba de trabajo.

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

Con la fusión ejecutándose en Goerli, es su última oportunidad de asegurarse de que su producto funciona como es debido a través de la transición a la prueba de participación y en un contexto después de la fusión. Como explicamos en una publicación anterior, la fusión tendrá un mínimo impacto en un subconjunto de contratos implementados 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 un ciclo completo de prueba e implementación en Sepolia, Ropsten o Kiln y que informen de cualquier problema relacionado con herramientas o dependencias a los mantenedores de esos proyectos. Si duda sobre en qué casos debe informar de una incidencia, consulte este directorio.

Además, hay que tener en cuenta que todas las redes de pruebas aparte de Sepolia y Goerli estarán obsoletas después de la fusión. Si usted es un usuario de Ropsten, Rinkeby o Kiln, debe planificar la migración a Goerli o Sepolia. Puede encontrar más información sobre esto aquí.

¿Hay algo que necesite hacer como usuario de Ethereum, o titular de Ether?

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

¿Hay algo que yo necesite hacer como minero?

No. Si está minando la red principal en Ethereum, deberá tener en cuenta que después de la fusión cada red funcionará completamente como prueba de participación. Y cuando eso ocurra, no se podrá minar en la red.

¿Puedo retirar mi participación como validador?

No. La fusión es la actualización más compleja de Ethereum realizada 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?

La comunidad EthStaker ha establecido un canal Discord para responder a las preguntas de participantes y de operadores de nodos. Puede unirse a su Discord aquí y luego usar el canal #goerli-prater como ayuda. Como ya se ha mencionado, el equipo de EthStaker también ha organizado un taller de preparación del validador para la fusión el 29 de julio.

Además, está programada una llamada comunitaria sobre la fusión el 12 de agosto 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. Tenga en cuenta que se espera que esta llamada comunitaria suceda después de la fusión de Goerli/Prater.

¿Cuándo se producirá 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 información que apunte a una fecha concreta debe considerarse falsa. En este blog se irá informando de cualquier avance. ¡Vele por su seguridad!

Asumiendo que no se encuentren problemas durante la fusión Goerli/Prater, una vez que los clientes tengan versiones con todas las funciones incorporadas se elegirá una altura de ranura para la actualización de Bellatrix en la cadena de baliza de la red principal y se establecerá un valor de dificultad total 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.

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 será posible calcular la fecha exacta de la fusión.

Es decir, 🔜 (pronto).