Vitalik Buterin propone un modelo de transacción de Ethereum a más largo plazo, cuya idea central es separar el tratamiento de los "acciones" y "dependencias" en las transacciones. Las primeras se encargan de modificar el estado en la cadena, mientras que las segundas sirven para demostrar que la transacción cumple con las condiciones de firma, prueba de estado y validez antes de su ejecución. Según este enfoque, parte del trabajo de validación puede completarse antes de ingresar al bloque, ampliando así el espacio para procesamiento paralelo.
La verificación y ejecución de operaciones se tratarán por separado.
El proceso actual de transacción de Ethereum generalmente agrupa la autorización, el pago de tarifas y la ejecución del contrato en una misma cadena de procesamiento. El nodo debe verificar simultáneamente si la firma es válida, si el remitente puede pagar las tarifas y si la ejecución de la transacción tiene éxito.
Buterin considera que parte de estas verificaciones no dependen de los cambios de estado final y, teóricamente, pueden procesarse por separado. Por ejemplo, las firmas digitales, las pruebas de conocimiento cero o ciertas pruebas de validez que no dependen de cambios de estado en la cadena pueden incluirse en la categoría de "dependencias".
Si las transacciones pueden declarar claramente qué estados accederán, la memoria temporal también podrá determinar más fácilmente qué condiciones serán afectadas por transacciones anteriores y qué verificaciones se pueden completar con anticipación. Esto significa que las transacciones más predecibles podrían obtener una mayor eficiencia de validación.
EIP-8141 aún está en fase de borrador
Correspondiente a esta idea está la propuesta de borrador denominada EIP-8141. Esta propuesta introduce un nuevo tipo de transacción llamado Frame Transaction, que divide una transacción en múltiples marcos de llamada para manejar por separado la autorización y verificación, el pago de tarifas y la ejecución de operaciones del usuario.
Según el diseño del borrador, la validez de la transacción y el pago de tarifas ya no dependen completamente de la firma estándar del nivel externo. El código de la cuenta puede definir sus propios métodos de autorización y reglas de pago. El marco de validación se encarga de confirmar si se cumplen las condiciones, mientras que el marco de envío se encarga de modificar realmente el estado.
Esta estructura también se considera útil para adoptar un formato de transacción más uniforme entre diferentes redes EVM. Sin embargo, el EIP-8141 aún es un borrador principal y no se ha incluido en ninguna actualización de la red principal de Ethereum, ni se ha establecido una fecha de implementación clara.
Durante la discusión de los desarrolladores, también se plantearon varias cuestiones técnicas, incluyendo riesgos de denegación de servicio, reglas de reemplazo de transacciones, adaptación de billeteras y constructores de bloques, así como límites en la cantidad de transacciones pendientes del mismo remitente en la memoria pública. Estas cuestiones aún requieren mayor convergencia.
Recursive STARK or reducing redundant verification
La dirección a largo plazo propuesta por Buterin va más allá del EIP-8141. También imagina que, para las "dependencias puras" que no requieren acceso al estado en la cadena, se pueda realizar una verificación inicial en el nivel del memory pool, en lugar de que cada validador la ejecute repetidamente.
En este modelo, la red puede comprimir múltiples verificaciones completadas en una prueba recursiva STARK, que luego es verificada de forma unificada por el verificador. El objetivo es reducir los cálculos repetitivos y aliviar parte de la carga de verificación.
También mencionó que este enfoque podría ayudar en el futuro a que Ethereum se adapte a esquemas de criptografía post-cuántica. La razón es que las firmas resistentes a la computación cuántica suelen ser más grandes y tener un costo de verificación más elevado. Si las cuentas pueden personalizar sus métodos de autorización, combinadas con la agregación de pruebas recursivas, el costo de verificación asociado podría reducirse.
Sin embargo, esta parte del contenido aún se encuentra en la fase de investigación y no forma parte de la especificación actual de EIP-8141. Para su implementación real, aún se deben resolver problemas como la generación de pruebas, la coordinación con el memory pool, la disponibilidad de datos y la protección contra agregación de errores.