Resumen de la última reunión de desarrolladores principales de Ethereum: activación de PeerDAS, aumento del límite de gas blob

Escrito por: Christine Kim

Compilado por: Luccy, BlockBeats

Editor’s note: The Ethereum All Core Developers Conference (ACDC) is held every two weeks to discuss and coordinate changes to the Ethereum Consensus Layer (CL). This is the 135th ACDC conference call, which mainly focuses on preparing the test networks for Pectra Devnet 1, PeerDAS Devnet 1, and the Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

Los desarrolladores han mantenido discusiones profundas sobre el mantenimiento de paquetes de software, el proceso de EIP, incluyendo el proceso de nombramiento de la nueva actualización del consenso de Ethereum, entre otros temas. Además, la reunión también abordó el progreso de implementación bajo la especificación de Electra, el impacto de los cambios en la red PeerDAS en el manejo y verificación de datos de los nodos de Ethereum, y los complejos problemas de ingeniería relacionados con el aumento del límite de gas blob.

La vicepresidenta de investigación de Galaxy Digital, Christine Kim, ha tomado una detallada nota de los puntos clave de esta conferencia, que BlockBeasts ha traducido como sigue:

El 13 de junio de 2024, los desarrolladores de Ethereum se reunieron en Zoom para participar en la reunión All Core Developers Consensus (ACDC)Call #135. Las ACDC son una serie de reuniones quincenales en las que los desarrolladores discuten y coordinan los cambios en la capa de consenso de Ethereum (CL), también conocida como cadena de señalización. Esta semana, los desarrolladores discutieron la preparación de Pectra Devnet 1, PeerDAS Devnet 1 y una tercera red de pruebas especializada para las Propuestas de mejora de Ethereum (EIPs) relacionadas con Simple Serialize (SSZ).

Anuncio

Los desarrolladores comenzaron la reunión con dos anuncios. Parithosh Jayanthi, ingeniero de operaciones de desarrollo (DevOps) de la Fundación Ethereum, dijo que el equipo ethPandaOps, un grupo de ingenieros de operaciones de desarrollo de la Fundación Ethereum, se hará cargo del mantenimiento y desarrollo del módulo ethereum-package Kurtosis. Este paquete de software solía ser utilizado por los desarrolladores para iniciar redes de prueba de Ethereum y herramientas relacionadas, como el panel de control de datos de Grafana para monitorear y probar diversas implementaciones de clientes. Durante el proceso de migración de este paquete de software del equipo técnico de Kurtosis al equipo ethPandaOps, es posible que los usuarios se vean afectados, ya que algunos enlaces serán redirigidos al repositorio de GitHub administrado por el equipo ethPandaOps en lugar del equipo de Kurtosis. Jayanthi sugirió a los usuarios que actualicen sus enlaces de software y sigan atentamente las nuevas versiones publicadas por el equipo ethPandaOps.

El segundo anuncio fue hecho por Tim Beiko, Jefe de Soporte de Protocolo de la Fundación Ethereum. Beiko dijo que está trabajando para introducir un nuevo proceso para incorporar EIP en la actualización de Ethereum en etapas. 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 finalizar este documento antes de la próxima reunión del ACD.

Electra

El próximo Electra versión principal v1.5.0-alpha.3 de las pautas de código está a punto de finalizarse. Los desarrolladores están de acuerdo en fusionar la solicitud de extracción (PR) #3768 en el repositorio GitHub de pautas de consenso para la próxima versión. Esta solicitud de extracción fue creada por Etan Kissling, desarrollador de Nimbus, quien señaló que el campo “committee_bits” debería adjuntarse al final de “Attestation” 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 había otros problemas pendientes que necesitaban resolverse antes del lanzamiento de la próxima versión principal de Electra. Jayanthi mencionó en el chat de Zoom que hay algunos problemas pendientes con la integración del validador desencadenado por la capa de ejecución (EL). Stokes tomó nota de los asuntos pendientes sobre el estado de la integración del validador desencadenado por EL después de la reunión.

Sobre el progreso de 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 expresaron que podrían estar listos para probar la nueva versión una o dos semanas después de la confirmación final de v1.5.0-alpha.3. Los desarrolladores acordaron discutir nuevamente el cronograma para el próximo desarrollo de la 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 red en 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 blob. Stokes repasó la decisión tomada en la última reunión de ACDC, en la que los desarrolladores acordaron desarrollar PeerDAS en paralelo con otros Pectra EIPs, activando PeerDAS en un ciclo de activación separado en la red de desarrollo.

El desarrollador de Lodestar, Gajinder Singh, ha indicado que, según las discusiones en la última reunión grupal sobre PeerDAS, los desarrolladores activarán PeerDAS en la red de desarrollo separada de otros Pectra EIPs, basándose en la actualización Deneb. Enrico Del Fante, desarrollador de Teku, ha señalado que es más fácil construir PeerDAS sobre el código estable especificado en la actualización Deneb de Ethereum que sobre el código cambiante de Pectra. Jayanthi está de acuerdo en que implementar PeerDAS junto con otras implementaciones de Pectra EIPs puede generar problemas complicados durante el proceso de pruebas, especialmente al intentar identificar la fuente de errores. Sugiere separar estos dos procesos y luego fusionarlos una vez que la implementación de ambos sea más estable. Stokes está de acuerdo y comenta que los desarrolladores pueden discutir nuevamente la fusión de PeerDAS y otras implementaciones de Pectra EIPs en aproximadamente un mes.

Respecto al tema de lanzar PeerDAS Devnet 1, el equipo de clientes no tiene una estimación clara de cuándo estará listo el Testnet. La estimación personal en la reunión está aproximadamente entre 2 semanas y 1 mes. Stokes sugirió que después de algunas semanas, cuando el equipo de clientes tenga más tiempo para implementar PeerDAS, se vuelva a discutir el cronograma de desarrollo de la red.

Posteriormente, Beiko señaló que aunque PeerDAS es una mejora de red y no un cambio en el protocolo central de Ethereum, aún así espera incluir el cambio de código en el EIP meta de la actualización Pectra. El documento del EIP meta es un archivo público que enumera todos los cambios en el protocolo central incluidos en las actualizaciones de Ethereum. Beiko señaló que PeerDAS es la “característica más grande” de Pectra, y aunque no requiere una activación de bifurcación dura, aún debería incluirse en el documento para mostrar que los desarrolladores están preparados para activarlo a tiempo para la Mainnet de Pectra. No hubo objeciones al respecto.

Aumentar el límite de gas de blob

PeerDAS ha cambiado la forma en que los nodos procesan y distribuyen datos a través de la capa de red de pares de Ethereum. Para que los usuarios, especialmente los rollups de Layer-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 cualquier dato. El cambio del límite de blobs requiere cambios en el protocolo central de Ethereum, como se discutió en la reunión de desarrolladores de esta semana, lo que puede implicar un trabajo de ingeniería más complejo que simplemente ajustar una constante en la pila tecnológica del protocolo.

Stokes propone desacoplar la dependencia entre la capa de ejecución (EL) y la capa de consenso (CL) al cambiar el límite de gas de blob. Actualmente, cualquier cambio en el límite de gas de blob requiere modificar los protocolos EL y CL. Stokes ha propuesto algunos métodos para romper esta dependencia, lo que permitiría a los desarrolladores eliminar de forma segura los límites de gas de blob codificados en EL y dejar que CL decida completamente. Dankrad Feist, investigador de la Fundación Ethereum (EF), señaló que, además del problema de dependencia entre EL y CL, es importante considerar las repercusiones del cambio en el límite de gas de blob en el cálculo de gas de los bloques. Feist dijo: ‘La mejor manera es cambiar la forma de calcular. Puede que sea un error que el cálculo del precio del gas ocurra en EL. Debería ser en CL, pero cambiarlo ahora es más difícil… no es fácil.’

Los desarrolladores acordaron continuar investigando la mejor manera de cambiar las restricciones de gas blob y el cálculo de gas en el bloque. También acordaron seguir discutiendo si la activación de PeerDAS en Pectra vendría con un aumento en las restricciones de gas blob. Existe división entre los desarrolladores sobre si estos cambios deben implementarse juntos o en múltiples hard forks por etapas.

Jayanthi dijo que combinar estos cambios es una decisión “arriesgada”, ya que los desarrolladores no sabrán cómo se comportará específicamente PeerDAS en la mainnet hasta que se active. Barnabas Busa, ingeniero de DevOps de la Ethereum Foundation (EF), agregó que el alcance del hard fork de Pectra ya es bastante grande y no necesita más cambios de código adicionales. Busa dijo: “La clave es que ya tenemos muchos EIP, siento que si seguimos agregando más contenido, nunca terminaremos. Así que en algún momento debemos trazar una línea, ese es nuestro punto final. No creo que sea posible publicar PeerDAS y aumentar la cantidad de blobs en el próximo año y medio de pruebas.”

Un desarrollador con el nombre de pantalla ‘Francesco’ sugirió que si no hay un aumento en la cantidad de blobs junto con los cambios en la red, se puede eliminar PeerDAS para ‘disminuir el riesgo de Pectra’. Francesco preguntó: ‘¿Cuál es el beneficio de PeerDAS de Pectra si no hay un aumento en la cantidad de blobs?’

Para ilustrar aún más las dificultades de probar PeerDAS, Jayanthi señaló que la introducción de blobs en el EIP 4844 de Ethereum no simula completamente el comportamiento y el impacto real de los blobs en la Mainnet de Ethereum. Jayanthi dijo: ‘El problema es que es muy difícil probar en una red de pruebas. Hemos realizado muchas pruebas excelentes relacionadas con el 4844, pero el comportamiento de los blobs en la Mainnet no es completamente consistente con el comportamiento en las pruebas. Hemos visto problemas en nodos más débiles y desafíos de tiempo, entre otras situaciones similares. Por eso, aunque podamos simular perfectamente PeerDAS y aumentar la cantidad de blobs en la red de desarrollo, esto no tiene ningún significado práctico en la Mainnet. Esta es la principal razón por la que creo que debemos avanzar paso a paso en lugar de hacerlo todo de una vez.’

El investigador de EF, Ansgar Dietrichs, comentó que asociar el aumento en la cantidad de blob con PeerDAS es incorrecto, ya que PeerDAS ya requiere que los desarrolladores elijan un valor de cantidad de blob. Aunque los desarrolladores pueden optar por el mismo número que en la red principal de Ethereum, debe tomarse una decisión sobre qué número debería usar PeerDAS. La única razón para elegir el mismo número es aumentar la complejidad de PeerDAS para que pueda retroceder al mecanismo de propagación de blob actual en la especificación Deneb en caso de errores. Dietrichs agregó que las preocupaciones sobre la complejidad de las pruebas refuerzan aún más su opinión de que Pectra debería ser activado por dos hard forks en lugar de uno, pero esto no significa que crea que PeerDAS debería separarse del cambio en la cantidad de blob.

Actualización de SSZ

Kissling compartió actualizaciones sobre el progreso de tres EIP relacionados con SSZ. Señaló que el trabajo de implementación de estos EIP ya ha comenzado en varios clientes, incluidos Teku, Grandine y Lighthouse. Dijo que los desarrolladores pueden comenzar a discutir el calendario de desarrollo de estas EIP de SSZ y es posible que las incluyan en el alcance de la actualización de Pectra en la próxima reunión de ACDC.

Nomenclatura de F-Star

Hay una publicación en Ethereum Magicians que discute el nombre de la próxima actualización de la capa de consenso (CL) después de Electra. Los desarrolladores han decidido el nombre para la próxima actualización de la capa de ejecución (EL) después de Prague: Osaka. Los nombres candidatos para la actualización de CL son: Fulu, Felis, Formosa y Funi. Estos nombres siguen la convención de nombrar las principales estrellas con la letra ‘F’ y son aplicables a la sexta actualización de la cadena Beacon. Stokes, por favor, comparte tu opinión sobre este tema en la publicación de Magicians durante la llamada con los desarrolladores.