El cofundador de Ethereum, Vitalik Buterin, explicó el 9 de septiembre la EIP-8288, una propuesta para agregar pruebas STARK y firmas criptográficas en el nivel del mempool.

Buterin afirmó que el modelo podría reducir el coste de las firmas poscuánticas, las transacciones privadas y los nuevos esquemas criptográficos sin modificar la Máquina Virtual de Ethereum.

La propuesta trasladaría parte de la computación y los datos fuera de la ruta principal de ejecución de Ethereum, al tiempo que almacenaría en cadena una prueba compacta de corrección.

El cofundador de Ethereum, Vitalik Buterin, explicó el 9 de septiembre la EIP-8288, una propuesta para introducir la agregación recursiva de pruebas STARK y firmas criptográficas en el nivel del mempool. Dijo que el enfoque podría abaratar significativamente las firmas poscuánticas, las transacciones privadas y los nuevos esquemas criptográficos sin requerir cambios en la Máquina Virtual de Ethereum.

Buterin espera que la propuesta pueda incluirse en la actualización I-star, prevista para después de Hegota. La describió como el siguiente paso después de Frames en una nota sobre mempools STARK recursivos.

Cómo funcionaría el mempool STARK recursivo

La EIP-8288, elaborada por Buterin y Tomas Koratje, fue creada el 3 de junio de 2026. Amplía la EIP-8141 con un nuevo tipo de frame que permitiría agregar firmas criptográficas y pruebas STARK fuera de cadena y verificarlas mediante una única STARK recursiva, sin almacenar directamente todos los datos originales en un bloque.

La EIP-8141 y el mempool STARK recursivo forman parte de una investigación para alejarse de la ejecución secuencial mediante la división de las transacciones en acciones y dependencias. El mecanismo propuesto usaría frames de dependencia, que contienen afirmaciones sobre las dependencias de una transacción. Un frame podría, por ejemplo, certificar que un hash de mensaje concreto fue firmado por una clave pública especificada o que determinados datos cumplieron una condición definida por una clave de verificación.

Cuando las transacciones entren en el mempool, los nodos de la red agregarían sus dependencias. Cada 500 milisegundos nominales, un nodo recopilaría nuevas transacciones, eliminaría las expiradas, generaría una STARK recursiva que certificaría todas las dependencias y reenviaría un nuevo sobre que abarcaría múltiples transacciones.

Buterin afirmó que este diseño podría limitar las exigencias de ancho de banda. El tráfico saliente de cada nodo consistiría en una STARK de unos 100-300 KB por ciclo, además de la difusión habitual única de las transacciones por toda la red.

Un constructor de bloques operaría, en efecto, como otro nodo del mempool. Recibiría transacciones, generaría su propia STARK para las dependencias que planease incluir y adjuntaría la prueba al bloque. La cadena de bloques almacenaría entonces una STARK de 100-300 KB más 96 bytes por cada afirmación cubierta por la prueba.

Buterin denominó al concepto “Proof Singularity” y afirmó que ya podría implementarse con la tecnología existente.

Firmas poscuánticas y privacidad

Buterin afirmó que una ventaja clave de la EIP-8288 sería la reducción de costes para la criptografía poscuántica. Las firmas poscuánticas basadas en hash pueden tener actualmente un tamaño de entre 2-3 KB y requieren aproximadamente entre 150.000-200.000 de gas para verificarse, mientras que el modelo propuesto evitaría colocar los propios datos de la firma en cadena.

Dijo que el enfoque podría hacer que las firmas poscuánticas como SPHINCS- fueran “ultra-baratas”. Buterin también propuso aplicar el mismo principio a los protocolos de privacidad. Una transacción privada bien optimizada cuesta actualmente unos 300.000 de gas, mientras que las soluciones poscuánticas pueden requerir alrededor de 10 millones de gas. Estimó que la EIP-8288 podría reducir ese coste a unas pocas decenas de miles de gas.

La propuesta también podría permitir a los desarrolladores utilizar nuevos esquemas criptográficos sin modificar la Máquina Virtual de Ethereum. Buterin citó Falcon, ML-DSA y otros algoritmos y esquemas basados en retículas, códigos e isogenias, que podrían encapsularse en una STARK del lado del cliente manteniendo los costes en cadena en unas pocas decenas de miles de gas.

“Con suerte, Ethereum nunca volverá a necesitar políticas de ‘por favor, admitan mi algoritmo criptográfico favorito’”, escribió Buterin.

Buterin destacó por separado la abstracción privada de cuentas. Dijo que podría ocultar la lógica de las cuentas y permitir que la propiedad de un estado completo en cadena —incluidas cuentas, posiciones de finanzas descentralizadas y registros de protocolos privados— se transfiera en una sola transacción sin revelar qué objetos específicos cambiaron de manos.

Requisitos de implementación

En virtud de la EIP-8288, los cálculos y datos que estén fuera de la lógica de negocio central de la ejecución de transacciones se trasladarían fuera de la ruta principal de ejecución de Ethereum. Los nodos del mempool procesarían y paralelizarían esas operaciones, mientras que la cadena de bloques conservaría una prueba compacta de su corrección.

Los desarrolladores también cambiarían la forma en que manejan las firmas y las STARK. En lugar de verificar directamente una prueba criptográfica, la lógica central de la transacción comprobaría la existencia de un frame que contenga la afirmación pertinente como dependencia.

La implementación requeriría que Ethereum seleccione un lenguaje, o una arquitectura de conjunto de instrucciones, para las STARK recursivas. Buterin identificó RISC-V como el principal candidato, pero afirmó que la decisión requería una consideración cuidadosa porque podría establecer RISC-V, u otra ISA, como el estándar canónico de Ethereum.

La EIP-8288 también contempla compatibilidad con FOCIL y utiliza herramientas Lean Ethereum para firmas y STARK.

Fuente: HODL Press