Autor: 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 134 de ACDC. En esta conferencia, los desarrolladores discutieron los detalles de implementación y los desafíos técnicos de múltiples EIP clave, incluidos EIP 7549, EIP 7251, EIP 6110, EIP 7688, etc.
Además, los desarrolladores también discutieron en profundidad la implementación de PeerDAS, una tecnología de muestreo de disponibilidad de datos que se espera mejore significativamente la capacidad de la red Ethereum para admitir acumulaciones y sus requisitos de disponibilidad de datos. Durante la reunión, se hizo una propuesta para dividir Pectra en dos bifurcaciones duras para su actualización y se discutieron cuestiones sobre el tiempo de activación y las interdependencias de diferentes EIP.
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 30 de mayo de 2024, los desarrolladores de Ethereum se reunieron en Zoom para la reunión número 134 del All Core Developers Consensus (ACDC). La convocatoria de ACDC es una serie de reuniones quincenales organizadas 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 discuten experiencias y problemas abiertos desde el lanzamiento de Pectra Devnet 0. También debatieron la viabilidad de ampliar el alcance de la actualización de Pectra para incluir cambios en el código de contenedor peerDAS y SSZ.
Revisión de DevNet 0
A la luz del lanzamiento de Pectra en Devnet 0, el equipo del cliente acordó mantener sin cambios el comportamiento de validación afectado por EIP 7549 durante la activación del hard fork. En una reunión anterior de ACDC, los desarrolladores consideraron varias opciones para garantizar que el impacto de EIP 7549 no resultara en una gran cantidad de verificaciones no válidas durante la bifurcación. Para evitar complicar aún más las actualizaciones, el equipo del cliente decidió activar EIP 7549 en la misma época que otros EIP de Pectra, sin cambiar el comportamiento de validación antes y después de la bifurcación.
Con respecto a EIP 7251, los desarrolladores aún no están seguros de si se debe permitir que las fusiones de ETH apostados se activen desde la capa de ejecución (EL). Esta sería una característica ideal para grupos de apuestas como Lido, de modo que la fusión de apuestas no tenga que depender de operadores de nodos, sino que pueda lograrse mediante contratos inteligentes. Stokes recomendó verificar el progreso de los clientes que implementan fusiones de participación de validadores en unas pocas semanas antes de decidir si deberían ser operaciones EL o CL.
Luego, los desarrolladores discutieron algunas preguntas sin respuesta sobre la confirmación final de los depósitos del validador según EIP 6110. El desarrollador de Teku, Mikhail Kalinin, resumió las instrucciones para resolver estos problemas en un comentario de GitHub antes de la conferencia. El desarrollador de Lighthouse, "sean", planteó una pregunta sobre el control de versiones de la solicitud "GetPayloadBodies" en la API del motor. Stokes recomendó que los desarrolladores expresen sus opiniones en una solicitud de extracción creada para este número en GitHub.
Cambios en EIP 7549
El desarrollador de Nimbus, Etan Kissling, sugirió un pequeño cambio en la implementación de EIP 7549. "Se trata de la estabilidad del índice generalizado. Cuando agregamos un nuevo campo en el medio del contenedor, a los campos posteriores se les asignará un nuevo índice, lo que romperá la prueba basada en EIP 4788 en el nivel de ejecución (EL). y algo engañoso... Por lo tanto, recomiendo mover el nuevo campo hasta el final para evitar ambos problemas", explicó Kissling. No hubo objeciones a este cambio. Stokes recomendó que los desarrolladores verifiquen la solicitud de extracción de Kissling en GitHub.
Otro cambio al EIP 7549 propuesto en la reunión sería diseñar solicitudes y otras solicitudes activadas por EL como complementos a los bloques EL. Con respecto a este cambio, Kalinin dijo: "En mi opinión, esta es una muy buena solución de diseño, simplifica EL... y es básicamente una alternativa a las solicitudes generalizadas en el bloque de la capa de ejecución. Se recomienda que este tema sea abordado por Stokes". Se discutirá nuevamente en la próxima reunión de CL para que los desarrolladores tengan más tiempo para revisar la propuesta en GitHub.
Discusión sobre el alcance de Pectra
Hay algunos EIP centrados en la capa de consenso (CL) que no se han incluido o excluido oficialmente de la actualización de Pectra. En la reunión de esta semana, los desarrolladores discutieron si agregar EIP 7688 y PeerDAS a Pectra. EIP 7688 adopta parte de la estructura de datos SSZ "StableContainer" para garantizar la compatibilidad futura de los cambios de certificación de EIP 7549. Como introducción general, SSZ es una estructura de datos utilizada en CL y los desarrolladores también quieren utilizarla en la capa de ejecución (EL). Para obtener más información sobre la transición a SSZ, consulte las actas de reuniones anteriores. PeerDAS es una implementación de muestreo de disponibilidad de datos en Ethereum que se espera que mejore en gran medida la capacidad de la red para admitir acumulaciones y sus requisitos de disponibilidad de datos. En la práctica, se espera que PeerDAS aumente la cantidad de transacciones de blobs que los validadores pueden adjuntar a un bloque de 3 a 64 o más por bloque.
Barnabas Busa, ingeniero de operaciones de desarrolladores de la Fundación Ethereum, dijo que los desarrolladores lanzaron una versión temprana de PeerDAS en una red de desarrollo. "Creo que muchos clientes han descubierto muchos problemas y, cuando logremos avances sustanciales, siempre podremos reiniciar una nueva red de desarrollo", afirmó Busa. Stokes preguntó a los desarrolladores si estarían dispuestos a agregar PeerDAS a Pectra sin causar retrasos en la actualización.
Un desarrollador apodado "Nishant" ha revivido la sugerencia de separar la activación de PeerDAS de la activación de otros EIP en Pectra. Aunque esto es factible, otro desarrollador apodado "atd" enfatizó que si los desarrolladores planean activar estas actualizaciones una tras otra en un corto período de tiempo, los usuarios aún necesitan actualizar su software al mismo tiempo. atd dijo: "Creo que es un poco loco hacer una bifurcación dos meses después de otra actualización. Si vamos a coordinar a todos para actualizar el cliente, no queremos que todos actualicen el cliente dos meses después. Eso sería , ni siquiera un ciclo de lanzamiento es suficiente”.
atd añadió que, en su opinión, PeerDAS es el cambio de código más "interesante" en el EIP incluido y discutido en Pectra. Stokes dijo que espera incluir PeerDAS en Pectra incluso si esto causa retrasos en la actualización. El desarrollador del cliente Grandine, Saulius Grigaitis, propuso eliminar EIP 7549 y EIP 7688 de Pectra en favor de PeerDAS. Esto provocó una discusión sobre los detalles de implementación de EIP 7688. Los desarrolladores no pudieron ponerse de acuerdo sobre los cambios de código y la propuesta será revisada en la próxima reunión de ACDC.
Sobre el tema de PeerDAS, los desarrolladores continúan sopesando la idea de dividir Pectra en dos bifurcaciones duras. Parithosh Jayanthi, ingeniero de opciones para desarrolladores de la Fundación Ethereum, advirtió que si los desarrolladores dividen Pectra en dos actualizaciones, deben tener cuidado de no agregar más EIP en la futura Parte 2 de Pectra. Jayanthi dijo: “Una cosa que quiero mencionar es que si consideramos dividirnos en dos bifurcaciones, debemos tener mucho cuidado de no agregar más EIP nuevos en la siguiente bifurcación. No sé si podremos hacerlo. Hasta este punto, si podemos comprometernos con algo hace un año o un año y medio, porque siempre se nos ocurren nuevas ideas y las prioridades están cambiando, etc.
Continuando con la discusión de las dos ideas de actualización, el desarrollador de Lighthouse "sean" dijo que no preveía muchas interdependencias entre PeerDAS y la lista actual de Pectra EIP. Por lo tanto, los dos se pueden hacer por separado y luego fusionarse fácilmente cuando el desarrollador tenga más confianza en su implementación. Atd estuvo de acuerdo, argumentando que no habría mucho riesgo al fusionar Pectra EIP, PeerDAS y EIP 7688 después de desarrollarlos y probarlos por separado.
Busa recomienda continuar probando Pectra EIP y PeerDAS, pero diseñando los cambios de código para que PeerDAS se active una época más tarde que Pectra EIP en las redes de desarrollo y prueba. Señaló que así es como se realizan las pruebas de Pectra EIP y PeerDAS en Devnet 0. "Realmente no hay nada que deba cambiarse", dijo Busa, y agregó que si PeerDAS no está listo cuando los otros Pectra EIP sí lo están, los desarrolladores pueden eliminar ese cambio de código de la actualización. Esto plantea varias preguntas sobre cómo las diferentes épocas de activación de PeerDAS afectan el trabajo de los equipos de los clientes. Al final, los desarrolladores acordaron continuar desarrollando PeerDAS y Pectra EIP, pero la premisa era que PeerDAS se activaría en diferentes épocas en la red de desarrollo y en la red de prueba.
Como se mencionó anteriormente, los desarrolladores acordaron dejar la discusión sobre si EIP 7688 se incluirá en Pectra hasta la próxima convocatoria de ACDC.
