Las blockchains públicas ofrecen transparencia e integridad a costa de la privacidad: cada transacción y estado de contrato se expone a todos los participantes. Esta apertura crea problemas como los ataques de MEV (Valor Extraíble por Mineros), el copy-trading y la fuga de lógica de negocio sensible. La privacidad programable tiene como objetivo resolver estos problemas al permitir cálculos 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 Homomórfico Completo (FHE-VM) y los Coprocesadores de Conocimiento Cero (ZK). Estos enfoques permiten la computación fuera de cadena o cifrada con verificación en cadena, preservando la confidencialidad y manteniendo la corrección sin confianza. 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, atención médica, mercados de datos y aprendizaje automático descentralizado.
Máquina Virtual de Cifrado Homomórfico Completo (FHE-VM)
El Cifrado Homomórfico Completo (FHE) permite realizar cálculos arbitrarios sobre datos cifrados sin necesidad de descifrarlos. Una Máquina Virtual FHE integra esta capacidad en los contratos inteligentes de blockchain, habilitando el estado y la 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 cifradas durante toda la ejecución. Esto significa que los validadores pueden procesar transacciones y actualizar el estado sin conocer ningún valor sensible, logrando la ejecución en cadena con confidencialidad de datos.
Arquitectura y Diseño de FHE-VM
Una FHE-VM típica extiende un entorno de ejecución de contrato inteligente estándar (como la Máquina Virtual de Ethereum) con soporte nativo para tipos de datos y operaciones cifrados. Por ejemplo, la FHEVM de Zama introduce enteros cifrados (euint8, euint32, etc.), booleanos cifrados (ebool) e incluso arrays cifrados como tipos de primera clase. Los lenguajes de contratos inteligentes como Solidity se aumentan mediante librerías o nuevos opcodes para que los desarrolladores puedan realizar operaciones aritméticas (add, mul, etc.), operaciones lógicas y comparaciones directamente sobre los textos cifrados. Bajo el capó, estas operaciones invocan primitivas FHE (por ejemplo, usando la librería TFHE) para manipular bits cifrados y producir resultados cifrados.
Se admite el almacenamiento de estado cifrado para que las variables del contrato permanezcan cifradas en el estado de la blockchain. El flujo de ejecución es típicamente:
- Cifrado del Lado del Cliente: Los usuarios cifran sus entradas localmente utilizando la clave FHE pública antes de enviar transacciones. La clave de cifrado es pública (para cifrado y evaluación), 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).
- Computación Homomórfica en Cadena: Los mineros/validadores ejecutan el contrato con opcodes cifrados. Realizan las mismas operaciones homomórficas deterministas sobre los textos cifrados, de modo 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.
- Descifrado (Opcional): Si un resultado necesita ser revelado o utilizado fuera de cadena, una parte autorizada con la clave privada puede descifrar el texto cifrado de salida. De lo contrario, los resultados permanecen cifrados y pueden usarse como entradas para transacciones posteriores (permitiendo cálculos consecutivos sobre un estado cifrado persistente).
Una consideración de diseño importante es la gestión de claves. Un enfoque son las claves por usuario, donde cada usuario posee su clave secreta y solo ellos pueden descifrar los resultados relevantes para ellos. Esto maximiza la privacidad (nadie más puede descifrar sus datos), pero las operaciones homomórficas no pueden mezclar datos cifrados bajo diferentes claves sin complejos protocolos de múltiples claves. 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 en cadena, de modo que cualquiera puede 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 que los descifrados parciales sean seguros. 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 nunca el texto plano, los datos permanecen cifrados en cadena en todo momento.
El control de acceso es otro componente crucial. Las implementaciones de FHE-VM incluyen controles granulares para gestionar quién (si alguien) puede activar descifrados o acceder a ciertos campos cifrados. Por ejemplo, la fhEVM de Cypher admite Listas de Control de Acceso sobre textos cifrados, permitiendo a los desarrolladores especificar qué direcciones o contratos pueden interactuar o volver a cifrar ciertos datos. Algunos frameworks admiten la re-cifrado: 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 los mercados de datos, donde un propietario de datos puede cifrar un conjunto de datos con su clave y, al comprarlo, volver a cifrarlo con la clave del comprador, todo en cadena, sin descifrarlo públicamente.
Garantizando la Corrección y la Privacidad
Uno podría preguntarse: si todos los datos están cifrados, ¿cómo garantizamos la corrección de la lógica del contrato? ¿Cómo puede la cadena prevenir operaciones inválidas si no puede "ver" los valores? FHE por sí mismo 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 era válida o si se debería tomar una rama condicional, etc., sin descifrar. Las pruebas de conocimiento cero (ZKP) pueden complementar FHE para resolver esta brecha. En una FHE-VM, típicamente los usuarios deben proporcionar una prueba ZK que certifique ciertas condiciones de 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 malintencionado 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 ≥ cantidad de retiro), el usuario puede proporcionar una prueba ZK de que esta condición es verdadera 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 la validación fuera de cadena con ZKP. Fhenix (un rollup L2 que utiliza FHE) opta por un modelo optimista donde un componente de red separado llamado Threshold Service Network puede descifrar o verificar resultados cifrados, y cualquier cálculo incorrecto puede ser impugnado con una prueba de fraude. En general, la combinación de FHE + ZK o pruebas de fraude asegura que la ejecución cifrada permanezca sin confianza. Los validadores, o bien 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 sobre 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 librerías criptográficas optimizadas (como la librería TFHE-rs de Zama para el bootstrapping de puertas binarias) y modificaciones personalizadas de EVM para el rendimiento. Por ejemplo, el cliente Geth modificado de Cypher añade 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álculos FHE. Zama informa que su rendimiento FHE mejoró 100 veces desde 2024 y apunta a miles de TPS con aceleración de GPU/FPGA. Los servidores de coprocesadores FHE dedicados (como el nodo LightLocker de Optalysys) pueden conectarse a los nodos validadores para descargar operaciones cifradas al hardware, soportando más de 100 transferencias ERC-20 cifradas por segundo por nodo. A medida que el hardware y los algoritmos mejoren, la brecha entre FHE y la computación 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 librería para declarar tipos y operaciones cifrados. El resto de la cadena de herramientas de Ethereum (Remix, Hardhat, etc.) aún se puede usar, 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 manejará los detalles específicos del cifrado detrás de escena. Los contratos incluso pueden interoperar con contratos normales, por ejemplo, un contrato cifrado podría generar un resultado descifrado a un contrato estándar si se desea, permitiendo una mezcla de partes privadas y públicas en un mismo ecosistema.
Proyectos actuales de FHE-VM: Varios proyectos son pioneros en este espacio. Zama (una startup de FHE con sede en París) desarrolló el concepto central de FHEVM y sus librerías (TFHE-rs y una librería 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 testnets (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. Optó 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 librería 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 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 crece rápidamente, impulsado por una financiación significativa; por ejemplo, Zama se convirtió en un "unicornio" con más de 130 millones de dólares recaudados para 2025 para avanzar en la tecnología FHE.
En resumen, una FHE-VM habilita contratos inteligentes que preservan la privacidad al ejecutar toda la lógica sobre datos cifrados en cadena. Este paradigma garantiza la máxima confidencialidad (nada sensible se expone en transacciones o estado) mientras aprovecha el consenso existente de la blockchain 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 la computación completamente fuera de cadena y solo utiliza la cadena para la verificación: el coprocesador de conocimiento cero.
Coprocesadores de Conocimiento Cero (ZK-Coprocesadores)
Un coprocesador ZK es un nuevo patrón de arquitectura de blockchain donde las computaciones costosas se realizan fuera de cadena, y una prueba de conocimiento cero sucinta de su corrección se verifica en cadena. Esto permite que los contratos inteligentes aprovechen una potencia computacional y datos mucho mayores de lo que permitiría la ejecución en cadena, sin sacrificar la falta de confianza. 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 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 en cadena 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 en cadena (por ejemplo, grandes cálculos sobre datos históricos, algoritmos pesados, inferencia de modelos de ML, etc.). Implementan esas partes como un programa fuera de cadena (en un lenguaje de alto nivel o DSL de circuito) que puede producir una prueba de conocimiento cero de su ejecución. El componente en cadena 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 como:
- Solicitud – El contrato en cadena activa una solicitud para que se realice una determinada computación fuera de cadena. 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 podría llamar a “queryHistoricalData(query)”.
- Ejecución y Prueba Fuera de Cadena – Un servicio fuera de cadena (que podría ser una red descentralizada de probadores o un servicio de confianza, dependiendo del diseño) recoge la solicitud. Recopila los datos necesarios (estado en cadena, entradas fuera de cadena, etc.) y ejecuta la computación en una Máquina Virtual ZK (ZKVM) o circuito especial. Durante la ejecución, se genera un rastro de prueba. Al final, el servicio produce una prueba sucinta (por ejemplo, un SNARK o STARK) que certifica que “Calcular la función F con la entrada X produce la salida Y” y, opcionalmente, certifica la integridad de los datos (más sobre esto a continuación).
- Verificación en Cadena – La prueba y el resultado se devuelven a la blockchain (a menudo a través de una función de 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 que la salida Y es correcta. El resultado puede almacenarse en el estado, emitirse como un evento o alimentarse a la lógica del contrato. Si la prueba no es válida o no se proporciona dentro de un tiempo determinado, la solicitud puede considerarse fallida (y potencialmente se activará alguna lógica de respaldo o de tiempo de espera).
Figura 1: Arquitectura de un Coprocesador ZK (ejemplo de RISC Zero Bonsai). Fuera de cadena, un programa se ejecuta en una ZKVM con entradas de la llamada al contrato inteligente. Una prueba de ejecución se devuelve en cadena a través de un contrato de retransmisión, que invoca una devolución de llamada con los resultados verificados.
Críticamente, el costo de gas en cadena para la verificación es constante (o crece muy lentamente) independientemente de la complejidad de la computación fuera de cadena. 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 fuera de cadena. 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 saturar 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 computaciones específicas. 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 utilizan para escribir su lógica fuera de cadena, 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 pueden escribirse en lenguajes estándar (Rust, C, etc.) y probarse automáticamente. Esto sacrifica el rendimiento (simular una CPU en un circuito añade sobrecarga) para una máxima experiencia de desarrollador.
-
Acceso e Integridad de Datos: Un desafío único es alimentar la computación fuera de cadena con los datos correctos, especialmente si esos datos residen en la blockchain (bloques pasados, estados de contratos, etc.). Una solución ingenua es hacer que el probador lea de un nodo de archivo y confíe en él, pero eso introduce suposiciones de confianza. Los coprocesadores ZK, en cambio, típicamente prueban que cualquier dato en cadena utilizado fue realmente auténtico al vincularlo a pruebas Merkle o compromisos de estado. Por ejemplo, el programa de consulta podría tomar un número de bloque y una prueba 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:
- Datos en Línea: Colocar los datos necesarios en cadena (como entrada para el verificador) para que puedan ser verificados directamente. Esto es muy costoso para grandes volúmenes de datos y socava todo el propósito.
- Confiar en un Oráculo: Hacer que un servicio de oráculo alimente los datos a la prueba y los garantice. Esto es más simple, pero reintroduce la confianza en un tercero.
- Probar la Inclusión de Datos a través de 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 del estado) y el historial de transacciones. Al verificar las pruebas Merkle Patricia de los datos dentro del circuito, la prueba de salida asegura al contrato que “esta computación utilizó datos genuinos de la blockchain del bloque N” sin necesidad de confianza adicional.
El tercer enfoque es el más descentralizado 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 confiable reciente, se puede probar recursivamente la inclusión de datos históricos sin confiar en ninguna parte externa.
-
Contrato Verificador: Este contrato en cadena 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 realizar algunos emparejamientos de curvas elípticas; para STARKs, podría realizar algunos cálculos de hash. Las optimizaciones de rendimiento como la agregación y la recursión pueden minimizar la carga en cadena. Por ejemplo, Bonsai de RISC Zero utiliza un envoltorio STARK-a-SNARK: ejecuta una VM basada en STARK fuera de cadena para mayor velocidad, pero luego genera una pequeña prueba SNARK que certifica 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 en cadena sea factible y económica. 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 tipo capa 2 o como servicios puramente fuera de cadena. 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 en cadena. El lema de Axiom era proporcionar a los contratos de Ethereum “acceso sin confianza a todos los datos en cadena y computación expresiva arbitraria sobre ellos”. Actúa efectivamente como un oráculo de consultas donde las respuestas son verificadas por ZKP 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 prueba de Bonsai a través de un contrato de retransmisión. El patrón de retransmisión, como se ilustra en la Figura 1, implica un contrato que media las solicitudes y respuestas: el contrato de la dApp llama al retransmisor para pedir una prueba, el servicio fuera de cadena escucha esto (por ejemplo, a través de un evento o una llamada directa), calcula la prueba, y luego el retransmisor invoca una función de callback en el contrato de la dApp con el resultado y la prueba. Este modelo asíncrono es necesario porque la prueba puede tardar de segundos a minutos dependiendo de la complejidad. Introduce una latencia (y una suposición de vivacidad de que el probador responderá), mientras que las computaciones 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 Oracle) 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 históricos en cadena. 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 una computación sobre todas las transacciones en un rango. Bajo el capó, 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 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 se pruebe 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 no puede hacer de forma nativa, habilitando el acceso sin estado a cualquier dato histórico con integridad criptográfica. También han enfatizado la seguridad, detectando y corrigiendo errores de circuitos subrestringidos 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 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 fuera de cadena), lo sube al servicio Bonsai y despliega un contrato verificador correspondiente. Cuando el contrato necesita esa computación, llama al relé de Bonsai que activa la generación de la prueba y devuelve el resultado a través de una devolución de llamada. Un ejemplo de aplicación demostrado fue la computación de gobernanza fuera de cadena: RISC Zero mostró una DAO utilizando Bonsai para contar votos y calcular métricas de votación complejas fuera de cadena, y luego publicar una prueba para que el contrato de Gobernador en cadena pudiera confiar en el resultado con un costo mínimo de gas. La tecnología de RISC Zero enfatiza que los desarrolladores pueden usar paradigmas de programación familiares (por ejemplo, escribir una función 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 en cadena. En agosto de 2023, verificaron con éxito pruebas de RISC Zero en la testnet Sepolia de Ethereum, con un costo del orden de 300k 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 está listo para producción y utiliza una configuración SNARK temporal sin ceremonia.)
-
Otros: Existen numerosos otros actores e iniciativas de investigación. Expansion/Xpansion (como se menciona en un blog) utiliza un enfoque de DSL incrustado, donde los desarrolladores pueden escribir consultas sobre datos en cadena con un lenguaje especializado, y este maneja la generación de pruebas internamente. 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 verificando pruebas dentro de contratos L1. También vemos proyectos en el dominio de ZKML (Aprendizaje Automático con ZK), que actúan efectivamente como coprocesadores para verificar la inferencia de modelos ML o los resultados de entrenamiento en cadena. Por ejemplo, una configuración zkML puede probar que “una inferencia de red neuronal sobre entradas privadas produjo la clasificación X” sin revelar las entradas ni realizar la computación en cadena. Estos son casos especiales del concepto de coprocesador aplicado a la IA.
Supuestos de confianza: Los coprocesadores ZK se basan en la solidez de las pruebas criptográficas. Si el sistema de pruebas es seguro (y cualquier configuración de confianza se realiza honestamente), entonces una prueba aceptada garantiza que la computación fue correcta. No se necesita confianza adicional en el probador, incluso un probador malicioso no puede convencer al verificador de una declaración falsa. Sin embargo, existe un supuesto de vivacidad: alguien debe realizar la computación fuera de cadena y producir la prueba. En la práctica, esto podría ser una red descentralizada (con incentivos o tarifas para realizar el trabajo) o un único operador de servicio. Si nadie proporciona la prueba, la solicitud en cadena podría quedar sin resolver. Otro aspecto sutil de la confianza es la disponibilidad de datos para entradas fuera de cadena que no están en la blockchain. Si la computación 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áculo). Pero para computaciones de datos puramente en cadena, los mecanismos descritos garantizan una falta de confianza equivalente a 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 préstamo” sin revelar la puntuación de crédito real o los datos brutos. El caso de uso de Axiom se centró más en datos públicamente conocidos (historial de blockchain), por lo que la privacidad no fue 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 fuera de cadena y solo el resultado necesario va en cadena. Vale la pena señalar que, a diferencia de 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 completamente privadas, pero la implementación no es trivial; a menudo se utilizan para computaciones únicas donde la entrada o la salida (o ambas) pueden ser privadas según sea necesario.
Experiencia del desarrollador: Usar un coprocesador ZK típicamente requiere aprender nuevas herramientas. Escribir circuitos personalizados (opción (1) anterior) es bastante complejo y generalmente solo se hace para propósitos específicos. Las opciones de nivel superior como los DSL o las zkVM facilitan la vida, pero aún añaden sobrecarga: el desarrollador debe escribir y desplegar código fuera de cadena y gestionar la interacción. A diferencia de FHE-VM, donde el cifrado se maneja en gran medida detrás de escena y el desarrollador escribe código de contrato inteligente normal, aquí el desarrollador necesita dividir su lógica y posiblemente escribir en un lenguaje diferente (Rust, etc.) para la parte fuera de cadena. Sin embargo, iniciativas como los DSL de 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 para que un desarrollador pueda simular su código fuera de cadena localmente (para verificar 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 mediante prueba ZK o en cadena; el compilador o las herramientas podrían decidir basándose en el costo.
FHE-VM vs Coprocesador ZK: Comparación
Tanto las FHE-VM como los coprocesadores ZK permiten una forma de “computación sobre datos privados con garantía en cadena”, pero difieren fundamentalmente en su arquitectura. La siguiente tabla resume las diferencias clave:
| Aspecto | FHE-VM (Ejecución Cifrada en Cadena) | Coprocesador ZK (Prueba Fuera de Cadena) |
|---|
Public blockchains provide transparency and integrity at the cost of privacy – every transaction and contract state is exposed to all participants. This openness creates problems like MEV (Miner Extractable Value) attacks, copy-trading, and leakage of sensitive business logic. Programmable privacy aims to solve these issues by allowing computations on private data without revealing the data itself. Two emerging cryptographic paradigms are making this possible: Fully Homomorphic Encryption Virtual Machines (FHE-VM) and Zero-Knowledge (ZK) Coprocessors. These approaches enable off-chain or encrypted computation with on-chain verification, preserving confidentiality while retaining trustless correctness. In this report, we dive deep into FHE-VM and ZK-coprocessor architectures, compare their trade-offs, and explore use cases across finance, identity, healthcare, data markets, and decentralized machine learning.
Fully Homomorphic Encryption Virtual Machine (FHE-VM)
Fully Homomorphic Encryption (FHE) allows arbitrary computations on encrypted data without ever decrypting it. An FHE Virtual Machine integrates this capability into blockchain smart contracts, enabling encrypted contract state and logic. In an FHE-enabled blockchain (often called an fhEVM for EVM-compatible designs), all inputs, contract storage, and outputs remain encrypted throughout execution. This means validators can process transactions and update state without learning any sensitive values, achieving on-chain execution with data confidentiality.
Architecture and Design of FHE-VM
A typical FHE-VM extends a standard smart contract runtime (like the Ethereum Virtual Machine) with native support for encrypted data types and operations. For example, Zama’s FHEVM introduces encrypted integers (euint8, euint32, etc.), encrypted booleans (ebool), and even encrypted arrays as first-class types. Smart contract languages like Solidity are augmented via libraries or new opcodes so developers can perform arithmetic (add, mul, etc.), logical operations, and comparisons directly on ciphertexts. Under the hood, these operations invoke FHE primitives (e.g. using the TFHE library) to manipulate encrypted bits and produce encrypted results.
Encrypted state storage is supported so that contract variables remain encrypted in the blockchain state. The execution flow is typically:
- Client-Side Encryption: Users encrypt their inputs locally using the public FHE key before sending transactions. The encryption key is public (for encryption and evaluation), while the decryption key remains secret. In some designs, each user manages their own key; in others, a single global FHE key is used (discussed below).
- On-Chain Homomorphic Computation: Miners/validators execute the contract with encrypted opcodes. They perform the same deterministic homomorphic operations on the ciphertexts, so consensus can be reached on the encrypted new state. Crucially, validators never see plaintext data – they just see “gibberish” ciphertext but can still process it consistently.
- Decryption (Optional): If a result needs to be revealed or used off-chain, an authorized party with the private key can decrypt the output ciphertext. Otherwise, results remain encrypted and can be used as inputs to further transactions (allowing consecutive computations on persistent encrypted state).
A major design consideration is key management. One approach is per-user keys, where each user holds their secret key and only they can decrypt outputs relevant to them. This maximizes privacy (no one else can ever decrypt your data), but homomorphic operations cannot mix data encrypted under different keys without complex multi-key protocols. Another approach, used by Zama’s FHEVM, is a global FHE key: a single public key encrypts all contract data and a distributed set of validators holds shares of the threshold decryption key. The public encryption and evaluation keys are published on-chain, so anyone can encrypt data to the network; the private key is split among validators who can collectively decrypt if needed under a threshold scheme. To prevent validator collusion from compromising privacy, Zama employs a threshold FHE protocol (based on their Noah’s Ark research) with “noise flooding” to make partial decryptions secure. Only if a sufficient quorum of validators cooperates can a plaintext be recovered, for example to serve a read request. In normal operation, however, no single node ever sees plaintext – data remains encrypted on-chain at all times.
Access control is another crucial component. FHE-VM implementations include fine-grained controls to manage who (if anyone) can trigger decryptions or access certain encrypted fields. For instance, Cypher’s fhEVM supports Access Control Lists on ciphertexts, allowing developers to specify which addresses or contracts can interact with or re-encrypt certain data. Some frameworks support re-encryption: the ability to transfer an encrypted value from one user’s key to another’s without exposing plaintext. This is useful for things like data marketplaces, where a data owner can encrypt a dataset with their key, and upon purchase, re-encrypt it to the buyer’s key – all on-chain, without ever decrypting publicly.
Ensuring Correctness and Privacy
One might ask: if all data is encrypted, how do we enforce correctness of contract logic? How can the chain prevent invalid operations if it can’t “see” the values? FHE by itself doesn’t provide a proof of correctness – validators can perform the homomorphic steps, but they can’t inherently tell if a user’s encrypted input was valid or if a conditional branch should be taken, etc., without decrypting. Zero-knowledge proofs (ZKPs) can complement FHE to solve this gap. In an FHE-VM, typically users must provide a ZK proof attesting to certain plaintext conditions whenever needed. Zama’s design, for example, uses a ZK Proof of Plaintext Knowledge (ZKPoK) to accompany each encrypted input. This proves that the user knows the plaintext corresponding to their ciphertext and that it meets expected criteria, without revealing the plaintext itself. Such “certified ciphertexts” prevent a malicious user from submitting a malformed encryption or an out-of-range value. Similarly, for operations that require a decision (e.g. ensure account balance ≥ withdrawal amount), the user can supply a ZK proof that this condition holds true on the plaintexts before the encrypted operation is executed. In this way, the chain doesn’t decrypt or see the values, but it gains confidence that the encrypted transactions follow the rules.
Another approach in FHE rollups is to perform off-chain validation with ZKPs. Fhenix (an L2 rollup using FHE) opts for an optimistic model where a separate network component called a Threshold Service Network can decrypt or verify encrypted results, and any incorrect computation can be challenged with a fraud-proof. In general, combining FHE + ZK or fraud proofs ensures that encrypted execution remains trustless. Validators either collectively decrypt only when authorized, or they verify proofs that each encrypted state transition was valid without needing to see plaintext.
Performance considerations: FHE operations are computationally heavy – many orders of magnitude slower than normal arithmetic. For example, a simple 64-bit addition on Ethereum costs ~3 gas, whereas an addition on an encrypted 64-bit integer (euint64) under Zama’s FHEVM costs roughly 188,000 gas. Even an 8-bit add can cost ~94k gas. This enormous overhead means a straightforward implementation on existing nodes would be impractically slow and costly. FHE-VM projects tackle this with optimized cryptographic libraries (like Zama’s TFHE-rs library for binary gate bootstrapping) and custom EVM modifications for performance. For instance, Cypher’s modified Geth client adds new opcodes and optimizes homomorphic instruction execution in C++/assembly to minimize overhead. Nevertheless, achieving usable throughput requires acceleration. Ongoing work includes using GPUs, FPGAs, and even specialized photonic chips to speed up FHE computations. Zama reports their FHE performance improved 100× since 2024 and is targeting thousands of TPS with GPU/FPGA acceleration. Dedicated FHE co-processor servers (such as Optalysys’s LightLocker Node) can plug into validator nodes to offload encrypted operations to hardware, supporting >100 encrypted ERC-20 transfers per second per node. As hardware and algorithms improve, the gap between FHE and plain computation will narrow, enabling private contracts to approach more practical speeds.
Compatibility: A key goal of FHE-VM designs is to remain compatible with existing development workflows. Cypher’s and Zama’s fhEVM implementations allow developers to write contracts in Solidity with minimal changes – using a library to declare encrypted types and operations. The rest of the Ethereum toolchain (Remix, Hardhat, etc.) can still be used, as the underlying modifications are mostly at the client/node level. This lowers the barrier to entry: developers don’t need to be cryptography experts to write a confidential smart contract. For example, a simple addition of two numbers can be written as euint32 c = a + b; and the FHEVM will handle the encryption-specific details behind the scenes. The contracts can even interoperate with normal contracts – e.g. an encrypted contract could output a decrypted result to a standard contract if desired, allowing a mix of private and public parts in one ecosystem.
Current FHE-VM Projects: Several projects are pioneering this space. Zama (a Paris-based FHE startup) developed the core FHEVM concept and libraries (TFHE-rs and an fhevm-solidity library). They do not intend to launch their own chain, but rather provide infrastructure to others. Inco is an L1 blockchain (built on Cosmos SDK with Evmos) that integrated Zama’s FHEVM to create a modular confidential chain. Their testnets (named Gentry and Paillier) showcase encrypted ERC-20 transfers and other private DeFi primitives. Fhenix is an Ethereum Layer-2 optimistic rollup using FHE for privacy. It decided on an optimistic (fraud-proof) approach rather than ZK-rollup due to the heavy cost of doing FHE and ZK together for every block. Fhenix uses the same TFHE-rs library (with some modifications) and introduces a Threshold Service Network for handling decryptions in a decentralized way. There are also independent teams like Fhenix (now rebranded) and startups exploring MPC + FHE hybrids. Additionally, Cypher (by Z1 Labs) is building a Layer-3 network focused on AI and privacy, using an fhEVM with features like secret stores and federated learning support. The ecosystem is nascent but growing rapidly, fueled by significant funding – e.g. Zama became a “unicorn” with >$130M raised by 2025 to advance FHE tech.
In summary, an FHE-VM enables privacy-preserving smart contracts by executing all logic on encrypted data on-chain. This paradigm ensures maximum confidentiality – nothing sensitive is ever exposed in transactions or state – while leveraging the existing blockchain consensus for integrity. The cost is increased computational burden on validators and complexity in key management and proof integration. Next, we explore an alternative paradigm that offloads compute entirely off-chain and only uses the chain for verification: the zero-knowledge coprocessor.
Coprocesadores de Conocimiento Cero (ZK-Coprocesadores)
Un coprocesador ZK es un nuevo patrón de arquitectura de blockchain donde las computaciones costosas se realizan fuera de cadena, y una prueba de conocimiento cero sucinta de su corrección se verifica en cadena. Esto permite que los contratos inteligentes aprovechen una potencia computacional y datos mucho mayores de lo que permitiría la ejecución en cadena, sin sacrificar la falta de confianza. 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 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 en cadena 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 en cadena (por ejemplo, grandes cálculos sobre datos históricos, algoritmos pesados, inferencia de modelos de ML, etc.). Implementan esas partes como un programa fuera de cadena (en un lenguaje de alto nivel o DSL de circuito) que puede producir una prueba de conocimiento cero de su ejecución. El componente en cadena 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 como:
- Solicitud – El contrato en cadena activa una solicitud para que se realice una determinada computación fuera de cadena. 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 podría llamar a “queryHistoricalData(query)”.
- Ejecución y Prueba Fuera de Cadena – Un servicio fuera de cadena (que podría ser una red descentralizada de probadores o un servicio de confianza, dependiendo del diseño) recoge la solicitud. Recopila los datos necesarios (estado en cadena, entradas fuera de cadena, etc.) y ejecuta la computación en una Máquina Virtual ZK (ZKVM) o circuito especial. Durante la ejecución, se genera un rastro de prueba. Al final, el servicio produce una prueba sucinta (por ejemplo, un SNARK o STARK) que certifica que “Calcular la función F con la entrada X produce la salida Y” y, opcionalmente, certifica la integridad de los datos (más sobre esto a continuación).
- Verificación en Cadena – La prueba y el resultado se devuelven a la blockchain (a menudo a través de una función de 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 que la salida Y es correcta. El resultado puede almacenarse en el estado, emitirse como un evento o alimentarse a la lógica del contrato. Si la prueba no es válida o no se proporciona dentro de un tiempo determinado, la solicitud puede considerarse fallida (y potencialmente se activará alguna lógica de respaldo o de tiempo de espera).
Figura 1: Arquitectura de un Coprocesador ZK (ejemplo de RISC Zero Bonsai). Fuera de cadena, un programa se ejecuta en una ZKVM con entradas de la llamada al contrato inteligente. Una prueba de ejecución se devuelve en cadena a través de un contrato de retransmisión, que invoca una devolución de llamada con los resultados verificados.
Críticamente, el costo de gas en cadena para la verificación es constante (o crece muy lentamente) independientemente de la complejidad de la computación fuera de cadena. 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 fuera de cadena. 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 saturar 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 computaciones específicas. 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 utilizan para escribir su lógica fuera de cadena, 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 pueden escribirse en lenguajes estándar (Rust, C, etc.) y probarse automáticamente. Esto sacrifica el rendimiento (simular una CPU en un circuito añade sobrecarga) para una máxima experiencia de desarrollador.
-
Acceso e Integridad de Datos: Un desafío único es alimentar la computación fuera de cadena con los datos correctos, especialmente si esos datos residen en la blockchain (bloques pasados, estados de contratos, etc.). Una solución ingenua es hacer que el probador lea de un nodo de archivo y confíe en él, pero eso introduce suposiciones de confianza. Los coprocesadores ZK, en cambio, típicamente prueban que cualquier dato en cadena utilizado fue realmente auténtico al vincularlo a pruebas Merkle o compromisos de estado. Por ejemplo, el programa de consulta podría tomar un número de bloque y una prueba 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:
- Datos en Línea: Colocar los datos necesarios en cadena (como entrada para el verificador) para que puedan ser verificados directamente. Esto es muy costoso para grandes volúmenes de datos y socava todo el propósito.
- Confiar en un Oráculo: Hacer que un servicio de oráculo alimente los datos a la prueba y los garantice. Esto es más simple, pero reintroduce la confianza en un tercero.
- Probar la Inclusión de Datos a través de 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 del estado) y el historial de transacciones. Al verificar las pruebas Merkle Patricia de los datos dentro del circuito, la prueba de salida asegura al contrato que “esta computación utilizó datos genuinos de la blockchain del bloque N” sin necesidad de confianza adicional.
El tercer enfoque es el más descentralizado 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 confiable reciente, se puede probar recursivamente la inclusión de datos históricos sin confiar en ninguna parte externa.
-
Contrato Verificador: Este contrato en cadena 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 realizar algunos emparejamientos de curvas elípticas; para STARKs, podría realizar algunos cálculos de hash. Las optimizaciones de rendimiento como la agregación y la recursión pueden minimizar la carga en cadena. Por ejemplo, Bonsai de RISC Zero utiliza un envoltorio STARK-a-SNARK: ejecuta una VM basada en STARK fuera de cadena para mayor velocidad, pero luego genera una pequeña prueba SNARK que certifica 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 en cadena sea factible y económica. 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 tipo capa 2 o como servicios puramente fuera de cadena. 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 en cadena. El lema de Axiom era proporcionar a los contratos de Ethereum “acceso sin confianza a todos los datos en cadena y computación expresiva arbitraria sobre ellos”. Actúa efectivamente como un oráculo de consultas donde las respuestas son verificadas por ZKP 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 prueba de Bonsai a través de un contrato de retransmisión. El patrón de retransmisión, como se ilustra en la Figura 1, implica un contrato que media las solicitudes y respuestas: el contrato de la dApp llama al retransmisor para pedir una prueba, el servicio fuera de cadena escucha esto (por ejemplo, a través de un evento o una llamada directa), calcula la prueba, y luego el retransmisor invoca una función de callback en el contrato de la dApp con el resultado y la prueba. Este modelo asíncrono es necesario porque la prueba puede tardar de segundos a minutos dependiendo de la complejidad. Introduce una latencia (y una suposición de vivacidad de que el probador responderá), mientras que las computaciones 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 Oracle) 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 históricos en cadena. 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 una computación sobre todas las transacciones en un rango. Bajo el capó, 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 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 se pruebe 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 no puede hacer de forma nativa, habilitando el acceso sin estado a cualquier dato histórico con integridad criptográfica. También han enfatizado la seguridad, detectando y corrigiendo errores de circuitos subrestringidos 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 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 fuera de cadena), lo sube al servicio Bonsai y despliega un contrato verificador correspondiente. Cuando el contrato necesita esa computación, llama al relé de Bonsai que activa la generación de la prueba y devuelve el resultado a través de una devolución de llamada. Un ejemplo de aplicación demostrado fue la computación de gobernanza fuera de cadena: RISC Zero mostró una DAO utilizando Bonsai para contar votos y calcular métricas de votación complejas fuera de cadena, y luego publicar una prueba para que el contrato de Gobernador en cadena pudiera confiar en el resultado con un costo mínimo de gas. La tecnología de RISC Zero enfatiza que los desarrolladores pueden usar paradigmas de programación familiares (por ejemplo, escribir una función 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 en cadena. En agosto de 2023, verificaron con éxito pruebas de RISC Zero en la testnet Sepolia de Ethereum, con un costo del orden de 300k 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 está listo para producción y utiliza una configuración SNARK temporal sin ceremonia.)
-
Otros: Existen numerosos otros actores e iniciativas de investigación. Expansion/Xpansion (como se menciona en un blog) utiliza un enfoque de DSL incrustado, donde los desarrolladores pueden escribir consultas sobre datos en cadena con un lenguaje especializado, y este maneja la generación de pruebas internamente. 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 verificando pruebas dentro de contratos L1. También vemos proyectos en el dominio de ZKML (Aprendizaje Automático con ZK), que actúan efectivamente como coprocesadores para verificar la inferencia de modelos ML o los resultados de entrenamiento en cadena. Por ejemplo, una configuración zkML puede probar que “una inferencia de red neuronal sobre entradas privadas produjo la clasificación X” sin revelar las entradas ni realizar la computación en cadena. Estos son casos especiales del concepto de coprocesador aplicado a la IA.
Supuestos de confianza: Los coprocesadores ZK se basan en la solidez de las pruebas criptográficas. Si el sistema de pruebas es seguro (y cualquier configuración de confianza se realiza honestamente), entonces una prueba aceptada garantiza que la computación fue correcta. No se necesita confianza adicional en el probador, incluso un probador malicioso no puede convencer al verificador de una declaración falsa. Sin embargo, existe un supuesto de vivacidad: alguien debe realizar la computación fuera de cadena y producir la prueba. En la práctica, esto podría ser una red descentralizada (con incentivos o tarifas para realizar el trabajo) o un único operador de servicio. Si nadie proporciona la prueba, la solicitud en cadena podría quedar sin resolver. Otro aspecto sutil de la confianza es la disponibilidad de datos para entradas fuera de cadena que no están en la blockchain. Si la computación 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áculo). Pero para computaciones de datos puramente en cadena, los mecanismos descritos garantizan una falta de confianza equivalente a 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 préstamo” sin revelar la puntuación de crédito real o los datos brutos. El caso de uso de Axiom se centró más en datos públicamente conocidos (historial de blockchain), por lo que la privacidad no fue 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 fuera de cadena y solo el resultado necesario va en cadena. Vale la pena señalar que, a diferencia de 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 completamente privadas, pero la implementación no es trivial; a menudo se utilizan para computaciones únicas donde la entrada o la salida (o ambas) pueden ser privadas según sea necesario.
Experiencia del desarrollador: Usar un coprocesador ZK típicamente requiere aprender nuevas herramientas. Escribir circuitos personalizados (opción (1) anterior) es bastante complejo y generalmente solo se hace para propósitos específicos. Las opciones de nivel superior como los DSL o las zkVM facilitan la vida, pero aún añaden sobrecarga: el desarrollador debe escribir y desplegar código fuera de cadena y gestionar la interacción. A diferencia de FHE-VM, donde el cifrado se maneja en gran medida detrás de escena y el desarrollador escribe código de contrato inteligente normal, aquí el desarrollador necesita dividir su lógica y posiblemente escribir en un lenguaje diferente (Rust, etc.) para la parte fuera de cadena. Sin embargo, iniciativas como los DSL de 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 para que un desarrollador pueda simular su código fuera de cadena localmente (para verificar 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 mediante prueba ZK o en cadena; el compilador o las herramientas podrían decidir basándose en el costo.
FHE-VM vs Coprocesador ZK: Comparación
Tanto las FHE-VM como los coprocesadores ZK permiten una forma de “computación sobre datos privados con garantía en cadena”, pero difieren fundamentalmente en su arquitectura. La siguiente tabla resume las diferencias clave:
| Aspecto | FHE-VM (Ejecución Cifrada en Cadena) | Coprocesador ZK (Prueba Fuera de Cadena) |
|---|
