Qué es un coprocesador ZK y por qué importa en DeFi

¿Qué es un coprocesador ZK?

Un coprocesador ZK es un sistema que realiza computación fuera de una blockchain y luego produce una prueba de que el cálculo se llevó a cabo correctamente. ZK significa zero-knowledge, una familia de técnicas criptográficas que pueden demostrar una afirmación sin revelar toda la información utilizada para establecerla. En muchos diseños de coprocesadores, la propiedad útil no es solo el secreto. Es la verificabilidad.

Imagina que un contrato inteligente pregunta: ¿estaba esta cartera entre los principales usuarios de un protocolo en el bloque N? ¿Mantuvo una cuenta al menos un determinado saldo durante un periodo pasado? ¿Se mantuvo un pool por debajo de un umbral de riesgo durante miles de bloques? Es posible que un contrato convencional no pueda responder a estas preguntas de forma barata porque las blockchains están diseñadas para ejecutar transiciones de estado actuales, no para escanear repetidamente todo su historial.

Un coprocesador ZK lee o recibe datos históricos de blockchain, realiza el cálculo solicitado fuera de la cadena y devuelve un resultado con una prueba. Un contrato verificador comprueba esa prueba mediante reglas criptográficas. Si la prueba es válida, el contrato puede actuar sobre el resultado sin aceptar una simple afirmación de un operador de servidor.

La mejor forma de entenderlo es como un ordenador externalizado verificable para datos de blockchain. No hace que un contrato sea omnisciente, y no convierte automáticamente una aplicación en privada, descentralizada o barata. Esas propiedades dependen de la fuente de datos, del circuito o la máquina virtual, del sistema de pruebas, del verificador y del diseño económico en torno al servicio.

Los principales riesgos y modos de fallo

La palabra prueba puede sonar más absoluta de lo que es. Una prueba válida generalmente establece que se realizó correctamente un cálculo definido sobre entradas definidas bajo un sistema de pruebas definido. No demuestra que el desarrollador eligiera la pregunta correcta, obtuviera la cadena correcta, interpretara correctamente un contrato o construyera una aplicación segura en torno a la respuesta.

La suposición técnica central es la solidez del sistema de pruebas. La solidez es la propiedad que hace inviable crear una prueba con apariencia válida para una afirmación falsa. Si la criptografía, la implementación, el circuito, el contrato verificador o la configuración de confianza tienen un fallo grave, un atacante podría enviar un resultado incorrecto que el contrato acepte. Una etiqueta zero-knowledge no sustituye la auditoría de estos componentes.

También existen riesgos de infraestructura ordinarios. Un probador puede dejar de estar disponible, un proveedor de datos puede devolver un historial incompleto, un servicio puede admitir solo cadenas seleccionadas o un contrato puede depender de un coordinador para enviar pruebas. Algunos sistemas reducen la confianza en un multisig mientras siguen dependiendo de operadores para el tiempo de actividad, la disponibilidad de datos, el pago de comisiones o las actualizaciones de software. Las claves de gobernanza y los permisos de actualización merecen el mismo escrutinio que el sistema de pruebas.

El modo de fallo financiero es especialmente importante en DeFi. Un cálculo histórico defectuoso podría valorar mal el colateral, distribuir recompensas a las cuentas equivocadas, activar liquidaciones o aprobar un préstamo deficiente. Una prueba puede mostrar que el código se ejecutó tal como estaba escrito, mientras que el propio código contiene un error económico. Por tanto, los usuarios deberían revisar auditorías, direcciones de verificadores, controles de actualización, fuentes de datos admitidas y procedimientos de emergencia antes de considerar que una aplicación respaldada por un coprocesador es más segura que una convencional.

Cómo demuestra datos históricos de la cadena

El flujo básico tiene varias etapas. Primero, una aplicación define una consulta y los datos que necesita. La consulta puede incluir saldos, swaps, posiciones de liquidez, actividad de préstamo o compromisos de estado registrados en bloques anteriores de Ethereum. Después, el sistema obtiene las cabeceras de bloque, los datos de transacciones, los recibos y la información de estado pertinentes, según lo que requiera el cálculo.

A continuación, un trabajador off-chain ejecuta el programa solicitado. Ese programa puede ser un circuito especializado o una máquina virtual de conocimiento cero de propósito general, a menudo llamada zkVM. Una zkVM permite a los desarrolladores expresar lógica en un entorno de programación más familiar, mientras el sistema convierte la ejecución en una forma que se puede demostrar. El resultado incluye tanto una respuesta como una prueba vinculada a los datos de entrada y al programa.

El verificador on-chain normalmente no reproduce todas las transacciones históricas. Comprueba una prueba compacta usando una clave de verificación y entradas públicas como un identificador de bloque, un compromiso de datos, los parámetros de la consulta y el resultado declarado. Si la prueba se acepta, un contrato puede almacenar el resultado o usarlo de inmediato. El contrato aún debe validar que el bloque y el compromiso de estado significan lo que la aplicación espera.

Acceder a datos históricos es más complicado que simplemente pedir un número a un nodo. Un saldo puede depender del almacenamiento de un contrato en un bloque concreto. Una métrica ponderada por tiempo puede requerir muchas instantáneas de estado. Un resultado basado en logs puede omitir información que no se emitió como evento. El sistema debe definir si demuestra datos de un nodo de archivo, una representación indexada, un compromiso de bloque u otra fuente. Esas decisiones afectan tanto a la corrección como a la confianza.

Qué dice realmente una prueba

Supongamos que un contrato recibe una afirmación de que una dirección aportó liquidez durante al menos 100 días antes de un bloque elegido. La prueba puede establecer que un programa especificado examinó entradas especificadas y llegó a ese resultado. No establece de forma independiente que la pregunta sea una medida útil de lealtad, que la dirección esté controlada por una sola persona o que la aplicación deba pagar una recompensa.

Esta distinción explica por qué importan las consultas reproducibles y los compromisos de entrada transparentes. Los desarrolladores deberían poder identificar la cadena, el intervalo de bloques, las direcciones de contrato, la versión del programa y los supuestos que hay detrás de un resultado. Sin ese contexto, una prueba puede ser matemáticamente válida pero difícil de interpretar para los usuarios.

Coprocesador frente a rollup

Un rollup es un sistema de escalado que ejecuta lotes de transacciones fuera de la cadena principal y publica datos o compromisos suficientes para que la cadena base pueda verificar o reconstruir el estado resultante. Su función principal es proporcionar un lugar donde los usuarios puedan transaccionar, mientras el rollup mantiene un estado propio de cuentas y aplicaciones. Un ZK rollup utiliza pruebas de validez para demostrar que su transición de estado se ejecutó según sus reglas.

Un coprocesador tiene una tarea diferente. Por lo general, no mantiene el estado canónico de cuentas para un nuevo entorno de transacciones, y no es principalmente un espacio donde los usuarios depositan activos y ejecutan llamadas ordinarias de aplicaciones. Realiza cálculos seleccionados sobre datos que ya existen en una blockchain y después envía un resultado y una prueba de vuelta a un contrato en esa cadena.

La frontera puede difuminarse. Un rollup puede usar un servicio similar a un coprocesador para analítica, y un coprocesador puede usar infraestructura de pruebas de estilo rollup o una zkVM. La pregunta práctica no es qué etiqueta aparece en una presentación comercial. Pregunta si el sistema es responsable de ordenar y liquidar transacciones de usuarios en su propio entorno de ejecución, o si responde consultas verificables sobre el historial de otra cadena.

Para los usuarios, esta diferencia cambia la superficie de riesgo. Un rollup plantea preguntas sobre la custodia de los puentes, la disponibilidad de datos, el comportamiento del secuenciador, las retiradas y la corrección del estado. Un coprocesador plantea preguntas sobre las entradas de la consulta, la solidez de la prueba, la cobertura de datos históricos, la disponibilidad del probador y si el contrato de destino gestiona el resultado de forma segura. Ninguna categoría elimina toda la confianza ni todo el riesgo operativo.

En qué se diferencia de un oracle

Un oracle suministra información a un smart contract que el contrato no puede obtener directamente. Los feeds de precios son el ejemplo más conocido. Una red de oracle puede agregar precios de ETH de exchanges y publicar un valor para mercados de préstamo. El contrato confía en el diseño del oracle, los informadores participantes, el método de agregación y las salvaguardas contra la manipulación.

Un coprocesador ZK suele demostrar un cálculo a partir de datos de blockchain especificados. Podría demostrar que una dirección interactuó con un protocolo, que la exposición histórica de una bóveda superó un umbral o que un conjunto de transacciones cumple una regla. La prueba responde si un cálculo siguió correctamente sus entradas. No demuestra automáticamente que un precio de mercado externo, una identidad del mundo real o un hecho legal sean verdaderos.

Los dos sistemas pueden trabajar juntos. Un oracle puede proporcionar una entrada de precio firmada o autenticada de otra manera, y un coprocesador puede demostrar un cálculo de riesgo que use esa entrada junto con posiciones históricas on-chain. En ese diseño, la prueba puede proteger el cálculo mientras el oracle sigue siendo un punto de confianza para los datos del mundo exterior.

También conviene advertir sobre la palabra trustless. Una prueba puede reducir la dependencia de una multisig o de un único servidor para el cálculo, pero no puede demostrar hechos que nunca estuvieron representados en sus entradas. Si una aplicación necesita una credencial del mundo real, un precio actual de exchange o una reclamación legal, sigue necesitando una atestación adecuada o un mecanismo de oracle.

¿Qué pueden construir los desarrolladores con uno?

El beneficio más inmediato es una computación más barata o más expresiva. Los contratos de Ethereum pagan la ejecución con gas, y escanear historiales largos o procesar grandes conjuntos de datos directamente on-chain puede ser impracticable. Un coprocesador traslada el trabajo pesado off-chain y deja un paso de verificación compacto on-chain. El coste total sigue incluyendo la generación de pruebas, la recuperación de datos, el envío de la prueba y, a veces, una comisión de servicio, así que más barato no significa gratis.

Motores de riesgo DeFi

Un protocolo de préstamo podría usar posiciones históricas para estimar la concentración, el comportamiento de liquidación o la relación de un prestatario con otros mercados. Una bóveda podría comprobar una ventana de riesgo más larga de lo que su código on-chain puede procesar de forma eficiente. Un sistema de recompensas podría calcular la participación a lo largo de muchos bloques sin almacenar cada valor intermedio on-chain.

Estos usos son valiosos porque las aplicaciones DeFi a menudo necesitan contexto, no solo un número actual. Pero los modelos de riesgo no se vuelven correctos por el hecho de estar demostrados. Los desarrolladores aún deben elegir supuestos sólidos, tener en cuenta datos faltantes y comportamientos de flash-loan, y definir cómo responde el protocolo cuando una prueba se retrasa o no está disponible.

Identidad privada y elegibilidad

Un usuario podría demostrar una afirmación limitada sobre una credencial más amplia sin revelar la propia credencial. Por ejemplo, una aplicación podría verificar que una persona cumple un requisito de edad o jurisdicción, o que una wallet satisface una regla de participación, limitando al mismo tiempo la información expuesta al contrato. Que esto sea realmente privado depende del emisor de la credencial, la wallet, los metadatos, el proceso de revocación y lo que la aplicación registre públicamente.

La actividad on-chain suele poder vincularse incluso cuando una prueba oculta algunas entradas. Una prueba privada no garantiza transacciones privadas, redes anónimas ni protección frente a todas las formas de análisis. Los sistemas de identidad también se enfrentan al problema de demostrar que una persona controla solo una identidad elegible, algo que la criptografía por sí sola no resuelve.

Computación barata y consultas complejas

La computación general es otro objetivo. Un desarrollador puede querer ejecutar lógica de reputación, analítica de carteras, cálculos de gobernanza o reglas de juego sobre el historial de una blockchain. Un sistema de propósito general puede reducir la barrera para expresar estas tareas en comparación con escribir cada operación como un contrato on-chain.

Axiom se centra en consultas verificables sobre datos de blockchain. RISC Zero ofrece un enfoque de zkVM de propósito general que puede demostrar programas ejecutados en un entorno RISC-V. Succinct desarrolla infraestructura y herramientas de pruebas, incluida su zkVM SP1. Estos proyectos ilustran un amplio espacio de diseño más que un producto estandarizado. Su rendimiento, entradas admitidas, modelos de despliegue y garantías en producción pueden diferir sustancialmente, por lo que el nombre de un proyecto por sí solo no es prueba de que una integración concreta sea segura o madura.

Límites actuales: coste de prueba, latencia y adopción

El cálculo de pruebas consume muchos recursos. Una consulta que resulta barata para un servidor normal puede requerir hardware, memoria y trabajo de ingeniería considerables cuando cada paso relevante debe representarse en una prueba. Los rangos históricos más amplios, los programas complejos, las operaciones criptográficas y muchos usuarios simultáneos pueden aumentar el tiempo de generación de pruebas y el coste operativo.

La latencia también importa. Una llamada a un contrato que necesita una respuesta inmediata puede no ser compatible con una prueba que tarda minutos o más en generarse. Algunas aplicaciones pueden tolerar actualizaciones asíncronas. Otras necesitan una alternativa, un resultado en caché, un periodo optimista o una acción conservadora mientras la prueba está pendiente. Esas soluciones introducen nuevas decisiones de diseño y, a veces, nuevos supuestos de confianza.

La disponibilidad de datos y la indexación siguen siendo cuellos de botella prácticos. Un prover puede necesitar acceso de archivo, índices especializados o compromisos preprocesados. Si una cadena se reorganiza, cambia un formato de datos o tiene una cobertura histórica incompleta, la aplicación necesita una política clara. La prueba solo es tan útil como los datos que el programa ha podido consumir realmente.

La experiencia de desarrollo está mejorando, pero escribir circuitos o programas zkVM todavía requiere conocimientos especializados. Los errores pueden surgir del código de la aplicación, de la traducción a una forma demostrable, del manejo de entradas públicas y privadas, o de la integración del verificador. Las auditorías ayudan, pero no son garantías. El código open-source, las compilaciones reproducibles, la verificación independiente, los programas de recompensas por errores y los límites conservadores son señales significativas que conviene examinar.

Qué significa esto para usuarios y constructores

Para los constructores, empieza por la afirmación exacta que el contrato necesita verificar. Define el bloque, la cadena, los compromisos de datos, la versión del programa, la obsolescencia aceptable y el comportamiento si la prueba no puede producirse. Después compara un coprocesador con opciones más sencillas, como almacenar un agregado móvil, usar un oracle establecido o hacer el cálculo directamente on-chain. La arquitectura más avanzada no es automáticamente la mejor.

Para los usuarios, mira más allá de la expresión con tecnología ZK. Averigua si el producto tiene uso real en mainnet o si es principalmente una demostración. Comprueba qué partes son open source, quién puede actualizar el verificador, si un coordinador puede censurar o retrasar pruebas, cómo se obtienen los datos históricos y qué ocurre tras un resultado incorrecto. Si un protocolo acepta grandes depósitos, examina las auditorías y el historial de incidentes en lugar de confiar en la marca criptográfica.

También es útil separar tres preguntas. ¿Puede el sistema calcular el resultado solicitado? ¿Puede probar el resultado de forma sólida? ¿Usará la aplicación ese resultado de forma segura en condiciones adversariales? Una respuesta convincente a la primera pregunta no resuelve las otras dos.

Como lector avanzado, quizá también quieras comparar este tema con cómo funciona el escalado de Ethereum y qué son las pruebas de conocimiento cero. Esos conceptos explican por qué la generación de pruebas puede reducir el trabajo de verificación on-chain, aunque siga requiriendo decisiones cuidadosas sobre datos, cálculo y confianza.

Lee críticamente las afirmaciones sobre coprocesadores ZK

Los coprocesadores ZK avanzan rápido, y las afirmaciones que los rodean a menudo avanzan aún más rápido. Seguir manualmente lanzamientos técnicos, integraciones y noticias de seguridad es difícil. Zippfeed muestra titulares relevantes con puntuación de sentimiento bullish, neutral o bearish y una calificación de importancia, lo que te ayuda a distinguir un despliegue de producción significativo de un prototipo, un anuncio de colaboración o un riesgo sin resolver. Usa ese contexto para seguir la tecnología sin tratar la cobertura como una recomendación para comprar o usar ningún proyecto.