Resumen de la última reunión de ETH Workshop Core Developers: Activar la actualización de Cancún en la red de pruebas a principios de enero de 2024

Título original: Ethereum All Core Developers ution Call #176 Writeup

Artículo original de Christine Kim

Compilación original: Luccy, BlockBeats

Nota del editor:

ETH Todas las Llamadas de Consenso de Desarrolladores Principales (ACDE) se llevan a cabo cada dos semanas para discutir y coordinar los cambios en la Capa de Ejecución (EL) del Taller de ETH. Esta es la 176ª conferencia telefónica de ACDE, y cubrirá las discusiones con la actualización de Cancún / Deneb, el progreso de las pruebas de Devnet # 12 y el plan de actualización de Praga / Electra.

Los desarrolladores discutieron cómo se probó la actualización de Cancun/Deneb en Devnet # 12, incluido el progreso y algunos problemas encontrados por diferentes equipos de clientes, así como los desafíos técnicos en la propagación de blobs, MEV (valor máximo extraíble) y más. Para la próxima actualización de Praga/Electra, los desarrolladores han propuesto una serie de posibles cambios técnicos.

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 7 de diciembre de 2023, ETH desarrolladores se reunieron en la convocatoria #176 de Zoom for All Core Developers ution (ACDE). La conferencia telefónica de ACDC es una serie de reuniones quincenales dirigidas por Tim Beiko, Jefe de Soporte de Protocolo de la Fundación ETH, donde los desarrolladores discuten y coordinan los cambios en la capa ejecutiva (EL) de ETH Place. Esta semana, los desarrolladores discutieron probar la actualización de Cancun/Deneb en Devnet #12. Acordaron coordinar la fecha de activación de la actualización en la red de prueba de Goerli en ETH principios de enero, después de que terminaran las vacaciones. Además, planean comenzar las discusiones a principios de enero sobre qué cambios en el código deberían incluirse en la próxima actualización del taller de ETH, Praga/Electra.

Actualización de Devnet #12

Las pruebas de la actualización Cancun/Deneb en Devnet #12 van bien. Parithosh Jayanthi, ingeniero de DevOps de la Fundación, reveló que se han encontrado algunos errores en dos clientes, Reth y Lighthouse, y que los dos equipos de clientes están trabajando en una solución de emergencia. Para probar los flujos de trabajo de MEV más a fondo, los equipos de DevOps se están centrando más en habilitar el software MEV-Boost en más validadores en Devnet #12. Según Jayanthi, su equipo ha encontrado al menos un error en la implementación del relé MEV de Flashbots. Danny Ryan, investigador de la Fundación ETH, enfatizó que para garantizar que los validadores puedan cambiar a la construcción de bloques locales en caso de una falla del relé, se necesitan pruebas adicionales para verificar si hay mecanismos alternativos.

Para las actualizaciones del equipo específicas del cliente, Terence Tsao, el desarrollador del cliente Prysm, dijo que su equipo está trabajando en un diseño actualizado para ACDC #122中讨论的 propagación de blobs. Tsao confirmó que el cliente de Prysm estará listo para unirse a Devnet #12 para las pruebas la próxima semana, posiblemente la próxima semana. Justin Florentine, el desarrollador del cliente Besu, dijo que Besu está listo para pasar de Devnet #12. Los representantes de los equipos de clientes de Nethermind, Erigon, Lodestar y Teku también dijeron que estaban listos para continuar probando la actualización en la red de prueba pública ETH.

En función de la preparación del cliente, Beiko recomienda coordinar una fecha de hard fork tan pronto como los desarrolladores salgan de las vacaciones. Suponiendo que no se encuentren errores importantes en Devnet #12 en las próximas semanas después de que el cliente Prysm se una, Beiko afirma que es probable que la activación de Cancun/Deneb en Goerli ocurra a mediados de enero. Ben Edgington, del equipo de Teku, preguntó a los desarrolladores si confiaban en cambiar el número de blobs por bloque de dos a tres. Ryan sugiere pruebas adicionales del aumento de los objetivos de blob durante la bifurcación masiva de la sombra y la activación de Cancun/Deneb en Goerli. Beiko confirmó que la activación de la actualización en Goerli será la “última prueba significativa” de los tres objetivos de blob por bloque. Suponiendo que no se encuentren problemas, los desarrolladores seguirán usando el mayor número de blobs para la activación de la red principal.

En general, Beiko dijo que los desarrolladores continuarán probando actualizaciones en Devnet # 12 desde ahora hasta el final de las vacaciones. El equipo de DevOps planea lanzar al menos una bifurcación en la sombra de Goerli a finales de diciembre en preparación para una verdadera bifurcación dura de Goerli en enero. Si los desarrolladores se reúnen para el Año Nuevo, discutirán la fecha de activación de la bifurcación dura Goerli.

Indicadores de anulación del constructor

A continuación, Tsao preguntó al equipo del cliente sobre su progreso en la implementación de la marca de anulación de Builder. El indicador de anulación del Builder es un nuevo campo booleano en la actualización de Cancún que el cliente de la capa de ejecución puede utilizar para indicar al cliente de la capa de consenso que cuando el Builder detecta actividad de censura, el validador debe recurrir a la generación de bloques locales en lugar de utilizar un Builder de terceros. Como enfatiza Tsao, los detalles de implementación sobre cómo detectar las actividades de revisión del Builder son subjetivos y se dejan deliberadamente al equipo del cliente para que los diseñe. Para obtener más información sobre los indicadores de anulación de Builder, consulte las actas de ACDC # 112 y ACDE # 165.

El desarrollador del equipo del cliente Geth, que usa el nombre de usuario “Lightclient”, dijo que su equipo ha implementado la bandera, pero no la fusionará en el lanzamiento oficial “en un futuro cercano”. Los representantes de los equipos de Besu y Nethermind afirmaron que esta bandera opcional aún no se ha implementado en sus clientes. Tsao enfatizó que la bandera puede ser una herramienta útil, y es mejor implementarla lo antes posible para desalentar y desalentar a los grupos de participación o a los grandes operadores de nodos validadores de participar en ciertos “juegos de tiempo”. Tsao explicó que los validadores pueden ganar más MEV (Valor Máximo Extraíble) retrasando la propagación de bloques, y que después de la introducción de blobs después de la actualización de Cancún, habrá un retraso en la propagación de bloques. Durante estos retrasos, los validadores pueden optar por incluir transacciones MEV más rentables en el bloque, lo que no es óptimo para la propagación oportuna de blobs.

Confirmando que las transacciones de blobs tendrán que competir con las transacciones regulares, un desarrollador seudónimo del equipo de Prysm, que usa el nombre de usuario Potuz, agregó: "Los blobs deben competir no solo con las tarifas, sino también con la latencia en sí misma y todo el MEV ganado al retrasar los bloques. A la hora de diseñar el mecanismo de tarifas para los blobs, pensé que era un mercado que no había sido bloqueado ni tenido en cuenta. Tsao dijo que volvería a plantear el tema en el Discord de Ethereum Research para una mayor discusión. Además, Ryan destacó la última publicación de los investigadores de la Fundación Ethereum, Caspar Schwarz-Schilling y Mike Neuder, sobre “juegos de cronometraje” en el sitio web de Ethresearch.

Progreso del proyecto

A continuación, Beiko compartió tres actualizaciones relacionadas con el proceso de planificación de actualizaciones de ETH Workshop. En primer lugar, al igual que en el #123上讨论的那样 ACDC, Beiko ha creado un documento de Meta EIP para la actualización de Cancún/Deneb, que enumera todas las ETH Propuestas de Mejora (EIP) que se han incluido en Cancún/Deneb. Ha sido creado en GitHub con el número EIP 7569. Además, Beiko creó EIP 7568 como el documento EIP de Meta para todas las actualizaciones anteriores, y los desarrolladores no crearon un documento dedicado para realizar un seguimiento de la lista de EIP incluidos en la actualización. EIP 7568 está vinculado a la especificación del código de actualización.

En segundo lugar, Beiko anunció que había creado un nuevo hilo de discusión en el sitio web de Ethereum Magicians para identificar la próxima actualización de la red, Praga/Electra. Pidió a los desarrolladores que piensen críticamente sobre si agrupar las actualizaciones de la capa de ejecución (EL) y la capa de consenso (CL) como lo han hecho las dos últimas bifurcaciones duras. La activación de ciertos cambios de código, como EIP 7002, requerirá cambios tanto en EL como en CL, por lo que las actualizaciones de Praga y Electra deberán coordinarse. Sin embargo, para otros cambios de código, como el árbol de Verkle, hay una manera de rediseñar la implementación y solo es necesario actualizar la CL.

Ryan señaló que los desarrolladores de la capa de consenso (CL) que trabajan en paralelo con el árbol de Verkle también están realizando cambios en el código para admitir el muestreo de disponibilidad de datos. Beiko aconseja a los desarrolladores que no entren en detalles sobre todos los EIP que quieren ver en la actualización de Praga/Electra, sino que revisen todos los cambios de código candidatos durante las vacaciones y estén preparados para discutirlos seriamente en enero. Potuz está de acuerdo, y añade que un EIP diseñado para abordar el creciente problema del tamaño del conjunto de validadores ETH sería un cambio de código importante en Praga/Electra. Basándose en la complejidad de los cambios en el código, Beiko recomienda que para ciertos EIP, como Verkle o el muestreo de disponibilidad de datos, los desarrolladores organicen reuniones dedicadas después de las vacaciones para discutir en detalle estos cambios de protocolo más grandes.