Autor: Christine Kim, Galaxy; Compilador: Wu Baht, Golden Finance
El 12 de septiembre de 2024, los desarrolladores del protocolo Ethereum se reunieron virtualmente a través de Zoom para la conferencia telefónica número 196 sobre All-Core Developer Execution (ACDE). Esta semana, la llamada fue organizada por Tim Beiko, jefe de soporte de protocolo de la Fundación Ethereum (EF). La conferencia telefónica ACDE es una serie de conferencias quincenales donde los desarrolladores discuten y coordinan cambios en la capa de ejecución de Ethereum (EL).
En ACDE #196, los desarrolladores compartieron las últimas actualizaciones de la versión Pectra Devnet 3 y discutieron varios cambios en el código de Pectra que se implementarán en la futura red de desarrollo. Tienen serias discusiones sobre dividir la actualización en dos partes para poder publicar los cambios de código en Devnet 3 en un cronograma más rápido, probablemente en febrero del próximo año. Los desarrolladores acordaron tomar una decisión final al respecto en la próxima convocatoria de ACD. Finalmente, un ingeniero de operaciones de desarrollo de EF que se hace llamar "pk910" compartió una actualización sobre su trabajo limpiando el repositorio público de prueba de Ethereum en GitHub y reestructurándolo para hacerlo más fácil de usar.
Pectra Devnet 3
Parithosh Jayanthi, ingeniero de EF DevOps, explica el lanzamiento de Pectra Devnet 3. La red de desarrollo se lanza el miércoles 11 de septiembre. Incluye correcciones para la fusión de validadores en EIP 7251 y especificaciones actualizadas para EIP 7702. Según las pruebas realizadas en Devnet 3 hasta el momento, tanto EIP 7251 como EIP 7702 parecen estar funcionando como se esperaba. Jayanthi señaló que se descubrieron algunos problemas en los clientes Nethermind y EthereumJS y que los dos equipos de clientes están trabajando arduamente para resolverlos. Jayanthi agregó que dado que EIP 7702 entra en funcionamiento en Devnet 3, sería una buena idea permitir que los desarrolladores de billeteras prueben la implementación y brinden comentarios sobre su uso. Toda la información sobre Pectra Devnet 3, incluidos los faucets para solicitar testnet ETH, se puede encontrar en este sitio web.
Actualización de la especificación de Pectra
El desarrollador de Geth, Felix Lange, propuso cambios en la codificación de las solicitudes de activación de EL en Pectra. Como antecedente, Pectra permitirá contratos inteligentes en EL para iniciar retiros de validadores y fusiones en CL. Durante la última llamada de ACD, Lange compartió una recomendación para reducir la cantidad de trabajo requerido por los clientes de EL para analizar estas solicitudes. Desde la llamada de la semana pasada, Lange ha formalizado sus recomendaciones y el trabajo que el equipo del cliente EL debe realizar para actualizar la codificación de los siguientes cuatro EIP:
EIP 7685, Solicitud de capa de ejecución genérica;
EIP 7002, EL puede provocar retiros;
EIP 6110, depósito del validador de suministro en cadena;
EIP 7251, aumenta el saldo efectivo máximo.
Los desarrolladores en general están de acuerdo con la propuesta de Lange. Sin embargo, un desarrollador de Nimbus que se hace llamar "Dustin" cree que la propuesta es "inútilmente flexible" y no es compatible con cambios futuros en el formato de serialización EL. También enfatizó que se necesitan especificaciones adicionales para regular claramente el orden de las solicitudes de los clientes de EL y el comportamiento de los clientes de CL cuando EL envía solicitudes inválidas a CL. Lange acordó 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 se debe dar una consideración más profunda al comportamiento del cliente CL cuando el cliente CL detecta una solicitud no válida de un cliente EL.
El investigador de la Fundación Ethereum, Peter Miller, señaló que, según el comportamiento lógico de los clientes CL según la especificación actual, los clientes CL deberían rechazar los bloques de EL que no estén ordenados de la manera correcta. Además, si hay solicitudes no válidas en la lista compartida por el EL con la CL, la CL simplemente debería procesar todas las solicitudes válidas de la lista e ignorar las solicitudes no válidas. Dustin está de acuerdo con Miller y recomienda que los desarrolladores especifiquen este comportamiento en la documentación adecuada. Beiko dijo que los desarrolladores deberían trabajar para solucionar los problemas de la propuesta de Lange y completarla antes de la próxima convocatoria de la ACD.
Posteriormente, el desarrollador de Erigon, Andrew Ashikhmin, propuso una actualización de EIP 7702, configurando códigos de cuenta EOA. Señaló que las comprobaciones de validez especificadas en el EIP eran inconsistentes con las especificadas en el antiguo EIP. El desarrollador de Geth Matt Garnett (también conocido como "Lightclient") dice que tiene una alternativa para abordar los problemas de coherencia y simplificar las comprobaciones de validez de EIP 7702. La mayoría de los desarrolladores están a favor de finalizar la propuesta Lightclient y agregarla a Pectra Devnet 4.
La siguiente discusión relacionada con Pectra es sobre el precio de la precompilación de BLS según EIP 2537. El desarrollador de Geth, Jared Wasinger, dijo que, según su análisis de referencia, la precompilación de BLS debería costar el doble de lo que se indica actualmente. Actualmente, el costo se basa en la ejecución multiproceso, que no es el estándar por el que se fija el precio de otras ejecuciones precompiladas. Por lo tanto, basándose en su análisis utilizando la ejecución de un solo subproceso, Wasinger recomendó cambios en la tabla de descuentos para operaciones en EIP 2537. El equipo de Nethermind informa que están desarrollando una herramienta para que otros equipos de clientes puedan realizar fácilmente su propio análisis comparativo de EIP. Beiko sugirió que el equipo realice sus propios puntos de referencia sobre la precompilación de BLS y proponga ideas sobre cómo cambiar el precio de estas operaciones en las próximas dos semanas.
Suplemento Pectra EIP
Luego, los desarrolladores comenzaron a discutir la adición de nuevos EIP para las actualizaciones de Pectra. Al comienzo de la discusión, Beiko advirtió: "Ya tenemos una gran cantidad de EIP en Pectra. Ya es la bifurcación más grande hasta la fecha en términos de volumen de EIP, según las opiniones compartidas por los desarrolladores antes de la llamada". dijo: Claramente, EIP 7742 (separación de recuento de blobs entre EL y CL) es el menos controvertido de la lista de EIP que aún se están considerando para su inclusión en la actualización.
El investigador de EF Alex Stokes ha vuelto a plantear la idea de dividir Pectra en dos bifurcaciones duras más pequeñas. "Creo que todos están de acuerdo en que se trata de una bifurcación muy grande. Así que lo natural es dividirla en dos. Generalmente, las bifurcaciones más pequeñas son menos riesgosas. En particular, Pectra ahora tiene una gran cantidad de EIP entre capas, que realmente aumenta la carga de pruebas, seguridad y revisión”, dijo Stokes. Jayanthi, quien también planteó la idea en una llamada anterior, dijo que todavía la apoya. "Creo que la razón principal es que en este momento tenemos muchos EIP y tendemos a tocar muchas capas de la pila, y cuanto más agregamos, es difícil para cualquier persona tener una visión general de todos los cambios. , incluso bajo la carga actual", dijo Jayanthi.
Con respecto a cómo se puede dividir el EIP de Pectra actual en dos ramas, Stokes sugirió usar todos los EIP que se ejecutan actualmente en la red de desarrollo para lanzar la primera parte de Pectra, y luego usar PeerDAS, EOF y algunos otros EIP adicionales para lanzar la segunda parte de Péctra. Los desarrolladores confían en que, al hacer esto, podrán lanzar la primera parte de Pectra en febrero del próximo año. "Creo que esta bifurcación sería un fracaso si solo lanzáramos la primera mitad en junio", dijo el investigador de EF Ansgar Dietrichs en un chat de Zoom.
Beiko favorece la idea de una bifurcación, pero advierte contra la eliminación de cualquier EIP de la devnet, ya que esto podría generar más trabajo para los equipos de los clientes y extender, en lugar de acortar, el cronograma para preparar estos cambios de código para la activación de la red principal. Danno Ferrin, un desarrollador independiente del protocolo Ethereum, sugirió completar el EIP en Devnet 3 lo antes posible para activar la red principal y luego trabajar en paralelo comenzando con Devnet 4 o 5 para reubicar PeerDAS y EOF en Pectra EIP. De hecho, en una actualización posterior a Pectra, Devnet 4 o 5 se convertirá en Devnet 0 y los desarrolladores no están seguros de cómo nombrarlo.
En una llamada anterior, los desarrolladores acordaron nombrar la actualización en honor a Pectra Fusaka, pero también acordaron reservar la actualización para la transición Verkle. En ese sentido, Ferrin aconsejó a los desarrolladores que no realicen pedidos anticipados de actualizaciones hasta que estén seguros de que los cambios de código están listos para la activación de la red principal. Esto provocó la ira del desarrollador de Geth, Guillaume Ballet, quien ha estado liderando el esfuerzo de transición de Verkle e insistió en que la transición de Verkle estuvo lista "hace mucho tiempo". Para aliviar las tensiones, Beiko dijo que el propósito de dividir Pectra en dos era, en última instancia, intentar publicar los cambios en el código de Pectra en un cronograma más rápido, lo que ayudaría 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 pueda hacerse más grande a medida que se agreguen más EIP y, por lo tanto, tarde más en publicarse que la lista actual de Pectra EIP al mismo tiempo. El desarrollador de Nethermind, Ben Adams, cuestionó cómo funcionaría el proceso de prueba de Pectra si la actualización se dividiera en dos partes. Dado que esta decisión cambiará por completo el alcance de la próxima actualización inmediata de Ethereum, Beiko recomendó que los desarrolladores se tomen una semana para considerar la idea. Pidió a los desarrolladores que se prepararan para tomar una decisión final sobre el asunto durante la llamada de consenso de desarrolladores del próximo jueves.
Alineación de la estructura de configuración de red
Por último, pero no menos importante, el ingeniero de EF DevOps "pk910" compartió una actualización sobre su trabajo para limpiar el repositorio público de prueba de Ethereum en GitHub y reestructurarlo para facilitar su uso. Pidió al equipo de cuentas que verificara la configuración de los nodos de la red principal y de prueba de Ethereum y agregara cualquier información faltante a los repositorios correspondientes.
