Starknet
Firmas de consenso post-cuánticas: una perspectiva desde la validación
Hace unas semanas, una wallet en Starknet hizo una transferencia real firmada con Falcon-512, un esquema de firma que ningún ordenador cuántico, ni uno mucho más potente que los que existen hoy, puede falsificar. Costó unos seis céntimos, la cuenta es experimental y no auditada, y la transacción quedó registrada en mainnet, pública.
Por qué importa: la criptografía que protege prácticamente todas las wallets hoy (Bitcoin, Ethereum, la mayoría de L2s) se basa en curva elíptica, y curva elíptica es exactamente lo que un ordenador cuántico lo bastante potente puede romper. Esa transferencia es la prueba de que ya existe, en producción, una alternativa que no depende de esa criptografía. Pero es solo la pieza más visible de una historia más larga: por qué Starknet pudo hacer esto sin fork ni migración forzada, qué tan resuelto está realmente el resto del roadmap, y qué queda por construir en la pieza menos visible de todas, el consenso que sostiene la red por debajo.
El riesgo cuántico ya está activo, aunque el hardware no exista aún
La exposición cuántica de una blockchain no empieza el día que exista un ordenador cuántico capaz de romper curvas elípticas. Empieza antes, bajo el modelo conocido como harvest now, decrypt later: un atacante puede archivar hoy datos on-chain cifrados y descifrarlos en cuanto el hardware esté disponible. La pregunta relevante no es cuándo llegará ese hardware, sino cuánto trabajo de migración le queda a una red antes de ese momento.
Toda blockchain tiene dos frentes de exposición independientes. La capa de cuenta: la firma que autoriza cada transacción. Y la capa de verificación: el sistema de pruebas que garantiza que el estado de la cadena es válido. Bitcoin y Ethereum tienen curva elíptica cableada en ambas. La mayoría de zk-rollups también, porque construyen sus SNARKs sobre curvas elípticas. Resolver solo una de las dos capas no resuelve el problema.
Por qué Starknet parte de otro punto
En la capa de verificación, Starknet corre sobre STARKs: pruebas basadas en funciones hash, no en curvas elípticas. No existe ataque cuántico conocido contra una función hash, el mejor disponible, el algoritmo de Grover, solo acelera la fuerza bruta, y se compensa aumentando el tamaño del hash. Es una propiedad estructural del sistema de pruebas, presente desde el diseño original, años antes de que esto fuera tema de conversación en la industria.
En la capa de cuenta, cada cuenta en Starknet es un smart contract: ningún esquema de firma está fijado en el protocolo, cada cuenta decide qué acepta en su propia lógica. Eso es lo que hizo posible la transferencia sin hard fork, sin migración coordinada y sin cambio de dirección.
La historia que no ha contado nadie: el coste real de Falcon-512
Aquí hay algo que no salió en ningún titular, y que vale la pena contar. Verificar una firma dentro de un contrato de Starknet no es gratis: cada operación tiene un coste en la red, y cuanto más compleja es la firma, más cara resulta verificarla. Con Falcon-512 ese coste era, hasta hace relativamente poco, un problema real y sin resolver.
En julio de 2025, casi un año antes del roadmap oficial, un desarrollador de la comunidad planteó en el foro público de Starknet una forma de abaratar ese coste. Un investigador de StarkWare le respondió con honestidad: no era suficiente. Una de las operaciones internas que necesita Falcon-512 seguía siendo demasiado pesada, tan cerca del límite de lo que un contrato puede soportar que ni siquiera estaba claro que fuera viable en la práctica. Fue una conversación técnica abierta, sin garantías de que fuera a funcionar.
Un año después, sí funciona. La implementación de Falcon-512 que corre hoy en mainnet resolvió ese problema: verificar una firma cuesta bastante menos que otras alternativas comparables que ya usan muchas wallets, y cabe con margen dentro de los límites de un contrato de Starknet. Es la misma firma que hizo posible la transferencia de seis céntimos con la que abríamos este artículo. Lo relevante no es solo que hoy funcione , es que todo el proceso, desde la duda inicial hasta la solución, ocurrió en público, en el foro de Starknet, mucho antes de que nadie hablara de esto en los medios.
El roadmap y su estado real, superficie por superficie
El roadmap post-cuántico de StarkWare, publicado el 30 de junio, plantea tres fases: asegurar la actividad nueva, dar herramientas de migración a los contratos existentes, y por último resolver las dependencias compartidas con Ethereum. Starknet mantiene un registro público de avance (quantum.starkware.co) con el estado real de cada superficie, que conviene citar con precisión en vez de dar por hecho que todo está resuelto:
Ya en marcha, en mainnet. Starknet cambió una de las funciones matemáticas internas que usa para sellar el estado de la red por una versión resistente a la cuántica (en la jerga técnica: sustituyó Pedersen por BLAKE2s-256 en los hashes de configuración del sistema).
Get Cumulo’s stories in your inbox
Join Medium for free to get updates from this writer.
Anunciado, pero todavía no activo. El mismo tipo de cambio para la estructura que guarda los datos de cada contrato y para cómo se calculan las direcciones de las cuentas. Se sabe qué se va a hacer y cómo, pero todavía no está desplegado en producción.
En fase de investigación, sin fecha ni herramienta pública todavía. Cómo migrar los contratos que ya existen y que guardan su información con el método antiguo. Es la parte más delicada, porque afecta a lo que ya está desplegado y en uso, y StarkWare aún no ha publicado un plan concreto de cómo hacerlo sin romper nada.
Fuera del control directo de Starknet. Parte de los datos de la red se publican en Ethereum, y esa pieza sigue usando una criptografía que Ethereum todavía no ha actualizado (el mecanismo se llama KZG). Lo mismo ocurre con el puente entre ambas redes. Aquí Starknet depende del calendario de Ethereum, no solo del suyo.
La pieza que casi nadie está conectando: consenso y validación descentralizada
Casi toda la conversación pública sobre este roadmap se ha centrado en la cuenta Falcon-512. Pero hay un dato que rara vez se menciona junto al anuncio: el roadmap oficial de descentralización de Starknet ubica la criptografía post-cuántica en la misma fase: Fase 4, actualmente en curso, que Staking v3 (validación de bloques descentralizada) y Staking v4 (consenso y operación de red totalmente descentralizados). No es una coincidencia de calendario: StarkWare ha señalado explícitamente firmas de consenso post-cuánticas, con Falcon-512 como candidato, pensadas para el momento en que la validación deje de depender de StarkWare y pase a manos de un set de validadores independientes.
Esa es la parte que nos toca directamente como validador, y donde el problema deja de ser “¿mi wallet acepta otra firma?” para pasar a ser “¿qué firma tendrá que soportar el software de nodo que opera cada validador, con qué antelación habrá una especificación pública, y habrá una ventana de testnet real antes de que sea obligatorio en mainnet?”. Son preguntas de infraestructura, no de UX, y preferimos plantearlas ahora, en fase de investigación, igual que se planteó y resolvió el coste de Falcon-512 en el foro hace un año, y no cuando la validación descentralizada ya esté en producción.
Desde Cumulo
Llevamos más de 5 años operando infraestructura de validación no custodia en distintas redes, Starknet incluida, con herramientas open source propias para monitorización y despliegue. Este es exactamente el tipo de decisión de protocolo que preferimos seguir desde la fase de investigación pública, con datos concretos, no desde el anuncio. En cuanto haya un esquema de firma de consenso disponible en testnet, nos ofrecemos a probarlo, documentar el proceso en abierto y compartir los hallazgos con la comunidad, como publicamos siempre.
En blockchain, los validadores son el motor que lo hace posible y la comunidad es el combustible que mantiene ese motor en marcha.
Fuentes:
- StarkWare, “The Architecture Advantage: Starknet’s Quantum Readiness Roadmap” (30 de junio de 2026), el anuncio oficial del roadmap, con las tres fases y sus tiempos estimados: https://starkware.co/blog/the-architecture-advantage-starknets-quantum-readiness-roadmap/
- StarkWare, “Quantum security for everyone: the StarkWare Quantum Hub is now live” (30 de julio de 2026), lanzamiento del hub y enlace a la transacción en X: https://starkware.co/blog/quantum-hub/
- Panel de seguimiento de la migración post-cuántica de StarkWare: https://quantum.starkware.co/
- Starknet, Decentralization Roadmap (última actualización 22 de marzo de 2026), ubica la criptografía post-cuántica en la Fase 4, junto a Staking v3 y v4: https://www.starknet.io/roadmap/
- Hilo SNIP-32 en el foro de Starknet, “Expose Keccak-f[1600] Permutation Syscall” (julio de 2025): https://community.starknet.io/t/snip-32-expose-keccak-f-1600-permutation-syscall/115770
- s2morrow, demo e implementación de Falcon-512 en Cairo, con cifras de gas y compresión: https://www.s2morrow.xyz/ y https://github.com/feltroidprime/s2morrow
- StarkWare, “Starknet’s Quantum Edge: STARKs and Native Account Abstraction” (20 de julio de 2026): https://starkware.co/blog/starknets-quantum-edge-starks-and-native-account-abstraction/
Síguenos en: Twitter | Medium | LinkedIn | Discord | cumulo.pro
O nuestro canal de noticias en telegram
