Escrito por Christine Kim

Compilado por: Luccy, BlockBeats

Nota del editor: La llamada de consenso para todos los desarrolladores principales (ACDC) de Ethereum se lleva a cabo cada dos semanas para discutir y coordinar cambios en la capa de consenso (CL) de Ethereum. Esta es la conferencia telefónica número 135 de ACDC. Esta conferencia se centra principalmente en la preparación de la red de prueba de Pectra Devnet 1, PeerDAS Devnet 1 y Simple Serialize (SSZ) Ethereum Improvement Proposals (EIP).

Los desarrolladores mantuvieron discusiones en profundidad sobre temas como el mantenimiento de paquetes de software, los procesos de inclusión de EIP y el nombramiento de la nueva ronda de actualizaciones de la capa de consenso de Ethereum. Además, la sesión abordó el progreso de la implementación bajo la especificación de Electra, el impacto de los cambios en la red PeerDAS en cómo los nodos de Ethereum procesan y validan los datos, y los complejos problemas de ingeniería que rodean el aumento de los límites de blob gas.

Christine Kim, vicepresidenta de investigación de Galaxy Digital, registró en detalle los puntos clave de esta reunión. BlockBeasts recopiló el texto original de la siguiente manera:

El 13 de junio de 2024, los desarrolladores de Ethereum se reunieron en Zoom para la reunión número 135 del Consenso de Desarrolladores Principales (ACDC). La llamada ACDC es una serie quincenal organizada por el investigador de la Fundación Ethereum, Alex Stokes, donde los desarrolladores discuten y coordinan cambios en la Capa de Consenso de Ethereum (CL, también conocida como Beacon Chain). Esta semana, los desarrolladores discutieron los preparativos para Pectra Devnet 1, PeerDAS Devnet 1 y una tercera red de prueba dedicada para las propuestas de mejora de Ethereum (EIP) de serialización simple (SSZ).

anuncio

Los desarrolladores iniciaron la reunión con dos anuncios. Parithosh Jayanthi, ingeniero de DevOps de la Fundación Ethereum, dijo que el equipo de ethPandaOps, un grupo de ingenieros que trabajan en DevOps de la Fundación Ethereum (EF DevOps), se hará cargo del mantenimiento y desarrollo del módulo Kurtosis del paquete Ethereum. Los desarrolladores han utilizado este paquete en el pasado para lanzar redes de prueba de Ethereum y herramientas relacionadas, como el panel de datos de Grafana para monitorear y probar varias implementaciones de clientes. La migración de este paquete del equipo técnico de Kurtosis al equipo de ethPandaOps puede afectar a los usuarios, ya que algunos enlaces redirigirán a repositorios de GitHub administrados por el equipo de ethPandaOps y ya no por el equipo de Kurtosis. Jayanthi aconseja a los usuarios que actualicen los enlaces de su software y estén atentos a los nuevos lanzamientos del equipo de ethPandaOps.

El segundo anuncio lo hizo Tim Beiko, jefe de soporte de protocolos de la Fundación Ethereum. Beiko dijo que está trabajando para introducir un nuevo proceso para incluir EIP en las actualizaciones de Ethereum en fases. Ha creado un borrador de EIP que define las etiquetas "Propuesto para inclusión", "Considerado para inclusión" y "Programado para inclusión". Espera que los desarrolladores revisen el documento y proporcionen comentarios. Espera tener el documento terminado antes de la próxima reunión del ACD.

electra

Las especificaciones de código para la próxima versión principal de Electra, v1.5.0-alpha.3, están casi completas. Los desarrolladores acordaron fusionar la solicitud de extracción (PR) n.° 3768 en el repositorio de GitHub de especificaciones de consenso en la próxima versión. La solicitud de extracción fue creada por el desarrollador de Nimbus, Etan Kissling, quien señaló que el campo "committee_bits" debe agregarse al final de la "Atestación" en lugar de en el medio de los datos para evitar problemas de serialización de datos. Además del PR #3768, Stokes preguntó si hay otros problemas abiertos que deban resolverse antes de que se publique la próxima versión principal de la especificación Electra. Jayanthi mencionó en el chat de Zoom que existen algunos problemas pendientes con la integración de validadores activados a través de la capa de ejecución (EL). Stokes tomó nota de hacer un seguimiento del estado de la integración del validador activado por EL después de la reunión.

Con respecto al progreso de la implementación de la última especificación de Electra, la mayoría de los equipos de clientes de la capa de consenso (CL) en la reunión declararon que podrán tener la nueva versión lista para probar dentro de una o dos semanas después de v1.5.0-alpha.3. está finalizado. Los desarrolladores acordaron revisar el calendario de la próxima red de desarrollo de Pectra, Pectra Devnet 1, en unas pocas semanas.

PeerDAS

A continuación, los desarrolladores discutieron el progreso de la implementación de PeerDAS. PeerDAS es una mejora de la red de Ethereum que mejorará la capacidad de los nodos para procesar y verificar grandes cantidades de datos arbitrarios enviados por los usuarios a través de transacciones de blobs. Stokes recordó la decisión tomada en la última reunión de ACDC de que los desarrolladores desarrollarían PeerDAS en paralelo con otros EIP de Pectra, activando un ciclo de activación separado para PeerDAS en la red de desarrollo.

El desarrollador de Lodestar, Gajinder Singh, dijo que, según las discusiones en una sesión reciente sobre PeerDAS, los desarrolladores activarán PeerDAS además de la actualización de Deneb y en una red de desarrollo separada de otros EIP de Pectra. El desarrollador de Teku, Enrico Del Fante, dijo que sería más fácil para los desarrolladores construir PeerDAS con las especificaciones de código estable ya establecidas en la actualización anterior de Ethereum, Deneb, en lugar de con las especificaciones de código de Pectra en constante cambio. Jayanthi estuvo de acuerdo en que fusionar la implementación de PeerDAS con otras implementaciones de Pectra EIP ahora podría causar complicaciones durante las pruebas, especialmente al intentar identificar la fuente de los errores. Sugirió mantener los dos flujos de trabajo separados y luego fusionarlos una vez que sus implementaciones sean más estables. Stokes estuvo de acuerdo y dijo que los desarrolladores podrían revisar la fusión de PeerDAS y otras implementaciones de Pectra EIP en aproximadamente un mes.

Sobre el tema del lanzamiento de PeerDAS Devnet 1, el equipo del cliente no tiene una estimación clara sobre cuándo estará lista la red de prueba para su lanzamiento. Las estimaciones individuales en las sesiones oscilaron aproximadamente entre 2 semanas y 1 mes. Stokes sugirió revisar el cronograma para el desarrollo de la red en unas pocas semanas, cuando el equipo del cliente tenga más tiempo para trabajar en la implementación de PeerDAS.

Luego, Beiko señaló que, si bien PeerDAS es una mejora de la red en lugar de un cambio en el protocolo central de Ethereum, todavía quiere que los cambios de código se incluyan en el meta-EIP para la actualización de Pectra. El documento meta-EIP es un documento público que enumera todos los cambios de protocolo principales incluidos en la actualización de Ethereum. Beiko señaló que PeerDAS es la "característica más importante" de Pectra, y aunque no requiere una activación de bifurcación, aún así debería incluirse en la documentación para mostrar que los desarrolladores toman en serio tenerlo listo a tiempo para la activación de la red principal de Pectra. No hay objeciones a esto.

Aumentar el límite de burbujas de gas

PeerDAS cambia la forma en que los nodos procesan y propagan datos a través de la capa de red peer-to-peer de Ethereum. Para que los usuarios, especialmente los paquetes acumulativos de Capa 2, se beneficien de estos cambios, los desarrolladores deben aumentar el límite actual de seis blobs por bloque a un umbral más alto, lo que permitirá un mayor rendimiento de blobs (datos arbitrarios). Cambiar el límite de blobs requeriría cambios en el protocolo central de Ethereum, lo cual, como lo discutieron los desarrolladores en una conferencia esta semana, puede implicar un trabajo de ingeniería más complejo que simplemente ajustar un valor constante en la pila de protocolos.

Stokes propuso desacoplar las dependencias entre la capa de ejecución (EL) y la capa de consenso (CL) al cambiar los límites de blob gas. Actualmente, cualquier cambio en los límites de las burbujas de gas requiere cambios en los protocolos EL y CL. Stokes propuso formas de romper estas dependencias, permitiendo a los desarrolladores eliminar de forma segura los límites de gases de burbujas codificados de EL y dejarlos completamente en manos de CL. El investigador de la Fundación Ethereum (EF), Dankrad Feist, señaló que además del problema de dependencia entre EL y CL, el efecto en cadena de cambiar el límite de gas de burbujas en el cálculo de gas del bloque también es importante. "El mejor enfoque es cambiar la forma en que se calcula", dijo Feist. "Probablemente sea un error que el cálculo del precio del gas se realice en EL. Eso debería ser en CL, pero ahora es más difícil cambiar... No es fácil. "

Los desarrolladores acordaron continuar investigando la mejor manera de realizar cambios en los límites de burbujas de gas y los cálculos de gas en bloques. Los desarrolladores también acordaron continuar las discusiones sobre si la activación de PeerDAS en Pectra iría acompañada de un aumento en el límite de burbujas de gas. Los desarrolladores están divididos sobre si los cambios deben implementarse juntos o implementarse en etapas en múltiples bifurcaciones duras.

Jayanthi dijo que incorporar estos cambios fue una decisión "arriesgada" porque los desarrolladores no sabrán exactamente cómo funcionará PeerDAS hasta que se active en la red principal. Barnabas Busa, ingeniero de DevOps de la Fundación Ethereum (EF), agregó que el alcance del hard fork de Pectra ya es muy grande y no requiere cambios de código adicionales. "La clave es que ya tenemos muchos EIP y siento que seguimos agregando más y nunca termina", dijo Busa. "Entonces, tenemos que trazar una línea en alguna parte y ahí es donde terminamos. Creo que no es así. Es posible lanzar PeerDAS y aumentar el número de blobs durante el próximo año y medio de pruebas".

Un desarrollador cuyo nombre de usuario es "Francesco" sugirió que si los cambios en la red no van acompañados de un aumento en el número de blobs, PeerDAS puede eliminarse para "reducir el riesgo de Pectra". Francesco preguntó: "¿Cuál es exactamente el beneficio de PeerDAS de Pectra si no aumenta el número de blobs?"

Para ilustrar aún más la dificultad de probar PeerDAS, Jayanthi señaló que probar EIP 4844, que introdujo blobs en Ethereum, no simuló completamente el rendimiento real y el impacto de los blobs en la red principal de Ethereum. Jayanthi dijo: “El problema es que es muy difícil probar la red. Tuvimos muchas pruebas excelentes relacionadas con 4844, pero los blobs no funcionaron exactamente igual en la red principal que en las pruebas. Surgen nodos más débiles. Vemos desafíos de sincronización y cosas así, por lo que aunque podemos simular una situación perfecta en la red de desarrollo donde PeerDAS y el aumento del número de blobs funcionan, no tiene ninguna implicación práctica. El significado de la red principal, esta es la razón principal por la que creo que deberíamos hacerlo paso a paso en lugar de hacerlo todo a la vez”.

El investigador de EF Ansgar Dietrichs comentó que es un error asociar el aumento del recuento de blobs con PeerDAS, ya que PeerDAS por sí solo ya requiere que los desarrolladores elijan un valor de recuento de blobs. Si bien los desarrolladores pueden elegir el mismo número que en la red principal de Ethereum, se debe tomar una decisión sobre qué número debe usar PeerDAS. La única razón para elegir el mismo número es que los desarrolladores aumentaron la complejidad de PeerDAS para permitirle recurrir al mecanismo de propagación de blobs en la especificación actual de Deneb en caso de error. Dietrichs añadió que las preocupaciones sobre la complejidad de las pruebas refuerzan aún más su opinión de que Pectra debería activarse mediante dos bifurcaciones duras en lugar de una, pero eso no significa que crea que PeerDAS debería desvincularse de los cambios en el recuento de blobs.

Actualización SSZ

Kissling compartió una actualización del progreso de tres EIP relacionados con SSZ. Señaló que la implementación de estos EIP ya está en marcha en varios clientes, incluidos Teku, Grandine y Lighthouse. Los desarrolladores pueden comenzar a discutir el cronograma de desarrollo de la red para estos EIP SSZ y posiblemente incluirlos en el alcance de la actualización de Pectra en la próxima reunión de ACDC, dijo.

Nombramiento de F-Star

Hay una publicación en Ethereum Magicians que analiza el nombre de la próxima actualización de la capa de consenso (CL) de Ethereum después de Electra. Los desarrolladores han elegido un nombre para la actualización de la capa ejecutiva (EL) después de Praga: Osaka. Los nombres de actualización de CL candidatos son: Fulu, Felis, Formosa y Funi. Estos nombres siguen la principal convención de nomenclatura de estrellas que comienza con "F" y son adecuados para la sexta actualización de Beacon Chain en toda la red. Stokes pidió a los desarrolladores en la llamada que opinaran sobre el tema en el hilo de Magicians.