Ethereum Mainnet enfrenta nuevos desafíos: la propuesta EIP-7983 genera discusión

Ante el contexto de la ineficiencia en la ejecución y la presión en la gestión de recursos en la red principal de Ethereum, una nueva propuesta ha entrado en la fase de discusión de la comunidad. Esta propuesta aboga por establecer un límite rígido de gas para cada transacción, concretamente de 16,777,216 gas (es decir, 2²⁴), para mejorar la estabilidad y la eficiencia de ejecución de la red.

Esta idea ya ha sido explorada en algunas propuestas anteriores, donde los desarrolladores intentaron introducir límites de recursos para sentar las bases del desarrollo modular y la optimización del rendimiento de Ethereum.

Introducción a la propuesta EIP-7983

Actualmente, Ethereum permite que una sola transacción utilice teóricamente todo el gas de un bloque. Aunque este diseño es flexible, puede dar lugar a problemas como la concentración de recursos y la carga desigual de nodos durante la ejecución de la transacción, lo que afecta al rendimiento general. La nueva propuesta tiene como objetivo limitar la cantidad máxima de gas utilizada por una sola transacción para evitar que una sola transacción consuma demasiados recursos de la red. Con un límite rígido establecido en 16,777,216 gas, las transacciones que excedan este límite serán rechazadas durante la validación del bloque.

La idea central de esta propuesta es establecer un límite, forzando la división de algunas transacciones de gran tamaño, para evitar que una única transacción consuma demasiados recursos. Esta restricción no cambiará la capacidad total de gas del bloque, no involucra modificaciones a las reglas de consenso, y solo introduce una condición de restricción durante el proceso de ejecución de la transacción. Con base en esto, si una transacción excede este límite antes de entrar en el bloque, será rechazada en la fase de verificación.

Para entornos de ejecución que dependen de la computación paralela, como las máquinas virtuales de conocimiento cero y los futuros modelos de ejecución multihilo, esta limitación ayuda a evitar que transacciones extremas ralenticen todo el proceso de procesamiento de bloques. En la lógica de la capa de ejecución, esta limitación se asemeja más a una "norma de uso de recursos", lo que permite que cada transacción se divida de manera más uniforme bajo la premisa de que el volumen total se mantenga constante, facilitando así la programación y ejecución general de la red.

Efectos reales y problemas potenciales

Establecer un límite de gas para transacciones individuales, la nueva propuesta busca reducir el riesgo de denegación de servicio causado por transacciones extremas, al mismo tiempo que mejora la previsibilidad del proceso de ejecución en general. Para el entorno de ejecución, esta limitación ayuda a simplificar la lógica de ejecución de los validadores y a aliviar la presión derivada de la concentración del consumo de recursos.

Esta propuesta tiene cierta correspondencia con la arquitectura modular que Ethereum está promoviendo, la integración de zkVM y la ruta de escalado L2. Dado que las transacciones grandes se ven obligadas a dividirse, este diseño tiene como objetivo mejorar la adaptabilidad de la capa base de Ethereum al procesamiento paralelo, brindando apoyo adicional a la arquitectura de computación multi-capa. Desde el punto de vista de la implementación, la nueva propuesta no implica cambios en las reglas de consenso o en la capa de protocolo, y el principal impacto radica en que los clientes, billeteras y herramientas de desarrollo necesitan actualizar la construcción de transacciones y la forma de mostrar interfaces para adaptarse a la nueva lógica de restricciones.

La restricción en la capa de ejecución de esta propuesta ha generado cierta discusión. Algunas aplicaciones avanzadas, como el despliegue de contratos y operaciones DeFi complejas, pueden necesitar dividir las transacciones adicionales, lo que lleva a un aumento en la complejidad de la interacción del usuario. Además, las diferencias en la forma en que diferentes plataformas muestran y manejan el gas pueden generar costos de comprensión y uso inconsistente en las etapas iniciales. Más importante aún, el ataque de denegación de servicio que esta propuesta busca abordar ocurre principalmente en la fase de ejecución de transacciones, y no está directamente relacionado con el comportamiento de manipulación de clasificación mediante transacciones de alto gas en la memoria. Por lo tanto, se inclina más hacia la limitación de la sobrecarga de recursos en el lado del nodo, en lugar de atacar todas las formas de ataques en la red.

En general, la nueva propuesta tiene un significado práctico en la mejora de la estabilidad de la ejecución de nodos y en el apoyo a la futura arquitectura paralela, pero su rango de restricción es limitado y aún necesita combinarse con otros mecanismos para abordar los problemas de seguridad de la red en un sentido amplio.

Reacción de la comunidad

En torno a esta propuesta, existen diferentes opiniones en la comunidad. Los partidarios creen que establecer un límite de gas para las transacciones está en línea con la dirección de desarrollo sencillo, seguro y modular de Ethereum, y ayuda a mejorar el rendimiento de la red y la experiencia del usuario, especialmente en un entorno donde zkVM y las soluciones L2 están madurando gradualmente. Los opositores, por otro lado, se preocupan por la complejidad y los riesgos de compatibilidad que trae la división de transacciones, y señalan que los problemas de la red provienen más del diseño de contratos inteligentes que de las limitaciones de gas de las transacciones.

Resumen

La nueva propuesta refleja la preocupación de la comunidad por la estabilidad de la red y la eficiencia en la ejecución. Esta propuesta presenta desafíos y discrepancias, pero ofrece una posible solución para la capacidad de ejecución y escalado de la capa base de Ethereum. Teniendo en cuenta la dirección actual de escalado multicapa y desarrollo modular de Ethereum, esta propuesta tiene cierto valor práctico, pero su efecto final debe evaluarse según la adopción por parte de la comunidad y los resultados de la implementación.