En la cumbre ETHShanghai 2023, el fundador de Axiom, Yi Sun, presentó el coprocesador ZK Axiom de Ethereum y su importancia en términos de acceso a datos y poder de cómputo. Axiom se da cuenta de la expansión del cálculo y el acceso a los datos a través del concepto de operación Reflection, y se da cuenta de la validez de la consulta mediante la verificación de la cadena hash y el mantenimiento de la memoria caché. Las aplicaciones para Axiom incluyen aplicaciones de alto costo, mayor acceso a datos, aplicaciones basadas en protocolos de administración de datos históricos y más. A través de Axiom, los contratos inteligentes pueden obtener más datos y poder de cómputo, promoviendo aún más el desarrollo de aplicaciones Ethereum.
El siguiente texto es la traducción al chino del discurso de Yi Sun, y el enlace es el video en vivo:
Primero, comprendamos el viaje del usuario para acceder realmente a la información de Ethereum. Cuando usábamos Ethereum por primera vez, la forma en que realmente recibíamos información sobre lo que sucedía en la cadena era a través de llamadas JSON-RPC para archivar anotaciones. El propósito de la API JSON-RPC es presentar información sobre el historial en cadena al usuario. Esencialmente, toda la información que vemos sobre la cadena de bloques se extrae de estas llamadas API y se presenta como una entrada en el sitio web para que el usuario la lea.
Ahora, a medida que los usuarios se vuelven más expertos en interactuar con la cadena de bloques, comenzamos a requerir vistas cada vez más complejas de la cadena. Por lo tanto, se están desarrollando diferentes tipos de nodos de archivo para diferentes compromisos de usuario. Entonces estaban Geth, Erigon, Nethermind y ahora Reth. Podemos elegir el nodo de archivo más adecuado según nuestras propias necesidades.
Si los usuarios no están satisfechos con una API JSON-RPC separada, se puede elegir un indexador para aplicar el procesamiento posterior mientras se rastrean las transacciones. Para diferentes aplicaciones, los usuarios pueden estar interesados en los datos devueltos por The Graph o Covalent.
Más recientemente, también ha habido billeteras y otros productos que ofrecen simulación de transacciones además de los nodos de archivo. Esto significa que podemos ver el resultado real de una transacción virtual antes de realizarla. En general, la forma en que interactuamos con Ethereum como usuarios finales se está volviendo más sofisticada, utilizando más computación además de los datos que leemos.
Ahora, si lo pensamos no desde la perspectiva de un usuario, sino desde la perspectiva de un contrato inteligente en Ethereum. Por supuesto, los contratos también quieren poder acceder a los datos y realizar cálculos sobre ellos, pero esto es más desafiante. De hecho, si vamos a OpenSea y miramos la lista de CryptoPunk, encontraremos que de toda la información de la página, solo una pequeña parte es accesible en el contrato inteligente de la cadena.
De hecho, para los listados de CryptoPunk, esta información es solo para los titulares actuales. Por supuesto, hay mucha otra información en la página, pero toda la información relacionada con la información histórica de transferencias, los precios históricos y los titulares históricos es en realidad inaccesible para el contrato inteligente porque pertenece al historial pasado. Estos historiales constituyen información en cadena, pero no están disponibles para contratos inteligentes porque debemos evitar obligar a cada nodo completo de Ethereum a mantener esta información en su acceso aleatorio para verificar transacciones.
Además, como cualquier desarrollador de blockchain puede decirle, ejecutar cálculos en la cadena es prohibitivamente costoso, aunque Ethereum tiene operaciones de máquina virtual (VM) relativamente eficientes, y la precompilación hace que ciertos tipos de operaciones sean más baratos. Por ejemplo, Ethereum proporciona un soporte relativamente económico para operaciones de curva elíptica en la curva BN254. Sin embargo, para algunas aplicaciones específicas, la máquina virtual Ethereum sigue siendo un entorno de tiempo de ejecución muy costoso. Al diseñar una máquina virtual de cadena de bloques, se debe elegir un conjunto inherente de operaciones que deben medirse cuidadosamente para garantizar que cada nodo pueda verificar las transacciones en un momento constante. Además, también se debe considerar la seguridad en el peor de los casos y la estabilidad del consenso. Entonces, el desafío aquí es cómo implementar el escalado específico de la aplicación para aplicaciones en cadena. Axiom tiene como objetivo expandir el acceso a datos y las capacidades informáticas para contratos inteligentes para satisfacer las necesidades de expansión de diferentes aplicaciones.
Lo que Axiom está construyendo es lo que llama un coprocesador Ethereum (coprocesador ZK), que permite que ciertos contratos inteligentes se deleguen sin confianza a nuestro sistema fuera de la cadena para que puedan delegar lecturas de datos y cálculos verificables a Axiom. Para emitir una consulta a Axiom, un contrato inteligente puede enviar una transacción a nuestro sistema en cadena. Nuestro nodo fuera de línea recibirá la transacción y generará un resultado basado en la consulta histórica de Ethereum, y adjuntará una prueba de conocimiento cero para demostrar la exactitud del resultado. Finalmente, verificamos los resultados en la cadena y entregamos los resultados de manera creíble a los contratos inteligentes posteriores.
Esto es similar a cómo la CPU en una computadora delega el cálculo a la GPU y recupera los resultados cuando se conocen. Este concepto fue llamado coprocesador (Coprocesso) en los primeros días. En la diapositiva, muestro una imagen de un coprocesamiento matemático avanzado de principios de la década de 1990 que es análogo a lo que hace Axiom.
Podemos obtener información sobre qué tipos de operaciones puede realizar Axiom. Cada consulta a Axiom se puede dividir en tres partes.
La primera es la parte de lectura, que es cómo se ingresan las consultas de Axiom: podemos leer de manera confiable los datos históricos en cadena.
La segunda parte es que podemos ejecutar cálculos de validación en estos datos. Esto puede comenzar desde un análisis básico, como sumar algunos números, encontrar el máximo o el mínimo, hasta cálculos más complejos. Por ejemplo, alguna agregación de firmas o verificación desde criptografía, e incluso aprendizaje automático basado en conocimiento cero, como verificar el funcionamiento de ciertos algoritmos de reputación sobre datos sociales en la cadena o usar ciertos algoritmos de aprendizaje automático en aplicaciones financieras. En última instancia, proporcionaremos funciones compuestas de computación programable a través de máquinas virtuales.
La última parte, después de los pasos de lectura y cálculo, obtenemos un resultado y siempre emparejamos ese resultado con una prueba de conocimiento cero de que el cálculo del resultado fue válido. Por lo tanto, verificamos esta prueba en el contrato inteligente de Ethereum y luego almacenamos el resultado para que lo use el contrato.
Dado que todos los resultados devueltos por Axiom en realidad se verifican con pruebas de conocimiento cero, esto significa que la seguridad de todo lo que devuelve Axiom es criptográficamente equivalente a la del propio Ethereum. La filosofía de Axiom es que no queremos imponer suposiciones adicionales a los usuarios más allá de las suposiciones criptográficas que ya tienen al usar Ethereum.
A continuación, presentaré en detalle su principio de implementación, que involucra el concepto de operación de Reflexión mencionado en el título del discurso. El principio central que lo hace posible es que cada bloque de la cadena de bloques contiene un historial completo. Podemos comenzar en el bloque Ethereum actual y volver a los bloques anteriores que nos interesan. Al tomar todos los encabezados de bloque entre el bloque anterior y el bloque actual, y al verificar la cadena hash de estos encabezados de bloque, podemos revertir el compromiso del bloque anterior con el bloque actual.
Entonces, ¿cuáles son los beneficios de Reflection?
Podemos tomar un bloque del Ethereum actual y volver a un bloque anterior que nos interese. Si obtenemos los encabezados de bloque entre el bloque anterior y el bloque actual, podemos revertir el compromiso del bloque anterior en el bloque actual verificando la ruta hash entre estos encabezados de bloque. Entonces, si estamos interesados en alguna información de un bloque pasado, podemos dar una prueba de inclusión en el compromiso de ese bloque. Específicamente, esto podría ser una prueba Merkle Patricia Trie de que la información existe en el estado del bloque, la transacción o el recibo. En el EVM, al menos en principio, se puede acceder a cualquier información pasada en la cadena solo a través del conocimiento de hashes de bloque recientes.
Desafortunadamente, hacer esto en el EVM es costoso. Como se acaba de mencionar, debe verificar las cadenas de hash y las pruebas de Merkle de todos los encabezados de bloque, lo que implica muchos cálculos de hash de Keccak en una gran cantidad de datos. Entonces, una vez que retrocedes en el tiempo, se vuelve muy difícil. Por lo tanto, aplicamos la operación Reflection envolviendo esta prueba con ZK en el EVM. Entonces, en lugar de poner todos los encabezados de bloques anteriores y todas estas pruebas de Merkle en cadena y luego verificarlas, verificamos con conocimiento cero si hay una secuencia de encabezados de bloques anteriores y algunas pruebas de verificación.
Esto tiene dos ventajas. Primero, nos evita tener que poner datos de prueba en los datos de llamadas. En segundo lugar, nos permite agregar pruebas, lo que es impensable sin el uso de ZK. La idea aquí es que al verificar cualquier cantidad de cálculos en Ethereum, el costo del gas es fijo, por lo que podemos usar una sola prueba ZK para verificar una gran cantidad de acceso a datos históricos.
Permítanme referirme brevemente a las ventajas y desventajas del concepto de operación Reflection basado en ZK.
Hay dos formas de acceder a los datos. La primera es la forma en que lo sabe antes: puede acceder a los datos en Ethereum directamente desde el contrato inteligente. Esto tiene la gran ventaja de que el acceso es síncrono. Por lo tanto, puede llamar directamente a la función de lectura en el contrato inteligente para obtener el valor actual. Por ejemplo, cuando opera en Uniswap, necesita esta sincronicidad. Sin embargo, también tiene muchas limitaciones. Su poder de cómputo está limitado por los costos de combustible y no tiene acceso a ningún dato histórico.
En segundo lugar, si desea aprovechar la capacidad de ZK para reflejarse en Ethereum, ya que debe generar pruebas de que su acceso es correcto, no hay forma de hacerlo de forma sincrónica. Entonces, en realidad no hay acceso directo al estado actual en la cadena, porque tienes que dar fe de un estado.
Por otro lado, si se permite acceder a datos históricos de forma asincrónica, puede aplicarles cálculos casi ilimitados y tener acceso a grandes cantidades de datos. Por lo tanto, al relajar el concepto de sincronización, el acceso a los datos operativos de Reflection basado en ZK se puede ampliar en gran medida.
Luego, veremos cómo implementar operaciones de Reflection a través de Axiom.
Primero, tenemos que mantener un caché de todos los bloques anteriores en nuestro contrato inteligente. En EVM, los últimos 256 hash de bloque están disponibles de forma nativa. Podemos probar que en cada lote de 1024 bloques, el hash del último bloque del lote anterior se confirma en el siguiente bloque. Asimismo, el hash del penúltimo bloque del lote anterior se confirma en el último bloque, y así sucesivamente. Por lo tanto, podemos verificar inversamente esta cadena hash y probar la validez de esta cadena hash a través del conocimiento cero.
Esto nos permite almacenar hashes de bloque en caché desde el bloque más reciente hasta el bloque de génesis. De hecho, hemos implementado esto en nuestro contrato inteligente de red principal, que contiene rutas Merkle almacenadas en caché cada 1024 bloques hash del bloque génesis.
Otra característica que estamos agregando es Merkle Mountain Range. Está construido sobre este caché de hash de bloque, una estructura de datos que nos permite hacer referencia a cada hash de bloque en Ethereum en un ADN limitado.
Una vez que hemos construido el caché, podemos consultar Axiom validando los bloques en el caché. Para que esto funcione, tenemos que demostrar que todos los datos del historial de Ethereum a los que intentamos acceder están comprometidos a estar en el caché de algún bloque. En segundo lugar, tenemos que demostrar que todos los cálculos que realizamos en esta consulta son correctos. Para verificar esto en cadena, verificamos la validez de la prueba de conocimiento cero. También verificamos que se correlacione con la información que hemos registrado en la cadena. Siempre generamos confianza en nuestros cachés o cachés de bloques y comparamos la información en esos cachés de bloques con información pública en pruebas de conocimiento cero.
Ahora hablemos de las posibles aplicaciones de la operación Reflection prevista.
El eje horizontal representa la complejidad de los datos, a cuántos datos realmente se necesita acceder para implementar la aplicación. El eje vertical representa la complejidad computacional, que es la cantidad de recursos computacionales que realmente se necesitan aplicar para completar la tarea.
Por lo tanto, el primer tipo de aplicación es una aplicación que se puede implementar en Ethereum con Axiom o cualquier tipo de mecanismo de operación de Reflection, pero el costo es un poco más alto.
Algunos ejemplos de esto incluyen la lectura de nonces de grado de consenso de encabezados de bloque en la capa de consenso de Ethereum, la verificación de edades históricas de cuentas o la lectura de diferentes tipos de datos de Oracle a partir de información de precios históricos. En el EVM, se pueden emplear varias soluciones para implementar estas aplicaciones, pero al colocar estas soluciones en conocimiento cero, se puede aumentar la eficiencia.
Ahora, hay otra clase de aplicaciones que generalmente requieren más acceso a datos y, por lo tanto, más cómputo. En mi opinión, estas aplicaciones no serían posibles sin el uso del coprocesador ZK.
Como ejemplo, una aplicación interesante es permitir que un Roll-up en Ethereum lea el estado de la capa base u otro Roll-up de manera confiable, utilizando el conocimiento cero para interactuar. Una de esas aplicaciones podría ser permitir que los Roll-ups lean instantáneas de saldos completos de tokens ERC20.
Si cambiamos nuestra atención del almacenamiento al historial de transacciones de las cuentas, puede imaginarse construir un sistema confiable de reputación, identidad o calificación crediticia al registrar el historial completo de las direcciones de Ethereum. Esto podría usarse para la puntuación de crédito, o para darle acceso a algún tipo de DAO en cadena, o para darle acceso para emitir NFT personalizados.
También hay una clase de aplicaciones que usan datos históricos en cadena para administrar el protocolo. Generalmente conocida como contabilidad de acuerdos.
La idea aquí es que existen protocolos para coordinar el comportamiento de los participantes, y el principio básico de la coordinación es la capacidad de recompensar o castigar a los participantes por su comportamiento. Si observa muchos protocolos en Ethereum, el registro de las acciones de los participantes en realidad se mantiene completamente en la cadena. Entonces, con Axiom, podemos imaginar que, en función del conjunto completo de acciones de los participantes del protocolo, el protocolo puede determinar la estructura de pago o incluso imponer algún tipo de penalización a los participantes, lo que creemos que realmente puede ampliar el espacio de diseño del protocolo. aplicaciones
Finalmente, si realmente subimos el nivel de computación, creemos que podría ser muy interesante usar modelos de aprendizaje automático para ajustar parámetros en cadena. Si piensa en las aplicaciones financieras tradicionales, es muy común modelar parámetros futuros complejos basados en grandes cantidades de datos históricos, como datos de precios, datos económicos, etc. Y cuando miramos el DeFi actual, está lejos de alcanzar ese nivel. No creo que DeFi deba funcionar exactamente de la misma manera que las finanzas tradicionales, pero sí creemos que inyectar algunas bases de datos históricas y modelos e información basados en aprendizaje automático puede ayudar a crear un protocolo DeFi más dinámico.
Estas son solo algunas ideas de lo que las operaciones de Reflection pueden aportar a la cadena de bloques.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Desmantelando las ventajas técnicas del coprocesador Ethereum ZK Axiom
Primero, comprendamos el viaje del usuario para acceder realmente a la información de Ethereum. Cuando usábamos Ethereum por primera vez, la forma en que realmente recibíamos información sobre lo que sucedía en la cadena era a través de llamadas JSON-RPC para archivar anotaciones. El propósito de la API JSON-RPC es presentar información sobre el historial en cadena al usuario. Esencialmente, toda la información que vemos sobre la cadena de bloques se extrae de estas llamadas API y se presenta como una entrada en el sitio web para que el usuario la lea.
Ahora, a medida que los usuarios se vuelven más expertos en interactuar con la cadena de bloques, comenzamos a requerir vistas cada vez más complejas de la cadena. Por lo tanto, se están desarrollando diferentes tipos de nodos de archivo para diferentes compromisos de usuario. Entonces estaban Geth, Erigon, Nethermind y ahora Reth. Podemos elegir el nodo de archivo más adecuado según nuestras propias necesidades.
Si los usuarios no están satisfechos con una API JSON-RPC separada, se puede elegir un indexador para aplicar el procesamiento posterior mientras se rastrean las transacciones. Para diferentes aplicaciones, los usuarios pueden estar interesados en los datos devueltos por The Graph o Covalent.
Más recientemente, también ha habido billeteras y otros productos que ofrecen simulación de transacciones además de los nodos de archivo. Esto significa que podemos ver el resultado real de una transacción virtual antes de realizarla. En general, la forma en que interactuamos con Ethereum como usuarios finales se está volviendo más sofisticada, utilizando más computación además de los datos que leemos.
Ahora, si lo pensamos no desde la perspectiva de un usuario, sino desde la perspectiva de un contrato inteligente en Ethereum. Por supuesto, los contratos también quieren poder acceder a los datos y realizar cálculos sobre ellos, pero esto es más desafiante. De hecho, si vamos a OpenSea y miramos la lista de CryptoPunk, encontraremos que de toda la información de la página, solo una pequeña parte es accesible en el contrato inteligente de la cadena.
De hecho, para los listados de CryptoPunk, esta información es solo para los titulares actuales. Por supuesto, hay mucha otra información en la página, pero toda la información relacionada con la información histórica de transferencias, los precios históricos y los titulares históricos es en realidad inaccesible para el contrato inteligente porque pertenece al historial pasado. Estos historiales constituyen información en cadena, pero no están disponibles para contratos inteligentes porque debemos evitar obligar a cada nodo completo de Ethereum a mantener esta información en su acceso aleatorio para verificar transacciones.
Además, como cualquier desarrollador de blockchain puede decirle, ejecutar cálculos en la cadena es prohibitivamente costoso, aunque Ethereum tiene operaciones de máquina virtual (VM) relativamente eficientes, y la precompilación hace que ciertos tipos de operaciones sean más baratos. Por ejemplo, Ethereum proporciona un soporte relativamente económico para operaciones de curva elíptica en la curva BN254. Sin embargo, para algunas aplicaciones específicas, la máquina virtual Ethereum sigue siendo un entorno de tiempo de ejecución muy costoso. Al diseñar una máquina virtual de cadena de bloques, se debe elegir un conjunto inherente de operaciones que deben medirse cuidadosamente para garantizar que cada nodo pueda verificar las transacciones en un momento constante. Además, también se debe considerar la seguridad en el peor de los casos y la estabilidad del consenso. Entonces, el desafío aquí es cómo implementar el escalado específico de la aplicación para aplicaciones en cadena. Axiom tiene como objetivo expandir el acceso a datos y las capacidades informáticas para contratos inteligentes para satisfacer las necesidades de expansión de diferentes aplicaciones.
Lo que Axiom está construyendo es lo que llama un coprocesador Ethereum (coprocesador ZK), que permite que ciertos contratos inteligentes se deleguen sin confianza a nuestro sistema fuera de la cadena para que puedan delegar lecturas de datos y cálculos verificables a Axiom. Para emitir una consulta a Axiom, un contrato inteligente puede enviar una transacción a nuestro sistema en cadena. Nuestro nodo fuera de línea recibirá la transacción y generará un resultado basado en la consulta histórica de Ethereum, y adjuntará una prueba de conocimiento cero para demostrar la exactitud del resultado. Finalmente, verificamos los resultados en la cadena y entregamos los resultados de manera creíble a los contratos inteligentes posteriores.
Esto es similar a cómo la CPU en una computadora delega el cálculo a la GPU y recupera los resultados cuando se conocen. Este concepto fue llamado coprocesador (Coprocesso) en los primeros días. En la diapositiva, muestro una imagen de un coprocesamiento matemático avanzado de principios de la década de 1990 que es análogo a lo que hace Axiom.
Podemos obtener información sobre qué tipos de operaciones puede realizar Axiom. Cada consulta a Axiom se puede dividir en tres partes.
La primera es la parte de lectura, que es cómo se ingresan las consultas de Axiom: podemos leer de manera confiable los datos históricos en cadena.
La segunda parte es que podemos ejecutar cálculos de validación en estos datos. Esto puede comenzar desde un análisis básico, como sumar algunos números, encontrar el máximo o el mínimo, hasta cálculos más complejos. Por ejemplo, alguna agregación de firmas o verificación desde criptografía, e incluso aprendizaje automático basado en conocimiento cero, como verificar el funcionamiento de ciertos algoritmos de reputación sobre datos sociales en la cadena o usar ciertos algoritmos de aprendizaje automático en aplicaciones financieras. En última instancia, proporcionaremos funciones compuestas de computación programable a través de máquinas virtuales.
La última parte, después de los pasos de lectura y cálculo, obtenemos un resultado y siempre emparejamos ese resultado con una prueba de conocimiento cero de que el cálculo del resultado fue válido. Por lo tanto, verificamos esta prueba en el contrato inteligente de Ethereum y luego almacenamos el resultado para que lo use el contrato.
Dado que todos los resultados devueltos por Axiom en realidad se verifican con pruebas de conocimiento cero, esto significa que la seguridad de todo lo que devuelve Axiom es criptográficamente equivalente a la del propio Ethereum. La filosofía de Axiom es que no queremos imponer suposiciones adicionales a los usuarios más allá de las suposiciones criptográficas que ya tienen al usar Ethereum.
A continuación, presentaré en detalle su principio de implementación, que involucra el concepto de operación de Reflexión mencionado en el título del discurso. El principio central que lo hace posible es que cada bloque de la cadena de bloques contiene un historial completo. Podemos comenzar en el bloque Ethereum actual y volver a los bloques anteriores que nos interesan. Al tomar todos los encabezados de bloque entre el bloque anterior y el bloque actual, y al verificar la cadena hash de estos encabezados de bloque, podemos revertir el compromiso del bloque anterior con el bloque actual.
Entonces, ¿cuáles son los beneficios de Reflection?
Podemos tomar un bloque del Ethereum actual y volver a un bloque anterior que nos interese. Si obtenemos los encabezados de bloque entre el bloque anterior y el bloque actual, podemos revertir el compromiso del bloque anterior en el bloque actual verificando la ruta hash entre estos encabezados de bloque. Entonces, si estamos interesados en alguna información de un bloque pasado, podemos dar una prueba de inclusión en el compromiso de ese bloque. Específicamente, esto podría ser una prueba Merkle Patricia Trie de que la información existe en el estado del bloque, la transacción o el recibo. En el EVM, al menos en principio, se puede acceder a cualquier información pasada en la cadena solo a través del conocimiento de hashes de bloque recientes.
Desafortunadamente, hacer esto en el EVM es costoso. Como se acaba de mencionar, debe verificar las cadenas de hash y las pruebas de Merkle de todos los encabezados de bloque, lo que implica muchos cálculos de hash de Keccak en una gran cantidad de datos. Entonces, una vez que retrocedes en el tiempo, se vuelve muy difícil. Por lo tanto, aplicamos la operación Reflection envolviendo esta prueba con ZK en el EVM. Entonces, en lugar de poner todos los encabezados de bloques anteriores y todas estas pruebas de Merkle en cadena y luego verificarlas, verificamos con conocimiento cero si hay una secuencia de encabezados de bloques anteriores y algunas pruebas de verificación.
Esto tiene dos ventajas. Primero, nos evita tener que poner datos de prueba en los datos de llamadas. En segundo lugar, nos permite agregar pruebas, lo que es impensable sin el uso de ZK. La idea aquí es que al verificar cualquier cantidad de cálculos en Ethereum, el costo del gas es fijo, por lo que podemos usar una sola prueba ZK para verificar una gran cantidad de acceso a datos históricos.
Permítanme referirme brevemente a las ventajas y desventajas del concepto de operación Reflection basado en ZK.
Hay dos formas de acceder a los datos. La primera es la forma en que lo sabe antes: puede acceder a los datos en Ethereum directamente desde el contrato inteligente. Esto tiene la gran ventaja de que el acceso es síncrono. Por lo tanto, puede llamar directamente a la función de lectura en el contrato inteligente para obtener el valor actual. Por ejemplo, cuando opera en Uniswap, necesita esta sincronicidad. Sin embargo, también tiene muchas limitaciones. Su poder de cómputo está limitado por los costos de combustible y no tiene acceso a ningún dato histórico.
En segundo lugar, si desea aprovechar la capacidad de ZK para reflejarse en Ethereum, ya que debe generar pruebas de que su acceso es correcto, no hay forma de hacerlo de forma sincrónica. Entonces, en realidad no hay acceso directo al estado actual en la cadena, porque tienes que dar fe de un estado.
Por otro lado, si se permite acceder a datos históricos de forma asincrónica, puede aplicarles cálculos casi ilimitados y tener acceso a grandes cantidades de datos. Por lo tanto, al relajar el concepto de sincronización, el acceso a los datos operativos de Reflection basado en ZK se puede ampliar en gran medida.
Luego, veremos cómo implementar operaciones de Reflection a través de Axiom.
Primero, tenemos que mantener un caché de todos los bloques anteriores en nuestro contrato inteligente. En EVM, los últimos 256 hash de bloque están disponibles de forma nativa. Podemos probar que en cada lote de 1024 bloques, el hash del último bloque del lote anterior se confirma en el siguiente bloque. Asimismo, el hash del penúltimo bloque del lote anterior se confirma en el último bloque, y así sucesivamente. Por lo tanto, podemos verificar inversamente esta cadena hash y probar la validez de esta cadena hash a través del conocimiento cero.
Esto nos permite almacenar hashes de bloque en caché desde el bloque más reciente hasta el bloque de génesis. De hecho, hemos implementado esto en nuestro contrato inteligente de red principal, que contiene rutas Merkle almacenadas en caché cada 1024 bloques hash del bloque génesis.
Otra característica que estamos agregando es Merkle Mountain Range. Está construido sobre este caché de hash de bloque, una estructura de datos que nos permite hacer referencia a cada hash de bloque en Ethereum en un ADN limitado.
Una vez que hemos construido el caché, podemos consultar Axiom validando los bloques en el caché. Para que esto funcione, tenemos que demostrar que todos los datos del historial de Ethereum a los que intentamos acceder están comprometidos a estar en el caché de algún bloque. En segundo lugar, tenemos que demostrar que todos los cálculos que realizamos en esta consulta son correctos. Para verificar esto en cadena, verificamos la validez de la prueba de conocimiento cero. También verificamos que se correlacione con la información que hemos registrado en la cadena. Siempre generamos confianza en nuestros cachés o cachés de bloques y comparamos la información en esos cachés de bloques con información pública en pruebas de conocimiento cero.
Ahora hablemos de las posibles aplicaciones de la operación Reflection prevista.
El eje horizontal representa la complejidad de los datos, a cuántos datos realmente se necesita acceder para implementar la aplicación. El eje vertical representa la complejidad computacional, que es la cantidad de recursos computacionales que realmente se necesitan aplicar para completar la tarea.
Por lo tanto, el primer tipo de aplicación es una aplicación que se puede implementar en Ethereum con Axiom o cualquier tipo de mecanismo de operación de Reflection, pero el costo es un poco más alto.
Algunos ejemplos de esto incluyen la lectura de nonces de grado de consenso de encabezados de bloque en la capa de consenso de Ethereum, la verificación de edades históricas de cuentas o la lectura de diferentes tipos de datos de Oracle a partir de información de precios históricos. En el EVM, se pueden emplear varias soluciones para implementar estas aplicaciones, pero al colocar estas soluciones en conocimiento cero, se puede aumentar la eficiencia.
Ahora, hay otra clase de aplicaciones que generalmente requieren más acceso a datos y, por lo tanto, más cómputo. En mi opinión, estas aplicaciones no serían posibles sin el uso del coprocesador ZK.
Como ejemplo, una aplicación interesante es permitir que un Roll-up en Ethereum lea el estado de la capa base u otro Roll-up de manera confiable, utilizando el conocimiento cero para interactuar. Una de esas aplicaciones podría ser permitir que los Roll-ups lean instantáneas de saldos completos de tokens ERC20.
Si cambiamos nuestra atención del almacenamiento al historial de transacciones de las cuentas, puede imaginarse construir un sistema confiable de reputación, identidad o calificación crediticia al registrar el historial completo de las direcciones de Ethereum. Esto podría usarse para la puntuación de crédito, o para darle acceso a algún tipo de DAO en cadena, o para darle acceso para emitir NFT personalizados.
También hay una clase de aplicaciones que usan datos históricos en cadena para administrar el protocolo. Generalmente conocida como contabilidad de acuerdos.
La idea aquí es que existen protocolos para coordinar el comportamiento de los participantes, y el principio básico de la coordinación es la capacidad de recompensar o castigar a los participantes por su comportamiento. Si observa muchos protocolos en Ethereum, el registro de las acciones de los participantes en realidad se mantiene completamente en la cadena. Entonces, con Axiom, podemos imaginar que, en función del conjunto completo de acciones de los participantes del protocolo, el protocolo puede determinar la estructura de pago o incluso imponer algún tipo de penalización a los participantes, lo que creemos que realmente puede ampliar el espacio de diseño del protocolo. aplicaciones
Finalmente, si realmente subimos el nivel de computación, creemos que podría ser muy interesante usar modelos de aprendizaje automático para ajustar parámetros en cadena. Si piensa en las aplicaciones financieras tradicionales, es muy común modelar parámetros futuros complejos basados en grandes cantidades de datos históricos, como datos de precios, datos económicos, etc. Y cuando miramos el DeFi actual, está lejos de alcanzar ese nivel. No creo que DeFi deba funcionar exactamente de la misma manera que las finanzas tradicionales, pero sí creemos que inyectar algunas bases de datos históricas y modelos e información basados en aprendizaje automático puede ayudar a crear un protocolo DeFi más dinámico.
Estas son solo algunas ideas de lo que las operaciones de Reflection pueden aportar a la cadena de bloques.