Vitalik Buterin planteó EIP-8288 como una vía para que Ethereum procese firmas de distintos algoritmos mediante pruebas STARK y agregación, sin publicar en cadena los datos de cada firma ni depender de nuevos precompilados para cada algoritmo. La propuesta extiende EIP-8141 con un nuevo tipo de frame, pero no consta como una función aprobada o activa. En paralelo, Eli Ben-Sasson advirtió que la criptografía basada en retículas aún necesita más tiempo de evaluación frente a posibles ataques de IA.
***
- EIP-8288 propone que los usuarios generen firmas localmente y las acrediten en Ethereum mediante pruebas STARK agrupadas por un agregador.
- La especificación plantea un nuevo tipo de frame que permitiría agregar firmas y pruebas a nivel de EVM, con el objetivo de evitar publicar en cadena los datos de cada firma y reducir la necesidad de nuevos precompilados.
- Eli Ben-Sasson pidió cautela con las versiones sucintas basadas en módulo SIS y sugirió esperar entre 3 y 5 años para que la IA las ponga a prueba.
⚡ EIP-8288 plantea ampliar las firmas de Ethereum
La propuesta de Vitalik usaría pruebas STARK y agregación para verificar firmas sin publicar sus datos en cadena.
Aún no está aprobada ni activa. Ben-Sasson pide 3-5 años más de evaluación para la criptografía basada en… pic.twitter.com/ZfssPKglcX
— Diario฿itcoin (@DiarioBitcoin) October 19, 2026
Vitalik propone EIP-8288 para admitir más algoritmos de firma en Ethereum
La propuesta plantea verificar firmas de distintos esquemas mediante pruebas STARK y un agregador, sin publicar en la cadena los datos de cada firma. EIP-8288 extiende EIP-8141 con un nuevo tipo de frame, pero no consta como una función aprobada o activa. El debate ocurre mientras Eli Ben-Sasson cuestiona la madurez de la criptografía basada en retículas ante posibles ataques de inteligencia artificial.
Vitalik Buterin propuso EIP-8288 como una vía para ampliar los algoritmos criptográficos que Ethereum puede admitir. Según un reporte de ChainCatcher recogido por KuCoin, su planteamiento permite que los usuarios generen firmas localmente, las demuestren con pruebas STARK y las envíen a la red a través de un agregador.
El diseño busca evitar que Ethereum tenga que añadir nuevos precompilados cada vez que sus usuarios necesiten otro algoritmo de firma. También apunta a no incluir en la cadena los datos de cada firma como calldata. La especificación de EIP-8288 describe la propuesta como una extensión de EIP-8141 que agrega un nuevo tipo de frame para habilitar la agregación de firmas y pruebas STARK a nivel de EVM.
La especificación presenta un mecanismo propuesto, no una función ya disponible para los usuarios. No consta que EIP-8288 haya sido aprobada o activada en Ethereum.
La ruta que plantea EIP-8288
Las firmas digitales permiten comprobar que una instrucción cuenta con la autorización correspondiente, y los algoritmos que las generan son una pieza central de las cuentas y las carteras. La propuesta de Buterin aborda cómo Ethereum podría aceptar métodos criptográficos distintos sin tener que modificar su infraestructura central para incorporar cada uno de ellos.
En el esquema descrito, el usuario produciría la firma en su propio dispositivo y presentaría una prueba STARK en vez de publicar directamente los datos de la firma como calldata. Esa prueba permite acreditar que se cumple una condición sin exponer necesariamente todo el cálculo que hay detrás, mientras que un agregador reuniría las pruebas y las enviaría a la cadena.
La distinción importa porque las firmas se generarían fuera de Ethereum, pero su validez se comprobaría mediante el mecanismo propuesto. El agregador actuaría como intermediario para llevar las pruebas a la red; la información disponible no detalla cómo se organizaría ese servicio ni qué requisitos operativos tendría, por lo que esos aspectos no pueden darse por resueltos.
Buterin describió esta ruta como una opción para soportar varios algoritmos criptográficos. El objetivo, tal como aparece en el reporte, es reducir la necesidad de añadir nuevos precompilados y publicar en la cadena los datos de cada firma. La propuesta no especifica plazos de implementación y no consta como aprobada o activa.
Menos dependencia de nuevos precompilados
En Ethereum, los precompilados son funciones integradas que permiten ejecutar determinadas operaciones de forma directa en la red. En este debate, el punto de Buterin es evitar que cada nuevo algoritmo de firma requiera una incorporación de ese tipo, una alternativa que podría resultar relevante si las necesidades criptográficas de las cuentas cambian con el tiempo.
La propuesta no significa que los precompilados desaparezcan ni que todos los algoritmos vayan a quedar disponibles automáticamente. Lo que describe es una vía para comprobar firmas mediante pruebas STARK, con trabajo local de los usuarios y el envío de pruebas agregadas, en vez de publicar en la cadena los datos de cada firma como calldata.
Ese diseño también coloca una parte del proceso fuera de la ejecución directa en Ethereum. Para que la idea funcione en la práctica, los usuarios tendrían que generar las firmas y las pruebas correspondientes, mientras un agregador se ocuparía de enviarlas; el reporte, sin embargo, no presenta detalles sobre costos, tiempos, incentivos o condiciones de seguridad para esos participantes.
Por eso conviene distinguir la propuesta técnica de una decisión de implementación. El planteamiento describe cómo podría abordarse la compatibilidad con varios algoritmos, pero no confirma que la red haya adoptado ese mecanismo ni establece qué firmas se admitirían primero, si es que el diseño avanza.
El debate sobre retículas y seguridad frente a la IA
La discusión se conecta con un desacuerdo sobre la seguridad de la criptografía basada en retículas. Eli Ben-Sasson, cofundador de StarkWare, cuestionó las opiniones de a16z sobre este tipo de criptografía y sostuvo que sus estructuras matemáticas podrían ofrecer vías que merecen un análisis adicional frente a ataques de inteligencia artificial.
Ben-Sasson señaló que las versiones sucintas basadas en módulo SIS son relativamente recientes, pues existen desde alrededor de 2012, según escribió. A su juicio, ese historial todavía no ofrece suficiente madurez para confiarles la custodia de grandes activos, una cautela que vincula la evaluación técnica con el riesgo práctico para usuarios y organizaciones.
Su recomendación fue esperar entre 3 y 5 años para que la IA tenga tiempo de poner a prueba exhaustivamente esas herramientas antes de utilizarlas para custodiar grandes cantidades de valor. La advertencia no equivale a afirmar que la inteligencia artificial ya haya quebrado esos sistemas: plantea que hacen falta más pruebas antes de considerarlos adecuados para ese uso.
Buterin, por su parte, indicó que la criptografía basada en retículas todavía podría integrarse mediante precompilados en el futuro si se demuestra segura frente a ataques de IA. Mencionó como posibles aplicaciones las cuentas y las carteras, de modo que su postura deja abierta esa opción, pero la condiciona a una evaluación de seguridad satisfactoria.
Una propuesta técnica y una cautela pendiente
Las dos posturas abordan preguntas relacionadas, aunque no idénticas: EIP-8288 se centra en cómo procesar distintos algoritmos de firma, mientras Ben-Sasson pone el foco en la confianza que merece una familia criptográfica concreta. El mecanismo de pruebas STARK ofrece una ruta general para verificar firmas sin publicar en cadena los datos de cada una, pero no elimina por sí mismo la necesidad de evaluar la seguridad de cada algoritmo.
En particular, la propuesta de Buterin no constituye una validación de la criptografía basada en retículas ni una respuesta definitiva a las objeciones de Ben-Sasson. El eventual uso de esa tecnología está condicionado a que se pruebe segura frente a ataques de IA, mientras que el cofundador de StarkWare pide más tiempo de análisis antes de confiarle activos de gran valor.
La especificación de EIP-8288 describe la extensión de EIP-8141 y el nuevo tipo de frame para agregar firmas y pruebas STARK a nivel de EVM, pero no ofrece una hoja de ruta de desarrollo ni una fecha de votación. Por ahora, la propuesta plantea un método de firmas locales, pruebas STARK y agregación, mientras el debate sobre la madurez de la criptografía de retículas sigue abierto.
El siguiente punto de interés será si la propuesta se desarrolla como un mecanismo concreto y cómo se evalúa la seguridad tanto del esquema de verificación como de los algoritmos que podrían utilizarlo. Hasta entonces, EIP-8288 debe entenderse como una alternativa planteada para ampliar las opciones criptográficas de Ethereum, no como una función ya disponible para sus usuarios.
Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.
Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
Estados Unidos
Meta atribuye a una herramienta de Claude la suspensión temporal de No Kings en Instagram
Análisis de mercado
ETH bajo presión: niveles críticos y señales mixtas al 19 de octubre de 2026
Bancos y Pagos
BlackRock busca llevar BUIDL más allá de las criptomonedas: supera los USD $2.000 millones
Hyperscalers
