Resumen de la última reunión de los desarrolladores principales de ETH Place: Se lanza Devnet 12 y se está actualizando el proceso de planificación de la actualización

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

Artículo original de Christine Kim

Compilación original: Luccy, BlockBeats

Nota del editor:

El Taller ETH Todas las Llamadas de Consenso para Desarrolladores Principales (ACDC, por sus siglas en inglés) se llevan a cabo dos veces por semana para discutir y coordinar los cambios en la Capa de Consenso (CL, por sus siglas en inglés) del Taller de ETH. Esta es la conferencia telefónica número 123 del ACDC, que se centró en la evaluación de las actualizaciones de prueba de Cancún/Deneb y Devnet #12, así como en la resolución de los problemas de salida del validador que surgieron en Devnet #11. Además, los desarrolladores mantuvieron un debate en profundidad sobre la aclaración de las especificaciones de la red, el proceso de planificación de la actualización y el estado de la EIP.

Durante la discusión de Cancún/Deneb, los desarrolladores enfatizaron la estabilidad y discutieron si iniciar o no la bifurcación de sombra Goerli. Sin embargo, dado que el cliente de Prysm no estaba listo para las pruebas, se decidió esperar a que estuviera listo. Las discusiones sobre las herramientas de prueba y la reestructuración de la cadena destacaron la necesidad de una cobertura de prueba más completa e hicieron recomendaciones para el uso de los conjuntos de pruebas de Hive y Kurtosis. Sobre el tema del estado de EIP y las etiquetas de CFI, Beiko expresó su preocupación sobre si estas etiquetas deberían mantenerse, y los desarrolladores aún no han llegado a un consenso claro sobre este tema.

Christine Kim, VP de Investigación de Galaxy Digital, dio una nota detallada sobre los aspectos más destacados de la reunión, que BlockBeasts compiló de la siguiente manera:

El 30 de noviembre de 2023, ETH desarrolladores se reunieron en Zoom para la sesión de la convocatoria #122 del Consenso de Desarrolladores Principales (ACDC). La conferencia telefónica de ACDC es una serie de reuniones quincenales dirigidas por Danny Ryan, investigador de la Fundación ETH Workshop, donde los desarrolladores discuten y coordinan los cambios en la Capa de Consenso (CL) de ETH Workshop. Esta semana, los desarrolladores se centraron en los últimos desarrollos en las pruebas de Cancún/Deneb, que incluyen:

· Lanzamiento de Devnet #12: Las pruebas del software cliente Teku, Lodestar y Lighthouse, así como de todo el software cliente de la capa de ejecución (EL), en Devnet #12 están en marcha. El equipo de Prysm espera tener su software listo para las pruebas dentro de dos o tres semanas en la última Devnet.

· Problema de salida del validador en Devnet #11: En Devnet #11, los desarrolladores han identificado un problema relacionado con la salida del validador, que actualmente está siendo resuelto por el equipo del cliente Nimbus. Devnet #11 seguirá funcionando normalmente hasta que se resuelva el problema.

· Aclaración de la especificación de red: los desarrolladores discutieron la aclaración de la especificación para las solicitudes “BlockByRoot” y “BlobSidecarsByRoot”, aclarando si los nodos de la capa de consenso (CL) deben responder a estas solicitudes en un orden específico.

Además de la actualización de Cancun/Deneb, los desarrolladores discutieron algunos de los problemas de proceso planteados por Tim Beiko, Jefe de Soporte de Protocolo de la Fundación ETH, para mejorar la coordinación de la actualización de ETH Workshop.

Devnet #12

El miércoles 30 de noviembre de 2023, la actualización Cancun/Deneb se lanzó oficialmente en Devnet #12. Mario Vega, del equipo de pruebas de la Fundación ETH, dijo que “hasta la fecha no se han identificado problemas importantes” en los tres clientes CL que se ejecutan actualmente en la red de pruebas. Barnabas Busa, ingeniero de DevOps de la Fundación, mencionó que hay un total de 225 validadores repartidos en tres nodos entre Lighthouse, Teku y Lodestar. Debido a la estabilidad de Devnet #12, Parithosh Jayanthi, un ingeniero de DevOps de la Fundación, preguntó a los desarrolladores si deberían comenzar a planificar una bifurcación en la sombra de Goerli para probar más a fondo Cancun/Deneb. Sin embargo, teniendo en cuenta que Prysm, el cliente CL más popular en este momento, aún no se ha unido a Devnet #12, los desarrolladores han decidido suspender los planes para una bifurcación en la sombra de Goerli hasta que el software cliente de Prysm esté listo para las pruebas. Beiko sugiere moverse en la bifurcación de sombra de Goerli en algún momento antes de fin de año. Debido a la estabilidad de Devnet #12, los planes se suspenden hasta que el software cliente de Prysm esté listo para las pruebas.

Devnet #11

El desarrollador de Nimbus, que usa el nombre de usuario “Dustin”, comparte los detalles del problema Devnet # 11 en el que está trabajando su equipo. Estos problemas se descubrieron por primera vez cuando los desarrolladores salieron de un tercio de los validadores de Devnet #11 para su uso en Devnet #12. Ryan le pregunta a Dustin si puede detectar estos problemas con pruebas adicionales. Dustin respondió que, en su opinión, la naturaleza de estos errores se debía a detalles de implementación fuera del alcance de la especificación de consenso. Sin embargo, también reconoce que existe una “clara tensión” entre escribir software cliente estrictamente según la especificación CL para probar los beneficios de la cobertura y adentrarse en las áreas grises de la especificación para lograr un mejor rendimiento de los nodos.

“Estoy diciendo que más pruebas siempre son buenas, pero descubrir de manera más sistemática cómo incorporar más funcionalidad del lado del cliente en la ejecución de pruebas, tal vez más automatización, ya sea usando Hive o Kurtosis o lo que sea. Si estos problemas se pueden resolver o las cosas se pueden desglosar lo suficientemente bien como para poder incorporar más de estas tareas, creo que definitivamente sería útil”, agregó Dustin, y agregó que otro desafío que los desarrolladores de CL deberían considerar abordar es averiguar el nivel de detalle en el que la especificación de CL debe dictar y estandarizar el comportamiento de los nodos. “El otro desafío aquí es el grado de estandarización, que en realidad no es solo un problema de ingeniería de software, ¿qué tan estandarizado debe ser el comportamiento?”, preguntó Dustin. Todos los clientes CL se prueban para comprobar el comportamiento básico, pero el comportamiento fuera del ámbito de estas pruebas es ambiguo. “¿Son estas cosas deliberadamente vagas? ¿Qué debería estar realmente claramente definido por la especificación, y qué debería ser deliberadamente oscuro?” —preguntó Dustin.

Como mínimo, los desarrolladores acordaron agregar más pruebas a futuras Devnets y testnets para una gran cantidad de salidas de validadores en Cancún / Deneb. Ryan también reconoce que hay espacio para una cobertura de pruebas más rigurosa y completa cuando se trata de clientes de CL y la implementación de especificaciones de CL. Vega sugirió que Dustin creara una publicación en HackMD detallando sus preocupaciones y discutiera el tema en la próxima llamada de prueba de Cancún/Deneb. Jayanthi añadió que, basándose en algunos de los problemas identificados recientemente en Cancun/Deneb Devnets, existe una clara necesidad de que los desarrolladores cuenten con herramientas que puedan realizar sistemáticamente un cierto número de comportamientos relacionados con la integración en la cadena, como el staking ETH los retiros, los retiros de validadores, etc. Para ello, Jayanthi recomienda utilizar una combinación de conjuntos de pruebas de Hive y Kurtosis para crear una herramienta de este tipo.

Hablando sobre la nueva herramienta de prueba para la actualización de Cancun/Deneb, Jayanthi señaló que los desarrolladores están trabajando en una herramienta para activar de manera confiable las reuniones en cadena en Devnets y testnets. Para asegurarse de que la herramienta funcione, Jayanthi pidió a los desarrolladores que compartieran detalles del error conocido que desencadenó la reorganización de la cadena en el ETH. Jayanthi explicó que usará estos errores para probar la herramienta y asegurarse de que pueda identificar de manera confiable cuándo ocurre una reorganización y cuándo se resuelve.

Aclaración de especificaciones de red

Los desarrolladores discutieron brevemente una solicitud de extracción abierta propuesta por Justin Traglia, investigador de la Fundación ETH, con respecto al orden de las respuestas que los clientes de CL deben devolver al recibir una solicitud “BlockbyRoot” o “BlobSidecarsByRoot”. Ryan pregunta cómo los diferentes equipos de clientes de CL ya están implementando esta característica. Ninguno de los desarrolladores de la llamada respondió a esta pregunta. Ryan sugirió revivir la discusión en el canal de Discord de Investigación y Desarrollo de ETH para involucrar a una gama más amplia de desarrolladores de clientes. Ryan reconoce que hay ambigüedades en las especificaciones de las dos solicitudes, que “pueden ser la causa de problemas y casos extremos extraños” y “merecen ser aclarados y resueltos”, afirma Ryan.

Ryan también mencionó que lanzará una nueva versión de la especificación CL en los próximos días. La última versión agrega significativamente una especificación sobre cuándo un cliente CL puede proporcionar bloques y bloques a través de una solicitud RPC “byRoot”. Para obtener más información sobre la explicación de la recuperación de fragmentos y fragmentos que faltan a través de solicitudes RPC “byRoot”, consulte el registro de llamadas anterior. Ryan enfatiza que las nuevas adiciones a la especificación CL incluidas en la última versión no tendrán ningún cambio importante en el código que afecte el código para los validadores que ya se ejecutan en Devnet #11 o #12.

Proceso de planificación de actualizaciones

A continuación, los desarrolladores discutieron los diversos elementos del proceso propuestos por Beiko. Según Beiko, el 30 de noviembre se publicará en el blog de la Fundación ETH una publicación de blog que advierta a los usuarios de la red de prueba de Goerli sobre la inminente obsolescencia dentro de los 3 meses posteriores a la activación de la actualización de Cancun/Deneb en Goerli, o dentro de 1 mes de la activación de la actualización en la red principal de ETH, lo que ocurra más tarde. Desde la conclusión de la convocatoria, se ha publicado la entrada del blog anterior y se puede leer aquí.

Beiko recomienda crear una carpeta específica para la actualización en el repositorio ETH “pm” para organizar varios archivos relacionados con una actualización específica en una sola carpeta para su uso posterior. Los desarrolladores de la llamada estuvieron de acuerdo con la sugerencia de Beiko.

El segundo elemento del proceso propuesto por Beiko fue crear un documento “Meta EIP” para realizar un seguimiento del alcance total de las actualizaciones de la red que se habían completado en el ETH. “No hay un buen lugar para rastrear el alcance completo de una actualización de red antes de implementarla y anunciarla en una publicación de blog”, escribió Beiko en una publicación sobre su propuesta de Meta EIP. "En el caso de Dencun, tenemos los EIP de EL en un archivo de rebajas 7 difícil de encontrar, y los EIP de CL forman parte de la Especificación 3 de la cadena de balizas. Esto no es genial, ya que ambos son un poco difíciles de encontrar, cada uno usa un “formato” diferente y conducen a la duplicación. Dado que los ERC y los EIP ahora están separados, recomendaría (volver) a usar los EIP de Meta para realizar un seguimiento de los EIP incluidos en la actualización de la red. Los desarrolladores estaban a favor de crear estos documentos. Beiko dijo que redactará un documento para la revisión de la actualización de Cancún/Deneb esta semana.

Por último, Beiko planteó una pregunta sobre la utilidad de marcar los cambios de código propuestos, ETH las Propuestas de Mejora (EIP) como “consideradas para incluir” (CFI). Según Beiko, CFI es un estado que los desarrolladores han utilizado históricamente como “señales suaves”, lo que indica que los autores de EIP deben seguir trabajando duro en propuestas que puedan incluirse en futuras bifurcaciones duras. Solo se usa para cambios y actualizaciones de código centrados en EL. 「[CFI] más alto que las ideas aleatorias de personas al azar, pero antes de que sean aceptadas en la bifurcación", dijo Beiko.

En el pasado, las etiquetas CFI tenido poco efecto a la hora de indicar qué EIP en el EL se implementarían en la actualización o cuándo. Se ha aplicado a una amplia gama de EIP con diversos grados de preparación de código y soporte de los equipos de los clientes. En el caso de la propuesta EVM Object Format (EOF), los desarrolladores utilizan esta etiqueta para indicar su compromiso con la implementación de EOF en la próxima actualización, Cancún/Deneb. Sin embargo, el EOF, así como varias otras propuestas que también fueron etiquetadas como CFI, fueron rechazadas de Cancún/Deneb, y no está claro el estado de estos EIP etiquetados como CFI en la próxima actualización Praga/Electra.

Beiko dijo que si este estado no ayuda, los desarrolladores deben eliminarlo, pero si tienen la intención de mantenerlo, los desarrolladores de CL también deben usar la misma etiqueta en los cambios de código que consideren implementar en las actualizaciones de CL. No está claro hasta qué punto el proceso de revisión de CL EIP refleja el proceso de revisión de EL EIP y si deberían evolucionar de la misma manera en el futuro. Por lo general, los cambios de código propuestos para la especificación CL se discuten en la conferencia telefónica de ACDC, mientras que los EIP propuestos para la especificación EL se discuten en la conferencia telefónica de ACDE.

A Danno Ferrin, de Swirlds Labs, también se le ocurrió la idea de crear un campo de marcador de posición para todos los EIP, ya sean relacionados con CL o EL, que identifique su estado durante el proceso de revisión, incluido CFI estado. No hubo una decisión clara sobre el tema del estatus de EIP y CFI etiquetas en esta convocatoria.