Construir Aplicaciones Reales con Pruebas de Conocimiento Cero y FHE en 2026: Una Guía Pragmática

Las pruebas de conocimiento cero y el cifrado totalmente homomórfico cruzaron una línea en los últimos dos años. Apple ejecuta FHE en cientos de millones de iPhones. Google Wallet demuestra tu edad con una prueba de conocimiento cero. Probar un bloque entero de Ethereum ahora lleva segundos, no minutos. Y aun así, la mayoría de los proyectos que arrancan con "usemos ZK" o "usemos FHE" siguen fracasando, porque la tecnología nunca fue la pregunta correcta. Esta guía es el framework de decisión que usamos antes de escribir un solo circuito: cuándo tienen sentido estas herramientas, qué cuestan en 2026, y las cinco formas en que los equipos queman presupuesto con ellas.

Perspectiva de ingeniería, no un pitch de proveedor. Cada cifra de abajo tiene fuente, y cuando un dato es una proyección del vendor en lugar de un resultado ya lanzado, lo decimos. Los puntos de referencia vienen del trabajo de Wavect en zero-knowledge y tecnología de frontera.

¿Qué te dan ZK y FHE que el cifrado normal no?

El cifrado estándar protege los datos en reposo y en tránsito. En el momento en que quieres hacer algo con los datos, los descifras, y quien ejecuta la computación lo ve todo. Las tecnologías de mejora de la privacidad cierran esa brecha, cada una a su manera:

• Pruebas de conocimiento cero (ZK): permiten a una parte demostrar que una afirmación es verdadera sin revelar el porqué. "Soy mayor de 18" sin enseñar la fecha de nacimiento. "Esta computación se ejecutó correctamente" sin volver a ejecutarla. ZK va de verificabilidad con revelación selectiva.
• Cifrado totalmente homomórfico (FHE): permite a un servidor computar sobre datos que no puede leer. El input llega cifrado, la computación corre cifrada, el resultado vuelve cifrado. FHE va de computación externalizada sobre datos que el operador nunca debe ver. Mira nuestra entrada de glosario para lo básico.
• Computación multiparte segura (MPC): permite a varias partes computar conjuntamente sobre inputs que ninguna de ellas compartirá, a costa de un tráfico de red pesado entre ellas.
• Entornos de ejecución confiable (TEE): ejecutan código dentro de un enclave aislado por hardware. Velocidad casi nativa, pero confías en el fabricante del chip y en la ausencia de ataques de canal lateral.

Piénsalo como una escalera de confianza. ZK te pide confiar solo en la matemática del sistema de pruebas. FHE te pide confiar en la criptografía. MPC te pide confiar en que una mayoría de las partes se mantiene honesta. TEE te pide confiar en Intel, AMD o NVIDIA. Una base de datos normal te pide confiar en el operador. Cada peldaño hacia abajo es más rápido y más barato. La pregunta de ingeniería nunca es "cuál es la más segura", es "hasta qué peldaño te deja bajar tu modelo de amenazas". Comparamos las cuatro en profundidad en ZK vs FHE vs MPC vs TEE.

¿De verdad necesitas esto? Recorre primero el árbol de decisión.

El error más caro en este campo es la sobredosis criptográfica. Antes de que cualquiera de estas tecnologías entre en tu arquitectura, responde con honestidad cuatro preguntas:

1. ¿Tus usuarios confían en ti para ver sus datos? Si sí, y la ley lo permite, usa una base de datos, control de acceso, TLS y cifrado en reposo. Eso no es un compromiso, es la arquitectura correcta para la inmensa mayoría de los productos. Las PET resuelven problemas de confianza. Si no hay problema de confianza, no resuelven nada y cuestan mucho.
2. ¿Un tercero necesita verificar algo sin ver los datos subyacentes? Checks de edad, pruebas de solvencia, verificación de credenciales, "este código se ejecutó correctamente". Eso es territorio ZK, y es la opción más madura. Nuestro análisis a fondo: qué está realmente listo para producción en ZK.
3. ¿Una parte no confiable debe computar sobre datos que nunca puede ver? Un servicio cloud procesando historiales médicos, un lookup contra la base de datos de un servidor que no debe aprender nada sobre la consulta. Eso es territorio FHE o MPC, y solo funciona si el workload es pequeño y está bien definido. Chequeo de realidad: qué se lanza y qué sigue siendo hype en FHE.
4. ¿"No podemos ver tus datos" es una promesa central del producto o un requisito regulatorio, y no un nice-to-have? Si es un nice-to-have, un TEE te da casi toda la historia a velocidad prácticamente nativa. Si es el producto, presupuesta criptografía de verdad y la ingeniería que la acompaña.

Fíjate en el patrón: la elección de tecnología se deriva del modelo de confianza, no al revés. Los equipos que parten de "queremos usar FHE" y buscan un problema después son los que acaban en la lista de fracasos de abajo.

"Si tus usuarios confían en ti para ver sus datos, una base de datos gana a un criptosistema. Los proyectos interesantes son aquellos donde esa confianza es estructuralmente imposible."

¿Qué está corriendo de verdad en producción en 2026?

Esto ya no es un campo de investigación. Una lista corta de despliegues que puedes enseñar a tu consejo, cada uno con una lección adjunta:

Dos cosas destacan. Primera, cada despliegue FHE exitoso es un lookup privado o una computación estrecha, nunca "correr todo nuestro backend cifrado". Segunda, los despliegues ZK exitosos esconden un único hecho sensible detrás de una prueba, no intentan hacer que una aplicación entera sea zero-knowledge. La disciplina de alcance es el denominador común.

¿Qué cuesta? Las cifras de 2026.

Reglas rápidas que usamos en revisiones de arquitectura. Son cifras de orden de magnitud para planificar, y cada post de análisis a fondo lleva las cifras precisas con fuente:

La asimetría importa más que las cifras absolutas. ZK es caro una vez para el prover y casi gratis para cada verificador después, y por eso encaja en productos de "probar una vez, verificar en todas partes". FHE es caro en cada operación individual, y por eso encaja en computaciones pequeñas de altas apuestas y en nada más por ahora. Si alguien te cita benchmarks de FHE que parecen demasiado buenos, comprueba si está citando un paper de MPC. Confundir esos dos es el error más común en el contenido sobre este espacio, y lo desmontamos en el análisis a fondo de FHE.

¿Cuáles son las cinco formas en que fracasan estos proyectos?

Hemos visto o revisado cada una de ellas. Fracasan de formas predecibles:

• 1. Criptografía donde bastaría un login. El equipo lanza pruebas ZK entre servicios que pertenecen todos a la misma empresa. No hay adversario en el modelo de amenazas. El resultado es un sistema más lento y más caro con un diagrama de arquitectura impresionante. Si confías en el operador, usa control de acceso.
• 2. Circuitos con restricciones insuficientes. La clase dominante de vulnerabilidad ZK es un circuito que acepta pruebas que debería rechazar porque falta una restricción. Tooling de investigación como zkFuzz encontró decenas de bugs así en 2025, incluidos once en el componente zk-regex de zkEmail, ampliamente usado (zkFuzz, arXiv 2025). Un sistema ZK sin auditorías de circuito y fuzzing no es un producto de seguridad, es un pasivo.
• 3. Atajos con el trusted setup. Los primeros exploits ZK reales en circulación no fueron matemática exótica, fueron trusted setups de Groth16 mal gestionados (zkSecurity). En 2026 rara vez necesitas un trusted setup por aplicación: los sistemas de prueba transparentes (familia STARK) evitan la ceremonia por completo. Que sean tu opción por defecto.
• 4. Tecnología de privacidad, fallo de consentimiento. Apple lanzó Enhanced Visual Search con criptografía genuinamente fuerte (FHE más privacidad diferencial), luego la activó por defecto sin preguntar a los usuarios, y se llevó una reacción pública en enero de 2025 (The Register). La matemática perfecta no sustituye un diálogo de opt-in. Los reguladores y los usuarios juzgan el flujo de consentimiento, no los parámetros del retículo.
• 5. FHE para workloads interactivos. Un sobrecoste de más de 1.000x significa que cualquier cosa que un usuario espera en tiempo real queda fuera de alcance, y el chat cifrado con LLM está a años de ser práctico. Los equipos que lo prometen en un pitch deck acaban colando un TEE en silencio más tarde. Limita FHE a lookups, matching, scoring e inferencia de modelos pequeños, donde funciona de verdad.

¿Cómo dimensionas un primer proyecto que sobreviva al contacto con la realidad?

El patrón que funciona, destilado de los despliegues de arriba:

1. Aísla el único secreto que importa. No "hacer la app privada", sino "el servidor nunca debe aprender el número de teléfono consultado" o "el local nunca debe aprender la fecha de nacimiento". Una frase, un secreto, un verificador.
2. Pon solo eso en el camino caro. El patrón Apple: el 99 por ciento del sistema es una app normal, el lookup privado es la única llamada FHE. El patrón Google: la wallet es una wallet normal, el check de edad es la única prueba ZK.
3. Elige tooling aburrido y mantenido. Para ZK en 2026 eso significa una zkVM de Rust (SP1, RISC Zero) o Noir en lugar de circuitos escritos a mano. Para FHE significa TFHE-rs y Concrete ML de Zama, OpenFHE, o la librería Swift de Apple. El post de ZK y el post de FHE llevan las tablas completas de tooling.
4. Presupuesta la auditoría, no solo la construcción. Una auditoría de circuito más fuzzing es un coste fijo de lanzar ZK. Saltártela es la forma de que escriban writeups de bounties sobre ti. RISC Zero pagó un bounty de 50.000 dólares por un bug encontrado después de auditorías previas, lo que te dice lo difícil que es esto incluso para los mejores equipos.
5. Ten pronto la conversación del plan B. Si las cifras de latencia o coste no cierran, un TEE es el fallback honesto, y para muchos casos de compliance de la UE es suficiente. Decidirlo en la semana dos es barato. Decidirlo en el mes ocho es una reescritura.

Un motor más que merece nombrarse: la regulación está tirando de este campo hacia delante más rápido que la demanda de producto. Cada estado miembro de la UE debe ofrecer una wallet de identidad digital para finales de 2026 bajo eIDAS 2.0, y el marco fomenta explícitamente la revelación selectiva al estilo zero-knowledge. El European Health Data Space apunta a tecnologías de mejora de la privacidad para el uso secundario de datos de salud. Si vendes en la UE, la pregunta está pasando de "por qué usaríamos esto" a "qué partes esperan los reguladores". El post del framework de decisión mapea regulaciones a elecciones concretas de tecnología.