El cofundador de Ethereum, Vitalik Buterin, presentó el 6 de septiembre un modelo de transacción a largo plazo que podría permitir a la red procesar parte del trabajo de validación en paralelo.
Su propuesta separa los efectos producidos por las transacciones de las condiciones que deben cumplirse antes de que esos efectos puedan ocurrir.
Buterin describió los dos componentes como “acciones” y “dependencias” en una publicación detallada. Las acciones cambian el estado de Ethereum, como transferir ETH o llamar a un contrato. Las dependencias cubren la información necesaria para establecer que una transacción es válida.
Una firma digital es un ejemplo de dependencia. Otros ejemplos incluyen pruebas de Merkle que muestran que existe una salida no gastada, pruebas de conocimiento cero y condiciones de estado que deben seguir siendo verdaderas cuando una transacción entra en un bloque.
Buterin argumentó que hacer explícita esta distinción podría ayudar a Ethereum a escalar sin abandonar su entorno de ejecución flexible. Sin embargo, la propuesta sigue siendo parte de una investigación de protocolo continua. Los desarrolladores de Ethereum no han aprobado el diseño completo para su implementación.
Las transacciones de Ethereum actualmente combinan la autorización, el pago de tarifas y la ejecución dentro de un flujo de procesamiento común. Los nodos verifican si una transacción está correctamente firmada, si el remitente puede pagarla y si sus instrucciones se ejecutan correctamente.
Algunas de estas verificaciones no dependen de los cambios de estado finales de la transacción. Buterin dijo que tales dependencias podrían procesarse por separado y, en muchos casos, simultáneamente.
Por ejemplo, un validador puede necesitar confirmar una firma antes de aceptar una transacción. Esa verificación no necesita necesariamente esperar a firmas no relacionadas adjuntas a otras transacciones. Si se conocen de antemano múltiples verificaciones independientes, los clientes pueden distribuir el trabajo entre los recursos de procesamiento disponibles.
Las verificaciones dependientes del estado requieren mayor cuidado. Una condición ligada al saldo de una cuenta o a una ranura de almacenamiento puede volverse inválida si una transacción anterior cambia el mismo estado. Buterin dijo que los mempools podrían razonar sobre estas condiciones de manera más efectiva cuando las transacciones declaran qué partes del estado acceden.
El enfoque recompensaría las transacciones predecibles. Las operaciones que especifican claramente sus dependencias podrían recibir menores costos de gas porque los clientes podrían verificarlas de manera más eficiente. Las transacciones que requieren llamadas dinámicas y acceso impredecible al estado seguirían siendo posibles, pero podrían costar más.
Buterin estimó que más del 90% de la actividad de Ethereum por volumen no requiere el nivel completo de flexibilidad dinámica de la red. Esa cifra es su evaluación, no una medición de red publicada dentro del post. El argumento más amplio es que las transferencias comunes y las interacciones rutinarias con contratos podrían usar formatos más restrictivos sin limitar las aplicaciones especializadas.
El modelo propuesto preservaría el sistema de cuentas flexible de Ethereum para las transacciones que lo necesiten. Una actividad más predecible podría usar estructuras analizables estáticamente que se asemejan a partes del modelo de transacciones de Bitcoin.
Bitcoin utiliza un modelo de salida de transacción no gastada (UTXO) en el que una transacción identifica las salidas que pretende gastar. Ethereum normalmente utiliza cuentas con saldos, nonces y almacenamiento de contratos programable. Buterin no propone que Ethereum reemplace su modelo de cuentas con la arquitectura de Bitcoin. Describió un espectro que combina ideas de ambos sistemas.
EIP-8141 es una propuesta de mejora de Ethereum (EIP) en borrador para un nuevo tipo de transacción conocida como Transacción de Marco (Frame Transaction). Divide una transacción en marcos de llamada de contrato que pueden validar la autoridad, aprobar el pago de gas y realizar operaciones de usuario.
La propuesta oficial dice que la validez de la transacción y el pago de la tarifa ya no dependerían únicamente de una firma estándar adjunta a la transacción externa. El código de la cuenta podría definir en su lugar las reglas necesarias de autorización y pago.
Las Transacciones de Marco podrían admitir tarifas patrocinadas, pagos en tokens distintos de ETH, rotación de claves y lotes de transacciones. También podrían permitir que las cuentas de propiedad externa (EOA) reciban características de abstracción de cuenta sin depender de la misma implementación de contrato en cada red compatible.
Bajo la estructura propuesta, los marcos de verificación determinarían si el remitente autorizó la transacción. Marcos separados podrían establecer quién paga las tarifas y luego ejecutar las operaciones solicitadas.
Esta estructura se alinea con la división de Buterin entre dependencias y acciones. Los marcos de verificación manejan las condiciones que deben cumplirse. Los marcos del remitente manejan las operaciones que alteran el estado.
El formato también podría mejorar la interoperabilidad entre las redes de la Máquina Virtual de Ethereum. Diferentes cadenas podrían admitir la misma estructura de transacción mínima mientras aplican sus propias herramientas de verificación, precompilaciones o características de cuenta.
Buterin describió el formato potencial como una lista básica de llamadas con indicadores que identifican su función. Una llamada podría marcarse como una dependencia pura, una verificación dependiente del estado o una acción. La transacción también contendría información estándar como su origen y nonce.
EIP-8141 sigue clasificada como una propuesta Core en borrador. Su especificación actual incluye reglas detalladas para la admisión en el mempool, la ejecución de marcos, recibos, firmas, contabilidad de gas y propagación de transacciones. Esos detalles pueden cambiar durante la revisión.
Los desarrolladores de Ethereum también han debatido preocupaciones técnicas. Estas incluyen riesgos de denegación de servicio, reglas de reemplazo de transacciones, cambios en las herramientas, límites de transacciones pendientes y restricciones impuestas a los marcos de verificación.
Una discusión señaló que el mempool público propuesto normalmente mantendría solo una Transacción de Marco pendiente por cada remitente. Los desarrolladores han cuestionado cómo esa regla afectaría a las cuentas que regularmente envían varias transacciones dentro de un bloque.
Otros participantes han examinado si el formato introduce complejidad adicional para las billeteras, los constructores de bloques y las interfaces de llamada a procedimiento remoto de Ethereum. Estas preguntas deben resolverse antes de que los equipos de clientes puedan implementar una especificación estable.
El modelo a largo plazo de Buterin va más allá de EIP-8141. Sugirió que las dependencias que no requieren acceso al estado podrían verificarse una vez en la capa del mempool en lugar de ser repetidas por cada validador.
Una dependencia pura podría incluir una firma criptográfica o una prueba cuya validez no cambia con el estado de Ethereum. Después de verificarla, la red podría reemplazar múltiples piezas de trabajo de verificación con una STARK recursiva que confirme que todas las verificaciones se completaron correctamente.
Una STARK es una prueba criptográfica que permite a una parte demostrar que un cálculo se realizó correctamente. Las pruebas recursivas pueden verificar otras pruebas, lo que permite combinar muchas verificaciones en una tarea de verificación más pequeña.
El mempool propuesto podría agregar firmas de transacciones, pruebas de validez y otras dependencias antes de la ejecución del bloque. Los validadores verificarían entonces la prueba agregada en lugar de repetir independientemente cada cálculo original.
Buterin sugirió que este enfoque también podría reducir la cantidad de datos de verificación colocados en la cadena. Si la prueba recursiva establece que todas las dependencias eran válidas, parte de los datos originales podrían omitirse potencialmente.
Ese resultado no forma parte de la especificación actual de EIP-8141. Requeriría investigación adicional que cubra la generación de pruebas, la coordinación del mempool, la disponibilidad de datos y las protecciones contra la agregación inválida.
El diseño también se relaciona con la preparación de Ethereum para la criptografía post-cuántica. Las firmas resistentes a los cuánticos son generalmente más grandes y más caras de verificar que las firmas ECDSA utilizadas por las cuentas ordinarias de Ethereum.
EIP-8141 podría permitir a las cuentas definir nuevos esquemas de autorización sin esperar a que Ethereum reemplace un único estándar de firma fijo. La agregación recursiva de pruebas podría entonces reducir el costo de verificar grandes firmas post-cuánticas.
EIP-8141 podría ayudar a las cuentas de Ethereum a adoptar la autorización post-cuántica si los sistemas de firma prácticos están disponibles. Eso sigue siendo un camino de seguridad a más largo plazo en lugar de una respuesta inmediata a una amenaza cuántica activa.
Las cuentas de Ethereum usan nonces secuenciales para evitar la repetición de transacciones. Si una cuenta envía las transacciones numeradas 10, 11 y 12, la red normalmente las procesa en ese orden.
La secuencia puede crear un cuello de botella. Si la transacción 10 se atasca o es inválida, las transacciones posteriores de la misma cuenta también pueden esperar, incluso cuando sus operaciones no están relacionadas.
Los nonces con clave darían a una cuenta varias secuencias de nonces independientes. Las transacciones asignadas a diferentes claves podrían proceder sin esperar a que otra secuencia avance.
Esto podría ayudar a las cuentas inteligentes, los sistemas de privacidad y las aplicaciones que envían varias operaciones independientes simultáneamente. Cada flujo de trabajo podría recibir su propio dominio de nonce mientras conserva la protección contra la repetición.
Crypto.news informó anteriormente que los nonces con clave podrían evitar que las transacciones privadas independientes se bloqueen entre sí. La característica es parte de un esfuerzo más amplio para mejorar las transacciones de privacidad, las cuentas flexibles y la resistencia a la censura.
Buterin también conectó el trabajo de transacciones con modelos de estado alternativos, incluidos diseños UTXO nativos y estructuras de estado basadas en pruebas. Estos proyectos exploran si algunos activos u operaciones pueden usar reglas de estado predecibles mientras que los contratos complejos retienen la flexibilidad existente de Ethereum.
El enfoque podría crear varios niveles de procesamiento. Las operaciones simples y declaradas serían más fáciles de analizar y podrían recibir tarifas más bajas. Las llamadas dinámicas a contratos seguirían funcionando, pero consumirían más recursos porque los clientes no pueden preparar su ejecución de la misma manera.
Una tarificación diferenciada de este tipo intentaría alinear las tarifas con las limitaciones de escalado reales creadas por cada transacción. No garantizaría tarifas más bajas para cada usuario o aplicación.
EIP-8141 debe pasar varias etapas antes de que pueda afectar a los usuarios de Ethereum. Los desarrolladores principales primero deben acordar que las Transacciones de Marco ofrecen un camino mejor que los diseños de abstracción de cuenta de la competencia.
La propuesta requeriría entonces implementaciones de clientes, redes de desarrollo, pruebas de interoperabilidad, soporte de billeteras y revisión de seguridad. Los desarrolladores también necesitarían probar cómo las Transacciones de Marco interactúan con los constructores de bloques, los mempools, los mercados de tarifas y los contratos inteligentes existentes.
Discusiones anteriores de desarrolladores consideraron EIP-8141 para la futura actualización Hegotá de Ethereum. Sin embargo, crypto.news informó que las Transacciones de Marco seguían en consideración en lugar de estar formalmente programadas.
FOCIL, una propuesta separada destinada a mejorar la resistencia a la censura a través de listas de inclusión de transacciones, también se ha discutido junto con EIP-8141. Las dos propuestas abordan problemas diferentes. Las Transacciones de Marco se refieren a la autorización y la estructura de ejecución, mientras que FOCIL se refiere a la inclusión de transacciones elegibles en los bloques.
Los desarrolladores han argumentado que usarlas juntas podría proporcionar abstracción de cuenta nativa con una mayor resistencia a la censura. Esa combinación sigue siendo un paquete propuesto, no un compromiso aprobado de la hoja de ruta de Ethereum.
Por lo tanto, los comentarios de Buterin del 6 de septiembre describen una posible dirección para el diseño de transacciones de Ethereum. No anuncian una actualización completada, una fecha de activación o un cambio confirmado en las tarifas de gas de la red principal.
Los próximos hitos verificables serían el apoyo formal de los desarrolladores, la inclusión en un ámbito de actualización e implementaciones funcionales en redes de desarrollo. Hasta entonces, EIP-8141 y los mempools STARK recursivos siguen siendo propuestas activas de investigación e ingeniería.
EIP-8141 propone Transacciones de Marco que dividen la validación, la aprobación de tarifas y la ejecución en marcos de llamada de contrato separados.
Actualmente es una propuesta Core en borrador. Los desarrolladores de Ethereum aún pueden cambiar o rechazar su especificación.
Una acción cambia el estado de Ethereum, como enviar ETH o llamar a un contrato. Una dependencia es una condición que debe ser válida, como una firma o una prueba de estado.
Separarlas podría permitir que las dependencias independientes se procesen simultáneamente antes de que se ejecuten las operaciones que cambian el estado.
Podría hacer que las transacciones predecibles sean más baratas de procesar si los desarrolladores adoptan un precio de gas que recompense las operaciones analizables estáticamente.
No se confirma ninguna reducción de tarifas. Los costos dependerían de la especificación final, la implementación del cliente y las futuras decisiones de actualización.
ETH