Resumen de la última reunión de desarrolladores de Ethereum Core: actualización de la red de prueba pública de Ethereum después de las vacaciones del primer trimestre de 2024

Título original: Ethereum All Core Developers Consensus Call #121

Artículo original de Christine Kim

Compilación original: Luccy, BlockBeats

El 2 de noviembre de 2023, los desarrolladores de Ethereum se reunieron en Zoom para la reunión #121 del Consenso de Desarrolladores Todos los Núcleos (ACDC). La conferencia telefónica ACDC es una serie de reuniones quincenales moderadas por el investigador de la Fundación Ethereum, Danny Ryan, donde los desarrolladores discuten y coordinan los cambios en la capa de consenso (CL) de Ethereum. Esta semana, los desarrolladores se centran en los siguientes temas:

1. Cambios significativos en la especificación Cancun/Deneb para reducir la complejidad en la implementación de fragmentos;

2. Otro cambio en la especificación de actualización para permitir que los validadores honestos reorganicen los bloques tardíos;

3. Actualizaciones de progreso en la red de prueba Cancun/Deneb;

4. Cree una asignación JSON de la especificación para la especificación CL SSZ.

Simplifique la especificación del Blob Side Car

Después de las discusiones con el equipo del cliente de Prysm, Danny Ryan dijo que los desarrolladores han ideado una alternativa para manejar las condiciones de propagación de blobs, lo que reducirá en gran medida la complejidad y los problemas asociados con la propagación de blobs. “Creo que la mayoría de los problemas que hemos visto en la red de desarrolladores en las últimas seis a ocho semanas tienen que ver con la complejidad de lidiar con estos mensajes, como cuándo invalidarlos, cómo invalidarlos y bajo qué condiciones hacer estas validaciones”, dijo Ryan. Francesco D’Amato, investigador de la Fundación Ethereum, sugirió adjuntar encabezados de bloque y pruebas de inclusión a cada Blob Side Car para abordar estos problemas.

Esta propuesta ha sido creada como una solicitud de incorporación de cambios (PR) en GitHub por el desarrollador del cliente Lodestar “Dapplion”. Ryan enfatizó que la implementación de cambios en la especificación Cancun/Deneb en el cliente CL debe incluir principalmente la eliminación de código innecesario en lugar de agregar contenido nuevo. En cuanto a cómo estos cambios afectarán el progreso de la actualización en la red principal, Ryan dijo que cualquier retraso debe mantenerse al mínimo. “Obviamente, hay una relación con el lanzamiento de Deneb aquí, y de qué y cuándo se tratan Devnet 11 y 12. Pero al mismo tiempo, desde mi punto de vista, es probablemente el mismo momento que el lanzamiento de la red principal, porque es más fácil hacerlo bien y no tenemos que encontrarnos con tantos errores en la red de desarrolladores”. Ryan agregó: “Es casi seguro que esto nos permitirá lanzar la red principal de manera más segura, ya que es una especificación más simple y fácil de implementar correctamente”.

En la llamada, los desarrolladores no tuvieron objeciones al PR. Los desarrolladores dedicaron algún tiempo a discutir los detalles de implementación de la solicitud de incorporación de cambios para garantizar la coherencia entre los clientes. Ryan dijo que fusionará el PR el 2 de noviembre y planea lanzar una nueva versión de la especificación Deneb el 3 de noviembre.

Otros cambios en la especificación Cancun/Deneb

El investigador de la Fundación Ethereum, Alex Stokes, hizo una pregunta al equipo del cliente sobre la especificación del constructor MEV. Stokes pregunta: “Fundamentalmente, ¿quién calcula la prueba de inclusión de KZG?” Actualmente, la especificación requiere que los troncales MEV calculen estas atestados. Sin embargo, estos nodos de baliza pueden pasar estas pruebas a través de la API de baliza. Esto garantizará que el relé tenga una responsabilidad menos y menos código nuevo que deba probarse en el flujo de trabajo MEV. Gajinder Singh, desarrollador de los clientes Ethereum JS y Lodestar, está a favor de pasar las pruebas de inclusión de KZG de los nodos de baliza a los relés. No hay objeción por parte de otros desarrolladores. Desde entonces, Stokes ha actualizado las especificaciones del constructor para este cambio, que se pueden encontrar aquí.

A continuación, los desarrolladores discutieron PR #3034 en el repositorio de GitHub de especificaciones de consenso. PR #3034 es una propuesta antigua de octubre de 2022 que permite a los validadores honestos reorganizar los bloques tardíos, alentando así a todos los validadores a proponer bloques de manera oportuna en lugar de retrasar los envíos para obtener más MEV. Este PR ha sido completado por Michael Sproul, desarrollador del cliente Lighthouse. Se trata de un cambio que pueden implementar opcionalmente tanto los operadores de cliente como los de nodo. No hubo ninguna objeción a la fusión de este RP.

Actualización del calendario de pruebas de Cancún/Deneb

Danny Ryan dijo que la estimación del equipo del cliente sobre el tiempo para implementar el PR era de tres semanas. Una vez que el equipo del cliente ha completado la implementación, el desarrollador puede lanzar una nueva red de desarrolladores, Devnet 12, para probar el nuevo código. Si los desarrolladores no actualizan la versión del cliente durante Devconnect, el Ethereum Developer Focus a mediados de noviembre, es probable que Devnet 12 se ponga en marcha a principios de diciembre. Según estas nuevas estimaciones de prueba, es posible que los desarrolladores no puedan lanzar la actualización a la red de prueba de Goerli a fines de noviembre como se planeó originalmente. Lo más probable es que los desarrolladores comiencen a actualizar la red de prueba pública de Ethereum después de la temporada navideña en el primer trimestre de 2024.

Parithosh Jayanthi, ingeniero de DevOps de la Fundación Ethereum, dijo que Devnet 11 se ha lanzado para que cualquier equipo de clientes pruebe el código de Cancún/Deneb entre ahora y el lanzamiento de Devnet 12. También mencionó que los desarrolladores ejecutarán una bifurcación en la sombra en la red de prueba de Goerli el 3 de noviembre para evaluar mejor el bloque y la latencia del bloque.

JSON se asigna a la especificación SSZ

Por último, los desarrolladores discutieron la PR #3506 en el repositorio de GitHub de especificación de consenso. Este PR propone agregar una asignación JSON estándar 1:1 a la especificación CL SSZ. Esto aportará varios beneficios, como la documentación simplificada de la especificación de la API de baliza y la mejora de la legibilidad del código. Jacek Sieka, desarrollador del cliente Nimbus, dijo que la última versión del PR ha abordado problemas anteriores relacionados con la equivalencia de bytes y enteros sin signo. Ryan dijo que compartirá el PR en el canal de Discord de Ethereum R&D para poder recopilar los comentarios finales de los desarrolladores antes de fusionarlo en el repositorio de especificaciones de consenso.