El cofundador de Ethereum, Vitalik Buterin, esbozó un modelo de transacciones a largo plazo el 6 de septiembre que podría permitir a la red procesar parte del trabajo de validación en paralelo.
Resumen
- Buterin propuso separar las acciones de las transacciones de las dependencias para que Ethereum pueda optimizar cada componente de forma independiente más adelante.
- Las dependencias incluyen firmas, pruebas de estado y condiciones de validez que las transacciones deben satisfacer antes de que comience la ejecución.
- Las dependencias puras podrían ser verificadas una vez por los mempools y luego comprimidas en pruebas STARK recursivas.
- EIP-8141 propone transacciones de marco con validación, ejecución y pago de gas programables dentro de un único formato de transacción.
- Los desarrolladores de Ethereum no han aprobado EIP-8141 para una actualización de la red principal ni han publicado fechas de implementación todavía.
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 demuestran que existe una salida no gastada, pruebas de conocimiento cero y condiciones de estado que deben permanecer verdaderas cuando una transacción entra en un bloque.
Buterin argumentó que hacer esta distinción explícita podría ayudar a Ethereum a escalar sin abandonar su entorno de ejecución flexible. Sin embargo, la propuesta sigue siendo parte de la investigación continua del protocolo. Los desarrolladores de Ethereum no han aprobado el diseño completo para su implementación.
Ethereum podría procesar dependencias de transacciones en paralelo
Las transacciones de Ethereum actualmente combinan autorización, pago de tarifas y 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 con éxito.
Algunas de estas comprobaciones 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 necesariamente tiene que esperar por firmas no relacionadas adjuntas a otras transacciones. Si se conocen múltiples comprobaciones independientes de antemano, los clientes pueden distribuir el trabajo entre los recursos de procesamiento disponibles.
Las comprobaciones dependientes del estado requieren mayor cuidado. Una condición vinculada a un saldo de 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 costos de gas más bajos 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 en lugar de una medición de red publicada dentro de la publicación. 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. La actividad más predecible podría usar estructuras estáticamente analizables que se asemejan a partes del modelo de transacciones de Bitcoin.
Bitcoin utiliza un modelo de salidas de transacción no gastadas 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 proporciona un marco general de transacciones
EIP-8141 es un borrador de Propuesta de Mejora de Ethereum para un nuevo tipo de transacción conocido como Transacción de Marco. Divide una transacción en marcos de llamada a 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 tarifas 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 las reglas de autorización y pago necesarias.
Las Transacciones de Marco podrían admitir tarifas patrocinadas, pagos en tokens distintos de ETH, rotación de claves y agrupación de transacciones. También podrían permitir que las cuentas de propiedad externa reciban características de abstracción de cuentas sin depender del mismo despliegue de contratos en todas las redes compatibles.
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 condiciones que deben cumplirse. Los marcos de remitente manejan las operaciones que alteran el estado.
El formato también podría mejorar la interoperabilidad entre redes de Máquina Virtual de Ethereum. Diferentes cadenas podrían admitir la misma estructura mínima de transacción mientras aplican sus propias herramientas de verificación, precompilados o características de cuenta.
Buterin describió el formato potencial como una lista básica de llamadas con banderas 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 clasificado como una propuesta Core en borrador. Su especificación actual incluye reglas detalladas para la admisión en el mempool, 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 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 afectaría esa regla a las cuentas que envían regularmente varias transacciones dentro de un bloque.
Otros participantes han examinado si el formato introduce complejidad adicional para billeteras, constructores de bloques e 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.
Los STARK recursivos podrían eliminar la verificación repetida
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 de mempool en lugar de ser repetidas por cada validador.
Una dependencia pura podría incluir una firma criptográfica o prueba cuya validez no cambie con el estado de Ethereum. Después de verificarla, la red podría reemplazar múltiples piezas de trabajo de verificación con un STARK recursivo que confirme que todas las comprobaciones se completaron correctamente.
Un 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 hace posible combinar muchas comprobaciones 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, algunos de los datos originales podrían potencialmente omitirse.
Ese resultado no es 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 la computación cuántica son generalmente más grandes y más costosas de verificar que las firmas ECDSA utilizadas por las cuentas ordinarias de Ethereum.
EIP-8141 podría permitir que las cuentas definan 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 firmas post-cuánticas grandes.
EIP-8141 podría ayudar a las cuentas de Ethereum a adoptar autorización post-cuántica si sistemas de firma prácticos estuvieran disponibles. Eso sigue siendo un camino de seguridad a largo plazo más que una respuesta inmediata a una amenaza cuántica activa.
Los nonces con clave podrían eliminar los cuellos de botella en las transacciones
Las cuentas de Ethereum utilizan nonces secuenciales para evitar la repetición de transacciones. Si una cuenta envía 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 si 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 nonces mientras se mantiene la protección contra repetición.
Crypto.news informó anteriormente que los nonces con clave podrían evitar que 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 conservan 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 continuarían funcionando pero consumirían más recursos porque los clientes no pueden preparar su ejecución de la misma manera.
Tal diferenciación de precios intentaría alinear las tarifas con las restricciones reales de escalado creadas por cada transacción. No garantizaría tarifas más bajas para cada usuario o aplicación.
EIP-8141 aún requiere aprobación y pruebas de los desarrolladores
EIP-8141 debe pasar varias etapas antes de que pueda afectar a los usuarios de Ethereum. Los desarrolladores principales primero deben acordar que Frame Transactions ofrecen un mejor camino que los diseños competidores de abstracción de cuentas.
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 interactúan Frame Transactions 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 Frame Transactions seguían bajo consideración en lugar de programarse formalmente.
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. Frame Transactions 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 usarlos juntos podría proporcionar abstracción de cuentas nativa con una resistencia a la censura más fuerte. Esa combinación sigue siendo un paquete propuesto, no un compromiso aprobado en la hoja de ruta de Ethereum.
Los comentarios de Buterin del 6 de septiembre describen, por lo tanto, 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 el alcance de una actualización y las implementaciones funcionales en redes de desarrollo. Hasta entonces, EIP-8141 y los mempools recursivos de STARK siguen siendo propuestas activas de investigación e ingeniería.
Preguntas frecuentes
¿Qué es EIP-8141?
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 preliminar de Núcleo. Los desarrolladores de Ethereum aún pueden cambiar o rechazar su especificación.
¿Cuál es la diferencia entre una acción y una dependencia?
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.
¿Reducirá EIP-8141 las tarifas de transacción de Ethereum?
Podría hacer que las transacciones predecibles sean más baratas de procesar si los desarrolladores adoptan precios de gas que recompensen las operaciones estáticamente analizables.
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.
