TECNOLOGÍAS

Zero-Knowledge

Zero-Knowledge Proof (ZK)

Una técnica criptográfica que demuestra que una afirmación es verdadera sin revelar los datos que la sostienen.

Última revisión: porKevin Riedl wiki ↗

Una prueba de conocimiento cero permite a una parte (el probador) convencer a otra (el verificador) de que conoce cierta información, sin revelarla. Ejemplo canónico: demostrar que eres mayor de 18 sin revelar tu fecha de nacimiento.

En producción, ZK aparece en dos sabores. Los ZK-SNARKs son más pequeños y rápidos de verificar pero requieren un trusted setup. Los ZK-STARKs son más grandes y lentos pero no necesitan trusted setup y son resistentes a la computación cuántica. La mayoría de chains ya ofrecen circuitos pre-hechos para pruebas comunes (identidad, balance, elegibilidad de voto), así que no necesitas un criptógrafo en plantilla para enviar un smart contract que los verifique.

Ejemplo donde ZK se gana el pan: un exchange regulado tiene que demostrar a un auditor que cada usuario pasó el KYC, sin entregarle una base de datos de nombres y números de pasaporte. Una prueba de conocimiento cero permite al exchange atestiguar «este conjunto de cuentas está plenamente verificado por KYC» mientras las identidades de base quedan privadas. En la UE, donde el RGPD convierte esa base de pasaportes en un pasivo que preferirías no tener, la privacidad no es un extra agradable, es el objetivo. El contraejemplo es igual de instructivo: si una consulta a una base de datos de confianza satisfaría al verificador, ZK es teatro caro.

El trade-off honesto de ingeniería, y el error de founder más común: suponer que la parte difícil es la criptografía. La matemática es sólida. El riesgo vive en el circuito. Un circuito sutilmente mal hecho produce una prueba que verifica perfectamente mientras demuestra la afirmación equivocada, y ese bug es invisible hasta que alguien lo explota. Por eso el trabajo ZK vive cerca de account abstraction y otras primitivas on-chain donde las auditorías son innegociables, no atornillado como feature de marketing. El caso de negocio es más estrecho que el hype: ZK es genuinamente valioso cuando necesitas demostrar una propiedad on-chain (o a una contraparte) sin filtrar los datos. Para la mayoría de apps de consumo y la mayoría de proyectos web3 que lo mencionan es exagerado.

// FAQ

Preguntas frecuentes

SNARK si lo que pesa es tamaño de prueba y coste de verificación (la mayoría de casos on-chain). STARK si quieres evitar trusted setup y te preocupa la resistencia post-cuántica. Para una app de consumo el trade-off rara vez es decisivo; suele dictarlo la chain o el circuito ya disponibles.
Confundir «la prueba es válida» con «el dato de entrada es correcto». Una prueba ZK solo demuestra que el circuito se ejecutó con consistencia, no que los inputs sean los que tú esperabas. Sin validación cuidadosa de los inputs públicos, despliegas un sistema que confirma con seguridad criptográfica una afirmación falsa.
Casi nunca. La mayoría de aplicaciones reales usa circuitos pre-hechos (Semaphore, Noir, Risc Zero) auditados. Te hace falta un ingeniero que entienda los trade-offs y sepa integrarlos. Contratar criptografía aplicada in-house solo es razonable si tu propuesta de valor es un protocolo ZK, no una app que lo usa.