Título original: "Rescritura n.º 185 de la llamada de ejecución de todos los desarrolladores principales de Ethereum"
Autor original: Christine Kim
Compilación original: Luccy, BlockBeats
Nota del editor:
La llamada de consenso de todos los desarrolladores principales de Ethereum (ACDE) se lleva a cabo cada dos semanas para discutir y coordinar cambios en la capa de ejecución de Ethereum (EL). Esta es la conferencia telefónica número 185 de ACDE. Durante la reunión, los desarrolladores llevaron a cabo discusiones y evaluaciones en profundidad sobre los cambios de código y otros EIP necesarios para el próximo hard fork de Praga.
Los promotores debatieron vigorosamente las propuestas y llegaron a un consenso inicial sobre si algunas de ellas deberían incluirse en Praga. Sin embargo, ha habido cierta controversia, como la discusión sobre si EOF debería incluirse con la actualización Verkle. Al final de la reunión, los desarrolladores acordaron el próximo plan de trabajo y decidieron probar y evaluar más a fondo el impacto de cada propuesta en la futura red de desarrollo.
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 11 de abril de 2024, los desarrolladores de Ethereum se reunieron en Zoom para la reunión número 185 de All Core Developers Execution (ACDE). La conferencia telefónica ACDE es una serie de reuniones quincenales organizadas por Tim Beiko, jefe de soporte de protocolo de la Fundación Ethereum, donde los desarrolladores discuten y coordinan cambios en la capa de ejecución de Ethereum (EL). Esta semana, los desarrolladores discutieron los cambios de código que deberían agregarse a la próxima actualización de Ethereum EL, el hard fork de Praga. Praga se activará simultáneamente con la actualización CL Electra y se espera que esté completa antes de finales de 2024.
Inicialmente, los desarrolladores acordaron ampliar el alcance de Praga/Electra (Pectra) para incluir cinco propuestas de mejora de Ethereum (EIP). son, respectivamente:
EIP 2537, BLS12-381 Precompilación de operaciones de curvas
EIP 6110, Aprovisionamiento de depósitos de validador en cadena
EIP 7002, salida activada por EL
EIP 7251, aumenta el saldo efectivo máximo
EIP 7549, sacando el índice del comité de la certificación
Esta semana, acordaron por unanimidad incluir EIP 3074 (códigos de operación AUTH y AUTHCALL) y EIP 2935 (preservación de hashes de bloque históricos en el estado) en la lista anterior. También decidieron excluir EIP 7547 (incluir listas) y EIP 7667 (aumentar el costo del gas de las funciones hash) de Praga. Los desarrolladores se están inclinando fuertemente por combinar EIP 7667 con Verkle en la próxima actualización de EL después de Praga, Osaka. Actualmente, todavía se está considerando la inclusión de los 10 EIP de formato de objeto VM (EOF) de Ethereum y el EIP 7623 (mayor costo de datos de llamadas) en Praga.
Revisa lo que ya está incluido en Praga
Antes de profundizar en la lista de EIP que se están considerando en Praga, los desarrolladores se tomaron un momento para revisar los problemas con los EIP que ya están incluidos en la actualización.
EIP 7251
Uno de los EIP, EIP 7251, permitirá a los operadores de nodos consolidar validadores con saldos efectivos de hasta 32 ETH en un único validador grande con saldos efectivos de hasta 2048 ETH. El saldo efectivo se refiere al saldo de ETH apostado por el cual el validador recibe recompensas de emisión. Los saldos superiores a 32 ETH no otorgan a los validadores más recompensas de emisión, por lo que los operadores de nodos deben ejecutar varios validadores para aumentar sus recompensas de emisión. EIP 7251 tiene como objetivo reducir la cantidad de validadores activos en Ethereum al permitir la fusión de validadores y la composición automática de recompensas de apuesta.
Basado en discusiones entre desarrolladores y grandes grupos de participación de Ethereum como Lido, acordaron considerar cambios en el EIP para hacer que las fusiones de validadores sean una operación activada por contratos inteligentes en EL. El investigador de la Fundación Ethereum, Alex Stokes, destacó su artículo sobre cómo funcionaría la fusión dentro del protocolo y pidió comentarios sobre los cambios de código propuestos al equipo del cliente en una conferencia telefónica.
PEI 2537
Stokes también compartió las últimas noticias sobre EIP 2537, una propuesta que agrega operaciones a la Máquina Virtual Ethereum (EVM) que permite a los desarrolladores realizar de manera eficiente la verificación de firmas criptográficas utilizando construcciones de curva BLS12-381. Esta es una forma más segura y rápida que verificar las firmas ECDSA generadas utilizando la construcción de curva secp256k1 en EL. Stokes dijo que se completó el trabajo inicial de evaluación comparativa sobre el precio de estas operaciones y que los desarrolladores pueden esperar actualizaciones finales sobre sus costos exactos de gas en las próximas semanas. Mientras tanto, se anima a los equipos de clientes a implementar el EIP según el alcance actual de la primera red de prueba para desarrolladores de Pectra, pectra-devnet-0.
Debate ¿Qué más debería incluir Praga?
Antes de la llamada de esta semana, el equipo del cliente de EL proporcionó una actualización por escrito sobre los EIP adicionales que esperan incluir en Praga, además de los cinco EIP que ya acordaron incluir en la actualización. Beiko vinculó las preferencias del equipo del cliente de EL en la agenda de la conferencia telefónica y, para preservarlas a largo plazo, los enlaces se encuentran a continuación:
Preferencias de Eragon
preferencia besu
Preferencias
Preferencias de Mente Abisal
Preferencias geth
Final del Mega EOF
Al discutir otros EIP que se incluirán en Praga, el desarrollador de Geth, Guillaume Ballet, expresó su oposición a incluir cambios de EOF en la actualización. Le preocupaba que los cambios pudieran dificultar o imposibilitar la implementación de Verkle en una actualización posterior a Praga, conocida como Osaka. Danno Ferrin, ingeniero jefe de software de Swirlds Labs, objetó y dijo que EOF es "100% compatible" con los cambios de código de Verkle. Ballet expresó dudas sobre la evaluación de Ferrin, reiterando los comentarios de una llamada anterior de ACDE sobre el deseo de ver a EOF en la red de pruebas de Verkle. Beiko explicó que no es razonable evaluar la compatibilidad de EOF con Verkle en función de su funcionalidad en una futura red de prueba de hard fork, y le preguntó a Ballet si podía aclarar inquietudes específicas sobre la compatibilidad de EOF con Verkle. Ballet no respondió. Dijo que no había ninguna especificación de código para EOF para su revisión. Un desarrollador compartió un enlace a la última especificación EOF en un chat de Zoom. En el chat también se compartieron enlaces a la preparación de EOF basada en la implementación del lado del cliente.
El desarrollador de Geth, Marius van der Wijden, preguntó cuántos códigos de operación agregará o actualizará EOF. Beiko señaló que según la última especificación, EOF cambiará 18 códigos de operación. EOF es un paquete de cambios de código para EVM de 10 EIP diferentes. Van der Wijden dijo que su principal preocupación con EOF es su complejidad y cuánto trabajo llevará a los equipos de los clientes probar adecuadamente todos los casos extremos en EOF. El desarrollador de Nethermind, Marek Moraczyński, está de acuerdo en que EOF probablemente "introducirá muchos errores de consenso nuevos" y requerirá "pruebas cuidadosas", pero el impacto negativo de no implementar estos EIP significa que estas mejoras en el EVM tendrán que esperar otros dos o tres años.
Ferrin señaló que cuando los desarrolladores debatieron si EOF debería incluirse en la actualización de Shanghai, objetaron que estos cambios de código tenían un alcance demasiado limitado. Ahora que Ferrin y otros desarrolladores han trabajado para difundir más EOF, los equipos de los clientes han retrocedido porque los cambios en el código son demasiado complejos y difíciles de implementar. "No pudimos obtener solicitudes consistentes de todos los grupos principales de desarrolladores", dijo Ferrin, y agregó que era "frustrante" escuchar quejas sobre EOF en ambas versiones. Los equipos de clientes de Reth y Erigon apoyan la inclusión de EOF en Praga. Beiko recomendó que los desarrolladores pasen a otros EIP y revisen la discusión sobre el EOF más adelante en la llamada.
Códigos de operación EIP 3074, AUTH y AUTHCALL
Beiko preguntó al equipo del cliente qué pensaban sobre EIP 3074, la introducción de los códigos de operación AUTH y AUTHCALL. Estos códigos de operación agregarán más programabilidad a las cuentas controladas por el usuario al permitir que los contratos inteligentes autoricen transacciones desde EOA (cuentas de propiedad externa de Ethereum). Muchos desarrolladores presentes en la llamada, incluidos Georgios Konstantopoulos, Danno Ferrin y "protolambda", apoyaron este cambio de código. Protolambda volvió a proponer su propuesta EIP 7664, con el objetivo de corregir una vulnerabilidad en la lógica EIP 3074 al interactuar con listas de acceso. El desarrollador de Geth y coautor de EIP 3074, Matt Garnett, también conocido como "Lightclient", dijo que cree que EIP 7664 es una buena idea. Otro desarrollador preguntó cómo afectaría EIP 3074 al código de operación ORIGIN, que devuelve la dirección desde la que se inició la transacción. Beiko dijo que estos impactos están enumerados en el EIP y preguntó si algún desarrollador se opuso a incluir este cambio de código en Praga. Sin objeciones.
EIP 2935, guardando el estado histórico del hash del bloque
Ballet presentó EIP 2935 en ACDE #184, un cambio de código que brindará beneficios futuros a las implementaciones de Verkle. El equipo de clientes de Reth tiene una postura de "neutral a positiva" sobre el EIP y afirman que, considerando que se trata de un cambio simple, no tienen objeciones a su inclusión en Praga. El equipo del cliente de Erigon adopta una postura similar, pero señala que si se incluyen cambios de código más importantes como EOF en Praga, tendrán menos confianza a la hora de incorporarlo a Praga. Beiko sugirió continuar las discusiones sobre otros EIP y revisar el EIP 2935 más adelante en la llamada.
EIP 7667, aumenta el costo del gas de las funciones hash
El cofundador de Ethereum, Vitalik Buterin, propuso un EIP que tiene como objetivo aumentar el costo del gas de los códigos de operación de la función hash y la precompilación para igualar el costo de ejecución a través de sistemas de conocimiento cero (ZK), como los ZK EVM. Para obtener más información sobre ZK EVM, lea el informe de Galaxy Research. Con respecto a la motivación para cambiar el precio de las operaciones de la función hash de Ethereum, Buterin escribió en el documento EIP 7667: “Los códigos de operación de la función hash y los costos del gas precompilado se establecieron inicialmente en función del tiempo requerido para ejecutarlos en una CPU convencional. Sin embargo, luego se agregó otra capa de implementación igualmente importante. Surgió: sistemas a prueba de conocimiento cero (ZK-SNARK). Según este estándar, estos códigos de operación y precompilación tienen un precio inferior al de otras operaciones”.
Buterin agregó en la llamada que es fácil subestimar cómo las pruebas ZK se volverán cada vez más comunes, no solo para validar cosas como acumulaciones de Capa 2, sino también en cadenas de bloques de Capa 1 como Ethereum. Dijo: "Creo que incluso dentro de uno o dos años, podremos tener la capacidad de probar Ethereum L1 en tiempo real. Por eso creo que es importante adaptarnos al hecho de que ya no existe una diferencia entre la cadena ZK y la cadena que no es ZK. La diferencia. Ahora estamos básicamente en un modo en el que cada cadena seria es una cadena ZK ".
Dados los cambios en el precio y la programación del gas debido a Verkle en la actualización de Osaka, Ferrin recomendó implementar este EIP junto con Verkle. El investigador de EF, Carl Beekhuizen, dijo que este EIP requiere mucha investigación y que los desarrolladores deben ser "muy cuidadosos" al analizar cómo estos cambios de gas afectarán los contratos inteligentes en Ethereum. Van der Wijden estuvo de acuerdo con Beekhuizen en proceder con cautela en este EIP. Ferrin también sugirió que los cambios podrían implementarse primero en los paquetes acumulativos de Capa 2, mientras que los desarrolladores de Ethereum investigan más a fondo su impacto en la Capa 1. Beiko está de acuerdo y recomienda que los desarrolladores consideren EIP 7667, junto con Verkle, para su inclusión en la actualización de Osaka y le otorguen el estado "CFI" o "Considerado para inclusión". Sin objeciones.
EIP 7623, aumenta el costo de los datos de llamadas
El investigador de EF Toni Wahrstätter, coautor de EIP 7623, compartió una actualización sobre su propuesta de aumento en los costos de los datos de llamadas y preguntó a los equipos de los clientes qué pensaban al respecto. El investigador de EF Ansgar Dietrichs y el desarrollador de Nethermind Ahmad Bitar están de acuerdo. Beekhuizen agregó que cuando se presentó EIP 7623 en el último Rollcall, una serie de reuniones entre equipos acumulativos de Capa 2, no hubo objeciones a su implementación. Beiko sugirió continuar la discusión sobre otros EIP y revisar este EIP más adelante en la llamada.
EIP 7645, cambie el nombre de ORIGEN a REMITENTE
Beiko pidió al equipo del cliente su opinión sobre EIP 7645, una propuesta para cambiar el comportamiento del código de operación ORIGIN para evitar el uso indebido de contratos inteligentes. Cyrus Adkisson, uno de los primeros inversores en Ethereum y autor de EIP 7645, señaló que hay tres caminos posibles para actualizar el código de operación ORIGIN, cada uno con diferentes compensaciones. Ferrin dijo que el camino propuesto para cambiar el comportamiento del código de operación requiere un escrutinio cuidadoso por parte de los profesionales de seguridad y las firmas de auditoría, ya que los desarrolladores del protocolo Ethereum no pueden evaluar completamente el impacto de tales cambios en los contratos inteligentes y los usuarios finales existentes. Beiko recomendó que los desarrolladores continúen las discusiones sobre otros EIP por razones de tiempo.
EIP 7547, incluida la lista
Beiko preguntó a los desarrolladores su opinión sobre la incorporación de EIP 7547 en Praga. A juzgar por la respuesta del equipo del cliente de EL, no parece que exista un apoyo generalizado para este cambio de código. Beiko recomienda excluirlo de la actualización. Sin objeciones.
Propuesta de Ajuste de Curva de Emisión
Dietrichs propuso una propuesta para reducir la emisión de Ethereum. Considerando que este cambio afecta principalmente a la capa de ejecución de Ethereum, Beiko recomendó que los desarrolladores discutan más a fondo los méritos de esta propuesta durante la convocatoria de ACDC.
Revisando EOF, EIP 7623 y 2935 para Praga
Luego, los desarrolladores revisaron el EIP que se había propuesto para Praga pero que aún no se había acordado. Beiko preguntó si EOF podría incluirse con la actualización Verkle. Ballet se opuso firmemente a la idea, diciendo que ambos cambios de código eran complejos y que hacerlos simultáneamente sería "demasiado arriesgado". Protolambda destacó el EIP 7664 como otro EIP que debería considerarse para su inclusión en Praga. Garnett agregó que también se debe considerar EIP 7639, una propuesta para que los clientes dejen de proporcionar datos históricos antes de las actualizaciones de fusión (septiembre de 2022).
En respuesta a las preocupaciones de que la inclusión de EOF supondría demasiada carga adicional para los equipos de los clientes, el desarrollador de Reth, Georgios Konstantopoulos, animó a los desarrolladores a "hacerlo". Sin embargo, todavía no hay consenso sobre el EOF. Al final, los desarrolladores acordaron continuar trabajando en EOF, específicamente en las pruebas requeridas, y determinar más adelante si debería incluirse en Praga. También acordaron aplazar una decisión sobre EIP 7623. En cuanto al EIP 2935, los desarrolladores acordaron incluirlo en Praga.
Al resumir todas las decisiones tomadas durante la llamada, Beiko dijo que los desarrolladores incluirán EIP 3074 y EIP 2935 en la primera red de desarrollo actualizada por Pectra. Después de esta red de desarrollo, acordaron decidir si incluir EOF y/o EIP 7623 en una segunda red de desarrollo de Pectra.
