- Para la última transición de prueba de participación de testnet, Goerli se fusionará con Prater. La red combinada de Goerli/Prater conservará el nombre de Goerli después de la fusión.
- Bellatrix, la actualización de Prater que lo prepara para The Merge ocurrirá en epoch 112260esperado en 12:24 p. m. UTC del 4 de agosto de 2022.
- Después de activar Bellatrix, la fusión de Goerli/Prater ocurrirá cuando Goerli alcance una dificultad total de 10790000esperado entre 6-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 testnets. Los interesados que deseen iniciar un validador Goerli/Prater pueden hacerlo en el Plataforma de lanzamiento de Prater.
Fondo
Después de años de trabajo para llevar la prueba de participación a Ethereum, ahora estamos en la etapa final de prueba: ¡despliegues de redes de prueba!
Después de varias redes de desarrollo, bifurcaciones de sombra y fusiones en redes de prueba obsoletas, Sepolia pasó recientemente a prueba de participación. Ahora, solo queda una red de prueba más: Goerli y su Beacon Chain asociada, Prater.
La fusión es diferente de las actualizaciones anteriores de Ethereum de dos maneras. En primer lugar, los operadores de nodos deben actualizar los clientes de la capa de consenso (CL) y la capa de ejecución (EL) en tándem, en lugar de solo uno de los dos. En segundo lugar, la actualización se activa en dos fases: la primera, llamada Bellatrix, en una época alta en Beacon Chain y la segunda, llamada Paris, al golpear un Dificultad Total valor en la capa de ejecución.
Información de actualización
Sincronización
la fusión es un proceso de dos pasos. Comienza con una actualización de red, Bellatrix, en la capa de consenso, desencadenada por una altura de época. A esto le sigue la transición de la capa de ejecución de prueba de trabajo a prueba de participación, París, desencadenada por un Dificultad Total umbral, llamado Dificultad Total Terminal (TTD).
Él Bellatrix la actualización está programada para la época 112260 en el Prater Beacon Chain, esperado en 12:24 p. m. UTC del 4 de agosto de 2022. Parísla parte de la capa de ejecución de la transición, se activará al alcanzar un Dificultad total terminal (TTD) de 10790000 sobre Goerli, esperado entre 6-12 de agosto de 2022.
Una vez que la capa de ejecución ha superado la TTD, el siguiente bloque será producido únicamente por un validador de Beacon Chain. Consideramos que The Merge se ha completado una vez que Beacon Chain haya finalizado este bloque. Suponiendo que las condiciones de la red sean normales, esto debería ocurrir 2 épocas, o aproximadamente 13 minutos, ¡después de que se golpee el primer bloque post-TTD!
Una nueva etiqueta de bloque JSON-RPC, finalizado, devuelve el último bloque finalizado o un error si no existe dicho bloque posterior a la fusión. Esta etiqueta se puede utilizar para que las aplicaciones comprueben si se ha completado la fusión. Del mismo modo, los contratos inteligentes pueden consulta el DIFICULTAD código de operación (0x44)rebautizado como PREVRANDAO post-merge, para determinar si The Merge ha ocurrido. Recomendamos que los proveedores de infraestructura controlen la estabilidad general de la red además del estado de finalización.
Lanzamientos de clientes
Las siguientes versiones de clientes admiten The Merge en las redes de prueba de Goerli y Prater. Los operadores de nodos deben ejecutarse ambas cosas un cliente de capa de ejecución y consenso para permanecer en la red durante y después de The Merge.
Al elegir qué cliente ejecutar, los validadores deben tener especialmente en cuenta los riesgos de ejecutar un cliente mayoritario tanto en EL como en CL. Una explicación de estos riesgos y sus consecuencias se puede encontrar aquí. Se puede encontrar una estimación de la distribución actual de clientes EL y CL y guías para cambiar de un cliente a otro aquí.
Capa de consenso
Capa de ejecución
Especificaciones de actualización
Los cambios críticos de consenso para The Merge se especifican en dos lugares:
- La capa de consenso cambia, bajo la bellatrix directorio del repositorio de consenso-specs
- La capa de ejecución cambia, bajo el París Especificaciones en el repositorio de especificaciones de ejecución
Además de estas, otras dos especificaciones cubren cómo interactúan los clientes de la capa de consenso y ejecución:
- La API del motor, especificada en el repositorio de ejecución-apisse utiliza para la comunicación entre las capas de consenso y ejecución
- Optimistic Sync, especificado en el sincronizar carpeta del repositorio de especificaciones de consenso, la capa de consenso la utiliza para importar bloques a medida que el cliente de la capa de ejecución se sincroniza y para proporcionar una vista parcial de la cabeza de la cadena desde el primero hasta el último
Preguntas más frecuentes
Como operador de nodo, ¿qué debo hacer?
Después de la fusión, un nodo completo de Ethereum combinará un cliente de capa de consenso (CL), que ejecuta Beacon Chain de prueba de participación, y un cliente de capa de ejecución (EL), que administra el estado del usuario y ejecuta los cálculos asociados con actas. Estos se comunican a través de un puerto autenticado utilizando un nuevo conjunto de métodos JSON RPC llamados API del motor. El cliente EL y CL se autentican entre sí mediante un secreto JWT. Los operadores de nodos deben consultar la documentación de sus clientes para obtener instrucciones sobre cómo generarlos y configurarlos.
En otras palabras, si ya estaba ejecutando un nodo en Beacon Chain, ahora también necesita ejecutar un cliente de capa de ejecución. De manera similar, si estaba ejecutando un nodo en la red de prueba de trabajo actual, deberá ejecutar un cliente de capa de consenso. Para que se comuniquen de forma segura, se debe pasar un token JWT a cada cliente. Se pueden encontrar instrucciones resumidas para ejecutar un nodo en la red Goerli/Prater aquí.
Vale la pena enfatizar que, si bien ambos son parte de las versiones del cliente de la capa de consenso, ejecutar un Beacon Node es distinto de ejecutar un Validator Client. Los participantes deben ejecutar ambos, pero los operadores de nodos solo necesitan el primero. Esta publicación 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. Él Faro y RPC de JSON Las API seguirán funcionando como se esperaba.
Como staker, ¿qué debo hacer?
La fusión Goerli/Prater es su última oportunidad para asegurarse de que sus validadores estén configurados correctamente antes de la transición a la red principal. Se recomienda encarecidamente ejecutar la transición ahora para evitar problemas inesperados en la red principal.
Como se explicó anteriormente, los validadores en Beacon Chain necesitarán ejecutar un cliente de capa de ejecución después de The Merge, además de sus clientes de capa de consenso. Antes de la fusión, esto fue muy recomendable, pero los validadores podrían haber subcontratado estas funciones a proveedores externos. Esto fue posible porque los únicos datos requeridos en la capa de ejecución fueron las actualizaciones del contrato de depósito.
Después de la fusión, los validadores deben asegurarse de que las transacciones en bloques que crean y certifican sean válidas. Para hacer esto, cada nodo de baliza debe emparejarse con un cliente de capa de ejecución. Tenga en cuenta que aún se pueden emparejar varios validadores con un solo nodo de baliza y una combinación de cliente de capa de ejecución. Si bien esto amplía las responsabilidades de los validadores, también otorga a un validador que propone un bloque el derecho a sus tarifas de prioridad de transacción asociadas (que actualmente van a los mineros).
Si bien las recompensas del validador se acumulan en Beacon Chain y requerirán que se retire una actualización de red posterior, las tarifas de transacción se seguirán pagando, quemando y distribuyendo en la capa de ejecución. Los validadores pueden especificar cualquier dirección de Ethereum como destinatario de las tarifas de transacción.
Después de actualizar su cliente de consenso, asegúrese de configurar el destinatario de la tarifa como parte de las configuraciones de su cliente de validación para garantizar que las tarifas de transacción se envíen a una dirección que usted controla. Si ha apostado con un proveedor externo, depende de su proveedor seleccionado especificar cómo se asignan estas tarifas.
El Prater Staking Launchpad tiene un Lista de comprobación de preparación para la fusión que las partes interesadas pueden usar para asegurarse de haber pasado por cada paso del proceso. El equipo de EthStaker también está organizando una Taller de preparación del validador de fusión el 29 de julio.
¿Por qué la estimación de la Dificultad Total Terminal fecha tan amplia?
La volatilidad en la dificultad incremental por bloque hace estimar una ventana para el TTD más difícil que con una altura de bloque o época, por lo tanto, el rango esperado más amplio. Los usuarios deben tener en cuenta que este también será el caso de la transición de mainnet debido a cambios en la tasa de hash de prueba de trabajo.
Como desarrollador de aplicaciones o herramientas, ¿qué debo hacer?
Con The Merge en vivo en Goerli, ahora es su última oportunidad de asegurarse de que su producto funcione como se espera a través de la transición de prueba de participación y en un contexto posterior a la fusión. Como se explica en un Publicación anterior, The Merge solo tendrá un impacto mínimo en un subconjunto de contratos implementados en Ethereum, ninguno de los cuales debería romperse. Además, la mayor parte de los puntos finales de API de usuario se mantienen estables (a menos que utilice métodos específicos de prueba de trabajo, como eth_getWork).
Dicho esto, la mayoría de las aplicaciones en Ethereum implican mucho más que contratos en cadena. Ahora es el momento para asegurarse de que su código front-end, herramientas, canalización de implementación y otros componentes fuera de la cadena funcionen según lo previsto. Recomendamos enfáticamente que los desarrolladores ejecuten un ciclo completo de prueba e implementación en Sepolia, Ropsten o Kiln e informen cualquier problema con las herramientas o dependencias a los mantenedores de esos proyectos. Si no está seguro de dónde abrir un problema, utilice este repositorio.
Además, debe tener en cuenta que todas las redes de prueba, aparte de Sepolia y Goerli, quedarán obsoletas después de la fusión. Si es usuario de Ropsten, Rinkeby o Kiln, debe planificar la migración a Goerli o Sepolia. Se puede encontrar más información sobre esto aquí.
Como usuario de Ethereum o poseedor de Ether, ¿debo hacer algo?
No. La red principal de Ethereum no se ve afectada por esta red de prueba. Se realizarán anuncios posteriores en este blog antes de la transición de mainnet.
Como minero, ¿hay algo que deba hacer?
No. Si está minando en la red principal de Ethereum, debe tener en cuenta que la red operará completamente bajo prueba de participación después de The Merge. En ese momento, la minería ya no será posible en la red.
Como validador, ¿puedo retirar mi apuesta?
No. La fusión es la actualización más complicada de Ethereum hasta la fecha. Para minimizar los riesgos de interrupciones de la red, se tomó un enfoque mínimo que excluyó cualquier cambio que no fuera de transición de esta actualización.
Los retiros de Beacon Chain probablemente se introducirán en la primera actualización después de The Merge. Especificaciones tanto para el consenso y ejecución las capas están en progreso.
Tengo más preguntas, ¿dónde puedo hacerlas?
La comunidad de EthStaker ha establecido un canal de discordia para responder las preguntas de los participantes y operadores de nodos. Puedes unirte a su discordia aquí y luego usa el #goerli-charla canal de asistencia. Como se mencionó anteriormente, EthStaker también albergará una Taller de preparación del validador de fusión el 29 de julio.
Además, un Fusionar llamada comunitaria está programado para el 12 de agosto a las 14:00 UTC. Los desarrolladores e investigadores del cliente estarán disponibles para responder preguntas de los operadores de nodos, participantes, proveedores de infraestructura y herramientas y miembros de la comunidad. Tenga en cuenta que se espera que esta llamada de la comunidad suceda después la fusión Goerli/Prater.
Fuimos a fusionar?
A partir de la publicación de esta publicación, ha llegado el momento de la transición de la prueba de participación de la red principal de Ethereum. no sido establecido. Es probable que cualquier fuente que afirme lo contrario sea una estafa. Las actualizaciones se publicarán en este blog. ¡Por favor, mantente a salvo!
Suponiendo que no se encuentren problemas durante la fusión de Goerli/Prater, una vez que los clientes tengan lanzamientos de características completas, se elegirá una altura de ranura para la actualización de Bellatrix en la red principal Beacon Chain y una valor de dificultad total se configurará para la transición a la red principal. Luego, los clientes harán lanzamientos que habiliten The Merge en la red principal. Estos se anunciarán en este blog y en otras publicaciones de la comunidad.
Sin embargo, si se encuentran problemas en cualquier punto del proceso o si se considera que la cobertura de la prueba es insuficiente, estos problemas se abordarán antes de continuar con el proceso de implementación.
Solo entonces será posible estimar la fecha exacta de The Merge.
En otras palabras, 🔜.
