- Ethereum pasará a prueba de participación. La transición, conocida como La Fusión, primero debe activarse en la Cadena de Baliza con la actualización Bellatrix. Después de esto, la cadena de prueba de trabajo migrará a prueba de participación al alcanzar un valor de Total Difficulty específico.
- La actualización Bellatrix está programada para la época 144896, que se espera en la Cadena de Baliza a las 11:34:47 a. m. UTC del 6 de septiembre de 2022.
- El valor de Terminal Total Difficulty que activará La Fusión es 58750000000000000000000, que se espera del 10 al 20 de septiembre de 2022.
- Nota: Tal como se anunció anteriormente, la red de prueba Kiln se volverá obsoleta. Los operadores dejarán de funcionar el 6 de septiembre de 2022.
Contexto
Después de años de trabajo arduo, la actualización de prueba de participación de Ethereum finalmente estará disponible. La actualización exitosa de todas las redes públicas de prueba se completó, y se programó La Fusión para la red principal de Ethereum.
La Fusión se diferencia de actualizaciones anteriores de la red en dos cuestiones. 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 altura de época en la Cadena de Baliza, y la segunda, llamada Paris, al alcanzar un valor de Total Difficulty en la capa de ejecución.
Información sobre la actualización
Plazos
La Fusión es un proceso de dos pasos. El primer paso es la actualización de la red, Bellatrix, en la capa de consenso, desencadenada por una altura de época. Luego, sigue la transición de la capa de ejecución de prueba de trabajo a prueba de participación, Paris, desencadenada por un umbral específico de Total Difficulty denominado Terminal Total Difficulty (TTD).
La actualización Bellatrix está programada para la época 144896, que se espera en la Cadena de Baliza a las 11:34:47 a. m. UTC del 6 de septiembre de 2022.
Paris, la porción de la transición de la capa de ejecución, se activará al alcanzar una Terminal Total Difficulty (TTD) de 58750000000000000000000, que se espera entre el 10 y el 20 de septiembre de 2022. La fecha exacta en la que se alcanza la TTD depende de la tasa de hash de la prueba de trabajo. Se pueden encontrar estimaciones para la transición en bordel.wtf y 797.io/themerge.
Una vez que la capa de ejecución haya alcanzado o superado la TTD, un validador de la Cadena de Baliza producirá el bloque subsiguiente. La transición de La Fusión se considerará completada una vez que la Cadena de Baliza finalice este bloque. En condiciones normales de la red, esto debería suceder 2 épocas, o aproximadamente 13 minutos, después de que se produzca el primer bloque posterior a la TTD.
Una nueva etiqueta de bloque JSON-RPC, finalized, muestra 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 produjo La Fusión. Recomendamos que los proveedores de infraestructura controlen la estabilidad general de la red además del estado de finalización.
Versiones de clientes
Las siguientes versiones de clientes son compatibles con La Fusión en la red principal de Ethereum. Los operadores de nodo deben ejecutar tanto un cliente de capa de ejecución como de capa de consenso (ambos) para permanecer en la red durante y después de La Fusión.
A la hora de elegir qué cliente usar, los validadores deben prestar especial atención a los riesgos derivados de ejecutar un cliente principal, tanto en la EL como en la CL. Consulte una explicación de estos riesgos y sus consecuencias aquí. En este enlace encontrará una estimación de la distribución actual de clientes de las capas EL y CL, además de indicaciones para pasar de un cliente a otro.
Capa de consenso
Nombre | Versión | Enlace |
---|---|---|
Lighthouse | v3.1.0 | Descargar |
Lodestar | v1.0.0 | Descargar |
Nimbus | v22.9.0 | Descargar |
Prysm | v3.1.0 | Descargar |
Teku | 22.9.0 | Descargar |
Capa de ejecución
Nombre | Versión | Enlace |
---|---|---|
Besu | 22.7.2 | Descargar |
Erigon | v2022.09.01-alpha | Descargar |
go-ethereum (geth) | v1.10.23 | Descargar |
Nethermind | v1.14.1 | Descargar |
Advertencia: La versión geth v1.10.22 contiene un problema de base de datos crítico; no use esta versión y, si ya hizo la actualización, actualice a la versión v1.10.23 lo antes posible.
Especificaciones de la actualización
Los cambios fundamentales de consenso para La Fusión se especifican en dos lugares:
- Los cambios de la capa de consenso en el directorio Bellatrix del repositorio de especificaciones de consenso
- Los cambios de la capa de ejecución en la especificación Paris en el repositorio de especificaciones de ejecución
Además de estos, otras dos especificaciones tratan la forma en la que interactúan los clientes de capa de ejecución y capa de consenso:
- La Engine API, especificada en el repositorio de API de ejecución, se utiliza para la comunicación entre las capas de consenso y ejecución.
- Optimistic Sync, especificada en la carpeta sync del repositorio de especificaciones de consenso, es utilizada por la capa de consenso para importar bloques mientras el cliente de capa de ejecución se está sincronizando y para ofrecer una visión parcial del principio de la cadena desde la primera hasta la segunda.
Bono de recompensa por errores de la fusión
Todas las recompensas relacionadas con La Fusión por vulnerabilidades han recibido un multiplicador 4x entre ahora y el 8 de septiembre. Los errores críticos tienen un valor actual de hasta USD 1 millón.
Consulte el programa de recompensas por errores para obtener más detalles.
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 ejecute la Cadena de Baliza de pruebas de participación y un cliente de capa de ejecución (EL) que gestione el estado de los usuarios y se encargue de los cálculos asociados a las transacciones. Los clientes de EL y CL se comunican a través de un puerto autenticado usando un nuevo conjunto de métodos JSON RPC denominado Engine API. Los clientes de EL y CL se autentican utilizando un secreto JWT. Los operadores de nodos deben consultar la documentación de sus clientes para obtener instrucciones sobre cómo generar y configurar este valor.
Dicho de otra forma, si usted ya ejecutaba un nodo en la Cadena de Baliza, ahora también deberá ejecutar 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 estos se comuniquen de forma segura, se debe pasar un token JWT a cada cliente. Una actualización de la sección "Ejecutar un nodo" del sitio web ethereum.org repasa estos pasos con más detalle.
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, pero 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. Las API de Baliza y de JSON RPC continuarán funcionando según lo previsto.
¿Qué necesito hacer como participante?
Tal como se ha explicado anteriormente, los validadores de 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. Antes de la fusión, esto se recomendaba encarecidamente, pero algunos validadores han 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 de los usuarios y los bloques de transiciones de estado que creen y certifiquen sean válidos. Para ello, cada nodo de baliza debe estar acompañado de 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. Esto aumenta las responsabilidades de los validadores, pero también da al validador que propone un bloque derecho a las comisiones de prioridad de transacciones asociadas (que actualmente se destinan a los mineros).
Mientras que las recompensas del validador aún se acumulan en la Cadena de Baliza y requerirán una posterior actualización de la red para poder retirarse, las comisiones de transacción se pagarán, registrarán y distribuirán en la capa de ejecución. Los validadores pueden especificar cualquier dirección de Ethereum como destinatario de las comisiones de transacciones.
Después de actualizar su cliente de consenso, asegúrese de establecer el fee recipient como parte de las configuraciones de su cliente validador para asegurarse de que las comisiones de transacción se envíen a una dirección que usted controle. Si interviene usando un proveedor de terceros, corresponde a su proveedor seleccionado especificar cómo se asignan estas comisiones.
La plataforma de lanzamiento de participación (Staking Launchpad) tiene una Lista de verificación de preparación para la fusión que los participantes pueden usar para asegurarse de realizar cada uno de los pasos del proceso. EthStaker también realizó Talleres de preparación para validadores, y hay más programados.
Los interesados que deseen ejecutar un validador en una red de pruebas en preparación para la transición de prueba de participación de la red principal pueden hacerlo en Goerli (ahora fusionado con Prater), que también tiene una instancia de lanzamiento de participación.
¿Por qué es tan amplia la fecha estimada de la Terminal Total Difficulty?
La dificultad incremental añadida por bloque depende de la tasa de hash de la red, que es volátil. Si se une más tasa de hash a la red, se alcanzará la TTD antes. De manera similar, si la tasa de hash abandona la red, la TTD se alcanzará más tarde. En el caso de una caída significativa en los niveles de la tasa de hash, se podría coordinar un TTD Override, como se hizo en Ropsten.
¿Qué debo hacer como desarrollador de aplicaciones o herramientas?
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 API de usuario permanecen estables (a menos que use 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 momento de asegurarse de que su código front-end, herramientas, canal de implementación y otros componentes fuera de cadena funcionen como se espera. Recomendamos encarecidamente que los desarrolladores ejecuten un ciclo completo de prueba e implementación en Sepolia, o Goerli, y que informen de cualquier problema relacionado con herramientas o dependencias a los mantenedores de esos proyectos. Si no sabe en qué casos debe informar de una incidencia, consulte este repositorio.
Además, hay que tener en cuenta que todas las redes de prueba aparte de Sepolia y Goerli se darán de baja después de la fusión. Si es usuario de Ropsten, Rinkeby o Kiln, deberá migrar a Goerli o Sepolia. Puede encontrar más información sobre esto aquí.
¿Hay algo que deba hacer como usuario de Ethereum o si tengo Ether?
Ya sea que esté utilizando aplicaciones de Ethereum en cadena, tenga Ether en una plataforma de intercambio o en una billetera de autocustodia, no debería tener que hacer nada. Si una aplicación, plataforma de intercambio o billetera que utiliza ofrece instrucciones o recomendaciones adicionales, debe verificar que realmente procedan de estas. ¡Tenga cuidado con las estafas!
¿Hay algo que deba hacer como minero?
No. Si está minando en la red principal de Ethereum, debe tener en cuenta que, después de La Fusión, la red funcionará completamente en prueba de participación. Cuando eso ocurra, ya no se podrá minar en la red.
¿Qué sucede si soy minero u operador de nodos, y no participo de la actualización?
Si utiliza un cliente de Ethereum que no se actualiza a la última versión (ver arriba), su cliente se sincronizará con la cadena de bloques pre-fork una vez que se produzca la actualización.
Estará atrapado en una cadena incompatible bajo reglas antiguas y no podrá enviar Ether u operar en la red de Ethereum posterior a la fusión.
¿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 retiradas de la Cadena de Baliza en la primera actualización que se haga después de La Fusión. Se están elaborando especificaciones para ambas capas, la de consenso y la de ejecución.
Tengo más preguntas, ¿dónde puedo hacerlas?
Únase a desarrolladores de equipos de clientes, miembros de ETHStaker, investigadores y más en la próxima Llamada comunitaria sobre La Fusión el viernes 9 de septiembre a las 14:00 UTC.
¡Gracias!
La transición de Ethereum a prueba de participación se ha hecho esperar durante un laaargo tiempo. Gracias a todos los que han contribuido a investigar, especificar, desarrollar, analizar, probar, romper, corregir o explicar todo lo que nos llevó a La Fusión.
A lo largo de los años, ha habido muchísimos colaboradores como para mencionarlos aquí, pero ustedes saben quiénes son. Sin la ayuda de todos, no habríamos llegado hasta aquí.
¿Cuándo se producirá la fusión? Muy 🔜.
Agradecemos a Joseph Schweitzer y Tomo Saito por la imagen de portada de esta publicación.