Una publicación etiquetados con "FHE"

Las blockchains públicas proporcionan transparencia e integridad a costa de la privacidad: cada transacción y estado de contrato está expuesto a todos los participantes. Esta apertura crea problemas como los ataques de MEV (Valor Extraíble por Mineros), el copy-trading y la filtración de lógica de negocio sensible. La privacidad programable busca resolver estos problemas permitiendo cómputos sobre datos privados sin revelar los datos en sí. Dos paradigmas criptográficos emergentes están haciendo esto posible: las Máquinas Virtuales de Cifrado Totalmente Homomórfico (FHE-VM) y los Coprocesadores de Conocimiento Cero (ZK). Estos enfoques permiten el cómputo off-chain o cifrado con verificación on-chain, preservando la confidencialidad mientras se mantiene la corrección sin confianza (trustless). En este informe, profundizamos en las arquitecturas de FHE-VM y coprocesadores ZK, comparamos sus ventajas y desventajas, y exploramos casos de uso en finanzas, identidad, salud, mercados de datos y aprendizaje automático descentralizado.

Máquina Virtual de Cifrado Totalmente Homomórfico (FHE-VM)​

El Cifrado Totalmente Homomórfico (FHE) permite realizar cómputos arbitrarios sobre datos cifrados sin necesidad de descifrarlos. Una Máquina Virtual FHE integra esta capacidad en los contratos inteligentes de la blockchain, permitiendo estado y lógica de contrato cifrados. En una blockchain habilitada para FHE (a menudo llamada fhEVM para diseños compatibles con EVM), todas las entradas, el almacenamiento del contrato y las salidas permanecen cifrados durante toda la ejecución. Esto significa que los validadores pueden procesar transacciones y actualizar el estado sin conocer ningún valor sensible, logrando una ejecución on-chain con confidencialidad de los datos.

Arquitectura y Diseño de FHE-VM​

Una FHE-VM típica extiende un tiempo de ejecución de contrato inteligente estándar (como la Máquina Virtual de Ethereum) con soporte nativo para tipos de datos y operaciones cifradas. Por ejemplo, la FHEVM de Zama introduce enteros cifrados (euint8, euint32, etc.), booleanos cifrados (ebool) e incluso arreglos cifrados como tipos de primera clase. Los lenguajes de contratos inteligentes como Solidity se aumentan mediante bibliotecas o nuevos opcodes para que los desarrolladores puedan realizar operaciones aritméticas (add, mul, etc.), lógicas y comparaciones directamente sobre textos cifrados. Por debajo, estas operaciones invocan primitivas FHE (por ejemplo, usando la biblioteca TFHE) para manipular bits cifrados y producir resultados cifrados.

El almacenamiento de estado cifrado es compatible para que las variables del contrato permanezcan cifradas en el estado de la blockchain. El flujo de ejecución es típicamente:

1. Cifrado del Lado del Cliente: Los usuarios cifran sus entradas localmente usando la clave pública FHE antes de enviar las transacciones. La clave de cifrado es pública (para cifrar y evaluar), mientras que la clave de descifrado permanece secreta. En algunos diseños, cada usuario gestiona su propia clave; en otros, se utiliza una única clave FHE global (discutido a continuación).
2. Cómputo Homomórfico On-Chain: Los mineros/validadores ejecutan el contrato con opcodes cifrados. Realizan las mismas operaciones homomórficas deterministas sobre los textos cifrados, por lo que se puede alcanzar un consenso sobre el nuevo estado cifrado. Crucialmente, los validadores nunca ven datos en texto plano; solo ven texto cifrado "sin sentido" pero aún pueden procesarlo de manera consistente.
3. Descifrado (Opcional): Si un resultado necesita ser revelado o utilizado off-chain, una parte autorizada con la clave privada puede descifrar el texto cifrado de salida. De lo contrario, los resultados permanecen cifrados y pueden ser utilizados como entradas para transacciones posteriores (permitiendo cómputos consecutivos sobre un estado cifrado persistente).

Una consideración de diseño importante es la gestión de claves. Un enfoque es el de claves por usuario, donde cada usuario posee su clave secreta y solo ellos pueden descifrar las salidas relevantes para ellos. Esto maximiza la privacidad (nadie más puede descifrar tus datos), pero las operaciones homomórficas no pueden mezclar datos cifrados bajo diferentes claves sin complejos protocolos de claves múltiples. Otro enfoque, utilizado por la FHEVM de Zama, es una clave FHE global: una única clave pública cifra todos los datos del contrato y un conjunto distribuido de validadores posee partes de la clave de descifrado de umbral. Las claves públicas de cifrado y evaluación se publican on-chain, para que cualquiera pueda cifrar datos para la red; la clave privada se divide entre los validadores que pueden descifrar colectivamente si es necesario bajo un esquema de umbral. Para evitar que la colusión de validadores comprometa la privacidad, Zama emplea un protocolo FHE de umbral (basado en su investigación Noah’s Ark) con "inundación de ruido" para hacer seguras las descifraciones parciales. Solo si un quórum suficiente de validadores coopera se puede recuperar un texto plano, por ejemplo, para atender una solicitud de lectura. Sin embargo, en operación normal, ningún nodo individual ve texto plano; los datos permanecen cifrados on-chain en todo momento.

El control de acceso es otro componente crucial. Las implementaciones de FHE-VM incluyen controles detallados para gestionar quién (si es que alguien) puede activar descifrados o acceder a ciertos campos cifrados. Por ejemplo, la fhEVM de Cypher admite Listas de Control de Acceso en textos cifrados, permitiendo a los desarrolladores especificar qué direcciones o contratos pueden interactuar o recifrar ciertos datos. Algunos frameworks admiten el recifrado: la capacidad de transferir un valor cifrado de la clave de un usuario a la de otro sin exponer el texto plano. Esto es útil para cosas como mercados de datos, donde un propietario de datos puede cifrar un conjunto de datos con su clave y, tras la compra, recifrarlo a la clave del comprador, todo on-chain, sin descifrarlo públicamente.

Garantizando la Corrección y la Privacidad​

Uno podría preguntarse: si todos los datos están cifrados, ¿cómo hacemos cumplir la corrección de la lógica del contrato? ¿Cómo puede la cadena prevenir operaciones inválidas si no puede "ver" los valores? El FHE por sí solo no proporciona una prueba de corrección: los validadores pueden realizar los pasos homomórficos, pero no pueden saber inherentemente si la entrada cifrada de un usuario fue válida o si se debe tomar una bifurcación condicional, etc., sin descifrar. Las pruebas de conocimiento cero (ZKPs) pueden complementar el FHE para resolver esta brecha. En una FHE-VM, típicamente los usuarios deben proporcionar una prueba ZK que certifique ciertas condiciones del texto plano cuando sea necesario. El diseño de Zama, por ejemplo, utiliza una Prueba ZK de Conocimiento de Texto Plano (ZKPoK) para acompañar cada entrada cifrada. Esto prueba que el usuario conoce el texto plano correspondiente a su texto cifrado y que cumple con los criterios esperados, sin revelar el texto plano en sí. Dichos "textos cifrados certificados" evitan que un usuario malicioso envíe un cifrado mal formado o un valor fuera de rango. De manera similar, para operaciones que requieren una decisión (por ejemplo, asegurar que el saldo de la cuenta ≥ monto del retiro), el usuario puede proporcionar una prueba ZK de que esta condición se cumple en los textos planos antes de que se ejecute la operación cifrada. De esta manera, la cadena no descifra ni ve los valores, pero gana confianza en que las transacciones cifradas siguen las reglas.

Otro enfoque en los rollups FHE es realizar una validación off-chain con ZKPs. Fhenix (un rollup L2 que usa FHE) opta por un modelo optimista donde un componente de red separado llamado Red de Servicio de Umbral puede descifrar o verificar resultados cifrados, y cualquier cómputo incorrecto puede ser desafiado con una prueba de fraude. En general, combinar FHE + ZK o pruebas de fraude asegura que la ejecución cifrada permanezca sin confianza. Los validadores descifran colectivamente solo cuando están autorizados, o verifican pruebas de que cada transición de estado cifrada fue válida sin necesidad de ver el texto plano.

Consideraciones de rendimiento: Las operaciones FHE son computacionalmente pesadas, muchos órdenes de magnitud más lentas que la aritmética normal. Por ejemplo, una simple suma de 64 bits en Ethereum cuesta ~3 gas, mientras que una suma en un entero cifrado de 64 bits (euint64) bajo la FHEVM de Zama cuesta aproximadamente 188,000 gas. Incluso una suma de 8 bits puede costar ~94k gas. Esta enorme sobrecarga significa que una implementación directa en los nodos existentes sería imprácticamente lenta y costosa. Los proyectos de FHE-VM abordan esto con bibliotecas criptográficas optimizadas (como la biblioteca TFHE-rs de Zama para el bootstrapping de compuertas binarias) y modificaciones personalizadas de EVM para el rendimiento. Por ejemplo, el cliente Geth modificado de Cypher agrega nuevos opcodes y optimiza la ejecución de instrucciones homomórficas en C++/ensamblador para minimizar la sobrecarga. Sin embargo, lograr un rendimiento utilizable requiere aceleración. El trabajo en curso incluye el uso de GPUs, FPGAs e incluso chips fotónicos especializados para acelerar los cómputos FHE. Zama informa que su rendimiento FHE mejoró 100 veces desde 2024 y apunta a miles de TPS con aceleración por GPU/FPGA. Servidores coprocesadores FHE dedicados (como el LightLocker Node de Optalysys) pueden conectarse a los nodos validadores para descargar operaciones cifradas al hardware, soportando >100 transferencias ERC-20 cifradas por segundo por nodo. A medida que el hardware y los algoritmos mejoren, la brecha entre el FHE y el cómputo en texto plano se reducirá, permitiendo que los contratos privados se acerquen a velocidades más prácticas.

Compatibilidad: Un objetivo clave de los diseños de FHE-VM es mantener la compatibilidad con los flujos de trabajo de desarrollo existentes. Las implementaciones de fhEVM de Cypher y Zama permiten a los desarrolladores escribir contratos en Solidity con cambios mínimos, utilizando una biblioteca para declarar tipos y operaciones cifradas. El resto de la cadena de herramientas de Ethereum (Remix, Hardhat, etc.) todavía se puede utilizar, ya que las modificaciones subyacentes se encuentran principalmente a nivel de cliente/nodo. Esto reduce la barrera de entrada: los desarrolladores no necesitan ser expertos en criptografía para escribir un contrato inteligente confidencial. Por ejemplo, una simple suma de dos números se puede escribir como euint32 c = a + b; y la FHEVM se encargará de los detalles específicos del cifrado tras bambalinas. Los contratos pueden incluso interoperar con contratos normales; por ejemplo, un contrato cifrado podría generar un resultado descifrado para un contrato estándar si se desea, permitiendo una mezcla de partes privadas y públicas en un ecosistema.

Proyectos FHE-VM Actuales: Varios proyectos son pioneros en este espacio. Zama (una startup de FHE con sede en París) desarrolló el concepto central de FHEVM y las bibliotecas (TFHE-rs y una biblioteca fhevm-solidity). No tienen la intención de lanzar su propia cadena, sino de proporcionar infraestructura a otros. Inco es una blockchain L1 (construida sobre Cosmos SDK con Evmos) que integró la FHEVM de Zama para crear una cadena confidencial modular. Sus redes de prueba (llamadas Gentry y Paillier) muestran transferencias ERC-20 cifradas y otras primitivas DeFi privadas. Fhenix es un rollup optimista de Capa 2 de Ethereum que utiliza FHE para la privacidad. Se decidieron por un enfoque optimista (prueba de fraude) en lugar de un ZK-rollup debido al alto costo de hacer FHE y ZK juntos para cada bloque. Fhenix utiliza la misma biblioteca TFHE-rs (con algunas modificaciones) e introduce una Red de Servicio de Umbral para manejar los descifrados de manera descentralizada. También hay equipos independientes como Fhenix (ahora renombrado) y startups que exploran híbridos de MPC + FHE. Además, Cypher (de Z1 Labs) está construyendo una red de Capa 3 centrada en IA y privacidad, utilizando una fhEVM con características como almacenes secretos y soporte para aprendizaje federado. El ecosistema es incipiente pero está creciendo rápidamente, impulsado por una financiación significativa; por ejemplo, Zama se convirtió en un "unicornio" con más de $130M recaudados para 2025 para avanzar en la tecnología FHE.

En resumen, una FHE-VM permite contratos inteligentes que preservan la privacidad al ejecutar toda la lógica sobre datos cifrados on-chain. Este paradigma garantiza la máxima confidencialidad —nada sensible se expone nunca en las transacciones o el estado— mientras aprovecha el consenso de la blockchain existente para la integridad. El costo es una mayor carga computacional para los validadores y complejidad en la gestión de claves y la integración de pruebas. A continuación, exploramos un paradigma alternativo que descarga el cómputo completamente off-chain y solo utiliza la cadena para la verificación: el coprocesador de conocimiento cero.

Coprocesadores de Conocimiento Cero (Coprocesadores ZK)​

Un coprocesador ZK es un nuevo patrón de arquitectura de blockchain donde los cómputos costosos se realizan off-chain, y una prueba de conocimiento cero sucinta de su corrección se verifica on-chain. Esto permite que los contratos inteligentes aprovechen una potencia computacional y datos mucho mayores de lo que permitiría la ejecución on-chain, sin sacrificar la falta de confianza (trustlessness). El término coprocesador se utiliza por analogía con los coprocesadores de hardware (como un coprocesador matemático o una GPU) que manejan tareas especializadas para una CPU. Aquí, la "CPU" de la blockchain (la VM nativa como la EVM) delega ciertas tareas a un sistema de prueba de conocimiento cero que actúa como un coprocesador criptográfico. El coprocesador ZK devuelve un resultado y una prueba de que el resultado se calculó correctamente, que el contrato on-chain puede verificar y luego usar.

Arquitectura y Flujo de Trabajo​

En una configuración típica, un desarrollador de dApp identifica partes de la lógica de su aplicación que son demasiado costosas o complejas para la ejecución on-chain (por ejemplo, grandes cómputos sobre datos históricos, algoritmos pesados, inferencia de modelos de ML, etc.). Implementan esas partes como un programa off-chain (en un lenguaje de alto nivel o un DSL de circuito) que puede producir una prueba de conocimiento cero de su ejecución. El componente on-chain es un contrato inteligente verificador que comprueba las pruebas y pone los resultados a disposición del resto del sistema. El flujo se puede resumir en:

1. Solicitud – El contrato on-chain desencadena una solicitud para que se realice un cierto cómputo off-chain. Esto podría ser iniciado por una transacción de usuario o por un contrato que llama a la interfaz del coprocesador ZK. Por ejemplo, un contrato DeFi podría llamar a “proveInterestRate(currentState)” o un usuario llama a “queryHistoricalData(query)”.
2. Ejecución y Prueba Off-Chain – Un servicio off-chain (que podría ser una red descentralizada de probadores o un servicio de confianza, dependiendo del diseño) recoge la solicitud. Reúne los datos necesarios (estado on-chain, entradas off-chain, etc.) y ejecuta el cómputo en una Máquina Virtual ZK (ZKVM) o circuito especial. Durante la ejecución, se genera una traza de prueba. Al final, el servicio produce una prueba sucinta (por ejemplo, un SNARK o STARK) que atestigua que “Calcular la función F sobre la entrada X produce la salida Y” y opcionalmente atestigua la integridad de los datos (más sobre esto a continuación).
3. Verificación On-Chain – La prueba y el resultado se devuelven a la blockchain (a menudo a través de una función de devolución de llamada o callback). El contrato verificador comprueba la validez de la prueba utilizando una verificación criptográfica eficiente (comprobaciones de emparejamiento, etc.). Si es válida, el contrato puede ahora confiar en la salida Y como correcta. El resultado puede almacenarse en el estado, emitirse como un evento o introducirse en la lógica posterior del contrato. Si la prueba es inválida o no se proporciona en un cierto tiempo, la solicitud puede considerarse fallida (y potencialmente se activa alguna lógica de respaldo o de tiempo de espera).

Figura 1: Arquitectura de un Coprocesador ZK (ejemplo de Bonsai de RISC Zero). Off-chain, un programa se ejecuta en una ZKVM con entradas de la llamada al contrato inteligente. Se devuelve una prueba de ejecución on-chain a través de un contrato relay, que invoca una devolución de llamada (callback) con los resultados verificados.

Críticamente, el costo de gas on-chain para la verificación es constante (o crece muy lentamente) independientemente de cuán complejo fue el cómputo off-chain. Verificar una prueba sucinta podría costar del orden de unos cientos de miles de gas (una fracción de un bloque de Ethereum), pero esa prueba podría representar millones de pasos computacionales realizados off-chain. Como bromeó un desarrollador, “¿Quieres probar una firma digital? ~$15. ¿Quieres probar un millón de firmas? También ~$15.”. Esta escalabilidad es una gran ventaja: las dApps pueden ofrecer funcionalidades complejas (análisis de big data, modelos financieros elaborados, etc.) sin congestionar la blockchain.

Los componentes principales de un sistema de coprocesador ZK son:

• Entorno de Generación de Pruebas: Puede ser una ZKVM de propósito general (capaz de ejecutar programas arbitrarios) o circuitos personalizados adaptados a cómputos específicos. Los enfoques varían:

  • Algunos proyectos utilizan circuitos hechos a mano para cada consulta o función soportada (maximizando la eficiencia para esa función).
  • Otros proporcionan un Lenguaje Específico de Dominio (DSL) o un DSL Embebido que los desarrolladores usan para escribir su lógica off-chain, que luego se compila en circuitos (equilibrando la facilidad de uso y el rendimiento).
  • El enfoque más flexible es una zkVM: una máquina virtual (a menudo basada en arquitecturas RISC) donde los programas se pueden escribir en lenguajes estándar (Rust, C, etc.) y probarse automáticamente. Esto sacrifica el rendimiento (simular una CPU en un circuito agrega sobrecarga) por la máxima experiencia del desarrollador.

• Acceso e Integridad de los Datos: Un desafío único es alimentar el cómputo off-chain con los datos correctos, especialmente si esos datos residen en la blockchain (bloques pasados, estados de contratos, etc.). Una solución ingenua es que el probador lea de un nodo de archivo y confíe en él, pero eso introduce suposiciones de confianza. En cambio, los coprocesadores ZK suelen probar que cualquier dato on-chain utilizado fue auténtico al vincularlo a pruebas de Merkle o compromisos de estado. Por ejemplo, el programa de consulta podría tomar un número de bloque y una prueba de Merkle de una ranura de almacenamiento o transacción, y el circuito verificará esa prueba contra un hash de encabezado de bloque conocido. Existen tres patrones:

  1. Datos en Línea: Poner los datos necesarios on-chain (como entrada al verificador) para que puedan ser verificados directamente. Esto es muy costoso para grandes volúmenes de datos y socava todo el propósito.
  2. Confiar en un Oráculo: Hacer que un servicio de oráculo alimente los datos a la prueba y los certifique. Esto es más simple pero reintroduce la confianza en un tercero.
  3. Probar la Inclusión de Datos vía ZK: Incorporar pruebas de inclusión de datos en el historial de la cadena dentro del propio circuito de conocimiento cero. Esto aprovecha el hecho de que cada encabezado de bloque de Ethereum se compromete con todo el estado anterior (a través de la raíz de estado) y el historial de transacciones. Al verificar las pruebas de Merkle Patricia de los datos dentro del circuito, la prueba de salida asegura al contrato que “este cómputo utilizó datos genuinos de la blockchain del bloque N” sin necesidad de confianza adicional.

  El tercer enfoque es el más trustless y es utilizado por coprocesadores ZK avanzados como Axiom y Xpansion (aumenta el costo de la prueba, pero es preferible por seguridad). Por ejemplo, el sistema de Axiom modela la estructura de bloques de Ethereum, el trie de estado y el trie de transacciones dentro de sus circuitos, por lo que puede probar afirmaciones como “la cuenta X tenía un saldo Y en el bloque N” o “una transacción con ciertas propiedades ocurrió en el bloque N”. Aprovecha el hecho de que, dado un hash de bloque reciente de confianza, se puede probar recursivamente la inclusión de datos históricos sin confiar en ninguna parte externa.

• Contrato Verificador: Este contrato on-chain contiene la clave de verificación y la lógica para aceptar o rechazar pruebas. Para SNARKs como Groth16 o PLONK, el verificador podría hacer algunos emparejamientos de curvas elípticas; para STARKs, podría hacer algunos cómputos de hash. Las optimizaciones de rendimiento como la agregación y la recursión pueden minimizar la carga on-chain. Por ejemplo, Bonsai de RISC Zero utiliza un envoltorio de STARK a SNARK: ejecuta una VM basada en STARK off-chain por velocidad, pero luego genera una pequeña prueba SNARK que atestigua la validez del STARK. Esto reduce el tamaño de la prueba de cientos de kilobytes a unos pocos cientos de bytes, haciendo que la verificación on-chain sea factible y barata. El verificador de Solidity entonces solo comprueba el SNARK (que es una operación de tiempo constante).

En términos de despliegue, los coprocesadores ZK pueden funcionar como redes similares a la capa 2 o como servicios puramente off-chain. Algunos, como Axiom, comenzaron como un servicio especializado para Ethereum (con el respaldo de Paradigm) donde los desarrolladores envían consultas a la red de probadores de Axiom y obtienen pruebas on-chain. El eslogan de Axiom era proporcionar a los contratos de Ethereum “acceso sin confianza a todos los datos on-chain y cómputo expresivo arbitrario sobre ellos”. Actúa efectivamente como un oráculo de consultas donde las respuestas son verificadas por ZKPs en lugar de confianza. Otros, como Bonsai de RISC Zero, ofrecen una plataforma más abierta: cualquier desarrollador puede subir un programa (compilado a una ZKVM compatible con RISC-V) y usar el servicio de pruebas de Bonsai a través de un contrato relay. El patrón de relay, como se ilustra en la Figura 1, implica un contrato que media las solicitudes y respuestas: el contrato de la dApp llama al relay para solicitar una prueba, el servicio off-chain escucha esto (por ejemplo, a través de un evento o una llamada directa), calcula la prueba, y luego el relay invoca una función de devolución de llamada en el contrato de la dApp con el resultado y la prueba. Este modelo asíncrono es necesario porque la prueba puede tardar desde segundos hasta minutos dependiendo de la complejidad. Introduce una latencia (y una suposición de liveness de que el probador responderá), mientras que los cómputos de FHE-VM ocurren sincrónicamente dentro de un bloque. Diseñar la aplicación para manejar este flujo de trabajo asíncrono (posiblemente similar a las respuestas de un Oráculo) es parte del uso de un coprocesador ZK.

Proyectos Notables de Coprocesadores ZK​

• Axiom: Axiom es un coprocesador ZK diseñado para Ethereum, enfocado originalmente en probar consultas de datos on-chain históricos. Utiliza el framework de pruebas Halo2 (un SNARK tipo Plonk) para crear pruebas que incorporan las estructuras criptográficas de Ethereum. En el sistema de Axiom, un desarrollador puede consultar cosas como “¿cuál era el estado del contrato X en el bloque N?” o realizar un cómputo sobre todas las transacciones en un rango. Por debajo, los circuitos de Axiom tuvieron que implementar la lógica de estado/trie de Ethereum, incluso realizando operaciones de curva elíptica y verificación de SNARK dentro del circuito para soportar la recursión. Trail of Bits, en una auditoría, señaló la complejidad de los circuitos Halo2 de Axiom que modelan bloques y estados completos. Después de la auditoría, Axiom generalizó su tecnología en una OpenVM, permitiendo que código Rust arbitrario sea probado con la misma infraestructura basada en Halo2. (Esto refleja la tendencia de pasar de circuitos específicos de dominio a un enfoque de ZKVM más general). El equipo de Axiom demostró consultas ZK que Ethereum nativamente no puede hacer, permitiendo un acceso sin estado a cualquier dato histórico con integridad criptográfica. También han enfatizado la seguridad, detectando y corrigiendo errores de circuitos sub-restringidos y asegurando la solidez. Aunque el producto inicial de Axiom fue cerrado durante su pivote, su enfoque sigue siendo un hito en los coprocesadores ZK.

• RISC Zero Bonsai: RISC Zero es una ZKVM basada en la arquitectura RISC-V. Su zkVM puede ejecutar programas arbitrarios (escritos en Rust, C++ y otros lenguajes compilados a RISC-V) y producir una prueba STARK de la ejecución. Bonsai es el servicio en la nube de RISC Zero que proporciona esta prueba bajo demanda, actuando como un coprocesador para contratos inteligentes. Para usarlo, un desarrollador escribe un programa (digamos una función que realiza matemáticas complejas o verifica una respuesta de API off-chain), lo sube al servicio Bonsai y despliega un contrato verificador correspondiente. Cuando el contrato necesita ese cómputo, llama al relay de Bonsai que desencadena la generación de la prueba y devuelve el resultado a través de una devolución de llamada. Una aplicación de ejemplo demostrada fue el cómputo de gobernanza off-chain: RISC Zero mostró una DAO usando Bonsai para contar votos y calcular métricas de votación complejas off-chain, y luego publicar una prueba para que el contrato Gobernador on-chain pudiera confiar en el resultado con un costo de gas mínimo. La tecnología de RISC Zero enfatiza que los desarrolladores pueden usar paradigmas de programación familiares —por ejemplo, escribir una función en Rust para calcular algo— y el trabajo pesado de la creación de circuitos es manejado por la zkVM. Sin embargo, las pruebas pueden ser grandes, por lo que, como se señaló anteriormente, implementaron una compresión SNARK para la verificación on-chain. En agosto de 2023, verificaron con éxito pruebas de RISC Zero en la red de prueba Sepolia de Ethereum, con un costo del orden de 300k de gas por prueba. Esto abre la puerta para que las dApps de Ethereum usen Bonsai hoy como una solución de escalado y privacidad. (Bonsai todavía está en alfa, no listo para producción, y utiliza una configuración SNARK temporal sin una ceremonia).

• Otros: Existen numerosos otros actores e iniciativas de investigación. Expansion/Xpansion (como se menciona en un blog) utiliza un enfoque de DSL embebido, donde los desarrolladores pueden escribir consultas sobre datos on-chain con un lenguaje especializado, y este se encarga internamente de la generación de pruebas. Cairo de StarkWare y zkEVM de Polygon son VMs de ZK-rollup más generales, pero su tecnología podría ser reutilizada para un uso similar a un coprocesador al verificar pruebas dentro de contratos L1. También vemos proyectos en el dominio de ZKML (ZK Machine Learning), que actúan efectivamente como coprocesadores para verificar la inferencia de modelos de ML o los resultados de entrenamiento on-chain. Por ejemplo, una configuración de zkML puede probar que “una inferencia de red neuronal sobre entradas privadas produjo la clasificación X” sin revelar las entradas ni realizar el cómputo on-chain. Estos son casos especiales del concepto de coprocesador aplicado a la IA.

Suposiciones de confianza: Los coprocesadores ZK se basan en la solidez de las pruebas criptográficas. Si el sistema de prueba es seguro (y cualquier configuración de confianza se realiza honestamente), entonces una prueba aceptada garantiza que el cómputo fue correcto. No se necesita confianza adicional en el probador; incluso un probador malicioso no puede convencer al verificador de una afirmación falsa. Sin embargo, existe una suposición de liveness: alguien debe realizar realmente el cómputo off-chain y producir la prueba. En la práctica, esto podría ser una red descentralizada (con incentivos o tarifas para hacer el trabajo) o un único operador de servicio. Si nadie proporciona la prueba, la solicitud on-chain podría quedar sin resolver. Otro aspecto sutil de confianza es la disponibilidad de datos para entradas off-chain que no están en la blockchain. Si el cómputo depende de algunos datos privados o externos, el verificador no puede saber si esos datos se proporcionaron honestamente a menos que se utilicen medidas adicionales (como compromisos de datos o firmas de oráculos). Pero para cómputos de datos puramente on-chain, los mecanismos descritos aseguran una falta de confianza equivalente a la de la propia cadena (Axiom argumentó que sus pruebas ofrecen "seguridad criptográficamente equivalente a Ethereum" para consultas históricas).

Privacidad: Las pruebas de conocimiento cero también soportan inherentemente la privacidad: el probador puede mantener las entradas ocultas mientras prueba afirmaciones sobre ellas. En un contexto de coprocesador, esto significa que una prueba puede permitir que un contrato utilice un resultado que se derivó de datos privados. Por ejemplo, una prueba podría mostrar “la puntuación de crédito del usuario > 700, por lo tanto, aprobar el préstamo” sin revelar la puntuación de crédito real o los datos brutos. El caso de uso de Axiom se centraba más en datos públicamente conocidos (historial de la blockchain), por lo que la privacidad no era el foco allí. Pero la zkVM de RISC Zero podría usarse para probar afirmaciones sobre datos secretos proporcionados por un usuario: los datos permanecen off-chain y solo el resultado necesario va on-chain. Vale la pena señalar que, a diferencia del FHE, una prueba ZK no suele proporcionar confidencialidad continua del estado; es una prueba única. Si un flujo de trabajo necesita mantener un estado secreto a través de transacciones, se podría construir haciendo que el contrato almacene un compromiso con el estado y cada prueba muestre una transición de estado válida del compromiso antiguo al nuevo, con los secretos ocultos. Así es esencialmente como funcionan los zk-rollups para transacciones privadas (como Aztec o Zcash). Por lo tanto, los coprocesadores ZK pueden facilitar máquinas de estado totalmente privadas, pero la implementación no es trivial; a menudo se utilizan para cómputos únicos donde la entrada o la salida (o ambas) pueden ser privadas según sea necesario.

Experiencia del desarrollador: Usar un coprocesador ZK generalmente requiere aprender nuevas herramientas. Escribir circuitos personalizados (opción (1) anterior) es bastante complejo y generalmente solo se hace para propósitos específicos. Opciones de nivel superior como los DSLs o las zkVMs facilitan la vida pero aún agregan sobrecarga: el desarrollador debe escribir y desplegar código off-chain y gestionar la interacción. A diferencia de la FHE-VM, donde el cifrado se maneja principalmente tras bambalinas y el desarrollador escribe código de contrato inteligente normal, aquí el desarrollador necesita particionar su lógica y posiblemente escribir en un lenguaje diferente (Rust, etc.) para la parte off-chain. Sin embargo, iniciativas como los DSLs Noir, Leo, Circom o el enfoque de RISC Zero están mejorando rápidamente la accesibilidad. Por ejemplo, RISC Zero proporciona plantillas e integración con Foundry de tal manera que un desarrollador puede simular su código off-chain localmente (para la corrección) y luego conectarlo sin problemas a las pruebas de Solidity a través de la devolución de llamada de Bonsai. Con el tiempo, podemos esperar frameworks de desarrollo que abstraigan si una pieza de lógica se ejecuta a través de una prueba ZK o on-chain; el compilador o las herramientas podrían decidir en función del costo.

FHE-VM vs Coprocesador ZK: Comparación​

Tanto las FHE-VMs como los coprocesadores ZK permiten una forma de “cómputo sobre datos privados con garantía on-chain”, pero difieren fundamentalmente en su arquitectura. La siguiente tabla resume las diferencias clave:

Aspecto	FHE-VM (Ejecución Cifrada On-Chain)	Coprocesador ZK (Prueba Off-Chain)
Dónde ocurre el cómputo	Directamente on-chain (todos los nodos ejecutan operaciones homomórficas sobre textos cifrados).	Off-chain (un probador o red ejecuta el programa; solo se verifica una prueba on-chain).
Confidencialidad de los datos	Cifrado completo: los datos permanecen cifrados en todo momento on-chain; los validadores nunca ven texto plano. Solo los poseedores de las claves de descifrado pueden descifrar las salidas.	Conocimiento cero: las entradas privadas del probador nunca se revelan on-chain; la prueba no revela secretos más allá de lo que está en las salidas públicas. Sin embargo, cualquier dato utilizado en el cómputo que deba afectar el estado on-chain debe codificarse en la salida o en un compromiso. Los secretos permanecen off-chain por defecto.
Modelo de confianza	Confianza en la ejecución por consenso y la criptografía: si la mayoría de los validadores sigue el protocolo, la ejecución cifrada es determinista y correcta. No se necesita confianza externa para la corrección del cómputo (todos los nodos lo recalculan). Se debe confiar en la seguridad del esquema FHE (generalmente basado en la dureza de los problemas de retículos) para la privacidad. En algunos diseños, también se confía en que no ocurra una colusión de suficientes validadores para hacer un mal uso de las claves de umbral.	Confianza en la seguridad del sistema de prueba (solidez de SNARK/STARK). Si la prueba se verifica, el resultado es correcto con certeza criptográfica. Los probadores off-chain no pueden engañar a las matemáticas. Hay una suposición de liveness sobre los probadores para que realmente hagan el trabajo. Si se utiliza una configuración de confianza (por ejemplo, SRS de SNARK), se debe confiar en que se generó honestamente o usar sistemas transparentes/sin configuración.
Costo on-chain y escalabilidad	Alto costo por transacción: Las operaciones homomórficas son extremadamente costosas computacionalmente, y cada nodo debe realizarlas. Los costos de gas son altos (por ejemplo, más de 100k de gas por una sola suma de 8 bits). Los contratos complejos están limitados por lo que cada validador puede calcular en un bloque. El rendimiento es mucho menor que el de los contratos inteligentes normales a menos que se emplee hardware especializado. La escalabilidad se mejora con criptografía más rápida y aceleración por hardware, pero fundamentalmente cada operación aumenta la carga de trabajo de la cadena.	Bajo costo de verificación: Verificar una prueba sucinta es eficiente y de tamaño constante, por lo que el gas on-chain es modesto (cientos de miles de gas para cualquier tamaño de cómputo). Esto desacopla la complejidad de los límites de recursos on-chain: los grandes cómputos no tienen un costo on-chain adicional. Por lo tanto, escala en términos de carga on-chain. Off-chain, el tiempo de prueba puede ser significativo (minutos o más para tareas enormes) y podría requerir máquinas potentes, pero esto no ralentiza directamente la blockchain. El rendimiento general puede ser alto siempre que las pruebas se puedan generar a tiempo (potenciales redes de probadores en paralelo).
Latencia	Los resultados están disponibles inmediatamente en la misma transacción/bloque, ya que el cómputo ocurre durante la ejecución. Sin viajes de ida y vuelta adicionales: operación síncrona. Sin embargo, un mayor tiempo de procesamiento de bloques podría aumentar la latencia de la blockchain si las operaciones FHE son lentas.	Inherente asíncrono. Típicamente requiere una transacción para solicitar y una transacción posterior (o devolución de llamada) para proporcionar la prueba/resultado. Esto introduce un retraso (posiblemente de segundos a horas dependiendo de la complejidad de la prueba y el hardware de prueba). No es adecuado para la finalidad instantánea de una sola transacción, más bien un modelo de trabajo asíncrono.
Garantías de privacidad	Fuerte: Todo (entradas, salidas, estado intermedio) puede permanecer cifrado on-chain. Puedes tener un estado cifrado de larga duración que múltiples transacciones actualizan sin revelarlo nunca. Solo las acciones de descifrado autorizadas (si las hay) revelan las salidas, y estas pueden controlarse mediante claves/ACLs. Sin embargo, consideraciones de canal lateral como el uso de gas o los registros de eventos deben gestionarse para que no filtren patrones (los diseños de fhEVM se esfuerzan por una ejecución ajena a los datos con gas constante para las operaciones para evitar fugas).	Selectiva: La prueba revela lo que sea que esté en las salidas públicas o sea necesario para verificar (por ejemplo, un compromiso con el estado inicial). Los diseñadores pueden asegurarse de que solo se revele el resultado previsto, y todas las demás entradas permanezcan ocultas con conocimiento cero. Pero a diferencia del FHE, la blockchain típicamente no almacena el estado oculto; la privacidad se logra manteniendo los datos completamente off-chain. Si se necesita un estado privado persistente, el contrato puede almacenar un compromiso criptográfico con él (de modo que las actualizaciones de estado aún revelan un nuevo compromiso cada vez). La privacidad está limitada por lo que eliges probar; tienes flexibilidad para probar, por ejemplo, que se cumplió un umbral sin revelar valores exactos.
Aplicación de la integridad	Por diseño, todos los validadores recalculan el siguiente estado homomórficamente, por lo que si un actor malicioso proporciona un resultado de texto cifrado incorrecto, otros detectarán una discrepancia: el consenso falla a menos que todos obtengan el mismo resultado. Por lo tanto, la integridad se aplica mediante la ejecución redundante (como en una blockchain normal, solo que con datos cifrados). A menudo se utilizan pruebas ZK adicionales para hacer cumplir las reglas de negocio (por ejemplo, que un usuario no pudo violar una restricción) porque los validadores no pueden verificar directamente las condiciones del texto plano.	La integridad es aplicada por el contrato verificador que comprueba la prueba ZK. Mientras la prueba se verifique, se garantiza que el resultado es consistente con alguna ejecución válida del programa off-chain. No se necesita una suposición de mayoría honesta para la corrección; incluso un solo verificador honesto (el propio código del contrato) es suficiente. El contrato on-chain simplemente rechazará cualquier prueba falsa o faltante (similar a como rechazaría una firma inválida). Una consideración: si el probador aborta o se retrasa, el contrato puede necesitar una lógica de respaldo (o los usuarios pueden necesitar intentarlo de nuevo más tarde), pero no aceptará resultados incorrectos.
Experiencia del desarrollador	Pros: Se pueden usar en gran medida lenguajes de contratos inteligentes familiares (Solidity, etc.) con extensiones. La confidencialidad es manejada por la plataforma; los desarrolladores se preocupan principalmente por qué cifrar y quién tiene las claves. La composición de contratos cifrados y normales es posible, manteniendo la componibilidad de DeFi (solo con variables cifradas). Contras: Deben entender las limitaciones de FHE, por ejemplo, no hay saltos condicionales directos sobre datos secretos sin un manejo especial, profundidad de circuito limitada (aunque el bootstrapping en TFHE permite una longitud de cómputo arbitraria a expensas del tiempo). Depurar la lógica cifrada puede ser complicado ya que no se pueden introspeccionar fácilmente los valores en tiempo de ejecución sin la clave. Además, la gestión de claves y los permisos agregan complejidad al diseño del contrato.	Pros: Potencialmente se puede usar cualquier lenguaje de programación para la parte off-chain (especialmente con una zkVM). Aprovechar código/bibliotecas existentes en el programa off-chain (con advertencias sobre la compatibilidad con ZK). No se necesita criptografía personalizada por parte del desarrollador si se usa una ZKVM general: escriben código normal y obtienen una prueba. Además, el cómputo pesado puede usar bibliotecas (por ejemplo, código de aprendizaje automático) que nunca se ejecutarían on-chain. Contras: Los desarrolladores deben orquestar la infraestructura off-chain o usar un servicio de prueba. Manejar flujos de trabajo asíncronos e integrarlos con la lógica on-chain requiere más trabajo de diseño (por ejemplo, almacenar un estado pendiente, esperar una devolución de llamada). Escribir circuitos eficientes o código zkVM puede requerir aprender nuevas restricciones (por ejemplo, sin punto flotante, usar punto fijo o primitivas especiales; evitar ramificaciones pesadas que disparan el tiempo de prueba; optimizar para el recuento de restricciones). También existe la carga de lidiar con fallos de prueba, tiempos de espera, etc., que no son preocupaciones en Solidity regular. El ecosistema de herramientas está creciendo, pero es un nuevo paradigma para muchos.

Ambos enfoques están siendo mejorados activamente, e incluso vemos convergencia: como se señaló, las ZKPs se utilizan dentro de las FHE-VMs para ciertas verificaciones, y a la inversa, algunos investigadores proponen usar FHE para mantener privadas las entradas del probador en ZK (para que un probador en la nube no vea tus datos secretos). Es concebible que los sistemas futuros los combinen, por ejemplo, realizando FHE off-chain y luego probando la corrección de eso en la cadena, o usando FHE on-chain pero probando con ZK a los clientes ligeros que las operaciones cifradas se realizaron correctamente. Cada técnica tiene sus fortalezas: la FHE-VM ofrece privacidad continua e interacción en tiempo real a costa de un cómputo pesado, mientras que los coprocesadores ZK ofrecen escalabilidad y flexibilidad a costa de latencia y complejidad.

Casos de Uso e Implicaciones​

La llegada de la privacidad programable desbloquea una gran cantidad de nuevas aplicaciones de blockchain en todas las industrias. A continuación, exploramos cómo las FHE-VMs y los coprocesadores ZK (o híbridos) pueden potenciar diversos dominios al permitir contratos inteligentes que preservan la privacidad y una economía de datos segura.

DeFi Confidencial y Finanzas​

En las finanzas descentralizadas, la privacidad puede mitigar el front-running, proteger las estrategias de trading y satisfacer el cumplimiento normativo sin sacrificar la transparencia donde sea necesario. El DeFi Confidencial podría permitir a los usuarios interactuar con protocolos sin revelar sus posiciones al mundo.

• Transacciones Privadas y Saldos Ocultos: Usando FHE, se pueden implementar transferencias de tokens confidenciales (saldos y transacciones ERC-20 cifrados) o pools protegidos en una L1 de blockchain. Ningún observador puede ver cuánto de un token tienes o transferiste, eliminando el riesgo de ataques dirigidos basados en las tenencias. Las pruebas ZK pueden asegurar que los saldos se mantengan sincronizados y que no ocurra un doble gasto (similar a Zcash pero en plataformas de contratos inteligentes). Un ejemplo es un AMM (Creador de Mercado Automatizado) confidencial donde las reservas del pool y las operaciones están cifradas on-chain. Los arbitrajistas o front-runners no pueden explotar el pool porque no pueden observar el deslizamiento de precios hasta después de que la operación se haya liquidado, reduciendo el MEV. Solo después de un cierto retraso o a través de un mecanismo de acceso controlado se podrían revelar algunos datos para auditoría.

• Subastas y Trading Resistentes al MEV: Los mineros y los bots explotan la transparencia de las transacciones para hacer front-running en las operaciones. Con el cifrado, se podría tener un mempool cifrado o subastas por lotes donde las órdenes se envían en texto cifrado. Solo después de que la subasta se liquida, las operaciones se descifran. Este concepto, a veces llamado Flujo Justo de Órdenes, se puede lograr con descifrado de umbral (múltiples validadores descifran colectivamente el lote) o probando los resultados de la subasta a través de ZK sin revelar las ofertas individuales. Por ejemplo, un coprocesador ZK podría tomar un lote de ofertas selladas off-chain, calcular el precio de liquidación de la subasta y generar solo ese precio y los ganadores con pruebas. Esto preserva la equidad y la privacidad de las ofertas perdedoras.

• Préstamos y Derivados Confidenciales: En los préstamos DeFi, los usuarios podrían no querer revelar el tamaño de sus préstamos o colateral (puede afectar el sentimiento del mercado o invitar a la explotación). Una FHE-VM puede mantener un libro de préstamos cifrado donde los detalles de cada préstamo están cifrados. La lógica del contrato inteligente aún puede hacer cumplir reglas como las condiciones de liquidación operando sobre factores de salud cifrados. Si el ratio de colateral de un préstamo cae por debajo del umbral, el contrato (con la ayuda de pruebas ZK) puede marcarlo para liquidación sin exponer nunca los valores exactos; podría simplemente producir una bandera de sí/no en texto plano. De manera similar, las posiciones secretas de derivados u opciones podrían gestionarse on-chain, revelando solo métricas de riesgo agregadas. Esto podría prevenir el copy trading y proteger estrategias propietarias, fomentando una mayor participación institucional.

• Privacidad Conforme a la Normativa: No todos los contextos financieros desean un anonimato total; a veces se necesita una divulgación selectiva para la regulación. Con estas herramientas, podemos lograr una privacidad regulada: por ejemplo, las operaciones son privadas para el público, pero un exchange regulado puede descifrar o recibir pruebas sobre ciertas propiedades. Se podría probar a través de ZK que “esta operación no involucró una dirección en la lista negra y ambas partes están verificadas por KYC” sin revelar las identidades a la cadena. Este equilibrio podría satisfacer las reglas Anti-Lavado de Dinero (AML) mientras se mantienen confidenciales las identidades y posiciones de los usuarios para todos los demás. El FHE podría permitir que un contrato de oficial de cumplimiento on-chain escanee transacciones cifradas en busca de señales de riesgo (con una clave de descifrado accesible solo bajo orden judicial, por ejemplo).

Identidad Digital y Datos Personales​

Los sistemas de identidad pueden beneficiarse significativamente de la tecnología de privacidad on-chain. Actualmente, poner credenciales o atributos personales en un registro público es impráctico debido a las leyes de privacidad y la renuencia de los usuarios. Con FHE y ZK, la identidad auto-soberana puede realizarse de una manera que preserve la privacidad:

• Credenciales de Conocimiento Cero: Usando pruebas ZK (ya comunes en algunos proyectos de identidad), un usuario puede probar afirmaciones como “Soy mayor de 18 años”, “Tengo una licencia de conducir válida” o “Gano más de $50k (para calificación crediticia)” sin revelar ninguna otra información personal. Los coprocesadores ZK pueden mejorar esto manejando verificaciones más complejas off-chain, por ejemplo, probando que la puntuación de crédito de un usuario está por encima de un umbral consultando una base de datos de crédito privada de manera similar a Axiom, y generando solo un sí/no para la blockchain.

• KYC Confidencial en DeFi: Imagina un protocolo DeFi que por ley debe asegurarse de que los usuarios estén verificados por KYC. Con FHE-VM, las credenciales de un usuario pueden almacenarse cifradas on-chain (o referenciadas a través de DID), y un contrato inteligente puede realizar un cómputo FHE para verificar que la información KYC cumple con los requisitos. Por ejemplo, un contrato podría verificar homomórficamente que el nombre y el SSN en un perfil de usuario cifrado coinciden con una lista de usuarios sancionados (también cifrada), o que el país del usuario no está restringido. El contrato solo obtendría un "aprobado/fallido" cifrado que puede ser descifrado por umbral por los validadores de la red a una bandera booleana. Solo se revela el hecho de que el usuario está permitido o no, preservando la confidencialidad de la PII y alineándose con los principios del GDPR. Esta divulgación selectiva garantiza el cumplimiento y la privacidad.

• Acceso Basado en Atributos y Divulgación Selectiva: Los usuarios podrían tener un conjunto de credenciales verificables (edad, ciudadanía, habilidades, etc.) como atributos cifrados. Pueden autorizar a ciertas dApps a ejecutar cómputos sobre ellos sin divulgar todo. Por ejemplo, una dApp de reclutamiento descentralizada podría filtrar candidatos realizando búsquedas en currículums cifrados (usando FHE), por ejemplo, contar años de experiencia, verificar una certificación, y solo si se encuentra una coincidencia, contactar al candidato off-chain. Los detalles privados del candidato permanecen cifrados a menos que elijan revelarlos. Las pruebas ZK también pueden permitir a los usuarios probar selectivamente que poseen una combinación de atributos (por ejemplo, mayor de 21 y dentro de un cierto código postal) sin revelar los valores reales.

• Verificación de Identidad Multipartita: A veces, la identidad de un usuario necesita ser verificada por múltiples partes (digamos, una verificación de antecedentes por la empresa A, una verificación de crédito por la empresa B). Con herramientas homomórficas y ZK, cada verificador podría contribuir con una puntuación o aprobación cifrada, y un contrato inteligente puede agregarlas a una decisión final sin exponer las contribuciones individuales. Por ejemplo, tres agencias proporcionan bits de "aprobado/fallido" cifrados, y el contrato emite una aprobación si las tres son aprobadas; el usuario o la parte que confía solo ve el resultado final, no qué agencia específica podría haberlos reprobado, preservando la privacidad del registro del usuario en cada agencia. Esto puede reducir el sesgo y el estigma asociados con, por ejemplo, una verificación fallida que revela un problema específico.

Salud y Compartición de Datos Sensibles​

Los datos de salud son altamente sensibles y regulados, sin embargo, combinar datos de múltiples fuentes puede desbloquear un valor enorme (para investigación, seguros, medicina personalizada). La blockchain podría proporcionar una capa de confianza para el intercambio de datos si se resuelve la privacidad. Los contratos inteligentes confidenciales podrían permitir nuevos ecosistemas de datos de salud:

• Intercambio Seguro de Datos Médicos: Los pacientes podrían almacenar referencias a sus registros médicos on-chain en forma cifrada. Un contrato habilitado para FHE podría permitir a una institución de investigación ejecutar análisis sobre una cohorte de datos de pacientes sin descifrarlos. Por ejemplo, un contrato podría calcular la eficacia promedio de un medicamento a través de los resultados cifrados de los pacientes. Solo los resultados estadísticos agregados salen descifrados (y quizás solo si se incluye un número mínimo de pacientes, para evitar la reidentificación). Los pacientes podrían recibir micropagos por contribuir con sus datos cifrados a la investigación, sabiendo que su privacidad se preserva porque incluso la blockchain y los investigadores solo ven texto cifrado o pruebas agregadas. Esto fomenta un mercado de datos para la salud que respeta la privacidad.

• Procesamiento de Reclamaciones de Seguros que Preserva la Privacidad: El procesamiento de reclamaciones de seguros de salud podría automatizarse a través de contratos inteligentes que verifican condiciones sobre datos médicos sin exponer los datos a la aseguradora. Una reclamación podría incluir un código de diagnóstico cifrado y un costo de tratamiento cifrado; el contrato, usando FHE, verifica las reglas de la póliza (por ejemplo, cobertura, deducible) sobre esos datos cifrados. Podría generar una aprobación y un monto de pago sin revelar nunca el diagnóstico real a la blockchain de la aseguradora (solo el paciente y el médico tenían la clave). Las pruebas ZK podrían usarse para demostrar que los datos del paciente provinieron de los registros de un hospital certificado (usando algo como Axiom para verificar la firma de un hospital o la inclusión de un registro) sin revelar el registro en sí. Esto garantiza la privacidad del paciente mientras previene el fraude.

• Cómputo de Datos Genómicos y Personales: Los datos genómicos son extremadamente sensibles (son literalmente el plano de ADN de una persona). Sin embargo, analizar genomas puede proporcionar valiosos conocimientos sobre la salud. Las empresas podrían usar FHE-VM para realizar cómputos sobre genomas cifrados subidos por los usuarios. Por ejemplo, un contrato inteligente podría ejecutar un modelo de riesgo gen-ambiente sobre datos genómicos cifrados y datos ambientales cifrados (quizás de wearables), generando una puntuación de riesgo que solo el usuario puede descifrar. La lógica (quizás un algoritmo de puntuación de riesgo poligénico) está codificada en el contrato y se ejecuta homomórficamente, por lo que los datos genómicos nunca aparecen en texto plano. De esta manera, los usuarios obtienen conocimientos sin dar a las empresas datos de ADN brutos, mitigando tanto las preocupaciones de privacidad como de propiedad de los datos.

• Epidemiología y Salud Pública: Durante situaciones como pandemias, compartir datos es vital para modelar la propagación de enfermedades, pero las leyes de privacidad pueden obstaculizar el intercambio de datos. Los coprocesadores ZK podrían permitir a las autoridades de salud pública enviar consultas como “¿Cuántas personas en la región X dieron positivo en las últimas 24h?” a una red de datos de hospitales a través de pruebas. Cada hospital mantiene los registros de pruebas de los pacientes off-chain pero puede probar al contrato de la autoridad el recuento de positivos sin revelar quiénes son. De manera similar, el rastreo de contactos podría hacerse haciendo coincidir rastros de ubicación cifrados: los contratos pueden calcular intersecciones de historiales de ubicación cifrados de pacientes para identificar puntos calientes, generando solo las ubicaciones de los puntos calientes (y quizás una lista cifrada de identificaciones afectadas que solo el departamento de salud puede descifrar). Los rastros de ubicación brutos de los individuos permanecen privados.

Mercados de Datos y Colaboración​

La capacidad de computar sobre datos sin revelarlos abre nuevos modelos de negocio en torno al intercambio de datos. Las entidades pueden colaborar en cómputos sabiendo que sus datos propietarios no serán expuestos:

• Mercados de Datos Seguros: Los vendedores pueden poner datos a disposición en forma cifrada en un mercado de blockchain. Los compradores pueden pagar para ejecutar análisis específicos o modelos de aprendizaje automático sobre el conjunto de datos cifrado a través de un contrato inteligente, obteniendo ya sea el modelo entrenado o resultados agregados. Los datos brutos del vendedor nunca se revelan al comprador ni al público; el comprador podría recibir solo un modelo (que aún podría filtrar algo de información en los pesos, pero técnicas como la privacidad diferencial o el control de la granularidad de la salida pueden mitigar esto). Las pruebas ZK pueden asegurar al comprador que el cómputo se realizó correctamente sobre el conjunto de datos prometido (por ejemplo, el vendedor no puede hacer trampa ejecutando el modelo sobre datos ficticios porque la prueba lo vincula al conjunto de datos cifrado comprometido). Este escenario fomenta el intercambio de datos: por ejemplo, una empresa podría monetizar los datos de comportamiento del usuario permitiendo que algoritmos aprobados se ejecuten sobre ellos bajo cifrado, sin entregar los datos en sí.

• Aprendizaje Federado e IA Descentralizada: En el aprendizaje automático descentralizado, múltiples partes (por ejemplo, diferentes empresas o dispositivos) quieren entrenar conjuntamente un modelo con sus datos combinados sin compartir datos entre sí. Las FHE-VMs sobresalen aquí: pueden habilitar el aprendizaje federado donde las actualizaciones del modelo de cada parte se agregan homomórficamente por un contrato. Debido a que las actualizaciones están cifradas, ningún participante aprende las contribuciones de los demás. El contrato podría incluso realizar partes del bucle de entrenamiento (como los pasos de descenso de gradiente) on-chain bajo cifrado, produciendo un modelo actualizado que solo las partes autorizadas pueden descifrar. ZK puede complementar esto probando que la actualización de cada parte se calculó siguiendo el algoritmo de entrenamiento (evitando que un participante malicioso envenene el modelo). Esto significa que se puede entrenar un modelo global con total auditabilidad on-chain, pero los datos de entrenamiento de cada contribuyente permanecen privados. Los casos de uso incluyen el entrenamiento conjunto de modelos de detección de fraude entre bancos o la mejora de asistentes de IA utilizando datos de muchos usuarios sin centralizar los datos brutos.

• Análisis Inter-Organizacional: Considera dos empresas que quieren encontrar su intersección de clientes para una campaña de asociación sin exponer sus listas completas de clientes entre sí. Podrían cifrar cada una sus listas de ID de clientes y subir un compromiso. Un contrato habilitado para FHE puede calcular la intersección en los conjuntos cifrados (usando técnicas como la intersección de conjuntos privados a través de FHE). El resultado podría ser una lista cifrada de IDs de clientes comunes que solo un tercero de confianza mutua (o los propios clientes, a través de algún mecanismo) puede descifrar. Alternativamente, un enfoque ZK: una parte prueba a la otra en conocimiento cero que “tenemos N clientes en común y aquí hay un cifrado de esos IDs” con una prueba de que el cifrado corresponde efectivamente a las entradas comunes. De esta manera, pueden proceder con una campaña para esos N clientes sin intercambiar nunca sus listas completas en texto plano. Escenarios similares: calcular métricas de la cadena de suministro entre competidores sin revelar detalles de proveedores individuales, o bancos que cotejan información crediticia sin compartir datos completos de clientes.

• Cómputo Seguro Multipartito (MPC) en Blockchain: FHE y ZK esencialmente traen conceptos de MPC on-chain. La lógica de negocio compleja que abarca múltiples organizaciones puede codificarse en un contrato inteligente de tal manera que las entradas de cada organización se compartan en secreto o se cifren. El contrato (como facilitador de MPC) produce salidas como divisiones de ganancias, cálculos de costos o evaluaciones de riesgo conjuntas en las que todos pueden confiar. Por ejemplo, supongamos que varias compañías de energía quieren liquidar un mercado de comercio de energía. Podrían alimentar sus ofertas y demandas cifradas en una subasta de contrato inteligente; el contrato calcula los precios de liquidación y las asignaciones sobre las ofertas cifradas, y genera la asignación y el costo de cada compañía solo para esa compañía (a través de cifrado a su clave pública). Ninguna compañía ve las ofertas de las demás, protegiendo la información competitiva, pero el resultado de la subasta es justo y verificable. Esta combinación de transparencia de blockchain y privacidad de MPC podría revolucionar los consorcios y las alianzas empresariales que actualmente dependen de terceros de confianza.

Aprendizaje Automático Descentralizado (ZKML y FHE-ML)​

Llevar el aprendizaje automático a las blockchains de una manera verificable y privada es una frontera emergente:

• Inferencia de ML Verificable: Usando pruebas ZK, se puede probar que “un modelo de aprendizaje automático f, cuando se le da la entrada x, produce la salida y” sin revelar ni x (si son datos privados) ni el funcionamiento interno de f (si los pesos del modelo son propietarios). Esto es crucial para los servicios de IA en blockchain, por ejemplo, un oráculo de IA descentralizado que proporciona predicciones o clasificaciones. Un coprocesador ZK puede ejecutar el modelo off-chain (ya que los modelos pueden ser grandes y costosos de evaluar) y publicar una prueba del resultado. Por ejemplo, un oráculo podría probar la afirmación “La imagen satelital proporcionada muestra al menos un 50% de cobertura arbórea” para respaldar un contrato de créditos de carbono, sin revelar la imagen satelital o posiblemente incluso el modelo. Esto se conoce como ZKML y hay proyectos trabajando en la optimización de redes neuronales amigables con los circuitos. Asegura la integridad de las salidas de IA utilizadas en los contratos inteligentes (sin trampas ni salidas arbitrarias) y puede preservar la confidencialidad de los datos de entrada y los parámetros del modelo.

• Entrenamiento con Privacidad y Auditabilidad: Entrenar un modelo de ML es aún más intensivo en cómputo, pero si se logra, permitiría mercados de modelos basados en blockchain. Múltiples proveedores de datos podrían contribuir al entrenamiento de un modelo bajo FHE para que el algoritmo de entrenamiento se ejecute sobre datos cifrados. El resultado podría ser un modelo cifrado que solo el comprador puede descifrar. A lo largo del entrenamiento, se podrían suministrar pruebas ZK periódicamente para probar que el entrenamiento seguía el protocolo (evitando que un entrenador malicioso inserte una puerta trasera, por ejemplo). Si bien el entrenamiento de ML completamente on-chain está lejos dados los costos, un enfoque híbrido podría usar cómputo off-chain con pruebas ZK para partes críticas. Se podría imaginar una competencia descentralizada tipo Kaggle donde los participantes entrenan modelos en conjuntos de datos privados y envían pruebas ZK de la precisión del modelo en datos de prueba cifrados para determinar un ganador, todo sin revelar los conjuntos de datos ni los datos de prueba.

• IA Personalizada y Propiedad de los Datos: Con estas tecnologías, los usuarios podrían retener la propiedad de sus datos personales y aun así beneficiarse de la IA. Por ejemplo, el dispositivo móvil de un usuario podría usar FHE para cifrar sus datos de uso y enviarlos a un contrato de análisis que calcula un modelo de IA personalizado (como un modelo de recomendación) solo para ellos. El modelo está cifrado y solo el dispositivo del usuario puede descifrarlo y usarlo localmente. La plataforma (quizás una red social) nunca ve los datos brutos ni el modelo, pero el usuario obtiene el beneficio de la IA. Si la plataforma quiere conocimientos agregados, podría solicitar pruebas ZK de ciertos patrones agregados del contrato sin acceder a los datos individuales.

Áreas Adicionales​

• Juegos: Los juegos on-chain a menudo tienen dificultades para ocultar información secreta (por ejemplo, manos de cartas ocultas, niebla de guerra en juegos de estrategia). FHE puede habilitar juegos de estado oculto donde la lógica del juego se ejecuta sobre un estado cifrado. Por ejemplo, un contrato de juego de póker podría barajar y repartir cartas cifradas; los jugadores obtienen descifrados de sus propias cartas, pero el contrato y los demás solo ven texto cifrado. La lógica de apuestas puede usar pruebas ZK para asegurar que un jugador no está mintiendo sobre una acción (o para revelar la mano ganadora al final de una manera verificablemente justa). De manera similar, las semillas aleatorias para la acuñación de NFT o los resultados de los juegos pueden generarse y probarse como justas sin exponer la semilla (evitando la manipulación). Esto puede mejorar enormemente los juegos de blockchain, permitiéndoles soportar la misma dinámica que los juegos tradicionales.

• Votación y Gobernanza: Las DAOs podrían usar tecnología de privacidad para votaciones secretas on-chain, eliminando la compra de votos y la presión. La FHE-VM podría contar los votos que se emiten en forma cifrada, y solo los totales finales se descifran. Las pruebas ZK pueden asegurar que cada voto fue válido (provino de un votante elegible, que no ha votado dos veces) sin revelar quién votó por qué. Esto proporciona verificabilidad (todos pueden verificar las pruebas y el recuento) mientras se mantienen secretos los votos individuales, lo cual es crucial para una gobernanza imparcial.

• Cadena de Suministro Segura e IoT: En las cadenas de suministro, los socios podrían querer compartir pruebas de ciertas propiedades (origen, métricas de calidad) sin exponer todos los detalles a los competidores. Por ejemplo, un sensor de IoT en un envío de alimentos podría enviar continuamente datos de temperatura cifrados a una blockchain. Un contrato podría usar FHE para verificar si la temperatura se mantuvo en un rango seguro durante todo el tránsito. Si se excedió un umbral, puede activar una alerta o una penalización, pero no tiene que revelar todo el registro de temperatura públicamente, quizás solo una prueba o un agregado como “temperatura del percentil 90”. Esto genera confianza en la automatización de la cadena de suministro mientras se respeta la confidencialidad de los datos del proceso.

Cada uno de estos casos de uso aprovecha la capacidad central: computar o verificar datos sin revelar los datos. Esta capacidad puede cambiar fundamentalmente la forma en que manejamos la información sensible en los sistemas descentralizados. Reduce el compromiso entre la transparencia y la privacidad que ha limitado la adopción de la blockchain en áreas que tratan con datos privados.

Conclusión​

La tecnología blockchain está entrando en una nueva era de privacidad programable, donde la confidencialidad de los datos y la funcionalidad de los contratos inteligentes van de la mano. Los paradigmas de FHE-VM y coprocesadores ZK, aunque técnicamente distintos, ambos se esfuerzan por expandir el alcance de las aplicaciones de blockchain al desacoplar lo que podemos computar de lo que debemos revelar.

Las Máquinas Virtuales de Cifrado Totalmente Homomórfico mantienen los cómputos on-chain y cifrados, preservando la descentralización y la componibilidad, pero exigiendo avances en eficiencia. Los coprocesadores de Conocimiento Cero trasladan el trabajo pesado off-chain, permitiendo un cómputo virtualmente ilimitado bajo garantías criptográficas, y ya están demostrando su valía en el escalado y la mejora de Ethereum. La elección entre ellos (y sus híbridos) dependerá del caso de uso: si se necesita una interacción en tiempo real con un estado privado, un enfoque FHE podría ser más adecuado; si se requiere un cómputo extremadamente complejo o la integración con código existente, un coprocesador ZK podría ser el camino a seguir. En muchos casos, son complementarios; de hecho, vemos pruebas ZK reforzando la integridad de FHE, y FHE potencialmente ayudando a ZK al manejar datos privados para los probadores.

Para los desarrolladores, estas tecnologías introducirán nuevos patrones de diseño. Pensaremos en términos de variables cifradas y verificación de pruebas como elementos de primera clase en la arquitectura de las dApps. Las herramientas están evolucionando rápidamente: lenguajes de alto nivel y SDKs están abstrayendo los detalles criptográficos (por ejemplo, las bibliotecas de Zama que hacen que los tipos FHE sean tan fáciles como los tipos nativos, o las plantillas de RISC Zero para solicitudes de prueba). En unos pocos años, escribir un contrato inteligente confidencial podría sentirse casi tan sencillo como escribir uno regular, solo que con la privacidad "incorporada" por defecto.

Las implicaciones para la economía de datos son profundas. Los individuos y las empresas estarán más dispuestos a poner datos o lógica on-chain cuando puedan controlar su visibilidad. Esto puede desbloquear colaboraciones inter-organizacionales, nuevos productos financieros y modelos de IA que antes eran inviables debido a preocupaciones de privacidad. Los reguladores también pueden llegar a adoptar estas técnicas, ya que permiten verificaciones de cumplimiento y auditorías a través de medios criptográficos (por ejemplo, probar que los impuestos se pagan correctamente on-chain sin exponer todas las transacciones).

Todavía estamos en los primeros días: los prototipos actuales de FHE-VM tienen límites de rendimiento, y las pruebas ZK, aunque mucho más rápidas que antes, todavía pueden ser un cuello de botella para tareas extremadamente complejas. Pero la investigación continua y los esfuerzos de ingeniería (incluido el hardware especializado, como lo demuestran empresas como Optalysys que impulsan la aceleración óptica de FHE) están erosionando rápidamente estas barreras. La financiación que fluye hacia este espacio (por ejemplo, el estatus de unicornio de Zama, la inversión de Paradigm en Axiom) subraya una fuerte creencia de que las características de privacidad serán tan fundamentales para la Web3 como lo fue la transparencia para la Web1/2.

En conclusión, la privacidad programable a través de FHE-VMs y coprocesadores ZK anuncia una nueva clase de dApps que son sin confianza, descentralizadas y confidenciales. Desde operaciones DeFi que no revelan detalles, hasta investigaciones de salud que protegen los datos de los pacientes, pasando por modelos de aprendizaje automático entrenados en todo el mundo sin exponer datos brutos, las posibilidades son vastas. A medida que estas tecnologías maduren, las plataformas de blockchain ya no forzarán el compromiso entre utilidad y privacidad, permitiendo una adopción más amplia en industrias que requieren confidencialidad. El futuro de la Web3 es uno donde los usuarios y las organizaciones pueden transaccionar y computar con confianza datos sensibles on-chain, sabiendo que la blockchain verificará la integridad mientras mantiene sus secretos a salvo.

Fuentes: La información en este informe se extrae de la documentación técnica y blogs de investigación recientes de proyectos líderes en este espacio, incluyendo la documentación de FHEVM de Cypher y Zama, análisis detallados de Trail of Bits sobre los circuitos de Axiom, guías para desarrolladores y publicaciones de blog de RISC Zero, así como artículos de la industria que destacan casos de uso de la tecnología de blockchain confidencial. Estas fuentes y más han sido citadas a lo largo del texto para proporcionar lecturas adicionales y evidencia para las arquitecturas y aplicaciones descritas.