¿Por qué se dice que ZK es el juego final?

Antecedentes históricos del coprocesador

En el mundo informático tradicional, un coprocesador es una unidad de procesamiento que es responsable de procesar otras cosas complejas para el cerebro de la CPU. El coprocesamiento es muy común en el campo de la informática, como el coprocesador de movimiento M7 de Apple en 2013, que mejoró en gran medida la sensibilidad al movimiento de los dispositivos inteligentes. La GPU, como se le conoce comúnmente, es un coprocesador propuesto por Nvidia en 2007 para manejar tareas como el renderizado de gráficos para la CPU. Las GPU aceleran las aplicaciones que se ejecutan en las CPU al descargar algunas partes del código que requieren mucho tiempo y computación, una arquitectura conocida como computación “heterogénea”/“híbrida”.

Los coprocesadores pueden descargar código complejo y de alto rendimiento que cumple con requisitos de rendimiento específicos o extremadamente altos, permitiendo que la CPU maneje partes más flexibles y variables.

En la cadena de bloques Ether, hay dos problemas graves que obstaculizan el desarrollo de las aplicaciones:

1. Debido al alto costo de la tarifa de gas requerida para las operaciones, una transferencia común tiene un límite de gas duro codificado de 21000, lo que muestra el nivel base de la tarifa de gas en la red de Ethereum. Otras operaciones, como el almacenamiento, requerirán más gas, lo que limitará el alcance del desarrollo de aplicaciones en la cadena. La mayoría del código de contrato se centra únicamente en operaciones de activos, y una vez que se involucran operaciones complejas, se necesitará una gran cantidad de gas, lo que representa un grave obstáculo para la “Adopción Masiva” de aplicaciones y usuarios.
2. Debido a que los contratos inteligentes existen en máquinas virtuales, los contratos inteligentes en realidad solo pueden acceder a los datos de los 256 bloques recientes, especialmente en la actualización de Pectra del próximo año, la introducción de la propuesta EIP-4444, los nodos completos no almacenarán más largos los datos pasados. Bloquear datos, luego la falta de datos, lo que resulta en el retraso en la aparición de aplicaciones innovadoras basadas en datos, después de todo, similar a Tiktok, Instagram, aplicaciones Defi de datos más largas, LLM, etc. se construyen en base a datos, Esta es también la razón por la que Lens, un protocolo social basado en datos, quiere lanzar Layer3 Momoka, porque creemos que la cadena de bloques es que el flujo de datos es muy suave, después de todo, los on-chain son abiertos y transparentes, pero de hecho, no es el caso, solo token el flujo fluido de datos de activos, pero los activos de datos aún se ven obstaculizados en gran medida debido a la imperfección de la infraestructura subyacente, lo que también limitará seriamente la aparición de productos de “adopción masiva”.

A través de este hecho, nos encontramos con que tanto el cálculo como los datos son las razones que limitan la aparición del nuevo paradigma informático “Adopción Masiva”. Sin embargo, este es un inconveniente del Ethereum Cadena de bloques en sí, y no fue diseñado para manejar tareas computacionalmente grandes y con uso intensivo de datos. Pero, ¿cómo desea ser compatible con estas aplicaciones informáticas y de uso intensivo de datos? Aquí es necesario introducir el coprocesador, la propia cadena de Ethereum como CPU, el coprocesador es similar a la GPU, la propia cadena puede procesar algunos datos de activos no computacionales, intensivos en datos y operaciones simples, y la aplicación quiere usar datos o recursos informáticos de manera flexible puede usar el coprocesador. Con la exploración de la tecnología ZK, en orden de garantizar que no sea necesario confiar en el coprocesador para la computación y el uso de datos en el off-chain, es natural que la mayoría de los coprocesadores se desarrollen largo con ZK como capa inferior.

Para ZK Coprocessor, su amplio alcance de aplicaciones puede cubrir cualquier escenario de aplicación de dapp real, como redes sociales, juegos, bloques de construcción DeFi, sistemas de control de riesgos basados en datos en cadena, oráculos, almacenamiento de datos, entrenamiento de lenguaje de modelos grandes, inferencia, etc. En teoría, cualquier cosa que una aplicación Web2 pueda hacer, se puede lograr con el coprocesador ZK, y además se cuenta con Ethereum como capa de liquidación final para proteger la seguridad de la aplicación.

En el mundo tradicional, el coprocesador no tiene una definición clara y cualquier chip independiente que pueda ayudar a completar una tarea se llama coprocesador. Actualmente, la definición de coprocesador ZK no es completamente la misma en la industria, como ZK-Query, ZK-Oracle, ZKM, etc., todos son coprocesadores que pueden ayudar a consultar datos completos en la cadena, datos confiables fuera de la cadena y resultados de cálculo fuera de la cadena. Desde esta definición, de hecho, Layer2 también se considera un coprocesador de Ethereum. En el siguiente texto, también compararemos las similitudes y diferencias entre Layer2 y el coprocesador ZK general.

Lista de proyectos de coprocesador

Parte del proyecto del coprocesador ZK, fuente de la imagen: Gate Ventures

Actualmente, la conocida industria se divide en tres partes principales: indexación de datos en la cadena, máquinas de oráculo y la aplicación ZKML. Los tres escenarios contienen el proyecto General-ZKM, y cada uno de ellos tiene su propia máquina virtual que se ejecuta fuera de la cadena, como Delphinus que se centra en zkWASM, y Risc Zero que se centra en la arquitectura Risc-V.

Arquitectura de tecnología de coprocesador

Tomemos el procesador General ZK como ejemplo para analizar su arquitectura y comprender las similitudes y diferencias en su diseño técnico y mecanismos. Esto nos permitirá evaluar las tendencias futuras en el desarrollo de procesadores auxiliares. En este análisis nos centraremos principalmente en tres proyectos: Risc Zero, Lagrange y Succinct.

Risc Zero

En Risc Zero, su coprocesador ZK se llama Bonsai.

Estructura Bonsai, fuente de imagen: Risc Zero

Componentes de Bonsai, Fuente de imagen: Risc Zero

En Bonsai, se ha construido un conjunto completo de componentes de prueba de conocimiento cero independientes de la cadena, con el objetivo de convertirse en un coprocesador independiente de la cadena, basado en la arquitectura del conjunto de instrucciones Risc-V, con gran versatilidad, y admite lenguajes como Rust, C++, Solidity, Go, etc. Sus principales funciones incluyen:

1. zkVM general, capaz de ejecutar cualquier máquina virtual en un entorno de conocimiento cero/verificable.
2. Sistema de generación de pruebas ZK que se puede integrar directamente en cualquier contrato inteligente o cadena
3. Un rollup genérico que distribuye cualquier cálculo probado en Bonsai en la cadena, permitiendo a los mineros de la red generar pruebas.

Sus componentes incluyen:

1. Red de probadores: a través de la API de Bonsai, los probadores reciben código ZK que necesita ser verificado en la red, luego ejecutan el algoritmo de pruebas y generan una prueba de conocimiento cero (ZK), esta red estará abierta a todos en el futuro.
2. Pool de solicitudes: esta piscina almacena las solicitudes de prueba iniciadas por los usuarios (similar al mempool de Ethereum, que se utiliza para almacenar temporalmente transacciones), luego este Pool de solicitudes se ordenará por el Secuenciador para generar bloques, muchas de las solicitudes de prueba se dividirán para mejorar la eficiencia de la prueba.
3. Motor Rollup: Este motor recopila los resultados de prueba recopilados en la red de validadores y los empaqueta en una Prueba de Raíz, que se carga en la Mainnet de Ethereum para que los validadores on-chain puedan verificar en cualquier momento.
4. Image Hub: Esta es una plataforma de desarrollo visual en la que se pueden almacenar funciones y aplicaciones completas. Por lo tanto, los desarrolladores pueden llamar a las API correspondientes a través de contratos inteligentes, lo que le permite a los contratos inteligentes en la cadena llamar a programas fuera de la cadena.
5. State Store: Bonsai también introduce almacenamiento de estado fuera de la cadena, que se almacena en la base de datos en forma de pares de clave-valor, lo que puede reducir los costos de almacenamiento en la cadena y, en combinación con la plataforma ImageHub, puede reducir la complejidad de los contratos inteligentes.
6. Proving Marketplace: La cadena de suministro de ZK de la cadena de la industria, el mercado de potencia computacional se utiliza para emparejar la oferta y la demanda de potencia computacional.

Lagrange

El objetivo de Lagrange es construir un coprocesador y una base de datos verificable, que incluya 01928374656574839201 datos históricos en la cadena, para permitir el desarrollo de aplicaciones sin confianza que puedan utilizar estos datos de manera fluida. Esto puede satisfacer el desarrollo de aplicaciones intensivas en cálculos y datos.

Esto implica dos funciones:

1. Base de datos verificable: a través del almacenamiento de contratos inteligentes en la cadena de índices on-chain, se coloca el estado on-chain generado por los contratos inteligentes en una base de datos. Básicamente, se reconstruye el almacenamiento, estado y bloques de la cadena de bloques, y se almacena de manera actualizada en una base de datos off-chain fácilmente recuperable.
2. Cálculo basado en el principio de MapReduce: el principio de MapReduce implica el cálculo en bases de datos de gran tamaño mediante la separación de datos en múltiples instancias y la ejecución en paralelo, para finalmente integrar los resultados. Lagrange se refiere a esta arquitectura de ejecución en paralelo como zkMR.

En el diseño de la base de datos, hay tres partes de datos en la cadena, a saber, los datos almacenados en el contrato, los datos de estado de EOA y los datos de bloque.

Estructura de la base de datos de Lagrange, fuente de la imagen: Lagrange

El anterior es la estructura de mapeo de los datos almacenados en el contrato, donde se almacenan las variables de estado del contrato, y cada contrato tiene un Trie de Almacenamiento independiente, este Trie se almacena en forma de árbol MPT dentro de Ethereum. Aunque el árbol MPT es simple, su eficiencia es baja, esto es también la razón por la que los desarrolladores principales de Ethereum están impulsando el desarrollo del árbol Verkle. En Lagrange, cada nodo puede usar SNARK/STARK para hacer una “prueba”, y el nodo padre contiene la prueba de los nodos hijos, lo que requiere el uso de la técnica de prueba recursiva.

Estado de cuenta, fuente de imagen: Lagrange

Las cuentas se dividen en EOA y cuentas de contrato, ambas pueden representar el estado de la cuenta en forma de cuenta / Storage Root (espacio de almacenamiento de variables de contrato). Sin embargo, parece que Lagrange no ha diseñado completamente esta parte, de hecho, también se necesita la raíz del State Trie (espacio de almacenamiento de estado de cuentas externas).

Estructura de datos de bloque, fuente de la imagen: Lagrange

En la nueva estructura de datos, Lagrange creó una estructura de datos de bloques amigable para las pruebas SNARKs, donde cada hoja del árbol es una cabecera de bloque y el tamaño de este árbol es fijo. Si Ethereum genera un bloque cada 12 segundos, esta base de datos durará unos 25 años.

En la máquina virtual ZKMR de Lagrange, su cálculo consta de dos pasos:

1. Mapa: Una máquina distribuida mapea todos los datos para generar pares clave-valor.
2. Reducción: los ordenadores de cálculo distribuido calculan las pruebas por separado y luego se combinan todas las pruebas.

En resumen, ZKMR puede combinar pruebas de cálculos más pequeños para crear una prueba de todo el cálculo. Esto permite que ZKMR se escale de manera efectiva para demostrar cálculos complejos en conjuntos de datos grandes que requieren múltiples pasos o capas de cálculo. Por ejemplo, si Uniswap se despliega en 100 cadenas, para calcular el precio TWAP de un token en 100 cadenas se requiere una gran cantidad de cálculos e integración. En este caso, ZKMR puede calcular cada cadena por separado y luego combinarlas en una prueba de cálculo completa.

Proceso de ejecución del coprocesador Lagrange, fuente de la imagen: Lagrange

El proceso de ejecución es el siguiente:

1. Los contratos inteligentes de los desarrolladores primero se registran en Lagrange, luego envían una solicitud de prueba al contrato inteligente en la cadena de Lagrange, en este momento, el contrato del agente es responsable de interactuar con el contrato del desarrollador.
2. El Lagrange off-chain divide las solicitudes en tareas pequeñas paralelizables y las distribuye a diferentes probadores para su verificación conjunta.
3. Este validador en realidad es una red, cuya seguridad está garantizada por la tecnología de Restaking de EigenLayer.

Conciso

El objetivo de la Red Concisa es integrar conjuntos de hechos programables en cada parte del stack de desarrollo de blockchain (incluyendo L2, coprocesadores, puentes cross-chain, etc.).

Proceso de operación conciso, fuente de imagen: Succinct

Succinct puede aceptar códigos especializados, incluidos Solidity y lenguajes específicos de dominio (DSL) en el campo del conocimiento cero, que se transmiten al coprocesador Succinct fuera de la cadena. Succinct completa el índice de datos del chain objetivo, luego envía la solicitud de prueba al mercado de pruebas, lo que permite que los rigs de minera con chips de CPU, GPU y ETC, entre otros, envíen pruebas en la red de pruebas. Su característica radica en la compatibilidad del mercado de pruebas con diversos sistemas de pruebas, ya que habrá un período prolongado en el futuro en el que coexistan varios sistemas de pruebas.

El ZKVM off-chain de Succinct, llamado SP (Succinct Processor), es capaz de admitir el lenguaje Rust y otros lenguajes LLVM, con características principales que incluyen:

1. Recursividad + Verificación: La tecnología de prueba recursiva basada en la tecnología STARKs puede mejorar exponencialmente la eficiencia de compresión de ZK.
2. Soporte para envoltura SNARKs a STARKs: Capaz de adoptar simultáneamente las ventajas de SNARKs y STARKs, resolviendo el problema de equilibrio entre el tamaño de la prueba y el tiempo de verificación.
3. Arquitectura zkVM centrada en la compilación previa: para algunos algoritmos comunes como SHA256, Keccak, ECDSA, etc., se pueden compilar de antemano para reducir el tiempo de generación y verificación de pruebas en tiempo de ejecución.

Comparación

Al comparar los coprocesadores ZK comunes, nos centramos principalmente en compararlos según el primer principio de la Adopción Masiva. También explicaremos por qué es importante:

1. Problemas de indexación/sincronización de datos: solo con datos completos en la cadena y una función de índice de sincronización se pueden cumplir los requisitos de aplicaciones basadas en grandes datos; de lo contrario, su alcance de aplicación es más limitado.
2. Basado en tecnología: SNARKs y la tecnología STARKs tienen diferentes puntos de inflexión. En el corto plazo, la tecnología SNARKs es la principal, mientras que a largo plazo, la tecnología STARKs es la principal.
3. ¿Soporta recursión?: Solo con soporte para recursión se puede comprimir los datos al máximo y lograr una prueba de cálculo paralelo, por lo tanto, la implementación completa de la recursión es el punto destacado del proyecto.
4. Sistema de prueba: El sistema de prueba afecta directamente al tamaño y tiempo de generación de pruebas, que es el área de mayor costo en la tecnología ZK, actualmente se basa principalmente en la creación de un mercado de potencia computacional ZK y una red de pruebas.
5. Cooperación ecológica: puede determinar si su dirección tecnológica es reconocida por los usuarios B a través de la demanda real de terceros.
6. VC admitidos y situación de financiamiento: puede representar la situación de apoyo de recursos posteriores.

Fuente de la imagen: Gate Ventures

De hecho, la ruta tecnológica en su conjunto ya está muy clara, por lo que la mayoría de las tecnologías tienden a ser similares, como el uso de envoltorios de STARKs a SNARKs, lo que permite aprovechar las ventajas de ambas, reduciendo el tiempo de generación y verificación de pruebas, así como la resistencia a los ataques cuánticos. Dado que el rendimiento recursivo del algoritmo de conocimiento cero (ZK) puede afectar en gran medida el rendimiento de ZK, los tres proyectos actuales tienen capacidades recursivas. La generación de pruebas mediante el algoritmo de ZK es la parte más costosa y que requiere más tiempo, por lo que los tres proyectos dependen de la demanda de potencia computacional de ZK para construir redes de probadores y mercados de minería en la nube. Dado este panorama, en el que actualmente las rutas tecnológicas son muy similares, es posible que para destacarse se necesite la ayuda del equipo y los VC detrás de ellos para aprovechar los recursos de colaboración en el ecosistema y ganar cuota de mercado.

Diferencias y similitudes entre el coprocesador y Layer2

A diferencia de Layer2, el coprocesador está orientado a la aplicación, mientras que Layer2 sigue estando orientado al usuario. El coprocesador puede funcionar como un componente de aceleración o modular, formando los siguientes escenarios de aplicación:

1. Como componente de la máquina virtual off-chain de ZK Layer2, estos Layer2 pueden cambiar su propia VM por un coprocesador.
2. Como coprocesador para descargar la potencia computacional de las aplicaciones en la cadena pública a la cadena fuera de la misma.
3. Máquina de oráculo para que las aplicaciones en la cadena pública obtengan datos verificables de otras cadenas.
4. Transmitir mensajes como puentes cross-chain en dos cadenas.

Estos escenarios de aplicación son solo una parte de la lista. En cuanto a los coprocesadores, necesitamos entender el potencial que traen de sincronización de datos en tiempo real y de alto rendimiento y baja costo de cómputo confiable para toda la cadena, y la capacidad de reconstruir de manera segura casi todos los middleware de blockchain a través de coprocesadores. Incluyendo Chainlink, The Graph actualmente está desarrollando su propio oráculo ZK y consultas; mientras que puentes cross-chain líderes como Wormhole, Layerzero, etc., también están investigando tecnologías de puentes cross-chain basadas en ZK; entrenamiento de LLMs (oráculos de modelos grandes) off-chain y razonamiento confiable, etc.

Problemas enfrentados por el coprocesador

1. Hay resistencia para que los desarrolladores ingresen, la tecnología ZK es teóricamente factible, pero todavía hay dificultades técnicas anhelantes, y la comprensión externa también es oscura, por lo que cuando los nuevos desarrolladores ingresan al ecosistema, puede ser una gran resistencia debido a la necesidad de dominar lenguajes específicos y herramientas de desarrollo.
2. La pista está en una etapa muy temprana, el rendimiento de zkVM es muy complejo e implica múltiples dimensiones (incluyendo hardware, rendimiento de nodos individuales y múltiples, uso de memoria, costos recursivos, selección de funciones hash, etc.), actualmente hay proyectos en construcción en cada dimensión, la pista está en una etapa muy temprana y el panorama aún no está claro.
3. Las condiciones previas como el hardware aún no se han implementado. En cuanto al hardware, actualmente los principales métodos de construcción son ASIC y FPGA, con fabricantes como Ingonyama, Cysic, etc. Sin embargo, todavía se encuentran en fase experimental y no se han comercializado. Consideramos que el hardware es un requisito previo para la implementación a gran escala de la tecnología ZK.
4. Las trayectorias técnicas son similares, es difícil tener una ventaja técnica generacional. Actualmente, la principal competencia se centra en los recursos de VC y la capacidad de desarrollo empresarial del equipo, para ver si pueden obtener una posición ecológica en las aplicaciones y cadenas públicas principales.

Resumen y perspectivas

La tecnología ZK es altamente versátil y también ayuda al ecosistema de Ethereum a pasar de una orientación de valor descentralizada a una visión de valor sin confianza. ‘No confíes, verifica’, esta frase es la mejor práctica de la tecnología ZK. La tecnología ZK puede reconstruir una serie de escenarios de aplicación como puentes cross-chain, máquinas de oráculo, consultas en cadena, cálculos fuera de cadena, máquinas virtuales, etc., y el coprocesador ZK de propósito general es una de las herramientas para implementar la tecnología ZK. En cuanto al coprocesador ZK, su aplicación es amplia y puede cubrir cualquier escenario de aplicación real de dapp. En teoría, cualquier cosa que una aplicación Web2 pueda hacer, se puede lograr con un coprocesador ZK.

Curva de adopción de tecnología, fuente: Gartner

Desde la antigüedad, el desarrollo tecnológico siempre ha estado rezagado con respecto a la imaginación de los seres humanos para una vida mejor (como el viaje de Chang’e a la Luna hasta el aterrizaje de Apolo en la Luna). Si algo es verdaderamente innovador, disruptivo y necesario, la tecnología sin duda lo logrará, es solo cuestión de tiempo. Creemos que el Procesador ZK universal sigue esta tendencia de desarrollo. Tenemos dos indicadores para la ‘Adopción Masiva’ del Procesador ZK: una base de datos en tiempo real con pruebas y cálculos de baja costo fuera de la cadena. Si los datos son suficientes, se sincronizan en tiempo real y se realizan cálculos de verificación fuera de la cadena a bajo costo, entonces el paradigma de desarrollo de software puede cambiar por completo, pero este objetivo se logra a través de iteraciones lentas. Por lo tanto, nos enfocamos en buscar proyectos que cumplan con estas dos tendencias o valores, y la implementación de chips de potencia computacional ZK es un requisito previo para la aplicación comercial a gran escala del Procesador ZK. Esta etapa del ciclo carece de innovación y es una ventana real para construir la próxima generación de tecnología y aplicaciones de ‘Adopción Masiva’. Esperamos que en el próximo ciclo, la cadena industrial ZK pueda aterrizar comercialmente, por lo que ahora es el momento de volver a centrarse en tecnologías que realmente permitan que Web3 soporte interacciones en la cadena para mil millones de personas.