Resumen de la última reunión de los desarrolladores principales de ETH Place: Habrá una bifurcación en la sombra de Goerli y una prueba de la actualización Cancun/Deneb antes de fin de año

Título original: Ethereum All Core Developers Consensus Call #124 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 124 de ACDC, que cubre las actualizaciones de Devnet # 12, el progreso en la actualización de Cancún / Deneb y temas relacionados con la difusión de Slashable. Durante la reunión, los desarrolladores discutieron activamente cambios menores en el protocolo de red Libp2p para reducir el efecto de amplificación de los mensajes grandes en los nodos.

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 14 de diciembre de 2023, ETH desarrolladores se reunieron en Zoom para la sesión de la convocatoria #124 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 el progreso de las pruebas de la actualización Cancun/Deneb en la red de prueba Devnet #12. Desde la reunión All-Core Developer Execution (ACDE) de la semana pasada, todas las combinaciones de clientes de Capa de Ejecución (EL) y Capa de Consenso (CL) se han incorporado a Devnet #12, incluido el cliente Prysm. El software MEV-Boost está habilitado, pero las combinaciones de clientes con Prysm no están incluidas. Los desarrolladores dijeron que están en camino con los planes para lanzar la rama sombra de Goerli en las próximas una o dos semanas para probar la actualización de Cancún / Deneb e incluir a todos los clientes. Además, los desarrolladores discutieron las reglas para la difusión de información sobre Slashable, así como el cronograma de llamadas para las próximas dos semanas.

Actualización de Devnet #12

Barnabas Busa, ingeniero de DevOps de la Fundación ETH, dijo que todas las combinaciones de clientes EL/CL, incluidas las que utilizan Prysm como cliente CL, se han integrado con éxito en Devnet #12. La cartera de clientes que utilizan Prysm no ha sido probada para el software MEV-Boost. Sin embargo, en Devnet #12, el flujo de trabajo MEV está probando otros clientes CL. Recientemente, el cliente de Lighthouse se ha sometido a una actualización de parches para abordar los errores relacionados con MEV. Además, Parithosh Jayanthi, otro ingeniero de DevOps de la Fundación, dijo que notaron un problema con el nodo Besu en Devnet #12 y que todavía están trabajando para determinar la causa raíz. Como siguiente paso, los desarrolladores enviarán deliberadamente bloques maliciosos a través de la red, probarán los generadores de bloques y ejecutarán pruebas de hive para los clientes de Prysm recién agregados para realizar pruebas de estrés de las combinaciones de clientes en Devnet. Jayanthi dijo en un mensaje público de Discord durante la llamada que los desarrolladores todavía planean lanzar una rama sombra en la red de prueba Goerli para fin de año.

Información slashable actualizada

A continuación, los desarrolladores discutieron brevemente varios problemas relacionados con la difusión y el momento del mensaje de Slashable en el ETH después de la actualización de Cancun/Deneb. En segundo plano, la información de Slashable incluye la propagación de bloques y blobs duplicados o no válidos. Dapplion, un desarrollador anónimo del cliente Lodestar, ha realizado una solicitud de incorporación de cambios (PR) a través de GitHub que tiene como objetivo agregar nuevos eventos a la API de Beacon Chain para permitir que los operadores de nodos aprendan sobre los eventos Slashable más rápidamente, lo que sería especialmente útil si hay una gran cantidad de información Slashable. En su PR, Dapplion menciona: "Para los grandes operadores, el costo total de un evento de corte depende en gran medida de su tiempo de respuesta. Si hay muchas claves involucradas en errores operativos, es posible que esta información cortable tarde algún tiempo en incluirse en la cadena. Las relaciones públicas de Dapplion se fusionaron con la especificación de la API de Beacon Chain antes de la llamada y están siendo implementadas por varios equipos de clientes de CL, como Prysm y Lighthouse.

Dapplion también propone un PR relacionado con la medición del tiempo de propagación de bloques. Señaló que la medición del tiempo de propagación de bloques se volverá más difícil debido a la actualización de Cancun/Deneb y la introducción de transacciones de blobs. Dapplion explica la solución que propone en su PR. Como notaron los desarrolladores en el hilo de PR, tienden a resolver este problema agregando un campo de marca de tiempo a los eventos de API de Beacon Chain relacionados existentes.

El tercer tema que trataron los desarrolladores se relacionó con la propagación de la información de Slashable después de la actualización de Cancun/Deneb fueron las condiciones de propagación de blobs. El desarrollador de Lighthouse “sean” (o “realbigsean” en GitHub) señaló que las reglas de propagación de blobs existentes tenían consecuencias no deseadas. Durante la llamada, Sean dijo: "Si está utilizando la API de Beacon para la autenticación de transmisión, es inesperado que un enfoque de chismes pueda conducir a mensajes válidos e inválidos. La razón de esto es que, técnicamente, es posible propagar dos blobs con diferentes índices de blob del encabezado Slashable asociado a ellos. Se le permite propagarlos, pero no los que tienen el mismo índice de blobs. 」

Sean agregó que el comportamiento extraño cuando se trata de la propagación de información cortable de blobs no tiene un impacto sustancial en la salud de la red, aparte de un resultado “extraño” para que los operadores de nodos lo entiendan y analicen. Por lo tanto, si bien no hay urgencia para la activación de Cancún/Deneb, sugiere que los desarrolladores consideren realizar cambios en las reglas para manejar la difusión de información de Slashable en futuras actualizaciones. Danny Ryan está de acuerdo y dice que los desarrolladores deberían tomarse el tiempo para pensar “holísticamente” sobre cómo resolver este problema. Ryan sugiere volver a examinar este tema en enero para dar tiempo a los desarrolladores a diseñar un plan integral para actualizar las reglas de propagación de blobs y bloques de Slashable.

A continuación, los desarrolladores discutieron cambios menores en el protocolo de red libp2p para reducir el efecto de amplificación en los nodos que envían mensajes grandes, como bloques con una gran cantidad de blobs. Sean destacó el nuevo mensaje de control “IDONTWANT”, que se puede usar para notificar a los pares libp2p que detengan el envío de mensajes grandes. Ryan dijo que intentará ponerse en contacto con el equipo de libp2p para fusionar este PR, y si hay más retrasos, el tema se volverá a tratar en la conferencia telefónica de ACDE la próxima semana.