En nuestra publicación anterior, que sería ejecutable, discutimos el papel del consenso prueba de este método emergente de minimización de confianza en facilitar el puente entre cadenas de bloques.

En este artículo, exploraremos la prueba de almacenamiento, que toma el concepto de verificación de minimización de confianza y lo extiende a transacciones en bloques históricos más antiguos. La capacidad de verificar transacciones pasadas y la actividad del usuario de esta manera desbloquea una gran cantidad de casos de uso entre cadenas.

En nuestro publicación anterior, introdujimos Prueba de Consenso, un enfoque de minimización de confianza para vincular fondos a través de bloques. Dado que los usuarios del puente generalmente desean ver que las transacciones ocurran inmediatamente en el momento más reciente, la prueba de consenso es muy útil porque constantemente verifican el estado más reciente de la cadena de bloques a medida que opera.

Este concepto de minimización de la confianza también se puede aplicar en otra dirección, que es retroceder en el tiempo y utilizar pruebas de conocimiento cero para verificar transacciones y datos en bloques antiguos. Estas "pruebas de almacenamiento histórico" respaldan una amplia gama de casos de uso entre cadenas, y en este artículo cubriremos estos casos de uso, cómo funcionan y los actores construidos en este espacio.

Recuperar datos históricos

Hay muchos usos para los datos históricos de la cadena de bloques. Se puede utilizar para demostrar la propiedad de activos, el comportamiento del usuario y el historial de transacciones, y luego introducir estos en contratos inteligentes o aplicaciones on-chain.En el momento de la escritura, se han escrito más de 18 millones de bloques en Ethereum.Los contratos inteligentes solo pueden acceder a los 256 bloques más recientes (o datos dentro de los últimos 30 minutos), por lo que los "datos históricos" se refieren a cualquier cosa que no sea los últimos 256 bloques.

Hoy en día, para acceder a datos históricos, los protocolos a menudo consultan nodo de archivoproveedores, es decir, terceros como Infura, Alchemy u otros indexadores. Eso significa confiar y depender de ellos y sus datos.

Datos históricos

Sin embargo, estos datos pueden relajarse de una manera más minimizada en confianza, a través del uso de pruebas de almacenamiento.

Datos históricos

Sin embargo, estos datos pueden recuperarse de una manera más confiable al utilizar pruebas de almacenamiento.

La prueba de almacenamiento es una prueba de conocimiento cero que permite la verificación de datos históricos almacenados en la cadena de bloques. Más específicamente, la prueba de almacenamiento se puede utilizar para probar la existencia de un estado específico en un bloque particular en el pasado.Este enfoque no requiere confianza en terceros u oráculos; en su lugar, su confianza está integrada en la prueba de almacenamiento.

¿Cómo pueden las pruebas de almacenamiento ayudar a verificar que algunos datos existen en bloques históricos antiguos? Esto requiere verificar dos cosas:

• El primer paso es verificar si un bloque específico forma parte de la historia regulatoria de la cadena de bloques, es decir, si el bloque es una parte válida de la historia de la cadena de origen
• El segundo paso es verificar si datos específicos son parte del bloque, es decir, si una pieza de información (como una transacción específica) es parte del bloque (esto puede ser demostrado por Merkle incluyendo prueba)

Después de recibir y verificar la prueba, el destinatario (como un contrato inteligente en la cadena de destino) cree en la validez de los datos y puede ejecutar el conjunto correspondiente de instrucciones. El concepto puede incluso ampliarse más: se pueden ejecutar cálculos adicionales fuera de la cadena con datos validados, luego se genera otra prueba de conocimiento cero para demostrar los datos y los cálculos.

Simplemente dicho, la prueba de almacenamiento apoya la recuperación de datos en la cadena histórica de una manera que minimiza la confianza. Esto es importante porque, como describimos en nuestra primera publicación, vemos que web3 se convierte en un espacio más multi-cadena y multinivel en los próximos años. La aparición de múltiples protocolos de capa 1, rollups y cadenas de aplicaciones significa que la actividad en cadena de los usuarios puede estar dispersa en varias cadenas. Esto enfatiza aún más la necesidad de soluciones de interoperabilidad que minimicen la confianza y mantengan la composabilidad de los activos de los usuarios, identidades e historial de transacciones en múltiples dominios. Este es un problema que la prueba de almacenamiento puede ayudar a resolver.

¿Cuáles son los casos de uso para la prueba de almacenamiento?

La prueba de almacenamiento permite a los contratos inteligentes verificar cualquier transacción o datos históricos como requisito previo. Esto hace que el diseño de aplicaciones entre cadenas sea más flexible.

Primero, almacenar pruebas puede demostrar cualquier dato histórico en la cadena de bloques de origen, como

1. Saldo de cuenta y propiedad de tokens
2. Actividad comercial del usuario o estado estático
3. El precio histórico de una transacción de activos durante un período de tiempo especificado
4. Saldo de activos en tiempo real en piscina de liquidez entre cadenas

La prueba puede enviarse luego a la cadena objetivo para desbloquear la gama de casos de uso entre cadenas:

1. Permite a los usuarios votar en propuestas de gobernanza en acuerdos de capa 2 de menor costo
2. Permitir a los titulares de NFT recibir nuevos NFT o beneficios comunitarios en una nueva cadena
3. Recompensar a los usuarios en función de su historial y sus interacciones con aplicaciones descentralizadas específicas (por ejemplo, a través de airdrops)
4. Préstamos que ofrecen tasas de interés personalizadas basadas en el historial de transacciones y crédito general del usuario
5. Activar la recuperación de cuenta para cuentas inactivas
6. Calculando la historia de los futuros swaps TWAP
7. Calcular precios de intercambio AMM más precisos basados en piscinas de liquidez multi-cadena

Básicamente, las pruebas de almacenamiento permiten a las aplicaciones consultar y trasladar la actividad y el historial de los usuarios en cadena a través de múltiples cadenas para introducirlos en un contrato inteligente o aplicación en otra cadena.

Casos de uso de prueba de almacenamiento

Tomemos un ejemplo detallado para entender cómo funciona la prueba de almacenamiento.

Cómo funciona la Prueba de Almacenamiento: Ejemplos Detallados

Supongamos “X”, que es un protocolo DeFi con tokens en Ethereum. Se va a presentar una propuesta de gobernanza, y quieren promover la votación en cadena en cadenas objetivo de menor costo. Los usuarios solo pueden votar si poseen tokens X en Ethereum en un momento específico (lo llamamos “instantánea”), como el bloque #17,000,000.

¿Cómo se realiza actualmente la votación en la cadena?

El enfoque actual es consultar el nodo de archivo para obtener la lista completa de titulares de tokens elegibles en el bloque #17,000,000. Luego, el administrador de DAO almacena esa lista en un contrato inteligente en la cadena de destino para determinar quién puede votar. Hay algunas limitaciones para este enfoque:

1. La lista de votantes puede ser muy larga, y cada instantánea cambia, lo que hace costoso almacenar y actualizar cada propuesta de votación en la cadena;
2. Existe una confianza implícita en el proveedor de nodo de archivo y los datos que proporciona;
3. Los miembros que gestionan el DAO deben ser confiables para no manipular la lista de votantes

¿Cómo resuelve la prueba de almacenamiento este problema?

Como explicamos en el artículo 2, los cálculos costosos pueden transferirse a pruebas de conocimiento cero fuera de la cadena.

El atestador zk generará una prueba concisa y la enviará a la cadena de destino para su verificación. Para los ejemplos de elegibilidad de votantes DAO anteriores, los siguientes son:

1. El atestiguador genera una prueba de conocimiento cero de que el bloque #17,000,000 es parte de la historia de Ethereum (como en el primer paso* anterior).
2. Después de demostrar la validez del bloque, podemos usar Merkle para incluir la prueba de que el usuario tenía tokens DAO cuando el bloque se finalizó (como en el paso 2 anterior*)

Verificar datos históricos para habilitar votación entre cadenas

La prueba se envía luego a un contrato inteligente en la cadena de destino para su verificación. Si la verificación es exitosa, entonces el contrato inteligente en el protocolo de capa 2 permite a los usuarios votar.

Este enfoque resolvió algunos problemas. No requiere:

Confía en el proveedor del nodo de archivo;

1. permita que el acuerdo mantenga costosas listas de votantes en cadena;
2. Para que los usuarios transfieran activos a la cadena de propósito

¿Qué configuraciones son necesarias para la prueba de almacenamiento?

Hasta ahora, hemos abstraído algunas de las complejidades de las pruebas de almacenamiento. Sin embargo, su uso también requiere una configuración inicial cuidadosa por parte del proveedor de servicios para garantizar que se puedan utilizar sin confiar en el proveedor. Durante este proceso, se generan y almacenan dos cosas en la cadena.

1. Prueba de conocimiento cero de cadena completa ("promesa zk"): El proveedor de servicios agrupa todos los bloques históricos en la cadena de origen en "bloques" continuos de tamaño fijo (utilizando árboles de Merkle)y genera pruebas de conocimiento cero para cada bloque, que se utilizan para verificar las agrupaciones. Estas pruebas se combinan luego de forma recursiva hasta obtener una prueba de conocimiento cero final, una "promesa zk" a toda la cadena. Esto demuestra que el proveedor ha indexado correctamente toda la historia de la cadena.

La promesa "zk" explica toda la historia de Ethereum

• **Cadena de montañas de Merkle: ** El proveedor también almacena las raíces de Merkle de Keccak de los hashes de bloques (bloques) de la cadena fuente agrupados en una estructura de datos en cadena llamada Cadena de Montañas de Merkle (MMR). Esta estructura de datos se utiliza porque es fácil de consultar y actualizar, y permite a los proveedores demostrar eficazmente que un bloque dado existe en la historia de la cadena. MMR se crea utilizando un hash Keccak256, un hash Poseidon, o ambos. Los hashes de Poseidon son más amigables con el conocimiento cero y admiten el cálculo de datos históricos. La validez de los datos y el cálculo posteriormente se puede demostrar a través del conocimiento cero.

Ilustración de la cordillera Merkel (MMR)

A medida que se agregan nuevos bloques a la cadena de origen, los proveedores de servicios actualizan regularmente (por ejemplo, cada hora o diariamente) el “compromiso zk” y MMR para mantenerse al día con el ritmo de la cadena. Esto se hace para que el bloque pasado esté siempre vinculado a uno de los 256 bloques actualmente accesibles desde EVM. Esto garantiza que los datos históricos estén vinculados a uno de los bloques actualmente disponibles en Ethereum.

En la imagen a continuación, hemos detallado cómo completar la configuración:

En resumen, lo siguiente muestra cómo usar la prueba de almacenamiento una vez que la configuración esté completa en el contexto del ejemplo de votación de DAO que cubrimos anteriormente:

1. Los proveedores de servicios crean y almacenan "promesas zk" para toda la cadena (es decir, la historia de Ethereum) y MMR en la cadena de destino
2. El proveedor permite a las aplicaciones consultar datos históricos en cadena o fuera de cadena a través de una API
3. Una dApp de votación en la cadena de objetivos envía una consulta al contrato inteligente del proveedor para averiguar si el usuario posee tokens DAO en el bloque n.º 17,000,000 en Ethereum

El proveedor verificará dos cosas:

1. El bloque consultado es parte de la historia regulatoria de Ethereum (primer paso anterior); el proveedor luego genera una prueba de cero conocimiento del contenido del bloque a través de Merkle Mountain Range
2. El usuario tiene tokens DAO en el bloque n.º 17,000,000 (paso 2 anterior); luego, el proveedor genera otra prueba de conocimiento cero de que el usuario tiene tokens DAO dentro del bloque
3. El proveedor agrega la prueba generada anteriormente en una prueba de conocimiento cero
4. La prueba ZK agregada se envía de vuelta al contrato inteligente dApp de votación en la cadena objetivo para verificar la prueba ZK y permitir al usuario votar una vez que la verificación sea exitosa.

Construcción de equipos en este campo

Algunos participantes están construyendo contratos inteligentes que permiten que los contratos inteligentes accedan a datos en cadenas históricas de una manera que minimiza la confianza.

Actualmente, Axiomase está ejecutando en Ethereum y se compromete a proporcionar contratos inteligentes en Ethereum y acceder a datos históricos de Ethereum a través de pruebas de almacenamiento basadas en zk. El equipo también está mejorando las capacidades computacionales fuera de la cadena basadas en datos históricos y utilizando el conocimiento cero para demostrar la precisión de estos datos y cálculos.

Protocolo de Reliquiaproporciona un enfoque técnico similar a Axiom, y el protocolo se ejecuta en Ethereum y en la Era zkSync. Relic utiliza pruebas de inclusión de Merkle para demostrar la inclusión de datos (en contraposición al método de Axiom para demostrar la inclusión de Merkle en conocimiento cero).

Herodotoestá trabajando para proporcionar datos históricos sobre Ethereum para protocolos de capa 2. La implementación de prueba ya está disponible en Starknet y zkSync Era. Con financiación de la Fundación OP, creemos saber a dónde se dirige el equipo de Herodotus a continuación.

Lagrange Labs Labsha introducido pruebas totalmente actualizables a través de su reciente innovación ZK MapReduce (ZKMR). Utiliza una nueva promesa de vector llamadaRecproofsextender el concepto de actualización a la computación de datos.

Equipos trabajando en la certificación de almacenamiento

epílogo

En este artículo, hemos descrito cómo la prueba de almacenamiento puede respaldar la verificación de datos en la cadena histórica sin confiar en terceros. Esto los convierte en una herramienta valiosa para la composición en cadena y la interoperabilidad entre cadenas.

A medida que el Valor Total Bloqueado (TVL) continúa migrando de Ethereum al ecosistema de Nivel 2, anticipamos la aparición de aplicaciones más expresivas que utilicen datos históricos en cadena a través de pruebas de almacenamiento.

Si bien la tecnología de conocimiento cero se está volviendo más rápida y más barata, generar continuamente pruebas de almacenamiento para mantenerse al día con los costos asociados con estar en la cadena aún es un desafío. La rentabilidad de dichos servicios dependerá del volumen de consultas generadas por la aplicación de consulta.

A pesar de los desafíos, no se puede subestimar la importancia de la prueba de consenso y la prueba de almacenamiento respaldadas por la tecnología de conocimiento cero. Esperamos ver cómo se utilizarán estas tecnologías para construir un futuro multi-cadena con un mínimo de confianza.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [ espejo]. Todos los derechos de autor pertenecen al autor original [Jacob, Hitesh, Ji Hao]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn（gatelearn@gate.io) y lo resolverán rápidamente.
2. Renuncia de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se indique lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.