El 30 de noviembre de 2023, los desarrolladores de Ethereum se reunieron en Zoom para la reunión #122 de la convocatoria #122 del Consenso de Desarrolladores Principales (ACDC). La conferencia telefónica ACDC es una serie de reuniones quincenales moderadas por el investigador de la Fundación Ethereum, Danny Ryan, en las que los desarrolladores discuten y coordinan los cambios en la capa de consenso (CL) de Ethereum. 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 en Devnet #12, así como todo el software cliente de la capa de ejecución (EL), están en marcha. El equipo de Prysm espera tener su software listo para las pruebas en un plazo de dos a 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 Cancún/Deneb, los desarrolladores discutieron algunos de los problemas de proceso planteados por Tim Beiko, Jefe de Soporte de Protocolo de la Fundación Ethereum, para mejorar la coordinación de la actualización de Ethereum.
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 Ethereum, 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 se hace llamar "Dustin", comparte los detalles del problema Devnet #11 en el que está trabajando su equipo. Estos problemas se descubrieron por primera vez cuando un desarrollador salió 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.
"Quiero decir 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 es quizás más automatizado, ya sea usando Hive o Kurtosis o lo que sea. Creo que sin duda sería útil si estos problemas pudieran resolverse o si las cosas pudieran desglosarse lo suficientemente bien como para poder incorporar más de estas tareas", agregó Dustin, y agregó que otro desafío que los desarrolladores de CL deberían considerar abordar es averiguar el nivel de detalle que la especificación de CL debería 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 de CL superan pruebas que comprueban el comportamiento básico, pero el comportamiento fuera del ámbito de estas pruebas es ambiguo. "¿Son estas cosas deliberadamente vagas? ¿Qué debería quedar realmente claro por la norma 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 los retiros de ETH en staking, los retiros de validadores, etc. Para ello, Jayanthi recomienda crear una herramienta de este tipo utilizando una combinación de conjuntos de pruebas de Hive y Kurtosis.
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 esta herramienta funcione, Jayanthi pidió a los desarrolladores que compartieran detalles de los errores conocidos que desencadenaron las reorganizaciones de la cadena en Ethereum. 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 las especificaciones de la red
Los desarrolladores discutieron brevemente una solicitud de extracción abierta propuesta por el investigador de la Fundación Ethereum, Justin Traglia, con respecto al orden de 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 Ethereum Research & Development 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 especificaciones 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 discusión de la recuperación de bloques faltantes y bloques 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. Beiko dijo que el 30 de noviembre se publicará en el blog de la Fundación Ethereum una publicación de blog que advierte 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 Cancun/Deneb en Goerli, o 1 mes después de que la actualización se active en la red principal de Ethereum, lo que ocurra más tarde. Desde la conclusión de la convocatoria, se ha publicado la entrada de blog anterior y se puede leer aquí.
Beiko sugiere crear una carpeta específica para la actualización en el repositorio "pm" de Ethereum 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 consiste en crear un documento "Meta EIP" para realizar un seguimiento del alcance completo de las actualizaciones de red que se han completado en Ethereum. "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, usan diferentes 'formatos' y conducen a la duplicación. Dado que los ERC y los EIP ahora están separados, recomiendo (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, las Propuestas de Mejora de Ethereum (EIP), como "Considerar la inclusión" (CFI). Según Beiko, CFI es un estado que los desarrolladores han utilizado históricamente como una "señal suave", lo que indica que los autores del EIP deben seguir trabajando 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, el etiquetado de CFI ha hecho poco o ningún esfuerzo para indicar qué EIP en el EL se implementarán 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 de 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, Cancun/Deneb. Sin embargo, el EOF, así como varias otras propuestas que también están marcadas como CFI, han sido rechazadas de Cancún/Deneb, y no está claro el estado de estos EIP marcados como CFI en la próxima actualización de 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 a la especificación CL se discuten en la conferencia telefónica de ACDC, mientras que los EIP propuestos a 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 el estado de CFI. En esta llamada, no hubo una decisión clara sobre el tema del estado de EIP y el etiquetado de CFI.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Resumen de la última reunión de desarrolladores del núcleo de Ethereum: Devnet #12启动, proceso de planificación de actualizaciones
El 30 de noviembre de 2023, los desarrolladores de Ethereum se reunieron en Zoom para la reunión #122 de la convocatoria #122 del Consenso de Desarrolladores Principales (ACDC). La conferencia telefónica ACDC es una serie de reuniones quincenales moderadas por el investigador de la Fundación Ethereum, Danny Ryan, en las que los desarrolladores discuten y coordinan los cambios en la capa de consenso (CL) de Ethereum. 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 en Devnet #12, así como todo el software cliente de la capa de ejecución (EL), están en marcha. El equipo de Prysm espera tener su software listo para las pruebas en un plazo de dos a 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 Cancún/Deneb, los desarrolladores discutieron algunos de los problemas de proceso planteados por Tim Beiko, Jefe de Soporte de Protocolo de la Fundación Ethereum, para mejorar la coordinación de la actualización de Ethereum.
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 Ethereum, 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 se hace llamar "Dustin", comparte los detalles del problema Devnet #11 en el que está trabajando su equipo. Estos problemas se descubrieron por primera vez cuando un desarrollador salió 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.
"Quiero decir 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 es quizás más automatizado, ya sea usando Hive o Kurtosis o lo que sea. Creo que sin duda sería útil si estos problemas pudieran resolverse o si las cosas pudieran desglosarse lo suficientemente bien como para poder incorporar más de estas tareas", agregó Dustin, y agregó que otro desafío que los desarrolladores de CL deberían considerar abordar es averiguar el nivel de detalle que la especificación de CL debería 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 de CL superan pruebas que comprueban el comportamiento básico, pero el comportamiento fuera del ámbito de estas pruebas es ambiguo. "¿Son estas cosas deliberadamente vagas? ¿Qué debería quedar realmente claro por la norma 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 los retiros de ETH en staking, los retiros de validadores, etc. Para ello, Jayanthi recomienda crear una herramienta de este tipo utilizando una combinación de conjuntos de pruebas de Hive y Kurtosis.
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 esta herramienta funcione, Jayanthi pidió a los desarrolladores que compartieran detalles de los errores conocidos que desencadenaron las reorganizaciones de la cadena en Ethereum. 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 las especificaciones de la red
Los desarrolladores discutieron brevemente una solicitud de extracción abierta propuesta por el investigador de la Fundación Ethereum, Justin Traglia, con respecto al orden de 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 Ethereum Research & Development 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 especificaciones 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 discusión de la recuperación de bloques faltantes y bloques 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. Beiko dijo que el 30 de noviembre se publicará en el blog de la Fundación Ethereum una publicación de blog que advierte 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 Cancun/Deneb en Goerli, o 1 mes después de que la actualización se active en la red principal de Ethereum, lo que ocurra más tarde. Desde la conclusión de la convocatoria, se ha publicado la entrada de blog anterior y se puede leer aquí.
Beiko sugiere crear una carpeta específica para la actualización en el repositorio "pm" de Ethereum 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 consiste en crear un documento "Meta EIP" para realizar un seguimiento del alcance completo de las actualizaciones de red que se han completado en Ethereum. "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, usan diferentes 'formatos' y conducen a la duplicación. Dado que los ERC y los EIP ahora están separados, recomiendo (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, las Propuestas de Mejora de Ethereum (EIP), como "Considerar la inclusión" (CFI). Según Beiko, CFI es un estado que los desarrolladores han utilizado históricamente como una "señal suave", lo que indica que los autores del EIP deben seguir trabajando 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, el etiquetado de CFI ha hecho poco o ningún esfuerzo para indicar qué EIP en el EL se implementarán 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 de 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, Cancun/Deneb. Sin embargo, el EOF, así como varias otras propuestas que también están marcadas como CFI, han sido rechazadas de Cancún/Deneb, y no está claro el estado de estos EIP marcados como CFI en la próxima actualización de 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 a la especificación CL se discuten en la conferencia telefónica de ACDC, mientras que los EIP propuestos a 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 el estado de CFI. En esta llamada, no hubo una decisión clara sobre el tema del estado de EIP y el etiquetado de CFI.