--- title: "Apps reales con conocimiento cero y FHE en 2026" canonical: https://wavect.io/es/blog/building-real-applications-zero-knowledge-fhe-2026/ language: es description: "ZK y FHE corren en producción en Apple, Google y Microsoft. Guía pragmática 2026: árbol de decisión, coste y latencia honestos y cinco modos de fallo." image: "https://wavect.io/img/blog/headers/header_building-real-applications-zero-knowledge-fhe-2026.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min de lectura · 5 Jul 2026 Última revisión 7 de agosto de 2026 [**Siguiente**](/es/blog/zero-knowledge-proofs-production-2026/) # Construir Aplicaciones Reales con Pruebas de Conocimiento Cero y FHE en 2026: Una Guía Pragmática Resumen ZK y el cifrado homomórfico son tecnologías de producción para workloads seleccionados. Apple documenta funciones HE de lookup privado y ML, Google Wallet usa ZK para age assurance, y el proving de bloques en tiempo real está demostrado. Empieza por el modelo de amenazas, mantén pequeño el núcleo criptográfico, mide el camino completo, usa tooling mantenido y presupuesta revisión independiente más fuzzing. Rendimiento y coste dependen del workload, no de multiplicadores universales. Revisado con fuentes primarias el 2026-08-07. 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](/es/glossary/zero-knowledge/), 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](/es/services/zero-knowledge/) y [tecnología de frontera](/es/services/bleeding-edge/). ## ¿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](/es/glossary/homomorphic-encryption/) 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](/es/blog/zero-knowledge-proofs-production-2026/). 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](/es/blog/fully-homomorphic-encryption-practical-2026/). 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. ![Kevin Riedl](/img/team/kevin.webp) "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: | Despliegue | Tecnología | Escala | Lección | | --- | --- | --- | --- | | Funciones de lookup privado de Apple | HE (BFV), PIR y otras técnicas | Funciones de consumo en producción; Apple no publica una cifra de dispositivos HE | HE encaja en lookups pequeños y bien definidos | | Verificación de edad de Google Wallet | Prueba ZK sobre identidad digital | En vivo desde 2025, con Bumble entre las primeras apps asociadas | La identidad ZK es real; Google liberó como open source la librería subyacente | | Microsoft Edge Password Monitor | Cifrado homomórfico | Disponible como función de seguridad de Edge | Mismo patrón: lookup privado y estrecho | | World ID | ZK (Semaphore) | Millones de usuarios verificados | Las pruebas de unicidad ZK funcionan a escala de población | | Pruebas de validez de L2 de Ethereum | ZK (zkVMs basadas en STARK) | Miles de millones en valor asegurado | Probar computación arbitraria es ya un problema de ingeniería, no de investigación | | Mainnet del Protocolo Zama | FHE (TFHE) en Ethereum | En vivo desde diciembre de 2025 | El estado cifrado de smart contracts es posible, hoy a decenas de transacciones por segundo | 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: | Tecnología | Sobrecoste vs texto plano | Carácter de latencia | Señal de coste 2026 | | --- | --- | --- | --- | | TEE (Intel TDX, AMD SEV-SNP, GPUs confidenciales de NVIDIA) | A menudo casi nativo, pero depende mucho del workload y la plataforma | Normalmente lo más cercano a la latencia en texto plano | A menudo la mejora de privacidad más barata si la raíz de confianza en hardware es aceptable | | Proving ZK (zkVM) | Alto para el prover, normalmente mucho menor para los verificadores | De milisegundos a minutos según el programa y el hardware | El proving de bloques Ethereum alcanzó costes cloud publicados bajos; las aplicaciones requieren benchmarks del workload | | FHE (TFHE, CKKS, BFV) | Grande y específico de la operación | Desde primitivas rápidas hasta workloads compuestos largos | No extrapoles un benchmark de una primitiva a la aplicación completa | | MPC | Depende del protocolo, el umbral y la red | Puede estar dominada por round trips y datos transferidos | Haz el benchmark entre las partes y condiciones WAN previstas, no solo en un datacenter | 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](/es/blog/fully-homomorphic-encryption-practical-2026/). ## ¿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)](https://arxiv.org/abs/2504.11961). 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)](https://blog.zksecurity.xyz/posts/groth16-setup-exploit/). 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)](https://www.theregister.com/2025/01/03/apple_enhanced_visual_search/). 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](/es/blog/zero-knowledge-proofs-production-2026/) y el [post de FHE](/es/blog/fully-homomorphic-encryption-practical-2026/) 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. ## Preguntas frecuentes ### ¿Es práctico FHE en 2026? Para workloads estrechos y bien definidos, sí. Apple ejecuta lookups privados basados en FHE en iPhones a escala de consumo, y Microsoft Edge comprueba contraseñas de forma homomórfica. Para computación de propósito general o aplicaciones en tiempo real, no: el sobrecoste sigue siendo de tres a cuatro órdenes de magnitud frente al texto plano. El alcance lo es todo. ### ¿Zero-knowledge solo sirve para blockchains? No. Los despliegues más visibles de 2025 y 2026 son de identidad, no de crypto: Google Wallet demuestra la edad con ZK, las wallets de identidad digital de la UE están adoptando la revelación selectiva, y zkTLS permite a los usuarios probar hechos de cualquier sitio web. Las blockchains financiaron el tooling; la identidad es donde está aterrizando. Mira nuestro post sobre casos de uso de ZK fuera de crypto. ### ¿Debería una startup construir hoy con ZK o FHE? Solo si el problema de confianza es estructural al producto, es decir, si los usuarios o los reguladores exigen que no puedas ver los datos. Si es así, dimensiona un secreto, una prueba o una computación cifrada, y usa tooling mantenido como SP1, Noir o TFHE-rs. Si la promesa de privacidad es un nice-to-have, un TEE o cifrado normal te lleva al mercado meses antes. ### ¿Cuánto cuesta un proyecto ZK o FHE frente a un desarrollo normal? No existe un multiplicador universal defendible. Estima por separado circuito o parámetros, integración, benchmarks, auditoría, fuzzing, claves, infraestructura de proving y fallback. ## Fuentes y verificación 1. Apple Machine Learning Research (2024). Production homomorphic-encryption use cases and private lookup design. [machinelearning.apple.com](https://machinelearning.apple.com/research/homomorphic-encryption) 2. Google (2025). Open-source zero-knowledge technology for age assurance. [blog.google](https://blog.google/innovation-and-ai/technology/safety-security/opening-up-zero-knowledge-proof-technology-to-promote-privacy-in-age-assurance/) 3. Microsoft Research (2021). Homomorphic encryption in Edge Password Monitor. [microsoft.com](https://www.microsoft.com/en-us/research/blog/password-monitor-safeguarding-passwords-in-microsoft-edge/) 4. Mopro (2026). Mobile and browser proving benchmarks. [zkmopro.org](https://zkmopro.org/docs/performance/) 5. zkFuzz (2025). Differential fuzzing results across public ZK circuits. [arxiv.org](https://arxiv.org/abs/2504.11961) 6. zkSecurity (2026). Documented Groth16 setup exploits. [zksecurity.xyz](https://blog.zksecurity.xyz/posts/groth16-setup-exploit/) ## Reflexiones finales ZK y HE son tecnologías de producción para workloads seleccionados. Los despliegues más sólidos mantienen pequeño el núcleo criptográfico: un secreto, una prueba, un lookup cifrado. Empieza por el modelo de confianza, mide el camino completo, usa tooling mantenido, presupuesta revisión independiente y conserva un fallback probado. ## También te puede gustar.. [**Pruebas de Conocimiento Cero en 2026: Qué Está Realmente Listo para Producción** zkVMs, proving en el cliente, identidad ZK, y las cifras honestas de coste detrás del proving de Ethereum en tiempo real.](/es/blog/zero-knowledge-proofs-production-2026/) [**Wavect vs una agencia de desarrollo generalista** Los generalistas venden capacidad; nosotros vendemos criterio de producto más la ingeniería para lanzar tecnología de frontera con seguridad.](/es/compare/wavect-vs-dev-agencies/) Privacidad y criptografía ## Continúa por este clúster Zero knowledge, FHE y computación que preserva la privacidad sin hype. [Empieza por el artículo fundamental**Pruebas de Conocimiento Cero en 2026: Qué Está Realmente Listo para Producción**](/es/blog/zero-knowledge-proofs-production-2026/) - [zkTLS para agentes de IA: demostrar datos web sin exponer secretos](/es/blog/zktls-ai-agents/) - [Pruebas de Conocimiento Cero en 2026: Qué Está Realmente Listo para Producción](/es/blog/zero-knowledge-proofs-production-2026/) - [Cifrado Totalmente Homomórfico en 2026: Qué Se Lanza y Qué Sigue Siendo Hype](/es/blog/fully-homomorphic-encryption-practical-2026/) - [ZK vs FHE vs MPC vs TEE: Cómo Elegir en 2026](/es/blog/zk-vs-fhe-vs-mpc-vs-tee/) - [Zero-Knowledge Fuera del Cripto](/es/blog/zero-knowledge-use-cases-outside-crypto/) Tu bandeja, sin ruido ## Sigue el trabajo que te importa Recibe un correo breve cuando publiquemos algo nuevo. Sigue todo el blog o solo los temas que te interesan. [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min de lectura · 5 Jul 2026 Última revisión 7 de agosto de 2026 [**Siguiente**](/es/blog/zero-knowledge-proofs-production-2026/) Nuevos artículos por correo × × Recibe nuevos artículos por correo Un correo breve cuando publicamos. Gratis y sin seguimiento. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/building-real-applications-zero-knowledge-fhe-2026/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/es/blog/building-real-applications-zero-knowledge-fhe-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "ZK y el cifrado homomórfico son tecnologías de producción para workloads seleccionados. Apple documenta funciones HE de lookup privado y ML, Google Wallet usa ZK para age assurance, y el proving de bloques en tiempo real está demostrado. Empieza por el modelo de amenazas, mantén pequeño el núcleo criptográfico, mide el camino completo, usa tooling mantenido y presupuesta revisión independiente más fuzzing. Rendimiento y coste dependen del workload, no de multiplicadores universales. Revisado con fuentes primarias el 2026-08-07.", "articleBody": " Resumen del blog/Web3 y privacidad/Privacidad y criptografía Construir Aplicaciones Reales con Pruebas de Conocimiento Cero y FHE en 2026: Una Guía Pragmática Resumen ZK y el cifrado homomórfico son tecnologías de producción para workloads seleccionados. Apple documenta funciones HE de lookup privado y ML, Google Wallet usa ZK para age assurance, y el proving de bloques en tiempo real está demostrado. Empieza por el modelo de amenazas, mantén pequeño el núcleo criptográfico, mide el camino completo, usa tooling mantenido y presupuesta revisión independiente más fuzzing. Rendimiento y coste dependen del workload, no de multiplicadores universales. Revisado con fuentes primarias el 2026-08-07. 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: ¿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. ¿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. ¿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. ¿\"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é", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "machinelearning.apple.com", "url": "https://machinelearning.apple.com/research/homomorphic-encryption" }, { "@type": "WebPage", "name": "blog.google", "url": "https://blog.google/innovation-and-ai/technology/safety-security/opening-up-zero-knowledge-proof-technology-to-promote-privacy-in-age-assurance/" }, { "@type": "WebPage", "name": "microsoft.com", "url": "https://www.microsoft.com/en-us/research/blog/password-monitor-safeguarding-passwords-in-microsoft-edge/" }, { "@type": "WebPage", "name": "zkmopro.org", "url": "https://zkmopro.org/docs/performance/" }, { "@type": "WebPage", "name": "arxiv.org", "url": "https://arxiv.org/abs/2504.11961" }, { "@type": "WebPage", "name": "zksecurity.xyz", "url": "https://blog.zksecurity.xyz/posts/groth16-setup-exploit/" } ], "dateModified": "2026-08-07", "datePublished": "2026-07-05", "description": "ZK y el cifrado homomórfico son tecnologías de producción para workloads seleccionados. Apple documenta funciones HE de lookup privado y ML, Google Wallet usa ZK para age assurance, y el proving de bloques en tiempo real está demostrado. Empieza por el modelo de amenazas, mantén pequeño el núcleo criptográfico, mide el camino completo, usa tooling mantenido y presupuesta revisión independiente más fuzzing. Rendimiento y coste dependen del workload, no de multiplicadores universales. Revisado con fuentes primarias el 2026-08-07.", "headline": "Construir Aplicaciones Reales con ZK y FHE en 2026: Una Guía Pragmática", "image": "https://wavect.io/img/blog/headers/header_building-real-applications-zero-knowledge-fhe-2026.svg", "inLanguage": "es", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/building-real-applications-zero-knowledge-fhe-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/building-real-applications-zero-knowledge-fhe-2026/", "wordCount": 2617 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/web3-privacy/", "name": "Web3 y privacidad", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/privacy-cryptography/", "name": "Privacidad y criptografía", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/building-real-applications-zero-knowledge-fhe-2026/", "name": "Apps reales con conocimiento cero y FHE en 2026 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Para workloads estrechos y bien definidos, sí. Apple ejecuta lookups privados basados en FHE en iPhones a escala de consumo, y Microsoft Edge comprueba contraseñas de forma homomórfica. Para computación de propósito general o aplicaciones en tiempo real, no: el sobrecoste sigue siendo de tres a cuatro órdenes de magnitud frente al texto plano. El alcance lo es todo." }, "name": "¿Es práctico FHE en 2026?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Los despliegues más visibles de 2025 y 2026 son de identidad, no de crypto: Google Wallet demuestra la edad con ZK, las wallets de identidad digital de la UE están adoptando la revelación selectiva, y zkTLS permite a los usuarios probar hechos de cualquier sitio web. Las blockchains financiaron el tooling; la identidad es donde está aterrizando. Mira nuestro post sobre casos de uso de ZK fuera de crypto." }, "name": "¿Zero-knowledge solo sirve para blockchains?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Solo si el problema de confianza es estructural al producto, es decir, si los usuarios o los reguladores exigen que no puedas ver los datos. Si es así, dimensiona un secreto, una prueba o una computación cifrada, y usa tooling mantenido como SP1, Noir o TFHE-rs. Si la promesa de privacidad es un nice-to-have, un TEE o cifrado normal te lleva al mercado meses antes." }, "name": "¿Debería una startup construir hoy con ZK o FHE?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No existe un multiplicador universal defendible. Estima por separado circuito o parámetros, integración, benchmarks, auditoría, fuzzing, claves, infraestructura de proving y fallback." }, "name": "¿Cuánto cuesta un proyecto ZK o FHE frente a un desarrollo normal?" } ] } ```