Crypto Currency

Ethereum Fusaka Hard Fork establecido para finales de 2025 con cambios importantes de EVM

xxtac3 hours ago011 mins

Se espera que Fusaka Hard Fork de Ethereum tenga lugar en el tercer o cuarto trimestre de este año, según un funcionario de la Fundación Ethereum.

En un puesto del 28 de abril X, el director ejecutivo de la Fundación Ethereum, Tomasz Kajetan Stańczak, dijo que la organización tiene como objetivo implementar la actualización de la red Fusaka Ethereum en el tercer trimestre o el cuarto trimestre de 2025. Aún así, el horario exacto de implementación aún no se ha decidido.

Los comentarios vienen en medio de controversias sobre la próxima implementación de la actualización del formato de objeto EVM (EOF) para la máquina virtual Ethereum (EVM). Como señaló Stańczak, se espera que EOF sea parte de la actualización de la red Fusaka.

El EVM es el software que ejecuta contratos de Ethereum Smart. EOF implementaría una serie de cambios en el protocolo, conocidas como propuestas de mejora de Ethereum (EIP), con profundas implicaciones sobre cómo funciona. EOF introduce un formato de contenedor extensible y versionado para el bytecodo de contrato inteligente que se verifica una vez en la implementación, separando el código y los datos para obtener ganancias de eficiencia.

Relacionado: El investigador propone escalar el límite de gas Ethereum en 100 veces durante 4 años

Envolver, sellar una vez, enviar

Bytecode es un conjunto de instrucciones compacto de bajo nivel. Los contratos inteligentes de solidez deben compilarse en ByTecode antes de que el EVM pueda ejecutarlos.

EOF define un módulo de contenedor para el bytecodo Smart Contract, reemplazando las manchas de bytos de forma libre de hoy con una estructura mejor definida. Estos objetos estarían compuestos de:

Un encabezado que comienza con el valor hexadecimal 0xef00, seguido de un número de versión de un byte para garantizar la actualización.
Una tabla de sección, que proporciona metadatos sobre el contenido del contenedor. Cada entrada comprende una configuración de byte para el tipo de entrada y dos bytes para el tamaño de la entrada.
Secciones con el contenido real, con al menos una sección de código y cualquier sección de datos necesaria: se podrían agregar más tipos de secciones a través de EIP futuros.

Esta estructura optimiza la operación EVM, lo que permite una mayor eficiencia y un mayor procesamiento de sobrecarga. Esta actualización daría como resultado un entorno de desarrollador más limpio y más fácil de entender los contratos inteligentes implementados.

¡No saltes, rjump en su lugar!

EIP-4200, uno de los EIP EOF, proporciona una alternativa a las instrucciones Jump y Jumpi, que permiten al programa mover la ejecución a cualquier desplazamiento de bytes arbitrario. Este tipo de cadena de ejecución conduce a errores difíciles de hacer (el valor de salto es incorrecto en algunos casos puede no ser fácil de predecir) y facilita la ocultación de malware en manchas de datos y mover el puntero de ejecución allí.

Esta práctica se conoce como salto dinámico, y EIP-4750 (bajo revisión) propone rechazar el salto/salto dinámico dentro de los contratos inteligentes EOF, rechazándolos por completo durante una fase posterior de implementación de EOF. En su forma actual, este EIP los reemplaza con las llamadas de función de la función de llamada (Callf) y returación de la función (RETF). Esas nuevas instrucciones asegurarían que los destinos estén codificados en el código de bytes, pero el heredado pre-EOF contratos inteligentes no se vería afectado.

Los desarrolladores que optan por usar Jump o Jumpi después de la actualización hará que su bytecode pase por la validación del tiempo de implementación, lo que asegura que nunca puedan saltar a los datos o en la mitad de otra instrucción. Esta verificación se llevaría a cabo a través de reglas de validación de código EIP-3670, más la tabla de salto (EIP-3690), por lo que se verifica cada destino.

Como alternativa a esas funciones, EOF implementa RJUMP y RJUMPI, que requieren que el destino sea codificado en el código de bytes. Aún así, no todos están a bordo con la implementación de EOF.

Relacionado: Los miembros de la comunidad de Ethereum proponen una nueva estructura de tarifas para la capa de aplicaciones

EOF tiene sus enemigos

EOF es la implementación de 12 EIP con profundas implicaciones sobre cómo funcionan los desarrolladores de contratos inteligentes. Sus partidarios argumentan que es eficiente, más elegante y permite actualizaciones más fáciles en el futuro.

Aún así, sus detractores argumentan que está en exceso e introduce una mayor complejidad en un sistema ya complejo como Ethereum. El desarrollador de Ethereum, Pascal Caversaccio, se lamentó en una publicación de Magos de Ethereum del 13 de marzo de que “EOF es extremadamente complejo”, ya que agrega dos nuevas semánticas y elimina y agrega más de una docena de códigos opcodios. Además, argumentó que no es necesario.

Dijo que todos los beneficios podrían introducirse en “actualizaciones más fragmentarias y menos invasivas”. Agregó que el Legacy EVM también necesitaría mantenerse, “probablemente indefinidamente”.

Caversaccio también explicó que EOF requeriría una actualización de herramientas, lo que corre el riesgo de introducir nuevas vulnerabilidades debido a su gran superficie de ataque. Además, dijo, “los contratos de EVM se vuelven mucho más complicados debido a los encabezados”, mientras que actualmente los contratos vacíos pesan solo 15 bytes. Otro desarrollador planteó un punto separado en el hilo:

“Quizás como meta punto, parece haber un desacuerdo sobre si los principales cambios de EVM son deseables en general. Una VM estable, en la que las personas pueden invertir en construir excelentes herramientas y aplicaciones con confianza, es mucho más valioso”.

Caversaccio parece estar en buena compañía en su oposición al EOF. Una encuesta dedicada en la plataforma de votación Ethereum Ethpulse muestra que 39 votantes que tienen un total de casi 17,745 Ether (ETH) se oponen a la actualización. Solo siete tenedores de menos de 300 ETH votaron a favor.