Vitalik Buterin, cofundador de Ethereum, ha esbozado un diseño de transacciones propuesto que separaría las condiciones necesarias para validar una transacción de las acciones que finalmente se ejecutan en la red, lo que potencialmente permitiría a Ethereum manejar el trabajo de validación de manera más eficiente.

La propuesta se apoya en varias líneas de investigación de Ethereum, incluidas EIP-8141, nonces con clave, diseños de estado alternativos y mempools basados en STARK recursivos. La investigación de Buterin distingue entre las acciones de transacción, que producen cambios en Ethereum, y las dependencias, que deben resolverse antes de que esas acciones puedan ejecutarse de forma segura.

Bajo el modelo propuesto, esta separación podría permitir que distintas partes del procesamiento de transacciones se manejen de manera independiente, en lugar de requerir que la validación y la ejecución permanezcan estrechamente vinculadas.

El diseño de transacciones podría habilitar la validación en paralelo

Las acciones describen los efectos que genera una transacción, como transferir tokens, actualizar cuentas o interactuar con contratos inteligentes. Las dependencias, en cambio, representan las condiciones que deben establecerse antes de que esas acciones puedan proceder.

El flujo de transacciones actual de Ethereum vincula estos requisitos de validación con la ejecución: los nodos reciben transacciones, comprueban si se cumplen sus requisitos y luego procesan las operaciones solicitadas.

La propuesta de Buterin sugiere que muchas dependencias podrían manejarse de manera independiente, porque no necesariamente comparten las mismas características que las acciones mismas.

Algunas dependencias dependen de información contenida en el estado de Ethereum, mientras que otras pueden evaluarse sin acceder al estado de la red. Esta última categoría, denominada dependencias puras, podría verificarse potencialmente antes de que una transacción se incluya en un bloque.

Trasladar este trabajo al mempool podría reducir la cantidad de validación que los nodos deben repetir durante la ejecución del bloque. También permitiría comprobar múltiples dependencias de forma concurrente, en lugar de requerir que cada condición se procese de manera secuencial.

Esa distinción podría volverse cada vez más relevante a medida que las transacciones de Ethereum se vuelvan más complejas y requieran lógicas de autorización y ejecución más sofisticadas. La ejecución en paralelo y la mejora del rendimiento de validación son temas recurrentes en la hoja de ruta de escalabilidad de Ethereum, que ha enfatizado el aumento de la capacidad de transacciones de la red mediante una combinación de rollups de capa 2 y mejoras de la capa base.

Los STARK recursivos y la abstracción de cuentas forman parte de la propuesta

La tecnología STARK recursiva es otro componente del concepto. Múltiples comprobaciones de verificación completadas podrían combinarse potencialmente en una sola prueba criptográfica, permitiendo que los validadores verifiquen un resultado agregado en lugar de repetir de forma independiente cada cálculo subyacente. Los sistemas de prueba basados en STARK ya se utilizan en otras partes del ecosistema de Ethereum, incluidos los rollups de conocimiento cero, donde comprimen el cálculo en pruebas sucintas.

La arquitectura propuesta también se conecta con la investigación más amplia de Ethereum sobre abstracción de cuentas. EIP-8141 explora formatos de transacciones diseñados para admitir mecanismos de autorización y ejecución más flexibles, mientras que los nonces con clave podrían ofrecer mayor flexibilidad en cómo se ordenan las transacciones de cuentas individuales. La abstracción de cuentas ha avanzado de manera incremental en Ethereum mediante esfuerzos anteriores como ERC-4337, que introdujo un mempool alternativo y cuentas de contratos inteligentes, y EIP-7702, que permite que las cuentas de propiedad externa adopten temporalmente funcionalidades de contrato inteligente.

Los nonces tradicionales de Ethereum generalmente obligan a que las transacciones de la misma cuenta sigan un orden secuencial. Como resultado, una transacción retrasada puede impedir que las transacciones posteriores se procesen según lo previsto.

Los nonces con clave crearían secuencias de transacciones separadas dentro de una sola cuenta, lo que permitiría que operaciones no relacionadas avancen de forma independiente en lugar de quedar bloqueadas por una transacción anterior.

Los diseños de estado alternativos podrían cambiar aún más cómo Ethereum organiza la información de las transacciones y determina qué condiciones deben validarse.

En conjunto, estos enfoques apuntan hacia una arquitectura de transacciones más modular en la que la intención, la autorización, la verificación de dependencias y la ejecución podrían manejarse como componentes distintos.

La propuesta sigue siendo un concepto de investigación en desarrollo

El modelo de transacciones sigue siendo un concepto en desarrollo y no una actualización confirmada de la red de Ethereum. Su implementación requeriría trabajo adicional para determinar cómo podría desplegarse la arquitectura de forma segura y qué requisitos técnicos impondría sobre la infraestructura de Ethereum.

Si el enfoque resulta práctico, separar las dependencias de las acciones podría abrir oportunidades para la validación en paralelo, reducir el cálculo duplicado y hacer más eficiente el procesamiento de transacciones.

Por ahora, sin embargo, la propuesta representa un área de investigación en curso. Su impacto potencial dependerá de un mayor desarrollo, la evaluación de seguridad y la capacidad de los desarrolladores de Ethereum para traducir las ideas subyacentes en un diseño de red viable. Como con anteriores propuestas de mejora de Ethereum, el concepto tendría que pasar por el proceso de revisión pública y estandarización del ecosistema antes de que alguna parte pueda llegar a la red principal.

Fuente: Hokanews