Resumen de la última reunión de desarrolladores del núcleo de Ethereum: EIP-7702 incorpora dudas, conversión del método de serialización de la capa de ejecución

**Escrito por: Christine Kim

Recopilación: Luccy, BlockBeats

Además de prepararse para la vela con mecha larga Pectra Devnet 0, los desarrolladores discutieron nuevas propuestas de EIP, discusión y análisis de EIP existentes y análisis de impacto de contratos inteligentes y transacciones. Entre ellos, la discusión de EIP 7702 atrajo mucha atención de los asistentes, y la propuesta fue vista como un posible reemplazo de EIP 3074.

Christine Kim, VP de Investigación de Galaxy Digital, dio una nota detallada sobre los aspectos más destacados de la reunión, que BlockBeasts compiló de la siguiente manera:

El 9 de mayo de 2024, los desarrolladores de Ethereum se reunieron en Zoom para la sesión de llamada # 187 de All Core Developers ution (ACDE). La conferencia telefónica ACDE es una serie de reuniones quincenales dirigidas por Tim Beiko, Jefe de Soporte de protocolo de la Fundación Ethereum, donde los desarrolladores discuten y coordinan los cambios en la capa de ejecución (EL) de Ethereum. Esta semana, los desarrolladores discutieron los preparativos para Pectra Devnet 0, las actualizaciones de la implementación de EIP 3074 y la urgencia de convertir los métodos de serialización en EL de MPT a SSZ.

Actualización de Pectra Devnet-0

Barnabas Busa, ingeniero de operaciones de desarrollo de la Fundación Ethereum, dijo que su equipo está probando la configuración del cliente de la primera red de prueba centrada en el desarrollador de Pectra y trabajará para garantizar una configuración estable de Pectra Devnet 0 para el lunes 13 de mayo. Según el rastreador de preparación de Pectra Devnet 0, los equipos de clientes de Geth, Nethermind y EthereumJS han implementado completamente la especificación de código de Pectra.

Durante la llamada, Justine Florentine, desarrolladora de Besu, dijo que todos los EIP de Pectra se han implementado en Besu, pero que su equipo todavía está trabajando en la depuración del código. Andrew Ashikhmin, el desarrollador de Erigon, dijo que su equipo ya ha comenzado a procesar todos los EIP excepto EIP 7002, que son retiros activables EL. El equipo de Reth publicó un enlace a su rastreador de implementación en un chat de Zoom, mostrando que su trabajo en EIP 7002 aún está pendiente, al igual que el equipo de Erigon.

En el lado del cliente CL, el desarrollador de Grandine, Saulius Grigatis, dijo que todos los EIP habían sido implementados, pero al ejecutarse con el cliente EL, su equipo se encontró con algunos errores. Los representantes del equipo de Lighthouse dijeron que estaban cerca de tener una implementación completa lista para Pectra Devnet 0 y señalaron que la especificación en la API del motor necesitaba actualizarse. Mikhail Kalinin, un desarrollador de Teku, dijo que está trabajando para agregar estas actualizaciones a la especificación de la API del motor.

Mario Vegas del equipo de pruebas de EF dijo que los desarrolladores están trabajando para agregar casos de prueba para EIP 3074, AUTH y AUTHCALL Código de operación, y varios otros EIP.

Actualización EIP-3074

Aunque los desarrolladores han acordado mantener EIP 3074 en la especificación de Pectra Devnet 0, se ha discutido un EIP alternativo para reemplazarlo, EIP 7702. El desarrollador de Geth, “Lightclient”, resumió la última sesión de trabajo en EIP 3074, en la que los participantes discutieron qué cambios priorizar en la actualización de Pectra están relacionados con la mejora del control del usuario cuenta Programabilidad. Según Lightclient, todos los participantes estuvieron de acuerdo en que la abstracción de cuentas nativa completa aún está a unos años de implementarse en Ethereum. Sin embargo, existe desacuerdo en cuanto a si esto significa priorizar los cambios en las cuenta de propiedad externa (EOA) o migrar las EOA a contratos inteligentes Billetera. El 8 de mayo, el día antes de esta convocatoria de ACDE, Ethereum cofundador Vitalik Buterin propuso una nueva EIP, EIP 7702, que permitirá a Ethereum soporte un nuevo tipo de transacción para permitir que las EOA operen como contratos inteligentes Billetera durante una sola transacción. Según Lightclient, los participantes de las sesiones de trabajo de EIP 3074 fueron generalmente positivos sobre EIP 7702. Sin embargo, más tarde agregó que todavía hay detalles importantes que resolver sobre EIP 7702. Por ejemplo, los detalles sobre cómo se revierten las transacciones EIP 7702 y cómo escalar el costo de gas para dichas transacciones siguen sin estar claros.

Si EIP 7702 es aceptado e incluido en la actualización de Pectra, se considerará como un reemplazo para EIP 3074 porque EIP 7702 logra resultados similares a EIP 3074 pero no crea nuevos códigos de operación en Ethereum y mejora la facilidad del análisis estático del nuevo comportamiento de EOA. El investigador de EF Ansgar Dietrichs sugirió en un chat de Zoom que EIP 7702 se considere para su inclusión en Pectra y que se tome una decisión formal sobre si reemplazar EIP 3074 con 7702 en aproximadamente 2 a 4 semanas. Quedó claro a partir de la discusión de los desarrolladores sobre EIP 7702 en la conferencia telefónica que se necesitaba más trabajo antes de que la propuesta pudiera considerarse lista para su implementación. El desarrollador de Nethermind, Ahmad Mazen Bitar, señaló que el trabajo ya realizado para EIP 3074 no puede reutilizarse para implementar 7702. Beiko confirmó que los desarrolladores aún deben seguir adelante con la implementación de EIP 3074 para Devnet 0 y revisar la especificación Devnet-1 más adelante.

EIP-7685, SSZ y EIP-6110

Luego, los desarrolladores discutieron algunas de las preocupaciones planteadas por el desarrollador de Nimbus, Etan Kissling, sobre EIP 7685, a saber, solicitudes genéricas de capa de ejecución. En un comentario de GitHub bajo la agenda de la conferencia telefónica de esta semana, Kissling preguntó si era necesario un diseño propuesto para una solicitud de capa de ejecución común, y si esta oportunidad podría aprovecharse mejor para cambiar a SSZ, un formato de serialización que los desarrolladores han querido actualizar en la capa de ejecución desde la actualización de Merge. El equipo de cliente de capa de ejecución más largo en la llamada de conferencia admite mantener EIP 7685 en Pectra, y si hay algún obstáculo para incluir EIP en funcionamiento, como la sincronización optimista de los clientes, vuelva a revisar el diseño.

En cuanto al tema de SSZ, Kissling explicó que el nuevo formato de diseño para la solicitud de Common Execution Layer se basa en los formatos de serialización tradicionales MPT y RLP, por lo que tendrá que actualizarse cuando los desarrolladores hagan la transición a SSZ. Señala que si los desarrolladores continúan creando nuevas estructuras de datos MPT / RLP, retrasar el cambio a SSZ solo resultará en más trabajo largo para los desarrolladores. Sin embargo, no había un soporte sólido del equipo del cliente de ejecución para incluir EIP 7495, el contenedor estable de SSZ, en Pectra. Un desarrollador llamado “Dustin” escribió en un chat de Zoom que la decisión de posponer la transición a SSZ era “una locura” y que el problema de que la biblioteca SSZ funcionara mal en EL era “un problema grave”.

Con respecto a EIP 6110, el validador de suministro on-chain que deposita, Kissling hizo preguntas sobre depositar pedidos. Kalinin dijo que está de acuerdo en que el tema es “una preocupación importante” y que trabajará con los principales grupos de participación para investigar más a fondo.

Actualización de EOF

Danno Ferrin, desarrollador Ethereum protocolo independiente, y Alex Beregszaszi, jefe de investigación de EF Solidity, comparten actualizaciones sobre los esfuerzos de implementación de EOF. El trasfondo es que EOF es una serie de cambios de código para mejorar el EVM Máquina virtual (EVM) que los desarrolladores están considerando para su inclusión en la actualización de Pectra. Se ha finalizado el meta-EIP del EOF. Los desarrolladores también han simplificado el proceso de creación de transacciones en el EOF y están trabajando en una implementación del lado del cliente del EOF.

Actualización EIP-7623

Un desarrollador que usó el nombre de pantalla “William Morris” en la conferencia telefónica expresó su preocupación por el cambio en el costo de gas del almacenamiento de datos de llamadas en EIP 7623. Explicó que los cambios permitirán a algunos usuarios realizar transacciones abandonando sus transacciones para reducir las tarifas, fomentando la creación de un mercado secundario para descuentos de gas para que los rollups de segundo nivel (L2) y otros participantes puedan realizar transacciones en la red de manera más económica. Recomienda un EIP alternativo, EIP 7703, que aborda estos problemas aumentando el costo de los datos de llamadas a una tarifa plana.

Buterin dijo que si bien las preocupaciones de Morris son legítimas, la probabilidad de crear un mercado secundario para los datos de llamadas como resultado de EIP 7623 no es alta, ya que el número de usuarios que elijan participar en dicho mercado será extremadamente limitado. Buterin señaló que los principales actores afectados por EIP 7623 son el equipo de desarrollo de capa 2, Starkware y los creadores de inscripciones. Agregó que, si bien el mercado total direccionable para el mercado secundario de datos de llamadas es pequeño, el pump coro superior de limitar el tamaño máximo de bloque a través de los datos de llamadas es extremadamente alto, ya que permite a los desarrolladores aumentar el límite de blobgas y, por lo tanto, extender Ethereum capacidad para soporte L2. Vitalik también dijo que aplanar el costo de los datos de llamadas también tendría un impacto más severo en L2 y otras partes interesadas que el EIP actual, como sugirió Morris. Buterin compartió pensamientos anhelantes sobre los precios del gas blob en una publicación de blog antes de la llamada.

El coautor de EIP 7623, Toni Wahrstätter, está de acuerdo con Buterin, diciendo que cree que desde el punto de vista de la utilidad, la L2 más larga no crea un mercado secundario para los datos de llamadas. “Desde un punto de vista práctico, esto no es muy factible, sobre todo teniendo en cuenta que un mercado de este tipo requiere confianza y un alto grado de coordinación entre los participantes. Imagine que, como L2, desea publicar sus datos en L1, pero no sabe qué dirección publicará los datos y dónde terminarán los datos. Desde el punto de vista de la utilidad, debe personalizar el índice, etc. Por lo tanto, no creo que sea muy factible”, dice Wahrstätter.

El desarrollador de Reth, Georgios Konstantopoulos, preguntó si los desarrolladores están estudiando la posibilidad de aumentar los límites de blobgas si EIP 7623 se incluye en Pectra. Sin aumentar el límite de gas de la burbuja a medida que aumenta el EIP 7623, Konstantopoulos dice que el EIP “no resuelve el anhelo del problema”. El investigador de EF Dankrad Feist sugiere aumentar el límite de gas de blob hasta el punto en que el tamaño máximo de bloque de Ethereum siga siendo el mismo, lo que significa que los cortos liberados a medida que aumenta el costo de los datos de llamadas se llenarán con blobs (objetos binarios grandes). El investigador de EF Ansgar Dietrichs dijo que el EIP es útil no solo cuando se combina con un aumento en los límites de gas de blobs, sino también desde una perspectiva de seguridad, ya que puede garantizar que la red no se desestabilice por bloques que contienen el mayor número de transacciones y blobs.

En cuanto al análisis del impacto de EIP 7623 en contratos inteligentes y transacciones, Wahrstätter dijo que su propuesta no afectaría al 98% de los usuarios. Beiko también mencionó que Parithosh Jayanthi, ingeniero de operaciones de desarrollo de EF, puede estar haciendo un análisis más profundo de qué tan específico será el límite de blobgas, teniendo en cuenta cuenta EIP 7623.

Nuevo reemplazo para EIP 7609

Durante la llamada, un desarrollador con el nombre de usuario “Charles C” propuso un nuevo EIP para evitar ataques de reentrada en contratos inteligentes. Charles dijo que la propuesta, que crea dos nuevos códigos de operación para asegurar los contratos inteligentes, es una alternativa a una propuesta que presentó anteriormente llamada EIP 7609, que tiene como objetivo reducir el costo base de TLOAD / TSTORE en Pectra. Charles dijo que no estaba seguro de por qué EIP 7609 no estaba siendo considerado para Pectra y todavía estaba recopilando comentarios de los desarrolladores sobre cómo prevenir la reentrada de una manera rentable. Señala que las soluciones actuales, como Reentrancy Guard de OpenZeppelin y el código de operación TLOAD / TSTORE, son demasiado caras para que los desarrolladores de aplicaciones descentralizadas las usen de forma predeterminada. Beiko sugirió que los desarrolladores dieran su opinión a Charles sobre este nuevo EIP en el Ethereum Magician Forum.