El EIP-8141 de Ethereum parece estar trazando una nueva dirección, ya que Vitalik Buterin, cofundador de Ethereum, impulsa la propuesta como una forma de mejorar la eficiencia mediante transacciones escalables en la red.

En esencia, la propuesta separa los requisitos para aprobar una transacción de los procesos reales que esta ejecuta. Buterin cree que este enfoque podría permitir que Ethereum procese las transacciones comunes de manera más eficaz sin comprometer la flexibilidad. Lo describió como una de las estrategias para mejorar la escalabilidad de Ethereum preservando la descentralización. El esfuerzo continúa una línea de trabajo más amplia sobre el protocolo: el camino de actualizaciones de Ethereum ha pasado por etapas como el Merge de 2022 hacia prueba de participación y los posteriores hard forks "Dencun" y "Pectra", con la escalabilidad y la reducción del costo de las transacciones como prioridades persistentes en la hoja de ruta de desarrollo de la red.

En una publicación en X del 5 de septiembre de 2026, Buterin escribió:

One positive consequence of all the recent detailed thinking about transaction formats – not just 8141, also "future of state" discussions eg. UTXOs, PBT, keyed nonces, and also recursive STARK mempool – is that we have a much more explicit understanding of how transactions have…

— vitalik.eth (@VitalikButerin) September 5, 2026 (https://x.com/VitalikButerin/status/2096378061377900881)

El EIP de Ethereum separa las dependencias de las transacciones de las acciones

Buterin divide el proceso de ejecución de las transacciones en dos componentes principales: dependencias y acciones.

Las dependencias son los requisitos que deben cumplirse para que una transacción se considere válida. Estos incluyen la firma de transacciones, la verificación mediante un árbol de Merkle, el uso de ZK-SNARKs o STARKs, entre otras comprobaciones.

Las acciones son las operaciones que se realizan una vez verificadas todas las condiciones previas. Incluyen el envío de ETH, la llamada a contratos inteligentes y la modificación de información en la blockchain.

Con el método del EIP-8141, algunas comprobaciones de dependencias podrían ejecutarse de forma concurrente, en lugar de que cada cliente procese cada comprobación de manera secuencial. Otras comprobaciones de dependencias incluso podrían realizarse mientras la transacción espera en el mempool, antes de ser incluida en un bloque.

Las dependencias de estado siguen siendo más complejas, ya que transacciones previas pueden alterar los saldos y otros datos de la blockchain. Sin embargo, los mempools podrían gestionar estas comprobaciones de dependencias con mayor eficacia si las transacciones especifican qué estado requieren.

Buterin ha estimado que más del 90% de las transacciones en la red Ethereum no necesitan plena flexibilidad de ejecución. Señaló que esta cifra es una estimación propia y no una métrica medida de la red.

Un diseño de Frame Transaction

El EIP-8141 introduce un nuevo tipo de transacción denominada Frame Transaction. El diseño del marco separa las llamadas a contratos para autorizaciones, pagos de tarifas y operaciones del usuario.

El diseño permitiría que el código de la cuenta autorice una transacción y pague las tarifas, en lugar de depender del mecanismo tradicional de firma. Entre las funciones posibles que habilitaría este marco se incluyen el patrocinio de tarifas, el pago de tarifas con tokens, la rotación de claves y las transacciones agrupadas. Estas capacidades reflejan objetivos asociados desde hace tiempo a la abstracción de cuentas, un tema de diseño que Ethereum ya ha explorado mediante esfuerzos separados como el EIP-4337, que introdujo un mempool para "UserOperations" sin modificar el protocolo central; el EIP-8141, en cambio, actúa directamente en el nivel del formato de transacción.

La verificación sería el primer paso, determinando si la transacción está autenticada. Después, otros marcos podrían encargarse del pago de la tarifa y de la ejecución de las acciones especificadas.

El formato propuesto es relativamente sencillo e implica llamadas a contratos, indicadores (flags), origen e información de nonce. El mismo formato también podría ser adoptado por otras redes construidas sobre el modelo EVM.

Quedan preguntas abiertas

El EIP-8141 aún se encuentra en fase de borrador como propuesta Core, lo que significa que cualquier aspecto de su tecnología podría cambiar durante el desarrollo. Las Propuestas de Mejora de Ethereum en fase de borrador deben superar la revisión de los desarrolladores principales de Ethereum y ser programadas en una futura actualización de red antes de su activación, un proceso que históricamente tarda de meses a años y puede derivar en propuestas revisadas o descartadas por completo. La arquitectura actual abarca la entrada al mempool, la ejecución de marcos, los recibos, las firmas, el gas y la propagación de transacciones. Los desarrolladores trabajan en cuestiones de denegación de servicio, reemplazo de transacciones, modificación de billeteras, construcción de bloques y RPCs.

Otro tema pendiente es el número máximo de Frame Transactions que pueden recibirse de un solo remitente. Se han planteado dudas sobre las posibles consecuencias de este límite para los usuarios que necesitan realizar varias transacciones dentro de un mismo bloque.

Estas cuestiones indican que el EIP-8141 todavía enfrenta obstáculos técnicos antes de poder formar parte del protocolo de Ethereum.

Desde la perspectiva de Buterin, la propuesta vincula la abstracción de cuentas con los planes futuros de escalabilidad de Ethereum. El EIP-8141 no reemplaza las cuentas de Ethereum; en cambio, hace que las plantillas de transacción sean predecibles. Si el desarrollo continúa, la propuesta podría desempeñar un papel integral en la estrategia de Ethereum para la escalabilidad, la abstracción de cuentas y una mayor eficiencia transaccional.