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 homomórfico cruzaron una línea. Apple documenta casos de uso HE en producción para lookups privados y ML. Google Wallet demuestra edad con una prueba de conocimiento cero, y los bloques de Ethereum se prueban en segundos. Esta guía empieza por el modelo de confianza: cuándo tiene sentido cada herramienta, cómo estimar el coste y qué errores queman presupuesto.

Perspectiva de ingeniería, no un pitch de proveedor. Las mediciones publicadas tienen fuente; los rangos de planificación están etiquetados como tales. 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.

Son fronteras de confianza distintas, no una escalera estricta. ZK y FHE dependen también de implementación, compilador, circuito, parámetros y claves. MPC añade un umbral y supuesto de no colusión específicos del protocolo. Un TEE añade hardware, firmware, attestation y canales laterales. La pregunta es qué supuestos encajan con el workload y el modelo de amenazas.

¿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. Los despliegues HE mejor documentados se concentran en lookups privados o computaciones estrechas, no en cifrar un backend completo. Muchos despliegues ZK esconden un único hecho sensible. 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 sin benchmark end-to-end. Una primitiva rápida no garantiza un producto interactivo. Serialización, expansión, key switching, bootstrapping, red y mezcla de operaciones deciden. Mide todo el request y conserva un fallback TEE si la latencia es rígida.

¿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. En el patrón documentado por Apple, la aplicación sigue siendo convencional y el lookup privado es el paso HE acotado. En el patrón de Google, el check de edad es el paso ZK acotado.
3. Elige tooling mantenido y mídelo. Para ZK en 2026 eso significa una zkVM de Rust (SP1, RISC Zero) o Noir en lugar de circuitos escritos a mano. Para FHE, empieza con TFHE-rs para lógica cifrada y la librería Swift de Apple para lookups BFV. CKKS ya no tiene un default seguro de rendimiento: mide Poulpy, Lattigo, SEAL y OpenFHE en CPU, más una opción nativa de GPU como FIDESlib cuando sea relevante. El post de ZK y el post de FHE llevan las tablas completas y notas de ciclo de vida.
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 la latencia o el coste no cierran, evalúa un TEE frente al modelo de amenazas y los requisitos regulatorios. Decidirlo pronto cuesta mucho menos que hacerlo tras una integración profunda.

La regulación impulsa el campo. eIDAS 2.0 hace central la revelación selectiva, mientras EHDS exige acceso controlado, entornos seguros y protección fuerte. No prescribe ZK, FHE o MPC de forma universal. Mapea la propiedad exigida a la arquitectura más simple y confirma la interpretación jurídica.

Fuentes y verificación

1. Apple Machine Learning Research (2024). Production homomorphic-encryption use cases and private lookup design. machinelearning.apple.com
2. Google (2025). Open-source zero-knowledge technology for age assurance. blog.google
3. Microsoft Research (2021). Homomorphic encryption in Edge Password Monitor. microsoft.com
4. Mopro (2026). Mobile and browser proving benchmarks. zkmopro.org
5. zkFuzz (2025). Differential fuzzing results across public ZK circuits. arxiv.org
6. zkSecurity (2026). Documented Groth16 setup exploits. zksecurity.xyz