
Autor: Christine Kim, Galaxy;
El 12 de septiembre de 2024, los desarrolladores de protocolo de Ethereum celebraron la Celera de Conferencia de la Ejecución de Desarrolladores All-Core (ACDE) a través de la reunión virtual de Zoom.Esta semana, la conferencia telefónica fue organizada por Tim Beiko, jefe de apoyo de acuerdo en la Fundación Ethereum (EF).La conferencia telefónica de ACDE es una serie de conferencias quincenales donde los desarrolladores discuten y coordinan los cambios en la capa de ejecución de Ethereum (EL).
En ACDE #196,Los desarrolladores compartieron las últimas actualizaciones publicadas por Pectra Devnet 3 y discutieron varios cambios en el código Pectra implementados en la red de desarrollo en el futuro.Discutieron seriamente dividir la actualización en dos partes para que pudieran publicar cambios en el código en Devnet 3 en un horario más rápido (probablemente para febrero del próximo año).El desarrollador acordó tomar una decisión final sobre esto en la próxima conferencia telefónica de ACD.Finalmente, un ingeniero de operaciones de desarrolladores de EF llamado «PK910» compartió los últimos desarrollos en su trabajo para limpiar el repositorio de GitHub Public Testnet de Ethereum y ajustar su estructura para un uso más fácil.
Pectra Devnet 3
EF Development and Operations Engineer Parisosh Jayanthi introdujo el lanzamiento de Pectra Devnet 3.La red de desarrollo se lanzó el miércoles 11 de septiembre.Incluye correcciones para fusiones de validador en EIP 7251 y especificaciones actualizadas para EIP 7702.Según las pruebas en DevNet 3 hasta ahora, tanto EIP 7251 como EIP 7702 parecen funcionar como se esperaba.Jayanthi señaló que se encontraron algunos problemas en los clientes de los Países Bajos y Ethereumjs, y ambos equipos de clientes están trabajando para abordarlos.Jayanthi agregó que, dado que EIP 7702 está en línea en Devnet 3, es mejor que los desarrolladores de billeteras prueben la implementación y proporcionen comentarios sobre su uso.Toda la información sobre Pectra Devnet 3, incluidos los TAPS que solicitan TestNet ETH, se puede encontrar en este sitio web.
Actualización de especificaciones de Pectra
El desarrollador de Geth, Felix Lange, ha propuesto cambios en la codificación de las solicitudes de activación EL en Pectra.Como fondo, Pectra permitirá que los contratos inteligentes en El iniciaran retiros de validador y fusiones en CL.Durante la última llamada de ACD, Lange compartió una sugerencia para reducir la cantidad de trabajo requerido por los clientes EL para resolver estas solicitudes.Desde la conferencia telefónica de la semana pasada, Lange ha formalizado sus recomendaciones y el trabajo que el equipo de El Cliente debe hacer para actualizar la codificación de los siguientes cuatro EIP:
-
EIP 7685, solicitud de capa de ejecución general;
-
EIP 7002, El puede activar retiros;
-
EIP 6110, depósito de validador de suministro en cadena;
-
EIP 7251, aumente el equilibrio efectivo máximo.
Los desarrolladores generalmente estuvieron de acuerdo con la propuesta de Lange.Sin embargo, los desarrolladores de Nimbus, cuya web titulada «Dustin», creía que la propuesta era «sin sentido flexible» y no era compatible con cambios futuros en el formato de serialización EL.También enfatizó que se necesitan especificaciones adicionales para aclarar el orden de las solicitudes para los clientes de EL y el comportamiento de los clientes CL cuando EL envía solicitudes inválidas a CL.Lange acepta agregar más texto a la API del motor para especificar el orden de las solicitudes.También está de acuerdo con Dustin en que el comportamiento de los clientes CL cuando los clientes CL detectan solicitudes no válidas de los clientes EL deben considerarse más profundamente.
El investigador de la Fundación Ethereum, Peter Miller, señaló que, según el comportamiento lógico de los clientes CL bajo la especificación actual, los clientes CL deberían rechazar bloques de ELS que no están ordenados de la manera correcta.Además, si hay solicitudes no válidas en la lista compartidas por el EL al CL, el CL debe simplemente procesar todas las solicitudes válidas en la lista e ignorar las solicitudes no válidas.Dustin está de acuerdo con Miller y aconseja a los desarrolladores que especifiquen este comportamiento en la documentación apropiada.Beiko dijo que los desarrolladores deberían trabajar para resolver problemas en la propuesta de Lange y completarla antes de la próxima llamada ACD.
Entonces,El desarrollador de Eragon Andrew Ashikhmin propuso una actualización para EIP 7702, configurando el código de cuenta EOA.Señaló que la verificación de validez especificada en el EIP era inconsistente con la verificación de validez especificada en el EIP anterior.El desarrollador de Geth, Matt Garnett (también conocido como «LightClient») dijo que tiene una alternativa para abordar los problemas de consistencia y simplificar la verificación de efectividad del EIP 7702.La mayoría de los desarrolladores favorecen la finalización de la propuesta de LightClient y la agregar a Pectra Devnet 4.
La siguiente discusión relacionada con Pectra es sobre el precio de la precompilación de BLS bajo EIP 2537.El desarrollador de Geth, Jared Wasinger, dijo que, según su análisis de referencia, el precio de la precompilación de BLS debería ser el doble de lo alto que actualmente estipulado.Actualmente, el costo se basa en la ejecución múltiple, que no es un estándar para fijar el precio de otra ejecución precompilada.Por lo tanto, según su análisis utilizando un solo hilo, Wasinger recomienda hacer cambios en las tablas de descuento operadas en EIP 2537.El equipo de los Países Bajos informó que estaban desarrollando una herramienta para que otros equipos de clientes pudieran realizar fácilmente su propio análisis de evaluación comparativa de EIP.Beiko aconseja al equipo que realice sus propios puntos de referencia para la precompilación de BLS y que provoquen ideas sobre la reproducción de estas operaciones durante las próximas dos semanas.
Suplemento de PECTRA EIP
Luego, los desarrolladores comenzaron a discutir el tema de agregar nuevos EIP a la actualización de Pectra.Al comienzo de la discusión, Beiko advirtió: «Ya tenemos una gran cantidad de EIP en Pectra. Es, con mucho, la bifurcación más grande en términos de la cantidad de EIP». Dijo que es obvio que EIP 7742 (la separación de Blob cuenta entre El y CL) es la lista menos controvertida de EIP que todavía se están considerando para su inclusión en la lista mejorada.
El investigador de EF Alex Stokes propuso una vez más la idea de dividir a Pectra en dos horquillas duras más pequeñas.»Creo que todos están de acuerdo en que es una bifurcación muy grande. Por lo tanto, lo natural es dividirlo en dos. Por lo general, el riesgo de horquillas más pequeñas es menor. En particular, hay muchas capas cruzadas en Pectra en este momento EIP, eso realmente se suma a la carga de prueba, seguridad y revisión ”, dijo Stokes.Jayanthi también propuso la idea en una conferencia telefónica anterior, que dijo que todavía apoya.»Creo que la razón principal es que en este momento tenemos muchos EIP, tendemos a tocar muchas capas de la pila, y cuanto más agregamos, es difícil para cualquiera tener una comprensión global de todos los cambios incluso bajo los actuales Carga. «Jayanthi dijo.
Con respecto a la forma en que el PECTRA EIP actual se puede dividir en dos ramas, Stokes recomienda usar todos los EIP que se ejecutan actualmente en la red de desarrollo para publicar la primera parte de Pectra, y luego usar Peerdas, EOF y algunos otros EIP adicionales para publicar la segunda Parte de Pectra.Los desarrolladores confían en que al hacerlo, podrán lanzar la primera parte de Pectra para el próximo febrero.»Creo que si todavía lanzamos la primera mitad de junio, entonces esta bifurcación sería un fracaso», dijo el investigador de EF Ansgar Dietrichs en un chat de zoom.
Beiko favorece la idea de bifurcarse, pero advierte contra la eliminación de cualquier EIP de la red de desarrollo, ya que esto puede traer más trabajo al equipo del cliente y extender en lugar de acortar la línea de tiempo para preparar estos cambios en el código para activar el NET de Mainnet.Danno Ferrin, un desarrollador de protocolo Ethereum independiente, recomienda mejorar EIP en DevNet 3 lo antes posible para activar el Minnet, y luego trabajar en paralelo desde DevNet 4 o 5, reubicando Peerdas y EOF a Pectra EIP.De hecho, en la actualización después de Pectra, Devnet 4 o 5 se convertirá en Devnet 0, y los desarrolladores no están seguros de cómo nombrarlo.
En una conferencia telefónica anterior, los desarrolladores acordaron nombrar la actualización después de Pectra Fusaka, pero también acordaron mantener la actualización para la transición de Verkle.Con respecto a esto, Ferrin aconseja a los desarrolladores que no reserven una actualización por adelantado hasta que estén seguros de que los cambios en el código están listos para la activación de Mainnet.Esto ha causado la ira del desarrollador Geth Guillaume Ballet, quien ha liderado la transición de Verkle e insiste en que la transición de Verkle estaba lista «hace mucho tiempo».Para aliviar las tensiones, Beiko dijo que el objetivo de dividir a Pectra en dos es, en última instancia, tratar de liberar los cambios en el código Pectra en una línea de tiempo más rápida, lo que ayudará a despejar el camino para la transición de Verkle a partir de entonces.
Sin embargo,Existe el riesgo de que la segunda parte de la actualización de Pectra se haga más grande a medida que se agregan más EIP, por lo que tomará más tiempo liberarse que los listados de PECTRA EIP actuales se lanzan simultáneamente.El desarrollador de Nethermind, Ben Adams, cuestionó,Si la actualización se divide en dos partes, ¿cómo continuará el proceso de prueba de Pectra?Dado que esta decisión revolucionará el alcance de la próxima actualización inmediata de Ethereum, Beiko aconseja a los desarrolladores que pasen una semana pensando en esta idea.Pidió a los desarrolladores que se prepararan para una decisión final sobre el asunto en la llamada de consenso del próximo jueves para todos los desarrolladores principales.
Alineación de la estructura de configuración de red
Por último, pero no menos importante, el ingeniero de operaciones de desarrollo de EF «PK910» compartió su actualización de trabajo para limpiar el repositorio de GitHub de Ethereum Public Testnet y ajustar su estructura para un uso más fácil.Le pidió al equipo del cliente que verifique la configuración del nodo de Ethereum Mainnet y Testnet y agregue cualquier información faltante al repositorio correspondiente.