Si se te pidiera que explicaras coprocesadores a una persona no técnica o desarrolladora en solo una oración, ¿cómo lo describirías?
Creo que lo que dijo el Dr. Dong Mo puede estar muy cerca de la respuesta estándar, para decirlo sin rodeos, el coprocesador está "dándole al contrato inteligente la capacidad de hacer Análisis de Dune".
¿Cómo deconstruir esta oración?
Imagina el escenario en el que utilizamos Dune: quieres hacer LP en Uniswap V3 para ganar algunas comisiones de manejo, entonces abres Dune y encuentras el volumen de trading reciente de varios pares de trading en Uniswap, la Tasa Anual Equivalente de las comisiones de manejo en los últimos 7 días, y los rangos de fluctuación superior e inferior de los pares de trading principales, etc...
O tal vez cuando StepN se volvió popular, comenzaste a especular con zapatos, y no estabas seguro de cuándo venderlos, así que mirabas fijamente los datos de StepN en Dune todos los días, el volumen de transacciones diarias, el número de nuevos usuarios, el precio base de los zapatos... y planeabas vender una vez que hubiera crecimiento. Si la tendencia se ralentiza 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 solo pueden ayudar a juzgar los cambios en las tendencias, sino también utilizarlos para crear más trucos, al igual que el enfoque de “big data” comúnmente utilizado por las principales empresas de Internet.
Por ejemplo, basado en el estilo y precio de los zapatos que los usuarios compran y venden con frecuencia, se recomiendan zapatos similares.
Por ejemplo, basándose en la cantidad de tiempo que los usuarios mantienen los zapatos Chuangshi, se lanzará un "Programa de Recompensas por Lealtad de Usuarios" para brindar a los usuarios leales más airdrops o beneficios.
Por ejemplo, se puede lanzar un plan VIP similar a Cex basado en el TVL o volumen de operaciones proporcionado por LP o Trader en Uniswap, brindando a Trader reducción de tarifas de transacción o aumento de participación en tarifas de LP.
……
En este momento, surge el problema - cuando las principales empresas de Internet juegan con grandes datos + IA, es básicamente una caja negra. Pueden hacer lo que quieran. Los usuarios no pueden verlo y no les importa.
Pero en el lado de Web3, la transparencia y la falta de confianza son nuestra corrección política natural, ¡y rechazamos las cajas negras!
Entonces, cuando desees realizar el escenario anterior, te enfrentarás a un dilema: o bien puedes lograrlo a través de medios centralizados, usar 'manualmente' Dune para contar los datos del índice en segundo plano, y luego implementarlo; o bien puedes escribir contratos inteligentes para capturar automáticamente estos datos en la cadena, realizar cálculos y desplegar puntos automáticamente.
El primero puede dejarte con 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 (lado del proyecto) no puede permitírselo.
Este es el momento para que el coprocesador suba al escenario. Combine los dos métodos recién mencionados y al mismo tiempo use el paso de “manual en segundo plano” para “auto-probar la inocencia” a través de medios técnicos. En otras palabras, use la tecnología ZK para “indexar +” fuera de la cadena. La parte de “cálculo” “auto-prueba la inocencia”, y luego la alimenta al contrato inteligente. De esta manera, se resuelve el problema de confianza y se eliminan las enormes tarifas de gas. ¡Perfecto!
¿Por qué se llama “coprocesador”? De hecho, esto se deriva de la “GPU” en la historia del desarrollo de Web2.0. La razón por la que la GPU se introdujo como un hardware de cómputo 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 a gran escala en paralelo, cálculos gráficos, etc. Precisamente debido a esta arquitectura de “coprocesador”, hoy tenemos maravillosas películas CG, juegos, modelos de IA, etc., por lo que esta arquitectura de coprocesador es en realidad un salto en la arquitectura de cómputo. 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 inherentemente inadecuados para tareas de “datos pesados” y “lógica de cálculo compleja”, por lo que se introduce un coprocesador de cadena de bloques para ayudar a manejar tales cálculos, lo que expande enormemente las posibilidades de las aplicaciones de cadena de bloques.
Entonces, lo que hace el coprocesador se puede resumir en dos cosas:
Hace algún tiempo, Starkware tenía un concepto popular llamado Prueba de Almacenamiento, también llamado Prueba de Estado. Básicamente realiza el paso 1, representado por Herodoto, Langrage, etc. El enfoque técnico de muchos puentes entre cadenas basados en la tecnología ZK también está en el paso 1.
El co-procesador no es más que agregar el paso 2 después de que se complete el paso 1. Después de extraer los datos sin confianza, puede realizar un cálculo sin confianza.
Por lo tanto, para usar un término técnico relativamente preciso para describirlo, el coprocesador debería ser un superset 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.
Hablando técnicamente, 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 del Secuenciador. Incluso un Secuenciador descentralizado solo utiliza algún tipo de mecanismo de competencia o consenso. Tómelo en lugar de la Prueba de Almacenamiento en forma de ZK. Lo 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 blockchain L1. Este almacenamiento es permanente, mientras que el Coprocesador ZK es 'sin estado'. Después de que se completa el cálculo, no se retiene ningún estado.
Desde la perspectiva de los escenarios de aplicación, el coprocesador puede ser considerado como un complemento de servicio para todas las capas 1/2, mientras que Rollup recrea una capa de ejecución para ayudar a expandir la capa de liquidación.
Después de leer lo anterior, es posible que tengas una duda, ¿tiene que hacerse con ZK como coprocesador? Suena mucho como un “Gráfico con ZK agregado”, y no parece que tengamos ninguna “gran duda” sobre los resultados en el Gráfico.
Eso se debe a que cuando usas Graph, básicamente no involucras dinero real. Estos índices sirven para servicios fuera de la cadena. Lo que ves en la interfaz de usuario del frontend son el volumen de transacciones, el historial de transacciones, etc. Los datos pueden ser proporcionados a través de múltiples proveedores de índices de datos como Graph, Alchemy, Zettablock, etc., pero estos datos no pueden ser devueltos al contrato inteligente, porque una vez que los devuelves, agregarás confianza adicional en el servicio de indexación. Cuando los datos están vinculados a dinero real, especialmente en TVL de gran volumen, esta confianza adicional se vuelve importante. Imagina que la próxima vez que un amigo te pida prestados 100 yuanes, tal vez se los prestes sin dudarlo. Sí, ¿qué pasa cuando te pido prestados 10,000 yuanes, o incluso 1 millón de yuanes?
Pero una vez más, ¿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 de ramificación correspondientes. Se pregunta, ¿el coprocesador también tiene una rama de OP, como OP-Coprocesador?
De hecho, hay - pero estamos manteniendo los detalles específicos confidenciales por ahora, y pronto publicaremos información más detallada.
La arquitectura de Brevis consta de tres componentes: zkFabric, zkQueryNet y zkAggregatorRollup.
El siguiente es un diagrama de arquitectura Brevis:
zkFabric: Recopila encabezados de bloque de todas las blockchains conectadas y genera pruebas de consenso ZK que demuestran la validez de estos encabezados de bloque. A través de zkFabric, Brevis implementa un coprocesador interoperable para múltiples cadenas, lo que permite que una blockchain acceda a cualquier dato histórico de otra blockchain.
zkQueryNet: Un mercado abierto de motores de consulta 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 diferentes necesidades de aplicaciones.
zkAggregatorRollup: Un blockchain convolucional ZK que actúa como la capa de agregación y almacenamiento para zkFabric y zkQueryNet. Verifica pruebas de ambos componentes, almacena los datos verificados, y compromete su raíz de estado validada por zk a todos los blockchains conectados.
ZK Fabric es una parte clave en la generación de prueba para el encabezado del bloque. Es muy importante garantizar la seguridad de esta parte. A continuación se muestra el diagrama de arquitectura de zkFabric:
El cliente ligero basado en Prueba de Conocimiento Cero (ZKP) de zkFabric lo hace completamente libre de confianza sin depender de ninguna entidad externa de verificación. No es necesario depender de ninguna entidad externa de verificación, ya que su seguridad proviene enteramente de la cadena de bloques subyacente y 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 bloque. Los probadores pueden aprovechar aceleradores como GPUs, FPGAs y ASICs para minimizar el tiempo y el costo de la prueba.
zkFabric se basa en las suposiciones de seguridad de la cadena de bloques y el protocolo de cifrado subyacente y las suposiciones de seguridad del protocolo de cifrado subyacente. Sin embargo, para garantizar la efectividad de zkFabric, se requiere al menos un relé honesto para sincronizar la bifurcación correcta. Por lo tanto, zkFabric adopta una red de relés descentralizada en lugar de un solo relé para optimizar la efectividad de zkFabric. Esta red de relés puede aprovechar estructuras existentes, como la red de guardia de estado en la red Celer.
Asignación de proveedores: la red de proveedores es una red de proveedores de ZKP descentralizada que selecciona un proveedor para cada tarea de generación de pruebas y paga tarifas a estos proveedores.
Implementación actual:
Los protocolos de cliente ligero actualmente implementados para varias blockchains, incluyendo Ethereum PoS, Cosmos Tendermint y BNB Chain, sirven como ejemplos y pruebas de concepto.
Brevis actualmente ha cooperado con un gancho uniswap, que agrega en gran medida piscinas uniswap personalizadas. 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, Gate resolvió el desafío. Los hooks ahora pueden leer los datos completos de la cadena de historial de un usuario o LP y ejecutar cálculos personalizables de manera completamente segura.
Herodotus es un middleware de acceso a datos potente que proporciona a los contratos inteligentes las siguientes funciones para acceder de forma síncrona a datos actuales e históricos en la cadena a través de la capa de Ethereum:
Los estados de L1s de L2s
Estados L2 tanto de L1 como de otros L2
Los estados de L3/App-Chain a L2s y L1s
Herodoto propuso el concepto de prueba de almacenamiento, que combina la prueba de inclusión (confirmando la existencia de datos) y la prueba de computación (verificando la ejecución de un flujo de trabajo de múltiples pasos) para demostrar que un gran conjunto de datos (como toda la cadena de bloques de Ethereum o un rollup) o la validez de múltiples elementos.
El núcleo de la cadena de bloques es la base de datos, en la cual los datos están encriptados y protegidos utilizando estructuras de datos como árboles de Merkle y árboles de Merkle Patricia. Lo que es único acerca de estas estructuras de datos es que una vez que los datos se han comprometido de forma segura en ellas, se puede generar evidencia para confirmar que los datos están contenidos dentro de la estructura.
El uso de árboles de Merkle y árboles de Merkle Patricia mejora la seguridad de la cadena de bloques de Ethereum. Al hashear criptográficamente los datos en cada nivel del árbol, es casi imposible alterar los datos sin ser detectado. Cualquier cambio en un punto de datos requiere cambiar el hash correspondiente en el árbol al hash raíz, que es públicamente visible en el encabezado de la cadena de bloques. Esta característica fundamental de la cadena de bloques proporciona un alto nivel de integridad de datos e inmutabilidad.
En segundo lugar, estos árboles permiten una verificación eficiente de datos a través de 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 de Ethereum, sino solo en el camino dentro del árbol de Merkle relevante.
La prueba de almacenamiento, según lo define Herodoto, es una fusión de:
Flujo de trabajo :
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 necesitamos determinar y verificar el hash del bloque del bloque que contiene los datos en los que estamos interesados. Este es el primer paso en todo el proceso.
Una vez que se obtiene el hash de bloque relevante, el siguiente paso es acceder al encabezado del bloque. Para hacer esto, el encabezado del bloque asociado con el hash de bloque obtenido en el paso anterior necesita ser hasheado. Luego, se compara el hash del encabezado de bloque proporcionado con el hash de bloque resultante:
Hay dos formas de obtener el hash:
(1) Utilice el opcode BLOCKHASH para recuperar
(2) Consultar los hashes de los bloques que han sido verificados en la historia desde el Acumulador de Hash de Bloques
Este paso garantiza que el encabezado del bloque que se está procesando es auténtico. Una vez completado este paso, el contrato inteligente puede acceder a cualquier valor en el encabezado del bloque.
Con el encabezado del bloque en mano, podemos adentrarnos en su contenido, específicamente:
stateRoot: Un resumen criptográfico de todo el estado blockchain en el momento en que ocurrió el blockchain.
receiptsRoot: Resumen cifrado de todos los resultados de transacción (recibos) en el bloque.
TransactionsRoot: Un resumen criptográfico de todas las transacciones que ocurrieron en el bloque.
puede ser descodificado, permitiendo la verificación de si una cuenta específica, recibo o transacción está incluida en el bloque.
Con la raíz que seleccionamos, y considerando que Ethereum utiliza una estructura de árbol 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 admitidas:
Desde Ethereum a Starknet
Desde Ethereum Goerlia Starknet Goerli
Desde Ethereum Goerlia zkSync Era Goerli
Axiom proporciona una forma para que los desarrolladores consulten encabezados de bloques, cuentas o valores de almacenamiento de toda la historia 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 a través de pruebas de conocimiento cero, lo que significa que los contratos inteligentes pueden utilizarlos sin suposiciones adicionales de confianza.
Axiom recientemente lanzadoHalo2-repl , es un REPL de halo2 basado en el 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 consiste de dos componentes tecnológicos principales:
AxiomV1 - caché de blockchain de Ethereum, comenzando con Génesis.
AxiomV1Query - Contrato inteligente que ejecuta consultas contra AxiomV1.
(1) Valor hash del bloque de caché en AxiomV1:
El contrato inteligente AxiomV1 almacena en caché los hashes de bloques de Ethereum desde el bloque génesis en dos formas:
Primero, se almacena en caché la raíz de Merkle de Keccak de 1024 hashes de bloque consecutivos. Estas raíces de Merkle se actualizan a través de pruebas de conocimiento cero, verificando que el hash del encabezado del bloque forme una cadena de compromiso que termina con uno de los 256 bloques más recientes accesibles directamente para el EVM o un hash de bloque que ya existe en la caché de AxiomV1.
En segundo lugar. Axiom almacena la Cadena de Montañas de Merkle de estas raíces de Merkle comenzando desde el bloque génesis. La Cadena de Montañas de Merkle se construye en cadena actualizando la primera parte de la caché, la raíz de Merkle Keccak.
(2) Ejecutar la consulta en AxiomV1Query:
El contrato inteligente AxiomV1Query se utiliza para consultas por lotes para permitir el acceso sin confianza a los encabezados de bloque históricos de Ethereum, cuentas y datos arbitrarios almacenados en las cuentas. Las consultas pueden realizarse en cadena y se completan en cadena a través de pruebas de conocimiento cero (ZK) contra hashes de bloque en caché de AxiomV1.
Estas pruebas ZK verifican si los datos relevantes en cadena se encuentran directamente en la cabecera del bloque, o en el árbol de cuentas o almacenamiento del bloque, verificando la prueba de inclusión (o no inclusión) del Trie Merkle-Patricia.
Nexus intenta construir una plataforma común para la computación en la nube verificable utilizando pruebas de conocimiento cero. Actualmente es agnóstico en cuanto a la arquitectura de la máquina y soporta risc 5/ WebAssembly/ EVM. Nexus utiliza el sistema de prueba de supernova. El equipo probó que la memoria necesaria para generar la prueba es de 6GB. En el futuro, se optimizará sobre esta base para que los dispositivos y computadoras del usuario común puedan generar pruebas.
Para ser precisos, la arquitectura se divide en dos partes:
Nexus zero: Una red de computación en la nube descentralizada verificable impulsada por pruebas de conocimiento cero y zkVM universal.
Nexus: Una red de computación en la nube descentralizada 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, actualmente compatible con Rust, con más idiomas por venir.
Las aplicaciones de Nexus se ejecutan en una red de computación en la nube descentralizada, que es esencialmente una "blockchain" sin servidor de propósito general conectada directamente a Ethereum. Por lo tanto, las aplicaciones de Nexus no heredan la seguridad de Ethereum, pero a cambio obtienen acceso a una mayor potencia informática (como cálculo, almacenamiento y E/S impulsada por eventos) debido al tamaño reducido de su red. Las aplicaciones de Nexus se ejecutan en una nube privada que logra un consenso interno y proporciona "pruebas" verificables de la computación (no pruebas reales) a través de firmas de umbral verificables en toda la red dentro de Ethereum.
Las aplicaciones de Nexus Zero heredan la seguridad de Ethereum, ya que son programas universales con pruebas de conocimiento cero que pueden ser verificadas en la 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 aplicaciones generadas, incluidos secuenciadores de zk-rollup, secuenciadores de optimistic rollup y otros servidores de pruebas, como el propio zkVM de Nexus Zero.
Si se te pidiera que explicaras coprocesadores a una persona no técnica o desarrolladora en solo una oración, ¿cómo lo describirías?
Creo que lo que dijo el Dr. Dong Mo puede estar muy cerca de la respuesta estándar, para decirlo sin rodeos, el coprocesador está "dándole al contrato inteligente la capacidad de hacer Análisis de Dune".
¿Cómo deconstruir esta oración?
Imagina el escenario en el que utilizamos Dune: quieres hacer LP en Uniswap V3 para ganar algunas comisiones de manejo, entonces abres Dune y encuentras el volumen de trading reciente de varios pares de trading en Uniswap, la Tasa Anual Equivalente de las comisiones de manejo en los últimos 7 días, y los rangos de fluctuación superior e inferior de los pares de trading principales, etc...
O tal vez cuando StepN se volvió popular, comenzaste a especular con zapatos, y no estabas seguro de cuándo venderlos, así que mirabas fijamente los datos de StepN en Dune todos los días, el volumen de transacciones diarias, el número de nuevos usuarios, el precio base de los zapatos... y planeabas vender una vez que hubiera crecimiento. Si la tendencia se ralentiza 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 solo pueden ayudar a juzgar los cambios en las tendencias, sino también utilizarlos para crear más trucos, al igual que el enfoque de “big data” comúnmente utilizado por las principales empresas de Internet.
Por ejemplo, basado en el estilo y precio de los zapatos que los usuarios compran y venden con frecuencia, se recomiendan zapatos similares.
Por ejemplo, basándose en la cantidad de tiempo que los usuarios mantienen los zapatos Chuangshi, se lanzará un "Programa de Recompensas por Lealtad de Usuarios" para brindar a los usuarios leales más airdrops o beneficios.
Por ejemplo, se puede lanzar un plan VIP similar a Cex basado en el TVL o volumen de operaciones proporcionado por LP o Trader en Uniswap, brindando a Trader reducción de tarifas de transacción o aumento de participación en tarifas de LP.
……
En este momento, surge el problema - cuando las principales empresas de Internet juegan con grandes datos + IA, es básicamente una caja negra. Pueden hacer lo que quieran. Los usuarios no pueden verlo y no les importa.
Pero en el lado de Web3, la transparencia y la falta de confianza son nuestra corrección política natural, ¡y rechazamos las cajas negras!
Entonces, cuando desees realizar el escenario anterior, te enfrentarás a un dilema: o bien puedes lograrlo a través de medios centralizados, usar 'manualmente' Dune para contar los datos del índice en segundo plano, y luego implementarlo; o bien puedes escribir contratos inteligentes para capturar automáticamente estos datos en la cadena, realizar cálculos y desplegar puntos automáticamente.
El primero puede dejarte con 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 (lado del proyecto) no puede permitírselo.
Este es el momento para que el coprocesador suba al escenario. Combine los dos métodos recién mencionados y al mismo tiempo use el paso de “manual en segundo plano” para “auto-probar la inocencia” a través de medios técnicos. En otras palabras, use la tecnología ZK para “indexar +” fuera de la cadena. La parte de “cálculo” “auto-prueba la inocencia”, y luego la alimenta al contrato inteligente. De esta manera, se resuelve el problema de confianza y se eliminan las enormes tarifas de gas. ¡Perfecto!
¿Por qué se llama “coprocesador”? De hecho, esto se deriva de la “GPU” en la historia del desarrollo de Web2.0. La razón por la que la GPU se introdujo como un hardware de cómputo 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 a gran escala en paralelo, cálculos gráficos, etc. Precisamente debido a esta arquitectura de “coprocesador”, hoy tenemos maravillosas películas CG, juegos, modelos de IA, etc., por lo que esta arquitectura de coprocesador es en realidad un salto en la arquitectura de cómputo. 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 inherentemente inadecuados para tareas de “datos pesados” y “lógica de cálculo compleja”, por lo que se introduce un coprocesador de cadena de bloques para ayudar a manejar tales cálculos, lo que expande enormemente las posibilidades de las aplicaciones de cadena de bloques.
Entonces, lo que hace el coprocesador se puede resumir en dos cosas:
Hace algún tiempo, Starkware tenía un concepto popular llamado Prueba de Almacenamiento, también llamado Prueba de Estado. Básicamente realiza el paso 1, representado por Herodoto, Langrage, etc. El enfoque técnico de muchos puentes entre cadenas basados en la tecnología ZK también está en el paso 1.
El co-procesador no es más que agregar el paso 2 después de que se complete el paso 1. Después de extraer los datos sin confianza, puede realizar un cálculo sin confianza.
Por lo tanto, para usar un término técnico relativamente preciso para describirlo, el coprocesador debería ser un superset 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.
Hablando técnicamente, 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 del Secuenciador. Incluso un Secuenciador descentralizado solo utiliza algún tipo de mecanismo de competencia o consenso. Tómelo en lugar de la Prueba de Almacenamiento en forma de ZK. Lo 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 blockchain L1. Este almacenamiento es permanente, mientras que el Coprocesador ZK es 'sin estado'. Después de que se completa el cálculo, no se retiene ningún estado.
Desde la perspectiva de los escenarios de aplicación, el coprocesador puede ser considerado como un complemento de servicio para todas las capas 1/2, mientras que Rollup recrea una capa de ejecución para ayudar a expandir la capa de liquidación.
Después de leer lo anterior, es posible que tengas una duda, ¿tiene que hacerse con ZK como coprocesador? Suena mucho como un “Gráfico con ZK agregado”, y no parece que tengamos ninguna “gran duda” sobre los resultados en el Gráfico.
Eso se debe a que cuando usas Graph, básicamente no involucras dinero real. Estos índices sirven para servicios fuera de la cadena. Lo que ves en la interfaz de usuario del frontend son el volumen de transacciones, el historial de transacciones, etc. Los datos pueden ser proporcionados a través de múltiples proveedores de índices de datos como Graph, Alchemy, Zettablock, etc., pero estos datos no pueden ser devueltos al contrato inteligente, porque una vez que los devuelves, agregarás confianza adicional en el servicio de indexación. Cuando los datos están vinculados a dinero real, especialmente en TVL de gran volumen, esta confianza adicional se vuelve importante. Imagina que la próxima vez que un amigo te pida prestados 100 yuanes, tal vez se los prestes sin dudarlo. Sí, ¿qué pasa cuando te pido prestados 10,000 yuanes, o incluso 1 millón de yuanes?
Pero una vez más, ¿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 de ramificación correspondientes. Se pregunta, ¿el coprocesador también tiene una rama de OP, como OP-Coprocesador?
De hecho, hay - pero estamos manteniendo los detalles específicos confidenciales por ahora, y pronto publicaremos información más detallada.
La arquitectura de Brevis consta de tres componentes: zkFabric, zkQueryNet y zkAggregatorRollup.
El siguiente es un diagrama de arquitectura Brevis:
zkFabric: Recopila encabezados de bloque de todas las blockchains conectadas y genera pruebas de consenso ZK que demuestran la validez de estos encabezados de bloque. A través de zkFabric, Brevis implementa un coprocesador interoperable para múltiples cadenas, lo que permite que una blockchain acceda a cualquier dato histórico de otra blockchain.
zkQueryNet: Un mercado abierto de motores de consulta 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 diferentes necesidades de aplicaciones.
zkAggregatorRollup: Un blockchain convolucional ZK que actúa como la capa de agregación y almacenamiento para zkFabric y zkQueryNet. Verifica pruebas de ambos componentes, almacena los datos verificados, y compromete su raíz de estado validada por zk a todos los blockchains conectados.
ZK Fabric es una parte clave en la generación de prueba para el encabezado del bloque. Es muy importante garantizar la seguridad de esta parte. A continuación se muestra el diagrama de arquitectura de zkFabric:
El cliente ligero basado en Prueba de Conocimiento Cero (ZKP) de zkFabric lo hace completamente libre de confianza sin depender de ninguna entidad externa de verificación. No es necesario depender de ninguna entidad externa de verificación, ya que su seguridad proviene enteramente de la cadena de bloques subyacente y 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 bloque. Los probadores pueden aprovechar aceleradores como GPUs, FPGAs y ASICs para minimizar el tiempo y el costo de la prueba.
zkFabric se basa en las suposiciones de seguridad de la cadena de bloques y el protocolo de cifrado subyacente y las suposiciones de seguridad del protocolo de cifrado subyacente. Sin embargo, para garantizar la efectividad de zkFabric, se requiere al menos un relé honesto para sincronizar la bifurcación correcta. Por lo tanto, zkFabric adopta una red de relés descentralizada en lugar de un solo relé para optimizar la efectividad de zkFabric. Esta red de relés puede aprovechar estructuras existentes, como la red de guardia de estado en la red Celer.
Asignación de proveedores: la red de proveedores es una red de proveedores de ZKP descentralizada que selecciona un proveedor para cada tarea de generación de pruebas y paga tarifas a estos proveedores.
Implementación actual:
Los protocolos de cliente ligero actualmente implementados para varias blockchains, incluyendo Ethereum PoS, Cosmos Tendermint y BNB Chain, sirven como ejemplos y pruebas de concepto.
Brevis actualmente ha cooperado con un gancho uniswap, que agrega en gran medida piscinas uniswap personalizadas. 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, Gate resolvió el desafío. Los hooks ahora pueden leer los datos completos de la cadena de historial de un usuario o LP y ejecutar cálculos personalizables de manera completamente segura.
Herodotus es un middleware de acceso a datos potente que proporciona a los contratos inteligentes las siguientes funciones para acceder de forma síncrona a datos actuales e históricos en la cadena a través de la capa de Ethereum:
Los estados de L1s de L2s
Estados L2 tanto de L1 como de otros L2
Los estados de L3/App-Chain a L2s y L1s
Herodoto propuso el concepto de prueba de almacenamiento, que combina la prueba de inclusión (confirmando la existencia de datos) y la prueba de computación (verificando la ejecución de un flujo de trabajo de múltiples pasos) para demostrar que un gran conjunto de datos (como toda la cadena de bloques de Ethereum o un rollup) o la validez de múltiples elementos.
El núcleo de la cadena de bloques es la base de datos, en la cual los datos están encriptados y protegidos utilizando estructuras de datos como árboles de Merkle y árboles de Merkle Patricia. Lo que es único acerca de estas estructuras de datos es que una vez que los datos se han comprometido de forma segura en ellas, se puede generar evidencia para confirmar que los datos están contenidos dentro de la estructura.
El uso de árboles de Merkle y árboles de Merkle Patricia mejora la seguridad de la cadena de bloques de Ethereum. Al hashear criptográficamente los datos en cada nivel del árbol, es casi imposible alterar los datos sin ser detectado. Cualquier cambio en un punto de datos requiere cambiar el hash correspondiente en el árbol al hash raíz, que es públicamente visible en el encabezado de la cadena de bloques. Esta característica fundamental de la cadena de bloques proporciona un alto nivel de integridad de datos e inmutabilidad.
En segundo lugar, estos árboles permiten una verificación eficiente de datos a través de 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 de Ethereum, sino solo en el camino dentro del árbol de Merkle relevante.
La prueba de almacenamiento, según lo define Herodoto, es una fusión de:
Flujo de trabajo :
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 necesitamos determinar y verificar el hash del bloque del bloque que contiene los datos en los que estamos interesados. Este es el primer paso en todo el proceso.
Una vez que se obtiene el hash de bloque relevante, el siguiente paso es acceder al encabezado del bloque. Para hacer esto, el encabezado del bloque asociado con el hash de bloque obtenido en el paso anterior necesita ser hasheado. Luego, se compara el hash del encabezado de bloque proporcionado con el hash de bloque resultante:
Hay dos formas de obtener el hash:
(1) Utilice el opcode BLOCKHASH para recuperar
(2) Consultar los hashes de los bloques que han sido verificados en la historia desde el Acumulador de Hash de Bloques
Este paso garantiza que el encabezado del bloque que se está procesando es auténtico. Una vez completado este paso, el contrato inteligente puede acceder a cualquier valor en el encabezado del bloque.
Con el encabezado del bloque en mano, podemos adentrarnos en su contenido, específicamente:
stateRoot: Un resumen criptográfico de todo el estado blockchain en el momento en que ocurrió el blockchain.
receiptsRoot: Resumen cifrado de todos los resultados de transacción (recibos) en el bloque.
TransactionsRoot: Un resumen criptográfico de todas las transacciones que ocurrieron en el bloque.
puede ser descodificado, permitiendo la verificación de si una cuenta específica, recibo o transacción está incluida en el bloque.
Con la raíz que seleccionamos, y considerando que Ethereum utiliza una estructura de árbol 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 admitidas:
Desde Ethereum a Starknet
Desde Ethereum Goerlia Starknet Goerli
Desde Ethereum Goerlia zkSync Era Goerli
Axiom proporciona una forma para que los desarrolladores consulten encabezados de bloques, cuentas o valores de almacenamiento de toda la historia 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 a través de pruebas de conocimiento cero, lo que significa que los contratos inteligentes pueden utilizarlos sin suposiciones adicionales de confianza.
Axiom recientemente lanzadoHalo2-repl , es un REPL de halo2 basado en el 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 consiste de dos componentes tecnológicos principales:
AxiomV1 - caché de blockchain de Ethereum, comenzando con Génesis.
AxiomV1Query - Contrato inteligente que ejecuta consultas contra AxiomV1.
(1) Valor hash del bloque de caché en AxiomV1:
El contrato inteligente AxiomV1 almacena en caché los hashes de bloques de Ethereum desde el bloque génesis en dos formas:
Primero, se almacena en caché la raíz de Merkle de Keccak de 1024 hashes de bloque consecutivos. Estas raíces de Merkle se actualizan a través de pruebas de conocimiento cero, verificando que el hash del encabezado del bloque forme una cadena de compromiso que termina con uno de los 256 bloques más recientes accesibles directamente para el EVM o un hash de bloque que ya existe en la caché de AxiomV1.
En segundo lugar. Axiom almacena la Cadena de Montañas de Merkle de estas raíces de Merkle comenzando desde el bloque génesis. La Cadena de Montañas de Merkle se construye en cadena actualizando la primera parte de la caché, la raíz de Merkle Keccak.
(2) Ejecutar la consulta en AxiomV1Query:
El contrato inteligente AxiomV1Query se utiliza para consultas por lotes para permitir el acceso sin confianza a los encabezados de bloque históricos de Ethereum, cuentas y datos arbitrarios almacenados en las cuentas. Las consultas pueden realizarse en cadena y se completan en cadena a través de pruebas de conocimiento cero (ZK) contra hashes de bloque en caché de AxiomV1.
Estas pruebas ZK verifican si los datos relevantes en cadena se encuentran directamente en la cabecera del bloque, o en el árbol de cuentas o almacenamiento del bloque, verificando la prueba de inclusión (o no inclusión) del Trie Merkle-Patricia.
Nexus intenta construir una plataforma común para la computación en la nube verificable utilizando pruebas de conocimiento cero. Actualmente es agnóstico en cuanto a la arquitectura de la máquina y soporta risc 5/ WebAssembly/ EVM. Nexus utiliza el sistema de prueba de supernova. El equipo probó que la memoria necesaria para generar la prueba es de 6GB. En el futuro, se optimizará sobre esta base para que los dispositivos y computadoras del usuario común puedan generar pruebas.
Para ser precisos, la arquitectura se divide en dos partes:
Nexus zero: Una red de computación en la nube descentralizada verificable impulsada por pruebas de conocimiento cero y zkVM universal.
Nexus: Una red de computación en la nube descentralizada 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, actualmente compatible con Rust, con más idiomas por venir.
Las aplicaciones de Nexus se ejecutan en una red de computación en la nube descentralizada, que es esencialmente una "blockchain" sin servidor de propósito general conectada directamente a Ethereum. Por lo tanto, las aplicaciones de Nexus no heredan la seguridad de Ethereum, pero a cambio obtienen acceso a una mayor potencia informática (como cálculo, almacenamiento y E/S impulsada por eventos) debido al tamaño reducido de su red. Las aplicaciones de Nexus se ejecutan en una nube privada que logra un consenso interno y proporciona "pruebas" verificables de la computación (no pruebas reales) a través de firmas de umbral verificables en toda la red dentro de Ethereum.
Las aplicaciones de Nexus Zero heredan la seguridad de Ethereum, ya que son programas universales con pruebas de conocimiento cero que pueden ser verificadas en la 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 aplicaciones generadas, incluidos secuenciadores de zk-rollup, secuenciadores de optimistic rollup y otros servidores de pruebas, como el propio zkVM de Nexus Zero.