El coprocesador de datos ZK es el componente central de Brevis que permite a los contratos inteligentes acceder de forma segura y fiable a datos históricos y entre cadenas. Recupera datos auténticos on-chain y realiza cálculos off-chain, devolviendo los resultados junto con una prueba de conocimiento cero (ZK) para su validación on-chain. Como la capa más orientada a la aplicación de Brevis (BREV), transforma el problema de que los contratos no puedan calcular ni leer datos históricos en la fórmula “calcular off-chain, verificar on-chain”.
Los mecanismos de consenso de blockchain requieren que cada validador repita los mismos cálculos, haciendo que el acceso directo on-chain a grandes volúmenes de transacciones históricas sea extremadamente costoso. Por ello, los contratos inteligentes son prácticamente ciegos a los datos históricos.
Siguiendo la filosofía de Brevis de “probar el trabajo en lugar de repetirlo”, el coprocesador de datos ZK traslada la lectura intensiva de datos y el cálculo fuera de la cadena, mientras que la validación on-chain se reduce a un proceso de milisegundos. Así, los contratos pueden tomar decisiones basadas en el comportamiento on-chain a largo plazo sin depender de intermediarios centralizados.
El coprocesador de datos ZK es un motor especializado de cálculo off-chain diseñado para acceder a estados históricos de blockchain y datos entre cadenas, ejecutar cálculos que los contratos no pueden realizar eficientemente on-chain y adjuntar una prueba criptográfica a cada cálculo. Genera credenciales verificables: “resultado + prueba de que el resultado proviene de datos auténticos y está correctamente calculado”.
En el stack tecnológico de Brevis, el coprocesador de datos ZK es un ejemplo principal del Pico zkVM como “coprocesador a nivel de aplicación”. Pico zkVM actúa como una capa de conexión que enruta datos entre el núcleo general y los módulos especializados, mientras que el coprocesador de datos se centra en leer el historial, realizar análisis y adjuntar pruebas, permitiendo que los contratos confíen en las matemáticas y no en operadores centralizados.
Por diseño, los contratos inteligentes solo pueden acceder de forma eficiente al estado del bloque actual y son casi ciegos a los datos de bloques anteriores. Aunque redes como Ethereum conservan el historial completo, que los contratos accedan al almacenamiento de bloques pasados o a transacciones on-chain requiere pruebas adicionales costosas y, a menudo, carecen de interfaces nativas.
La razón principal es el coste y el consenso: reproducir, por ejemplo, el volumen de transacciones de una dirección durante los últimos seis meses on-chain obligaría a cada validador a procesar una cantidad masiva de datos de estado, superando rápidamente los límites de gas por transacción. Así, los datos históricos existen pero no están disponibles. Funciones como tarifas de trading por niveles o recompensas de fidelidad basadas en el comportamiento histórico han dependido tradicionalmente de cálculos off-chain y reintegración, lo que reintroduce la confianza en intermediarios centralizados.
El coprocesador de datos ZK accede a estados históricos completos a través de nodos de archivo de blockchain. Estos nodos almacenan instantáneas de cada bloque histórico, permitiendo al coprocesador leer saldos, slots de almacenamiento y registros de transacciones en cualquier momento, tanto en una sola cadena como en varias, sin que los contratos tengan que reproducir datos on-chain.
Tras recuperar los datos en bruto, el coprocesador ejecuta lógica de cálculo definida por el usuario off-chain, como agregación, filtrado, ponderación o evaluación condicional. A diferencia del cálculo off-chain estándar, cada punto de datos accedido se incluye en la prueba posterior, garantizando tanto la existencia de los datos como la corrección del cálculo.
El flujo de datos del coprocesador de datos ZK consta de cuatro pasos que forman un ciclo cerrado desde la solicitud de la aplicación hasta la adopción por el contrato inteligente on-chain. En el flujo de trabajo puramente ZK, la generación de pruebas en cada paso depende de la capa de ejecución general zkVM. La siguiente tabla resume cada paso:
| Paso | Etapa | Qué ocurre | Salida |
|---|---|---|---|
| ① | Solicitud de la aplicación | La dApp define la lógica de cálculo y el alcance de los datos, luego envía la solicitud | Tarea de cálculo |
| ② | Acceso y cálculo de datos off-chain | El coprocesador lee datos auténticos a través de nodos de archivo y realiza el cálculo | Resultado en bruto |
| ③ | Generación de prueba ZK | Se genera una prueba ZK de que el cálculo se ejecutó correctamente sobre datos reales | Resultado + prueba |
| ④ | Verificación on-chain | El contrato inteligente verifica la prueba en milisegundos y acepta el resultado | Conclusión de confianza |
Estos cuatro pasos crean una canalización de “calcular off-chain, verificar on-chain”: la lectura intensiva de datos y el cálculo se gestionan off-chain, mientras que on-chain solo verifica una prueba sucinta a un coste mínimo, sin necesidad de trasladar datos en bruto on-chain.

Figura 1. Flujo de datos en cuatro pasos del coprocesador de datos ZK: solicitud de la aplicación → acceso a datos off-chain (nodo de archivo) → cálculo → generación de prueba ZK (los datos existen y el cálculo es correcto) → verificador on-chain → resultado devuelto.
La fiabilidad de las pruebas del coprocesador de datos ZK reside en su triple garantía: el propio resultado, la autenticidad de los datos y la corrección del cálculo. Cualquier manipulación en cualquier capa provocará que la verificación on-chain falle.
Las pruebas de conocimiento cero desacoplan el coste de verificación de la escala computacional: independientemente del número de bloques históricos procesados off-chain, la verificación on-chain solo requiere comprobar una prueba sucinta de tamaño fijo, normalmente en milisegundos. La siguiente tabla detalla los tres tipos de hechos asegurados por la prueba.
| Tipo de garantía | Hecho asegurado por la prueba | Previene trampas |
|---|---|---|
| Resultado | El valor devuelto es la verdadera salida del cálculo | Manipulación del resultado final |
| Existencia de datos | Las entradas provienen del estado histórico auténtico de la cadena objetivo | Falsificación o sustitución de datos de entrada |
| Corrección del cálculo | El cálculo sigue estrictamente la lógica declarada | Omitir pasos, simplificar o alterar la lógica |
Esta estructura explica por qué los contratos pueden “no confiar, solo verificar”: el resultado, la entrada y el proceso están todos incluidos en la prueba, impidiendo que el coprocesador manipule en cualquier etapa. Esta propiedad de confianza minimizada lo distingue fundamentalmente de las soluciones que dependen de partes de confianza para reintegrar datos.

Figura 2. Estructura de la prueba del coprocesador de datos ZK: una sola prueba asegura simultáneamente el resultado, la existencia de los datos y la corrección del cálculo, verificada por un contrato inteligente on-chain en milisegundos.
El coprocesador de datos ZK es ideal para cualquier escenario on-chain que requiera resultados confiables basados en datos históricos o entre cadenas. Los casos de uso que antes dependían de cálculos off-chain y reintegración ahora pueden aprovechar el cálculo verificable. La siguiente tabla resalta varios escenarios comunes:
| Escenario | Capacidad requerida | Descripción |
|---|---|---|
| Incentivos basados en datos | Agregación de volumen/comportamiento histórico de trading | Recompensas emitidas según actividad real; resultados a prueba de manipulaciones |
| Fidelidad y niveles | Duración de la posición/instantáneas históricas | Beneficios por niveles en función de tenencia o registros de trading |
| Control de riesgos on-chain | Perfilado histórico de direcciones | Evaluar el riesgo según el comportamiento histórico antes de ejecutar la lógica del contrato |
| Lectura de estado entre cadenas | Datos de archivo multichain | Adoptar el estado histórico de otra cadena |
El denominador común en estos escenarios es que las decisiones se basan en eventos pasados y estos datos no pueden reproducirse de manera eficiente on-chain. A diferencia de los oráculos que simplemente importan datos off-chain, la diferencia entre Brevis y los oráculos es que el coprocesador no solo proporciona datos, sino que también entrega cálculo basado en los datos y su prueba de corrección, desplazando la confianza de la fuente de datos a la verificación matemática.
Las principales fortalezas del coprocesador de datos ZK son la minimización de la confianza y la escalabilidad. La ejecución off-chain elimina las restricciones computacionales impuestas por los límites de gas del bloque y las pruebas de conocimiento cero permiten verificar los resultados sin depender de terceros. Esto permite que los contratos tomen decisiones seguras basadas en la actividad on-chain a largo plazo.
Las principales limitaciones provienen del propio cálculo ZK: la generación de pruebas de conocimiento cero requiere hardware especializado y hashrate, y las pruebas para lógica compleja implican mayor sobrecarga y latencia que la ejecución nativa, por lo que no es adecuado para escenarios de latencia ultrabaja. La fiabilidad de los resultados también depende de la integridad de la fuente de datos: la falta o incorrección de datos de nodos de archivo afecta directamente a la autenticidad de la entrada.
Por tanto, el coprocesador de datos ZK es más adecuado para escenarios donde la corrección del resultado es más importante que la inmediatez, haciendo que los cálculos históricos a gran escala sean fiables y utilizables, aunque no sin coste. Para casos de uso más sensibles a la latencia y al coste de las pruebas, el modelo optimista de token BREV y coChain ofrece una alternativa. Todo lo anterior son limitaciones objetivas a nivel de mecanismo y no constituyen asesoramiento de inversión.
Como capa orientada a la aplicación de Brevis, el coprocesador de datos ZK resuelve los desafíos del acceso limitado de los contratos inteligentes a datos históricos y el alto coste de la reproducción on-chain. Accede a datos históricos y entre cadenas auténticos a través de nodos de archivo off-chain, realiza cálculos y devuelve una prueba de conocimiento cero—resultado, existencia de los datos y corrección del cálculo—para la verificación del contrato en milisegundos. El proceso de cuatro pasos—solicitud, cálculo off-chain, generación de prueba y verificación on-chain—traslada la confianza de los intermediarios centralizados a la criptografía, permitiendo incentivos basados en datos, programas de fidelidad, controles de riesgo y lectura de estados entre cadenas confiables.
Como motor de cálculo off-chain, el coprocesador de datos ZK accede a datos históricos y entre cadenas de blockchain, ejecuta cálculos que los contratos no pueden realizar on-chain y adjunta una prueba de conocimiento cero al resultado. Los contratos solo necesitan verificar una prueba sucinta on-chain para aceptar el resultado, eliminando la necesidad de reproducir datos en bruto.
Los datos se obtienen de nodos de archivo de blockchain, que almacenan instantáneas completas del estado de cada bloque histórico. El coprocesador utiliza estas instantáneas para leer saldos, almacenamiento y registros de transacciones en cualquier momento, cubriendo estados históricos en varias cadenas. Cada punto de datos se incluye en la prueba posterior.
La prueba de conocimiento cero devuelta asegura simultáneamente tres hechos: el propio resultado, que los datos de entrada realmente existen en la cadena objetivo y que el cálculo sigue estrictamente la lógica declarada. Cualquier manipulación hará que la prueba falle en la verificación on-chain, permitiendo que los contratos no confíen, solo verifiquen.
Los oráculos importan principalmente datos off-chain a la blockchain y aún requieren confiar en la fuente de los datos. Por el contrario, el coprocesador de datos ZK realiza cálculos off-chain basados en datos on-chain auténticos o históricos y adjunta una prueba de conocimiento cero de la corrección, desplazando la confianza de la fuente de datos a la verificación matemática.





