ZK-ACE eliminaría firmas cuánticas en blockchain con pruebas ZK ligadas a identidad

Una investigación académica sostiene que las cadenas de bloques pueden prescindir de los kilobytes que hoy exigen las firmas postcuánticas. ZK-ACE propone sustituir esos artefactos por pruebas de conocimiento cero que acrediten, sin revelar datos, que una identidad válida aprobó la operación, evitando así verificar algoritmos lattice dentro del circuito.

• ZK-ACE cambia firmas postcuánticas por pruebas ZK vinculadas a un compromiso de identidad on-chain.
• La iniciativa busca dividir por 10 o 20 el tamaño de los datos de autorización frente a esquemas ML-DSA.
• Es compatible con account abstraction, rollups, agregación por lotes y composición recursiva de pruebas.

La migración a criptografía cuántico-resistente plantea un desafío no solo criptográfico, sino de escalabilidad. Las firmas lattice que se perfilan como estándar añaden varios kilobytes por transacción, lastrando almacenamiento, ancho de banda y costo de verificación.

ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems, firmado por Jian Sheng Wang, sugiere cambiar el paradigma: en lugar de publicar una firma, el usuario entrega una prueba ZK que demuestra que una identidad registrada autorizó la operación, sin exponer la firma postcuántica al consenso.

El documento parte de la premisa de que la red no necesita verificar un objeto de firma específico, sino comprobar que la entidad correcta aprobó la transacción bajo las reglas del sistema. Así, la autorización se convierte en una propiedad semántica demostrable, no en un artefacto pesado que viaje en cada bloque.

Por qué las firmas postcuánticas lastran la escalabilidad

Una firma ML-DSA nivel 2 pesa unos 2,4 KB, frente a los 64 bytes de Ed25519 o los 71 bytes de ECDSA. En rollups, ese exceso se publica como calldata o blobs, encareciendo el costo y reduciendo el rendimiento. Envolver la verificación ML-DSA dentro de un circuito ZK tampoco resuelve el problema: requiere millones de restricciones, volviendo la generación de pruebas otro cuello de botella.

Funcionamiento interno de ZK-ACE

El esquema se apoya en DIDP (deterministic identity derivation primitive). Desde un valor raíz de 256 bits (REV) se derivan claves para cada contexto. La cadena almacena un compromiso compacto IDcom = hash(REV ‖ sal ‖ dominio). Para cada transacción, el usuario genera una prueba ZK que demuestra conocer un REV consistente con IDcom y que la operación fue autorizada bajo el contexto, el hash de la transacción y un mecanismo anti-replay.

La prueba se ancla a: hash de la transacción, dominio de la cadena, target derivado del contexto y rp_com para evitar reutilización. El validador comprueba que el compromiso esté registrado, que dominio y target coincidan, que la prueba ZK sea válida y que no se infrinja la regla anti-replay.

Qué verifica y qué omite el sistema

ZK-ACE no verifica firmas ML-DSA dentro del circuito ni implementa aritmética lattice. Define un token de autorización conceptual: hash(REV ‖ contexto ‖ hash_tx ‖ dominio ‖ nonce). La prueba ZK acredita que ese token puede derivarse desde la identidad comprometida y que está ligado a los datos públicos declarados. El circuito base requiere entre 1.100 y 1.800 restricciones R1CS, tres órdenes de magnitud menos que una verificación in-circuit de ML-DSA.

Seguridad, replay y separación de dominios

El trabajo formaliza autorización sólida, resistencia a replay, resistencia a sustitución y separación entre dominios. Propone dos modelos anti-replay: registro de nonces (estilo cuenta) y conjunto de nullifiers (estilo UTXO). Cualquier intento de reutilizar una prueba con un hash de transacción distinto falla porque los datos públicos están ligados criptográficamente. El dominio se integra en el compromiso, en el token y en la protección anti-replay, impidiendo migrar pruebas entre cadenas.

Huella on-chain, account abstraction y límites

Frente a 2.420-4.627 bytes de firma más 1.312-2.592 bytes de clave pública en un primer uso PQC, ZK-ACE ofrece 128-256 bytes de prueba, 32 bytes de IDcom y unas 160 bytes de entradas públicas, logrando 320-448 bytes en total. Esto supone una reducción de 10-20 veces en los datos de autorización visibles para consenso. Es compatible con ERC-4337, rollups, agregación por lotes y composición recursiva.

Las limitaciones incluyen la dependencia del DIDP asumido, el crecimiento del conjunto de nullifiers, la ausencia de benchmarks de circuito y la falta de mecanismos on-chain para revocación o rotación de compromisos. Aun así, la tesis es clara: la blockchain postcuántica escalará mejor si la autorización deja de centrarse en firmas y pasa a depender de pruebas ZK ligadas a identidad.

Referencia de contenido: consultar fuente original aquí