A medida que el concepto de coprocesadores se ha vuelto popular en los últimos meses, este nuevo caso de uso de ZK ha comenzado a recibir cada vez más atención.

Sin embargo, descubrimos que la mayoría de las personas todavía no están relativamente familiarizadas con el concepto de coprocesadores, especialmente con la ubicación precisa de los coprocesadores: qué es un coprocesador y qué no es todavía es relativamente vago. En cuanto a la comparación de las soluciones técnicas de varias pistas de coprocesadores disponibles en el mercado, nadie lo ha resuelto todavía de forma sistemática. Este artículo espera brindar al mercado y a los usuarios una comprensión más clara de la pista del coprocesador.

1. ¿Qué es Coprocesador y qué no lo es?

Si le pidieran que explicara los coprocesadores a un desarrollador o no técnico en una sola oración, ¿cómo lo describiría?

Creo que lo que dijo el Dr. Dong Mo puede estar muy cerca de la respuesta estándar: para decirlo sin rodeos, un coprocesador está "dando a los contratos inteligentes la capacidad de realizar Dune Analytics".

¿Cómo deconstruir esta frase?

Imagine el escenario en el que usamos Dune: desea hacer LP en Uniswap V3 para ganar algunas tarifas de manejo, por lo que abre Dune y encuentra el volumen de operaciones reciente de varios pares comerciales en Uniswap, la APR de las tarifas de manejo en los últimos 7 días. y los principales pares comerciales. Los rangos de fluctuación superior e inferior, etc.

O tal vez cuando StepN se hizo popular, comenzaste a especular con los zapatos y no estabas seguro de cuándo venderlos, por lo que mirabas los datos de StepN en Dune todos los días, el volumen de transacciones diarias, la cantidad de nuevos usuarios, el precio mínimo de los zapatos... y planeó hacerlo una vez que hubiera crecimiento. Si la tendencia se desacelera o baja, corre rápido.

Por supuesto, es posible que no solo estés mirando estos datos, sino que los equipos de desarrollo de Uniswap y StepN también están prestando atención a estos datos.

Estos datos son muy significativos: no sólo pueden ayudar a juzgar los cambios en las tendencias, sino también utilizarlos para crear más trucos, al igual que el enfoque de "grandes datos" comúnmente utilizado por las principales empresas de Internet.

Por ejemplo, según el estilo y el precio de los zapatos que los usuarios suelen comprar y vender, se recomiendan zapatos similares.

Por ejemplo, se lanzará un “Programa de recompensas por fidelidad de usuarios” en función del tiempo que los usuarios tengan Creation Shoes para brindarles a los usuarios leales más lanzamientos aéreos o beneficios.

Por ejemplo, se puede lanzar un plan VIP similar a Cex en función del TVL o el volumen de operaciones proporcionado por LP en Uniswap o Trader, lo que le brinda al Trader una reducción de la tarifa de transacción o mayores beneficios a la tarifa compartida de LP...

En este momento, surge el problema: el big data + AI de las grandes empresas de Internet es básicamente una caja negra. Ellos pueden hacer lo que quieran. Los usuarios no pueden verlo y no les importa.

Pero aquí en Web3, la transparencia y la falta de confianza son nuestra corrección política natural, ¡y rechazamos las cajas negras!

Entonces, cuando desee implementar el escenario anterior, se enfrentará a un dilema: o puede lograrlo a través de medios centralizados, usar Dune "manualmente" para contar los datos del índice en segundo plano y luego implementarlo e implementarlo; o puede escribir un Configurar contratos inteligentes para capturar automáticamente estos datos en la cadena, completar cálculos e implementar puntos automáticamente.

Lo primero le llevará a problemas de confianza “políticamente incorrectos”.

La tarifa de gas generada por este último en la cadena será una cifra astronómica y su billetera (del lado del proyecto) no puede permitírselo.

Este es el momento de que el coprocesador suba al escenario. Combine los dos métodos ahora y, al mismo tiempo, utilice el paso del "manual de backend" para "autocertificar la inocencia" a través de medios técnicos. En otras palabras, utilice la tecnología ZK para "indexar +" La parte de "cálculo" "autoprueba la inocencia" y luego la introduce en el contrato inteligente. De esta manera, se resuelve el problema de la confianza y desaparecen las enormes tarifas del gas. ¡Perfecto!

¿Por qué se llama "coprocesador"? De hecho, esto proviene de la "GPU" en el historial de desarrollo de Web2.0. La razón por la que la GPU se introdujo como un hardware informático separado y existía independientemente de la CPU en ese momento fue porque su arquitectura de diseño podía manejar algunos cálculos que eran fundamentalmente difíciles de manejar para la CPU, como cálculos repetidos paralelos a gran escala, gráficos. cálculos, etc. Es precisamente gracias a esta arquitectura de "coprocesador" que hoy en día tenemos maravillosas películas generadas por computadora, juegos, modelos de IA, etc., por lo que esta arquitectura de coprocesador es en realidad un salto en la arquitectura informática. Ahora varios equipos de coprocesadores también esperan introducir esta arquitectura en Web3.0. La cadena de bloques aquí es similar a la CPU de Web3.0. Ya sea L1 o L2, son intrínsecamente inadecuados para tareas de “datos pesados” y “lógica de cálculo compleja”, por lo que se introduce un coprocesador blockchain para ayudar a manejar dichos cálculos, ampliando así en gran medida las posibilidades de las aplicaciones blockchain.

Entonces, lo que hace el coprocesador se puede resumir en dos cosas:

1. Obtenga los datos de blockchain y use ZK para demostrar que los datos que obtuve son verdaderos y no están adulterados;
2. Realice los cálculos correspondientes basándose en los datos que acabo de recibir y una vez más use ZK para demostrar que los resultados que calculé son verdaderos y no están adulterados. Los resultados del cálculo se pueden llamar mediante el contrato inteligente "Low Fee + Trustless".

Hace algún tiempo, Starkware tenía un concepto popular llamado Storage Proof, también llamado State Proof. Básicamente realiza el paso 1, representado por Heródoto, Langrage, etc. El enfoque técnico de muchos puentes entre cadenas basados en la tecnología ZK también se encuentra en el paso 1.1 en adelante.

El coprocesador no es más que el paso 1 seguido del paso 2. Después de extraer los datos sin confianza, haz un cálculo sin confianza y listo.

Entonces, para usar un término relativamente técnico para describirlo con precisión, el coprocesador debe ser un superconjunto de Prueba de almacenamiento/Prueba de estado y un subconjunto de Computación verificable.

Una cosa a tener en cuenta es que el coprocesador no es Rollup.

Técnicamente hablando, la prueba ZK de Rollup es similar al paso 2 anterior, y el proceso del paso 1 "obtener datos" se implementa directamente a través de Sequencer. Incluso un secuenciador descentralizado sólo utiliza algún tipo de mecanismo de competencia o consenso para lograrlo. Tome, en lugar de Storage Proof, esta forma de ZK. Lo que es más importante es que, además de la capa de cálculo, ZK Rollup también necesita implementar una capa de almacenamiento similar a la cadena de bloques L1. Este almacenamiento es permanente, mientras que el coprocesador ZK es “sin estado”. Una vez completado el cálculo, no se conserva el estado Todo.

Desde la perspectiva de los escenarios de aplicación, el coprocesador puede considerarse como un complemento de servicio para todas las Capas 1/Capa 2, mientras que Rollup recrea una capa de ejecución para ayudar a expandir la capa de liquidación.

2. ¿Por qué tengo que utilizar ZK? ¿Está bien usar OP?

Después de leer lo anterior, es posible que tengas una duda: ¿se debe utilizar ZK como coprocesador? Suena muy parecido a un “Gráfico con ZK agregado”, y no parece que tengamos “grandes dudas” sobre los resultados del Gráfico.

Esto se debe a que cuando usas Graph, básicamente no hay dinero real involucrado. Estos índices prestan servicios fuera de la cadena. Lo que ve en la interfaz de usuario de front-end es el volumen de transacciones, el historial de transacciones, etc. Los datos se pueden proporcionar a través de múltiples proveedores de índices de datos, como Graph, Alchemy, Zettablock, etc., pero estos datos no se pueden volver a incluir en el contrato inteligente, porque una vez que los vuelva a ingresar, agregará confianza adicional en el servicio de índice. Cuando los datos están vinculados a dinero real, especialmente TVL de gran volumen, esta confianza adicional se vuelve importante. Imagina que la próxima vez que un amigo te pida prestados 100 yuanes, puedes prestárselos sin pestañear. Sí, ¿qué pasa cuando te pido que me prestes 10.000 yuanes, o incluso 1 millón de yuanes?

Pero, de nuevo, ¿realmente tenemos que usar ZK para coprocesar todos los escenarios anteriores? Después de todo, tenemos dos rutas técnicas, OP y ZK, en Rollup. El recientemente popular ZKML también tiene el concepto OPML de rutas secundarias correspondientes. Cuando se le preguntó, ¿el coprocesador también tiene una rama de OP, como OP-Coprocesador?

De hecho, realmente lo hay, pero mantenemos los detalles específicos confidenciales por ahora y pronto publicaremos información más detallada.

3. ¿Qué coprocesador es el mejor? Comparación de varias soluciones técnicas de coprocesadores comunes en el mercado

Brevis

La arquitectura de Brevis consta de tres componentes: zkFabric, zkQueryNet y zkAggregatorRollup.

El siguiente es un diagrama de arquitectura Brevis:

zkFabric: recopila encabezados de bloques de todas las cadenas de bloques conectadas y genera pruebas de consenso ZK que demuestran la validez de estos encabezados de bloques. A través de zkFabric, Brevis implementa un coprocesador interoperable para múltiples cadenas, lo que permite que una cadena de bloques acceda a cualquier dato histórico de otra cadena de bloques.

zkQueryNet: un mercado abierto de motores de consultas ZK que acepta consultas de datos de dApps y las procesa. Las consultas de datos procesan estas consultas utilizando encabezados de bloque verificados de zkFabric y generan pruebas de consulta ZK. Estos motores tienen funciones altamente especializadas y lenguajes de consulta generales para satisfacer las diferentes necesidades de las aplicaciones.

zkAggregatorRollup: una cadena de bloques convolucional ZK que actúa como una capa de agregación y almacenamiento para zkFabric y zkQueryNet. Verifica las pruebas de ambos componentes, almacena los datos verificados y envía su raíz de estado validada por zk a todas las cadenas de bloques conectadas.

ZK Fabric es una parte clave para generar pruebas para el encabezado del bloque. Es muy importante garantizar la seguridad de esta parte. El siguiente es el diagrama de arquitectura de zkFabric:

El cliente ligero basado en prueba de conocimiento cero (ZKP) de zkFabric lo hace completamente confiable, sin depender de ninguna entidad de verificación externa. No hay necesidad de depender de ninguna entidad de verificación externa, ya que su seguridad proviene completamente de la cadena de bloques subyacente y de pruebas matemáticamente confiables.

La red zkFabric Prover implementa circuitos para el protocolo de cliente ligero de cada blockchain y la red genera pruebas de validez para los encabezados de los bloques. Los probadores pueden aprovechar aceleradores como GPU, FPGA y ASIC para minimizar el tiempo y el costo de la prueba.

zkFabric se basa en los supuestos de seguridad de blockchain y los protocolos criptográficos subyacentes y los supuestos de seguridad de los protocolos criptográficos subyacentes. Sin embargo, para garantizar la eficacia de zkFabric, se requiere al menos un retransmisor honesto para sincronizar la bifurcación correcta. Por lo tanto, zkFabric utiliza una red de retransmisión descentralizada en lugar de un único retransmisión para optimizar la eficacia de zkFabric. Esta red de retransmisión puede aprovechar las estructuras existentes, como la red de guardias estatales en la red Celer.

Asignación de probadores: la red de probadores es una red de probadores ZKP descentralizada que selecciona un probador para cada tarea de generación de pruebas y paga tarifas a estos probadores.

Despliegue actual:

Los protocolos de cliente ligero implementados actualmente para varias cadenas de bloques, incluidas Ethereum PoS, Cosmos Tendermint y BNB Chain, sirven como ejemplos y pruebas de conceptos.

Brevis actualmente ha cooperado con uniswap hook, que agrega en gran medida grupos de uniswap personalizados. Sin embargo, en comparación con CEX, UnisWap todavía carece de capacidades efectivas de procesamiento de datos para crear proyectos que dependan de grandes datos de transacciones de usuarios (como programas de fidelización basados en el volumen de transacciones). Función.

Con la ayuda de Brevis, Hook resolvió el desafío. Hooks ahora puede leer los datos de la cadena del historial completo de un usuario o LP y ejecutar cálculos personalizables de una manera completamente confiable.

heródoto

Herodotus es un poderoso middleware de acceso a datos que proporciona contratos inteligentes con las siguientes funciones para acceder sincrónicamente a datos actuales e históricos en la cadena en toda la capa Ethereum:

1. Estados L1 de L2
2. Estados L2 tanto de L1 como de otros L2
3. Estados L3/App-Chain a L2 y L1

Heródoto propuso el concepto de prueba de almacenamiento, que combina prueba de inclusión (que confirma la existencia de datos) y prueba computacional (que verifica la ejecución de un flujo de trabajo de varios pasos) para demostrar que un gran conjunto de datos (como toda la cadena de bloques o el paquete acumulativo de Ethereum) o la validez de múltiples elementos.

El núcleo de la cadena de bloques es la base de datos, en la que los datos se cifran y protegen mediante estructuras de datos como los árboles Merkle y los árboles Merkle Patricia. Lo que es único acerca de estas estructuras de datos es que una vez que los datos se asignan de forma segura a ellas, se puede generar evidencia para confirmar que los datos están contenidos dentro de la estructura.

El uso de árboles Merkle y árboles Merkle Patricia mejora la seguridad de la cadena de bloques Ethereum. Al codificar criptográficamente los datos en cada nivel del árbol, es casi imposible alterar los datos sin detección. Cualquier cambio en un punto de datos requiere cambiar el hash correspondiente en el árbol al hash raíz, que es visible públicamente en el encabezado de la cadena de bloques. Esta característica fundamental de blockchain proporciona un alto nivel de integridad e inmutabilidad de los datos.

En segundo lugar, estos árboles permiten una verificación eficiente de los datos mediante pruebas de inclusión. Por ejemplo, al verificar la inclusión de una transacción o el estado de un contrato, no es necesario buscar en toda la cadena de bloques Ethereum, sino solo en la ruta dentro del árbol Merkle correspondiente.

La prueba de almacenamiento, tal como la define Heródoto, es una fusión de:

1. Pruebas de contención: estas pruebas confirman la existencia de datos específicos en una estructura de datos criptográficos (como un árbol Merkle o un árbol Merkle Patricia), asegurando que los datos en cuestión están realmente presentes en el conjunto de datos.
2. Prueba computacional: Verifique la ejecución de un flujo de trabajo de varios pasos, demostrando la validez de uno o más elementos en un conjunto de datos amplio, como la cadena de bloques Ethereum completa o un agregado. Además de indicar la presencia de datos, también verifican transformaciones u operaciones aplicadas a esos datos.
3. Pruebas de conocimiento cero: simplifique la cantidad de datos con los que los contratos inteligentes deben interactuar. Las pruebas de conocimiento cero permiten que los contratos inteligentes confirmen la validez de un reclamo sin procesar todos los datos subyacentes.

Flujo de trabajo

1.Obtener hash de bloque

Cada dato en la cadena de bloques pertenece a un bloque específico. El hash del bloque sirve como identificador único del bloque y resume todo su contenido a través del encabezado del bloque. En el flujo de trabajo de prueba de almacenamiento, primero debemos determinar y verificar el hash del bloque que contiene los datos que nos interesan. Este es el primer paso de todo el proceso.

2.Obtener encabezado de bloque

Una vez obtenido el hash del bloque relevante, el siguiente paso es acceder al encabezado del bloque. Para hacer esto, es necesario aplicar hash al encabezado del bloque asociado con el hash del bloque obtenido en el paso anterior. Luego, el hash del encabezado del bloque proporcionado se compara con el hash del bloque resultante:

Hay dos formas de obtener el hash:

1. Utilice el código de operación BLOCKHASH para recuperar
2. Consulta el hash de los bloques que se han verificado en el historial desde Block Hash Accumulator

Este paso garantiza que el encabezado del bloque que se está procesando sea auténtico. Una vez que se completa este paso, el contrato inteligente puede acceder a cualquier valor en el encabezado del bloque.

3.Determine las raíces requeridas (opcional)

Con la cabecera del bloque en la mano, podemos profundizar en su contenido, en concreto:

stateRoot: un resumen criptográfico de todo el estado de la cadena de bloques en el momento en que ocurrió la cadena de bloques.

recibosRoot: resumen cifrado de todos los resultados de las transacciones (recibos) en el bloque.

TransactionsRoot: un resumen criptográfico de todas las transacciones que ocurrieron en el bloque.

se puede decodificar, lo que permite verificar si una cuenta, recibo o transacción específica está incluida en el bloque.

4.Validar datos contra la raíz seleccionada (opcional)

Con la raíz que seleccionamos, y considerando que Ethereum usa una estructura Merkle-Patricia Trie, podemos usar la prueba de inclusión de Merkle para verificar que los datos existen en el árbol. Los pasos de verificación variarán según los datos y la profundidad de los datos dentro del bloque.

Redes actualmente soportadas:

1. De Ethereum a Starknet
2. De Ethereum Goerli a Starknet Goerli
3. De Ethereum Goerli a zkSync Era Goerli

Axioma

Axiom proporciona una forma para que los desarrolladores consulten encabezados de bloque, valores de cuenta o almacenamiento de todo el historial de Ethereum. AXIOM introduce un nuevo método de vinculación basado en criptografía. Todos los resultados devueltos por Axiom se verifican en cadena mediante pruebas de conocimiento cero, lo que significa que los contratos inteligentes pueden usarlos sin suposiciones de confianza adicionales.

Axiom lanzó recientemente Halo2-repl, un halo2 REPL basado en navegador escrito en Javascript. Esto permite a los desarrolladores escribir circuitos ZK usando solo Javascript estándar sin tener que aprender un nuevo lenguaje como Rust, instalar bibliotecas de prueba o lidiar con dependencias.

Axiom consta de dos componentes tecnológicos principales:

1. AxiomV1: caché de blockchain de Ethereum, comenzando con Genesis.
2. AxiomV1Query: un contrato inteligente que ejecuta consultas en AxiomV1.

Hashes de bloque de almacenamiento en caché en AxiomV1:

Los contratos inteligentes AxiomV1 almacenan en caché los hashes del bloque Ethereum desde el bloque génesis de dos formas:

Primero, se almacena en caché la raíz de Keccak Merkle de 1024 hashes de bloques consecutivos. Estas raíces de Merkle se actualizan mediante pruebas ZK, verificando que el hash del encabezado del bloque forme una cadena de compromiso que finalice con uno de los 256 bloques más recientes directamente accesibles al EVM o un hash de bloque que ya existe en la caché de AxiomV1.

En segundo lugar, Axiom almacena la Cordillera de Merkle de estas raíces de Merkle a partir del bloque de génesis. La Cordillera de Merkle se construye en cadena actualizando la primera parte del caché, la raíz de Keccak Merkle.

Ejecute la consulta en AxiomV1Query:

El contrato inteligente AxiomV1Query se utiliza para consultas por lotes para permitir el acceso sin confianza a encabezados de bloques históricos de Ethereum, cuentas y datos arbitrarios almacenados en las cuentas. Las consultas se pueden realizar en cadena y se completan en cadena a través de pruebas ZK contra hashes de bloques almacenados en caché de AxiomV1.

Estas pruebas ZK verifican si los datos relevantes en la cadena se encuentran directamente en el encabezado del bloque, o en la cuenta del bloque o en la prueba de almacenamiento, verificando la prueba de inclusión (o no inclusión) de la prueba Merkle-Patricia.

Nexo

Nexus intenta utilizar pruebas de conocimiento cero para construir una plataforma universal para la computación en la nube verificable. Actualmente es independiente de la arquitectura de la máquina y admite risc 5/WebAssembly/EVM. Nexus utiliza el sistema de prueba de supernovas. El equipo probó que la memoria necesaria para generar la prueba es de 6 GB. En el futuro, se optimizará sobre esta base para que los ordenadores de los dispositivos cliente habituales puedan generar pruebas.

Para ser precisos, la arquitectura se divide en dos partes:

1. Nexus zero: una red de computación en la nube descentralizada y verificable impulsada por pruebas de conocimiento cero y zkVM universal.
2. Nexus: una red de computación en la nube descentralizada y verificable impulsada por computación multipartita, replicación de máquinas de estado y una máquina virtual WASM universal.

Las aplicaciones Nexus y Nexus Zero se pueden escribir en lenguajes de programación tradicionales, que actualmente son compatibles con Rust, y habrá más lenguajes en el futuro.

Las aplicaciones Nexus se ejecutan en una red descentralizada de computación en la nube, que es esencialmente una “cadena de bloques sin servidor” de propósito general conectada directamente a Ethereum. Por lo tanto, las aplicaciones Nexus no heredan la seguridad de Ethereum, sino que a cambio obtienen acceso a una mayor potencia informática (como computación, almacenamiento y E/S controladas por eventos) debido al tamaño reducido de su red. Las aplicaciones Nexus se ejecutan en una nube dedicada que logra un consenso interno y proporciona "pruebas" verificables de cálculo (en lugar de pruebas verdaderas) a través de firmas de umbral verificables en toda la red dentro de Ethereum.

Las aplicaciones Nexus Zero heredan la seguridad de Ethereum, ya que son programas universales con pruebas de conocimiento cero que se pueden verificar en cadena en la curva elíptica BN-254.

Dado que Nexus puede ejecutar cualquier binario WASM determinista en un entorno replicado, se espera que se utilice como fuente de prueba de validez/dispersión/tolerancia a fallos para las aplicaciones generadas, incluidos los secuenciadores zk-rollup, los secuenciadores rollup optimistas y otras pruebas de servidor. como el propio zkVM de Nexus Zero.

Descargo de responsabilidad:

1. Este artículo se reimprime de [panewslab]. Todos los derechos de autor pertenecen al autor original [ABCDE]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.