Título original: "Resumen de la llamada de consenso n.º 139 de todos los desarrolladores principales de Ethereum

Autor: Christine Kim

Compilado por: Ladyfinger, BlockBeats

Nota del editor:

La llamada de consenso para desarrolladores de All Core Ethereum (ACDC) es una serie quincenal de reuniones centradas en discutir y coordinar cambios en la capa de consenso (CL) de Ethereum, también conocida como Beacon Chain. La convocatoria número 139 de ACDC fue organizada por el investigador de la Fundación Ethereum (EF), Alex Stokes, y cubrió las correcciones de Pectra Devnet 2, los preparativos para Devnet 3, el progreso de la implementación de PeerDAS y nuevos datos sobre la distribución de nodos de Ethereum.

Durante la reunión, los desarrolladores revisaron la estabilidad y los problemas existentes de Pectra Devnet 2, discutieron los preparativos para el próximo Devnet 3 y tuvieron una discusión en profundidad sobre el progreso de la implementación de PeerDAS. Además, la propuesta de EIP 7688, que tiene como objetivo introducir una estructura de datos compatible con versiones futuras para respaldar posibles cambios en el método de serialización de datos de Ethereum, también provocó una extensa discusión entre los asistentes. Christine Kim, vicepresidenta de investigación de Galaxy Digital, registró esta reunión en detalle y BlockBeats compiló el texto original de la siguiente manera:

El 8 de agosto de 2024, los desarrolladores de Ethereum celebraron la 139.ª conferencia telefónica de consenso de desarrolladores principales (ACDC) a través de Zoom. La conferencia telefónica de ACDC es una serie de reuniones quincenales donde los desarrolladores discuten y coordinan cambios en la Capa de Consenso (CL) de Ethereum, también conocida como Beacon Chain. La llamada de esta semana está organizada por el investigador de la Fundación Ethereum (EF), Alex Stokes. Los desarrolladores discuten las correcciones de Pectra Devnet 2, los preparativos para Devnet 3, el progreso de la implementación de PeerDAS y nuevos datos sobre la distribución de nodos de Ethereum.

Actualización de pectra

Stokes anunció que el investigador de EF, Hsiao Wei Wang, está a punto de lanzar la versión oficial actualizada alfa.4 de la especificación de la capa de consenso (CL) de Pectra. Esta versión contiene múltiples mejoras con respecto a la versión anterior y se planea lanzarla en un futuro cercano.

Sobre el tema de Pectra Devnet 2, el ingeniero de operaciones de desarrollo de EF, Barnabas Busa, dijo que la red es estable y ha alcanzado el 85% de participación en la red. Todavía quedan algunos problemas menores que deben resolverse en los clientes de la capa de ejecución (EL), principalmente EthereumJS y Erigon. La mayoría de los clientes CL son estables en Devnet 2. Sin embargo, Busa mencionó problemas menores con el cliente de Prysm que requieren más investigación. El ingeniero de EF DevOps, Parithosh Jayanthi, agregó que los equipos de clientes también deben investigar problemas entre los nodos Lighthouse, Teku y Besu.

Posteriormente, los desarrolladores discutieron cómo mejorar el proceso de comunicación del inicio de devnet. La desarrolladora de Prysm, Kasey Kirkham, señaló su falta de conocimiento sobre el tiempo de lanzamiento de Devnet 2 durante una charla de Zoom. Para garantizar que la información del lanzamiento de Devnet 3 se comunique con precisión a todos los equipos de los clientes, los desarrolladores decidieron programar una reunión semanal regular para actualizar el progreso de las pruebas de Pectra. Aunque aún no se ha determinado la hora exacta, se espera que estas reuniones se lleven a cabo todos los lunes, de manera similar a las llamadas de prueba previas a la actualización de Dencun. Jayanthi propuso que estas reuniones sean breves y eficientes, con una duración de entre 15 y 30 minutos, y se centren en discutir actualizaciones de pruebas de devnet relacionadas con Pectra, cubriendo temas como PeerDAS y EOF devnet s.

Al hablar de Pectra Devnet 3, los desarrolladores reiteraron que seguirá utilizando la misma configuración EIP que Devnet 2. Además, Devnet 3 integrará por primera vez el EIP 7702 de nuevo diseño, que el equipo realizará pruebas meticulosas para garantizar la compatibilidad con los EIP centrales de Pectra. Gajinder Singh del equipo de Lodestar mencionó que EIP 7251, el problema en la propuesta de MaxEB, se descubrió en Devnet 2. Aunque se ha depurado, aún se necesitan pruebas más profundas en el próximo devnet de Pectra para verificar la solución.

Como se analizó en ACDE #193, existe una nueva especificación de Engine API que permite a los clientes CL obtener blobs del grupo de memoria de transacciones de blobs EL. El método se llama " getBlobsV1 ". Para evitar abusos, el desarrollador de Teku, Enrico del Fante, propuso algunas aclaraciones a la especificación CL. Stokes recomendó que los desarrolladores revisen estas aclaraciones y planeen probar el uso de este enfoque en Pectra Devnet 3.

Los desarrolladores discutieron la obsolescencia del protocolo complejo. Mplex era un protocolo utilizado por los clientes CL para la transmisión de múltiples transmisiones a través de un único enlace de comunicación, pero sus mantenedores lo han desaprobado. El equipo del cliente planea pasar a nuevas tecnologías de reutilización de transmisiones como yamux. Phil Ngo de Lodestar anunció que han completado la integración y las pruebas de yamux y prefieren realizar la transición directa al nuevo protocolo en lugar de mantener dos protocolos a largo plazo, ya que esto aumentará los costos operativos del cliente. Etan Kissling de Nimbus también reveló que su equipo está probando yamux. Los desarrolladores acordaron que continuarán monitoreando el progreso de otros equipos de clientes de CL en la transición del protocolo y planean reevaluar la estrategia de migración del mplex al nuevo multiplexor en los próximos meses.

Etan Kissling presentó una discusión en el hilo de Pectra sobre EIP 7688, una propuesta para introducir una estructura de datos compatible con versiones futuras para permitir a los desarrolladores de contratos inteligentes realizar la transición de RLP al método de serialización de datos de la Capa de ejecución de Ethereum (EL) para continuar usándolo al llegar. SSZ. Aunque la actualización de Pectra en sí no implementará completamente SSZ, se propone EIP 7688 para garantizar la compatibilidad futura de Pectra EIP con respecto a los cambios de datos.

Alex Stokes se muestra cauteloso a la hora de incluir EIP 7688 en la actualización de Pectra, diciendo que la actualización ya es bastante grande. Parithosh Jayanthi mencionó durante la conferencia que EIP 7688 puede probarse en Devnet 5 lo antes posible. Representantes de equipos como Lodestar, Prysm, Teku y Lighthouse expresaron su apoyo a la propuesta. Stokes y Beiko recomiendan que se evite la adición de nuevos EIP a Pectra hasta que todos los EIP de Pectra existentes hayan alcanzado un estado estable. Kissling aceptó la sugerencia y preguntó cuándo sería el mejor momento para volver a abordar el tema. Aunque no se recibió una respuesta específica, el equipo en general estuvo de acuerdo en que EIP 7688 debería reevaluarse antes del lanzamiento de Pectra Devnet 5.

Actualización de PeerDAS

Representantes del equipo de clientes de Prysm informaron sobre sus últimos avances en la implementación de PeerDAS en la reunión, lo que generó una discusión sobre la necesidad de solicitudes de API de motor "blob sidecar". Alex Stokes sugirió que la próxima reunión del grupo PeerDAS requerirá una discusión en profundidad de los ajustes que PeerDAS necesita realizar en la API del motor. También señaló que un investigador de EF redactó una especificación formal que propone eliminar el mecanismo de muestreo de PeerDAS, con el objetivo de reducir la complejidad del proceso de actualización. Sin embargo, en una reunión reciente del grupo PeerDAS, los participantes expresaron su preocupación de que la medida podría dificultar la reintroducción del muestreo a través de una bifurcación dura en el futuro. Además, no está claro el impacto de la eliminación del mecanismo de muestreo en el aumento seguro de los límites de burbujas de gas en Pectra. Durante la conferencia telefónica de esta semana se volvió a plantear una propuesta para desacoplar los límites de blobs de gas en la capa de ejecución (EL) y la capa de consenso (CL), EIP 7742. Stokes dijo que actualizará el EIP y planea discutir su posible inclusión en la próxima convocatoria de CL, así como temas relacionados con los ajustes del límite de blob gas en Pectra.

Actualización de la investigación

Durante la conferencia telefónica de esta semana, los desarrolladores se centraron en tres temas de investigación. Primero, exploran los casos extremos que los validadores pueden encontrar al fusionar saldos de ETH apostados según EIP 7251. Etan Kissling sugirió que es posible que los saldos de los validadores no se actualicen durante largos períodos de tiempo durante las fusiones, lo que podría provocar que el protocolo asigne incorrectamente las responsabilidades del comité de sincronización. En respuesta, Alex Stokes respondió que este problema es similar al manejo del protocolo del retiro del validador y sugirió documentar este caso límite en la especificación de la capa de consenso (CL) sin cambiar el diseño de fusión existente.

Luego, los desarrolladores discutieron los cambios en la capa de red Ethereum, específicamente la introducción de una "entrada ENR rápida". Quic significa Conexión rápida a Internet UDP, que ayuda a los nodos a enviar y recibir datos. Stokes sugirió crear una solicitud de extracción (PR) en GitHub para detallar más los cambios específicos en la entrada ENR rápida.

Finalmente, ProbeLab compartió su análisis en curso de las operaciones de nodos en la red Ethereum. Los informes muestran que actualmente hay 8.335 nodos ejecutándose en la red Ethereum, el 42% de los cuales utiliza el cliente Lighthouse. Los nodos que operan en Estados Unidos representan el 36% del total y aproximadamente la mitad de los nodos están implementados en centros de datos. El desarrollador de Prysm, “Potuz”, expresó curiosidad por el hecho de que la cantidad de nodos Lighthouse alojados en el centro de datos excede la cantidad de nodos autohospedados. Stokes especula que esto puede deberse a que la principal base de usuarios del cliente Lighthouse incluye instituciones y operadores de nodos profesionales.

Al final de la reunión, Potuz instó al equipo a revisar el PR que había presentado con respecto a ajustar la estructura de la carga útil de ejecución. La propuesta se planteó por primera vez durante la última convocatoria de la ACDC. Potuz enfatizó la importancia de una toma de decisiones rápida y señaló que, si bien estos cambios son conceptualmente simples y fáciles de entender, integrarlos en la especificación de la Capa de Consenso (CL) puede ser un desafío. Aconseja a los desarrolladores que empiecen a trabajar en esto lo antes posible.