Desarrolladores de Ethereum recientemente revelaron nuevos avances en el diseño de EIP-8141. Esta propuesta intenta implementar ciertas funciones de transacción como llamadas a contratos programables, denominadas "frames", en lugar de modificar el formato de envoltura de transacciones de Ethereum cada vez que se añade una nueva funcionalidad.
La función de trading se ha cambiado a llamadas programables
Las funciones cubiertas por este enfoque incluyen la expiración de transacciones, la firma agregada, las raíces Merkle relacionadas con pools de privacidad y la verificación de aserciones tras la ejecución de la transacción. Los desarrolladores consideran que, si esta interfaz es lo suficientemente general, cuando Ethereum introduzca nuevos métodos de validación en el futuro, las billeteras, navegadores, dispositivos de firma y Layer 2 no necesitarán adaptarse a nuevos envoltorios de transacción cada vez.
El borrador de EIP-8141 define una Frame Transaction como una secuencia de llamadas a contratos. Diferentes frames pueden encargarse de verificar las condiciones de la transacción, aprobar el pago de gas o ejecutar operaciones del usuario.
Actualmente, el borrador enumera tres modos: DEFAULT, VERIFY y SENDER. El frame VERIFY se utiliza para verificar si se cumple una condición, mientras que el frame SENDER representa la ejecución de una operación en nombre del remitente de la transacción. Varios frames pueden agruparse en un lote atómico, que debe completarse completamente o revertirse en su totalidad.
Reducir los costos de coordinación de billeteras e infraestructura
La visión central del desarrollador Derek Chiang es que las nuevas funciones futuras no necesitan necesariamente diseñar un nuevo conjunto de envolturas de operaciones; solo es necesario expresarlas mediante nuevos objetivos de frame y patrones de llamada para ampliar la capacidad, manteniendo estable la estructura básica.
Cada modificación en el empaquetado de transacciones de Ethereum no afecta solo a los clientes de ejecución. Billeteras, Layer 2, exploradores de bloques, dispositivos de firma, bibliotecas de software y diversos proveedores de infraestructura deben comprender y admitir el nuevo formato.
Chiang indicó que la actualización de Ethereum ocurre aproximadamente cada nueve meses, y que cambiar con frecuencia el empaquetado de transacciones conlleva costos de coordinación elevados. En comparación, si el formato frame se convierte en una interfaz más estable, los nuevos métodos de validación podrían delegarse más a contratos o componentes de protocolo designados.
Sin embargo, esto no significa que todas las funciones futuras puedan evadir actualizaciones de red. EIP-8141 aún modificará las reglas de consenso de Ethereum y requerirá implementación en los clientes. Si involucra nuevos opcodes, contratos precompilados o reglas de gas, aún podría requerir un hard fork.
EIP-8130 y la dirección de validación paralela
Los desarrolladores también reconocen que, con el aumento del nivel de abstracción de las transacciones, será más difícil para las billeteras y los ordenadores analizar las transacciones antes de su ejecución. Para ello, el equipo está investigando cómo combinar EIP-8141 con otro borrador de abstracción de cuenta, EIP-8130.
EIP-8130 propone una estructura de keystore en cadena que permite registrar previamente participantes y contratos de autenticación, y especificar claramente el método de autenticación en las transacciones. De esta manera, los nodos pueden determinar previamente qué proceso de validación requiere una transacción antes de ejecutar cualquier código de billetera. Para Layer 2, esto ayuda a limitar las opciones de autenticación a un conjunto de métodos con costos más predecibles.
Vitalik Buterin también explicó la dirección relacionada en otra publicación. Dividió las transacciones en dos partes: "acciones" y "condiciones de dependencia". Las primeras se encargan de modificar el estado de Ethereum, mientras que las segundas incluyen condiciones previas como firmas, pruebas Merkle o pruebas de conocimiento cero. Si estas dependencias son independientes entre sí, en el futuro podrían verificarse en paralelo, reduciendo así el costo de procesamiento de ciertas transacciones.
Listado en Hegotá, pero la hora de activación no está definida
El EIP oficial de Hegotá Meta ha incluido las Frame Transactions como uno de los upgrades planificados, lo que significa que su estado ha avanzado respecto a antes. Sin embargo, el EIP-8141 sigue siendo un borrador principal y los detalles técnicos aún no se han definido definitivamente.
Los trabajos pendientes incluyen: actualizar las especificaciones, completar la implementación del cliente de ejecución, establecer la red de desarrollo y realizar pruebas de interoperabilidad con billeteras y sistemas de Layer 2. Los desarrolladores también deben evaluar los riesgos de denegación de servicio en la memoria pool, ya que la verificación programable podría aumentar el costo computacional para filtrar transacciones inválidas.
Actualmente, los tiempos de activación de Hegotá en Sepolia, Hoodi y la red principal aún están en blanco. EIP-8141 ya está incluido en el plan de actualización, pero aún falta un proceso de implementación y prueba antes de su lanzamiento final.