-
El avance reduce el costo de comprimir hashes tradicionales en SNARKs.
-
Ethereum reemplazará Poseidon por SHA o BLAKE en su capa base.
El anuncio de Justin Drake sobre el abandono de Poseidon en Ethereum no es una noticia de Bitcoin, pero toca una pieza técnica que esta red lleva años discutiendo: cómo comprimir firmas poscuánticas sin inflar el tamaño de las transacciones.
El hallazgo que describe Drake, sobre SNARKs construidas en campos binarios, no depende de ninguna decisión de gobernanza de Ethereum para ser relevante en otros contextos. Es un resultado matemático que cualquier protocolo puede intentar replicar.
Bitcoin enfrenta un problema parecido al que motivó el giro de Ethereum. Las propuestas actuales para blindar la red frente a computadoras cuánticas, reunidas bajo BIP-360, incluyen esquemas basados en hashes como SLH-DSA (SPHINCS+).
El costo de esa solidez es el tamaño. Una firma SPHINCS+ puede pesar decenas de kilobytes, muy por encima de los 64 a 80 bytes que ocupa una firma Schnorr actual. Ese sobrepeso no es un detalle menor para una red que ya discute el límite de bloque y las tarifas.
Si cada dirección migrada a un esquema basado en hashes multiplica por cientos su huella en la cadena, la capacidad de Bitcoin para procesar transacciones caería. Salvo que exista una forma de comprimir esas firmas antes de que lleguen a un bloque, algo donde el hallazgo de campos binarios se vuelve relevante.
Lo que cambia no es la seguridad de SHA-256 ni de las funciones hash que ya usa Bitcoin. Lo que cambia es el costo de demostrar, dentro de una prueba compacta, que esas funciones se ejecutaron correctamente.
Antes, generar ese tipo de prueba sobre un hash tradicional resultaba tan caro que forzaba a diseñar hashes artificiales como Poseidon. El nuevo enfoque revierte esa lógica: adapta el diseño de la prueba al hash, no al revés.
Qué significa la compresión de firmas para Bitcoin
La idea de comprimir muchas firmas en una sola prueba no depende de Poseidon ni es exclusiva de Ethereum. Cualquier protocolo que necesite verificar un lote de firmas basadas en hashes podría envolver esas verificaciones dentro de una SNARK.
En Bitcoin, ese principio ya circula de forma parcial. Protocolos como BitVM utilizan pruebas criptográficas para verificar cómputos externos sin cargar todos los datos originales en la cadena.
La eficiencia de las SNARK sobre campos binarios reduciría el costo de generar ese tipo de pruebas. Eso beneficiaría en principio a cualquier propuesta que intente agregar firmas poscuánticas de forma similar, aunque hoy ningún BIP activo propone directamente esta ruta.
Conviene aquí una precisión técnica. Bitcoin, a diferencia de Ethereum, no ejecuta contratos inteligentes de propósito general en su capa base ni cuenta con una máquina virtual programable como la que Drake proyecta con leanVM.
Cualquier esquema de agregación de firmas para Bitcoin tendría que llegar mediante un soft fork acotado, probablemente vía un nuevo opcode o una extensión de Taproot. No sería una réplica directa de lo que Ethereum planea para 2027 y 2028.
Bitcoin y los tiempos de una migración que no depende de Ethereum
Los investigadores que trabajan en la protección cuántica de Bitcoin, entre ellos Jonas Nick y Ethan Heilman, ya discuten formatos que buscan reducir el peso de SPHINCS+ sin sacrificar seguridad.
Un abaratamiento real en el costo de probar hashes dentro de circuitos SNARK les daría una herramienta adicional. Podrían aprovecharla incluso sin depender del código que produzca el equipo de Ethereum.
Existe además un paralelismo estratégico entre ambas redes. Ethereum optó por hashes tradicionales por desconfianza hacia estructuras más recientes, como retículos o isogenias, ante el avance del criptoanálisis asistido por IA.
Bitcoin comparte esa cautela desde antes. La inclusión de SPHINCS+ en BIP-360 responde a la misma lógica: apostar por primitivas con décadas de escrutinio público, no por esquemas nuevos y menos probados.
Esa coincidencia no es casual. Ambas comunidades llegan a conclusiones parecidas porque parten de la misma evaluación de riesgo: menos superficie de ataque matemático, aun a costa de firmas más pesadas.
Nada de esto adelanta una fecha concreta para que Bitcoin adopte compresión de firmas vía campos binarios. El cronograma de Drake es, según sus palabras, un borrador interno, no un estándar auditado.
Para Bitcoin, cualquier camino equivalente pasaría primero por discusión abierta en foros como Bitcoin-Dev, pruebas en testnet y el consenso necesario para activar un soft fork, un proceso que históricamente toma más tiempo que en Ethereum.
Lo que deja este episodio es una señal sobre hacia dónde se mueve la investigación criptográfica: el problema poscuántico ya no se resuelve solo eligiendo un algoritmo de firma resistente, sino diseñando la infraestructura de pruebas que permita comprimirlo sin destruir la escalabilidad. Bitcoin no depende de que Ethereum resuelva ese problema, pero sí puede beneficiarse de que alguien más lo haya hecho primero.
