Introducción

¿Qué pasaría si perdieras la memoria cada hora? ¿Y necesitas pedirle constantemente a alguien que te diga lo que has hecho? Ese es el estado actual de los contratos inteligentes. En cadenas de bloques como Ethereum, los contratos inteligentes no pueden acceder directamente a estados más allá de 256 bloques. Este problema se agrava aún más en el ecosistema de múltiples cadenas, donde la recuperación y verificación de datos en diferentes capas de ejecución es aún más difícil.

En 2020, Vitalik Buterin y Tomasz Stanczak propusieron una forma de acceder a los datos a lo largo del tiempo. Si bien el EIP se ha estancado, su necesidad ha resurgido en el mundo de cadenas múltiples centrado en la acumulación. Hoy en día, las pruebas de almacenamiento se han convertido en una frontera para dar conciencia y memoria a los contratos inteligentes.

Acceder a datos en cadena

Hay varias formas en que las dapps pueden acceder a los datos y al estado. Todos los enfoques requieren que la aplicación confíe en humanos/entidades o en seguridad o código criptoeconómico y tenga algunas compensaciones:

Confianza en humanos/entidades:

• Nodos de archivo: los operadores podrían ejecutar un nodo de archivo ellos mismos o confiar en proveedores de servicios de nodos de archivo como Alchemy o Infura para acceder a todos los datos desde el bloque Génesis. Proporcionan los mismos datos que un nodo completo, pero también todos los datos históricos del estado de toda la cadena de bloques. Los servicios fuera de la cadena como Etherscan y Dune Analytics utilizan nodos de archivo para acceder a los datos dentro de la cadena. Los actores fuera de la cadena pueden dar fe de la validez de estos datos, y los contratos inteligentes dentro de la cadena pueden verificar que los datos fueron firmados por un actor/comité confiable. No se verifica la integridad de los datos subyacentes. Este enfoque requiere que la dapp confíe en que el proveedor de servicios del nodo de archivo está ejecutando la infraestructura correctamente y sin ninguna intención maliciosa.

Confíe en la seguridad criptoeconómica:

• Indexadores: el protocolo de indexación organiza todos los datos en Blockchain, lo que permite a los desarrolladores crear y publicar API abiertas que las aplicaciones pueden consultar. Los indexadores individuales son operadores de nodos que apuestan tokens para proporcionar servicios de indexación y procesamiento de consultas. Sin embargo, pueden surgir disputas cuando los datos proporcionados son incorrectos y el proceso de arbitraje puede llevar tiempo. Además, los datos de indexadores como The Graph no pueden ser utilizados directamente por la lógica empresarial de los contratos inteligentes y se utilizan en el contexto de análisis de datos basado en web2.
• Oráculos: los proveedores de servicios de Oracle utilizan los datos agregados de muchos operadores de nodos independientes. El desafío aquí es que los datos disponibles de los Oráculos podrían no actualizarse con frecuencia y su alcance es limitado. Los oráculos como Chainlink generalmente solo mantienen estados específicos, como precios y para estados e historial de aplicaciones específicas, no son factibles. Además, este enfoque también introduce un cierto nivel de desviación en los datos y requiere confianza en los operadores de nodos.

Código de confianza:

• Variables y funciones especiales: Las cadenas de bloques como Ethereum tienen variables y funciones especiales que se utilizan principalmente para proporcionar información sobre la cadena de bloques o son funciones de utilidad de uso general. Solo es posible que un contrato inteligente acceda al hash de bloque de los 256 bloques más recientes. Los hashes de bloque no están disponibles para todos los bloques por motivos de escalabilidad. Tener acceso a hashes de bloques históricos sería útil, ya que podría permitir la verificación de pruebas en su contra. No hay ningún código de operación en la ejecución de EVM que permita el acceso a contenidos de bloques antiguos o contenidos de transacciones anteriores o salidas de recibos, por lo que un nodo puede olvidar esas cosas de forma segura y aún así poder procesar bloques nuevos. Este método también se limita a una única cadena de bloques.

Dados los desafíos y limitaciones de estas soluciones, existe una clara necesidad de almacenar y proporcionar hashes de bloques en la cadena. Aquí es donde entran las pruebas de almacenamiento. Para comprender mejor las pruebas de almacenamiento, echemos un vistazo rápido al almacenamiento de datos en blockchains.

Almacenamiento de datos en una cadena de bloques

Una cadena de bloques es una base de datos pública que se actualiza y comparte entre muchas computadoras en una red. Los datos y el estado se almacenan en grupos consecutivos llamados bloques y cada bloque hace referencia criptográficamente a su padre almacenando el hash del encabezado del bloque anterior.

Tomemos como ejemplo el bloque Ethereum. Ethereum aprovecha un tipo particular de árbol Merkle conocido como "árbol Merkle Patricia" (MPT). Los encabezados de bloques de Ethereum contienen raíces de cuatro intentos diferentes de Merkle-Patricia, es decir Prueba de estado, prueba de almacenamiento, prueba de recibos y prueba de transacciones. Estos 4 intentos codifican asignaciones que comprenden todos los datos de Ethereum. Los árboles Merkle se utilizan debido a su eficiencia en el almacenamiento de datos. Al utilizar hashes recursivos, eventualmente solo es necesario almacenar el hash raíz, lo que ahorra mucho espacio. Permiten que cualquiera pueda probar la existencia de un elemento en el árbol demostrando que el hash recursivo de los nodos conduce al mismo hash raíz. Las pruebas de Merkle permiten a los clientes ligeros de Ethereum obtener respuestas a preguntas como:

• ¿Existe esta transacción en un bloque en particular?
• ¿Cuál es el saldo actual de mi cuenta?
• ¿Existe esta cuenta?

En lugar de descargar cada transacción y cada bloque, un "cliente ligero" sólo puede descargar la cadena de encabezados de bloque y verificar la información utilizando Merkle Proofs. Esto hace que el proceso general sea altamente eficiente. Consulte este artículo de investigación del blog de Vitalik y Maven11 para comprender mejor la implementación, las ventajas y los desafíos asociados con Merkle Trees.

Pruebas de almacenamiento

Las pruebas de almacenamiento nos permiten demostrar que algo está confirmado en la base de datos y que también es válido mediante compromisos criptográficos. Si podemos proporcionar dicha prueba, será una afirmación verificable de que algo sucedió en la cadena de bloques.

¿Qué pueden permitir las pruebas de almacenamiento?

Las pruebas de almacenamiento permiten dos funcionalidades principales:

1. Acceda a datos históricos en cadena más allá de los últimos 256 bloques, hasta el bloque de génesis
2. Acceda a datos en cadena (históricos y actuales) de una cadena de bloques en otra cadena de bloques con la ayuda de verificación de consenso o puente L1-L2 en el caso de L2.

¿Cómo funcionan las pruebas de almacenamiento?

Las pruebas de almacenamiento a un nivel muy alto verifican si el bloque específico es parte del historial canónico de la cadena de bloques y luego verifican si los datos específicos solicitados son parte del bloque. Esto podría lograrse mediante:

• Procesamiento en cadena: las dapps podrían tomar el bloque confiable inicial, pasar el bloque como datos de llamada para acceder al bloque anterior y recorrer todo el camino de regreso al bloque de génesis. Esto requiere muchos cálculos en cadena y una gran cantidad de datos de llamadas. Este enfoque no es del todo viable en la práctica debido a la enorme cantidad de cálculos necesarios en la cadena. Aragón intentó utilizar el enfoque en cadena en 2018, pero no fue factible debido al alto costo en cadena.
• Uso de pruebas ZK: el enfoque es similar al procesamiento en cadena, excepto por el hecho de que el probador ZK se utiliza para mover el cálculo complejo fuera de la cadena.

1. Acceso a datos en la misma cadena: la prueba ZK se puede utilizar para afirmar que un encabezado de bloque histórico arbitrario es un antepasado de uno de los 256 encabezados de bloque más recientes a los que se puede acceder dentro del entorno de ejecución. El otro enfoque es indexar todo el historial de la cadena fuente y generar una prueba ZK de la misma para demostrar que la indexación se realizó correctamente. Esta prueba se actualiza periódicamente a medida que se agregan nuevos bloques a la cadena fuente. Acceso a datos a través de cadenas: el proveedor recopila los encabezados de bloque de la cadena de origen en la cadena de destino y certifica la validez de estos encabezados de bloque utilizando la prueba de consenso ZK. También es posible utilizar una solución AMP existente como Axelar, Celer o LayerZero para consultar los encabezados de los bloques.
2. En la cadena de destino se mantiene un caché de hash de encabezados de bloque de la cadena de origen, o el hash raíz de un acumulador de hash de bloque fuera de la cadena. Este caché se actualiza periódicamente y se utiliza para demostrar de manera eficiente en la cadena que un bloque determinado existe y tiene un vínculo criptográfico con un hash de bloque reciente accesible desde el estado. Este proceso se conoce como prueba de la continuidad de la cadena. También es posible utilizar una cadena de bloques dedicada para almacenar los encabezados de bloque de todas las cadenas de origen.
3. Se accede a los datos/bloques históricos desde datos indexados fuera de la cadena o caché dentro de la cadena (según la complejidad de la solicitud) según lo solicite la dapp en la cadena de destino. Si bien el caché de un hash de encabezados de bloque se mantiene en la cadena, los datos reales pueden almacenarse fuera de la cadena.
4. La existencia de datos en el bloque especificado se verifica mediante pruebas de inclusión merkle y se genera una prueba zk para los mismos. Esta prueba se combina con la prueba zk de indexación correcta o la prueba de consenso ZK y la prueba está disponible en la cadena para una verificación sin confianza.
5. Luego, las dapps pueden verificar esta prueba en cadena y usar los datos para ejecutar la acción deseada. Junto con la verificación de la prueba ZK, los parámetros públicos como el número de bloque y el hash del bloque se comparan con el caché de los encabezados de bloque mantenidos en la cadena.

Algunos de los proyectos que adoptan este enfoque son Herodotus, Lagrange, Axiom, Hyper Oracle, Brevis Network y nil Foundation. Si bien se están realizando esfuerzos significativos para que las aplicaciones sean conscientes del estado en múltiples blockchains, IBC (Comunicación Inter Blockchain) se destaca como un estándar de interoperabilidad que permite aplicaciones como ICQ (consultas Interchain) e ICA (cuentas Interchain). ICQ permite que las aplicaciones en la Cadena A consulten el estado de la cadena B al incluir la consulta en un paquete IBC simple y ICA permite que una cadena de bloques controle de forma segura una cuenta en otra cadena de bloques. Combinarlos puede permitir casos de uso interesantes entre cadenas. Los proveedores de RaaS como Saga ofrecen estas funcionalidades a todas sus cadenas de aplicaciones de forma predeterminada mediante IBC.

Hay muchas maneras en que se pueden optimizar las pruebas de almacenamiento para encontrar el equilibrio adecuado entre el consumo de memoria, el tiempo de prueba, el tiempo de verificación, la eficiencia informática y la experiencia del desarrollador. El proceso general se puede dividir en términos generales en 3 subprocesos principales.

• Acceso a los datos
• Procesamiento de datos
• Generación de ZK Proof para acceso y procesamiento de datos

Acceso a datos: en este subproceso, el proveedor de servicios accede a los encabezados de bloque de la cadena de origen de forma nativa en la capa de ejecución o manteniendo un caché en la cadena. Para el acceso a datos entre cadenas, se requiere la verificación del consenso de la cadena de origen sobre la cadena de destino. Algunos de los enfoques y optimizaciones que se están adoptando incluyen:

• La cadena de bloques Ethereum existente: la estructura existente de la cadena de bloques Ethereum se puede utilizar para demostrar el valor de cualquier espacio de almacenamiento histórico con respecto al encabezado de bloque actual utilizando ZKP. Esto puede considerarse como una gran prueba de inclusión. Es una prueba de que, dado un encabezado de bloque reciente X en la altura b, existe el encabezado de bloque Y que es un antepasado de X en la altura bk. Se basa en la seguridad del consenso de Ethereum y requiere un sistema de prueba rápida para su eficiencia. Este es el enfoque utilizado por Lagrange.
• Caché de las Cordilleras Merkle (MMR) en cadena: una Cordillera Merkle se puede ver como una lista de árboles Merkle donde los árboles Merkle individuales se combinan cuando dos árboles alcanzan el mismo tamaño. Los árboles Merkle individuales en MMR se combinan agregando nodos principales a las raíces anteriores de los árboles. MMR es una estructura de datos similar a los árboles de Merkle con algunos beneficios adicionales, como la adición eficiente de elementos y consultas de datos eficientes, particularmente cuando se leen datos secuenciales de grandes conjuntos de datos. Agregar nuevos encabezados a través del árbol Merkle requeriría pasar todos los nodos hermanos en cada nivel. Para agregar datos de manera eficiente, Axiom usa MMR para mantener un caché del hash de los encabezados de bloque en la cadena. Herodotus almacena el hash raíz del acumulador de hash de bloque MMR en cadena. Esto les permite comparar los datos obtenidos con estos hashes de encabezado de bloque mediante pruebas de inclusión. Este enfoque requiere que el caché se actualice periódicamente y genera problemas de vida si no se descentraliza.
• Heródoto mantiene dos MMR diferentes. Dependiendo de la cadena de bloques o capa específica, los acumuladores se pueden adaptar para utilizar diferentes funciones de hash, optimizando la eficiencia y los costos computacionales. Para realizar pruebas en Starknet, se puede usar hash Poseidón, pero se puede usar hash Keccack para cadenas EVM.
• Caché MMR fuera de la cadena: Herodotus mantiene un caché fuera de la cadena de consultas y resultados obtenidos previamente para permitir una recuperación más rápida en caso de que los datos se soliciten nuevamente. Esto requiere una infraestructura adicional además de simplemente ejecutar un nodo de archivo. Las optimizaciones realizadas en la infraestructura fuera de la cadena pueden potencialmente reducir los costos para el usuario final.
• Blockchain dedicada para almacenamiento: Brevis se basa en un paquete acumulativo ZK (capa de agregación) dedicado para almacenar todos los encabezados de bloque de todas las cadenas de las que dan fe. Sin esta capa de agregación, cada cadena necesitaría almacenar los encabezados de bloque de todas las demás cadenas, lo que daría como resultado O(N2) "conexiones" para N blockchains. Al introducir una capa de agregación, cada cadena de bloques solo necesita almacenar la raíz del estado para el resumen, lo que reduce las conexiones generales a O(N). Esta capa también se utiliza para agregar múltiples pruebas de encabezados de bloques/resultados de consultas y se puede enviar una única prueba para la verificación en cada cadena de bloques conectada.
• Paso de mensajes L1-L2: la verificación del consenso de la cadena de origen se puede evitar en el caso de los L2 porque los L2 admiten mensajería nativa para actualizar los contratos L2 en L1. El caché podría actualizarse en Ethereum y el paso de mensajes L1-L2 se puede usar para enviar el hash del bloque o la raíz del árbol compilado fuera de la cadena a otros L2. Heródoto está adoptando este enfoque, pero no es factible para las L1 alternativas.

Procesamiento de datos:

Además del acceso a los datos, los contratos inteligentes también deberían poder realizar cálculos arbitrarios sobre los datos. Si bien es posible que algunos casos de uso no requieran cálculo, es un importante servicio de valor agregado para muchos otros casos de uso. Muchos de los proveedores de servicios permiten cálculos sobre los datos, ya que se puede generar una prueba zk del cálculo y proporcionarla en cadena para su validez. Debido a que las soluciones AMP existentes como Axelar, LayerZero y Polyhedra Network podrían usarse para el acceso a datos, el procesamiento de datos podría convertirse en un diferenciador para los proveedores de servicios de prueba de almacenamiento.

Hyper Oracle, por ejemplo, permite a los desarrolladores definir cálculos personalizados fuera de la cadena con JavaScript. Brevis ha diseñado un mercado abierto de ZK Query Engines que acepta consultas de datos de dApps y las procesa utilizando los encabezados de bloque certificados. El contrato inteligente envía una consulta de datos, que es recogida por un probador del mercado. Prover genera una prueba basada en la entrada de la consulta, los encabezados de bloque relevantes (de la capa de agregación Brevis) y los resultados. Lagrange ha introducido ZK Big Data Stack para probar modelos de programación distribuida como SQL, MapReduce y Spark/RDD. Las pruebas son modulares y se pueden generar a partir de cualquier encabezado de bloque que se origine a partir de puentes entre cadenas y protocolos AMP existentes. ZK MapReduce, el primer producto de la pila Lagrange ZK BigData, es un motor de computación distribuida (basado en el conocido modelo de programación MapReduce) para probar resultados de computación que involucran conjuntos considerables de datos de múltiples cadenas. Por ejemplo, se puede utilizar una única prueba ZKMR para demostrar cambios en la liquidez de un DEX implementado en 4 a 5 cadenas durante un período de tiempo específico. Para consultas relativamente simples, el cálculo también se puede realizar directamente en la cadena, como lo hace Heródoto en este momento.

Generación de pruebas:

• Pruebas actualizables: las pruebas actualizables se pueden utilizar cuando es necesario calcular y mantener una prueba de manera eficiente en un flujo de bloques en movimiento. Cuando una dapp desea mantener una prueba para un promedio móvil de una variable de contrato (como el precio del token), a medida que se crean nuevos bloques, sin volver a calcular la nueva prueba desde cero, las pruebas existentes se pueden actualizar de manera eficiente. Para probar el cálculo dinámico de datos paralelos en un estado en cadena, Lagrange crea un compromiso de vector por lotes, llamado Recproof, sobre una parte de MPT, lo actualiza sobre la marcha y lo calcula dinámicamente. Al crear recursivamente un árbol Verkle sobre MPT, Lagrange puede calcular grandes cantidades de datos dinámicos de estado en cadena de manera eficiente.
• Árboles Verkle: a diferencia de los árboles Merkle, donde debemos proporcionar todos los nodos que comparten un padre, los árboles Verkle solo requieren la ruta a la raíz. Este camino es mucho más pequeño en comparación con todos los nodos hermanos en el caso del árbol Merkle. Ethereum también está explorando el uso de árboles Verkle en futuras versiones para minimizar la cantidad de estado que deben mantener los nodos completos de Ethereum. Brevis aprovecha Verkle Tree para almacenar encabezados de bloques certificados y resultados de consultas en la capa de agregación. Reduce significativamente el tamaño de la prueba de inclusión de datos, especialmente cuando el árbol contiene una gran cantidad de elementos, y también admite pruebas de inclusión eficientes para un lote de datos.
• Monitoreo de Mempool para una generación de pruebas más rápida: Herodotus anunció recientemente turbo, que permite a los desarrolladores agregar algunas líneas de código a su código de contrato inteligente para especificar la consulta de datos. Herodotus monitorea el mempool en busca de transacciones de contratos inteligentes que interactúen con el contrato turbo. El proceso de generación de pruebas comienza cuando la transacción está en el propio mempool. Una vez que la prueba se genera y verifica en la cadena, los resultados se escriben en el contrato de intercambio turbo en la cadena. Los resultados solo se pueden escribir en el contrato de intercambio de turbo una vez que estén autenticados mediante pruebas de almacenamiento. Una vez que esto sucede, una parte de las tarifas de transacción se comparte con el secuenciador o creador de bloques, lo que los incentiva a esperar un poco más para cobrar las tarifas. Para consultas de datos simples, es posible que los datos solicitados estén disponibles en la cadena antes de que la transacción del usuario se incluya en el bloque.

Aplicación de pruebas de estado/almacenamiento

Las pruebas de estado y de almacenamiento pueden desbloquear muchos casos de uso nuevos para contratos inteligentes en la capa de aplicación, middleware e infraestructura. Algunos de estos son:

Capa de aplicación:

Gobernancia:

• Votación entre cadenas: un protocolo de votación en cadena podría permitir a los usuarios de la Cadena B demostrar la propiedad de los activos en la Cadena A. Los usuarios no tendrán que unir sus activos para obtener poder de voto en una nueva cadena. Ejemplo: SnapshotX sobre Heródoto
• Distribución de tokens de gobernanza: las aplicaciones podrían distribuir más tokens de gobernanza a usuarios activos o a los primeros usuarios. Ejemplo: RetroPGF en Lagrange

Identidad y Reputación:

• Prueba de propiedad: un usuario puede proporcionar prueba de propiedad de un determinado NFT, SBT o activos en la cadena A, lo que le permite realizar ciertas acciones en la Cadena B. Por ejemplo, una cadena de aplicaciones de juegos puede decidir lanzar su colección NFT en otra cadena con liquidez existente como Ethereum o cualquier L2. Esto permitirá que el juego aproveche la liquidez que existe en otros lugares y conecte la utilidad NFT sin necesidad de conectar las NFT.
• Prueba de uso: los usuarios podrían recibir descuentos o funciones premium en función de su uso histórico de la plataforma (demuestre que el volumen X negociado por el usuario en Uniswap)
• Prueba de OG: un usuario puede demostrar que posee una cuenta activa que tiene más de X días
• Puntaje de crédito en cadena: una plataforma de puntaje de crédito de múltiples cadenas puede agregar datos de múltiples cuentas de un solo usuario para generar un puntaje de crédito.

Todas las pruebas anteriores se pueden utilizar para brindar una experiencia personalizada a los usuarios. Dapps podría ofrecer descuentos o privilegios para retener a comerciantes o usuarios experimentados y ofrecer una experiencia de usuario simplificada para usuarios novatos.

Defi:

• Préstamos entre cadenas: los usuarios pueden bloquear activos en la Cadena A y solicitar un préstamo en la Cadena B en lugar de unir los tokens.
• Seguro en cadena: las fallas se pueden determinar accediendo a datos históricos en cadena y el seguro se puede liquidar completamente en cadena.
• TWAP del precio del activo en un grupo: una aplicación podría calcular y recuperar el precio promedio de un activo en un grupo de AMM durante un período de tiempo específico. Ejemplo: Uniswap TWAP Oracle con Axiom
• Precio de opciones: un protocolo de opciones en cadena puede fijar el precio de una opción utilizando la volatilidad de un activo durante los últimos n bloques en un intercambio descentralizado.

Los dos últimos casos de uso requerirán que la prueba se actualice cada vez que se agregue un nuevo bloque a la cadena de origen.

Medio software:

• Intenciones: las pruebas de almacenamiento permitirán a los usuarios ser más articulados y claros con sus intenciones. Si bien es trabajo de los solucionadores ejecutar los pasos necesarios para cumplir la intención del usuario, un usuario podría especificar más claramente las condiciones en función de los datos y parámetros en cadena. Los solucionadores también pueden demostrar la validez de los datos en cadena aprovechados para encontrar la solución óptima.
• Abstracción de cuentas: los usuarios pueden confiar en los datos provenientes de otras cadenas utilizando pruebas de almacenamiento para establecer reglas a través de la abstracción de cuentas. Ejemplo: cada billetera tiene un nonce. Podemos demostrar que hace un año el nonce era un número particular y actualmente el nonce es el mismo. Esto se puede utilizar para demostrar que esta billetera no se ha utilizado en absoluto y luego se puede delegar el acceso a la billetera a otra billetera.
• Automatización en cadena: los contratos inteligentes podrían automatizar ciertas acciones en función de condiciones predefinidas que dependen de los datos en cadena. Se requieren programas automatizados para llamar contratos inteligentes en ciertos intervalos para mantener el flujo de precios óptimo del AMM o para mantener saludables los protocolos de préstamos evitando deudas incobrables. Hyper Oracle permite la automatización junto con el acceso a datos en cadena.

Infraestructura

• Oracle en cadena sin confianza: las redes de Oracle descentralizadas agregan respuestas de numerosos nodos de Oracle individuales dentro de una red de Oracle. Oracle Networks puede eliminar esta redundancia y aprovechar la seguridad criptográfica para los datos en cadena. La red de Oracle podría ingerir datos de múltiples cadenas (L1, L2 y L1 alternativas) en una sola cadena y simplemente demostrar su existencia utilizando pruebas de almacenamiento en otros lugares. Las soluciones DeFi con una tracción significativa también podrían funcionar en una solución personalizada. Por ejemplo, Lido Finance, el mayor proveedor de apuestas de liquidez, se ha asociado con Nil Foundation para financiar el desarrollo de zkOracle. Las soluciones permitirán el acceso confiable a datos históricos en EVM y asegurarán $ 15 mil millones en liquidez de Ethereum apostada por Lido Finance.
• Protocolos AMP: las soluciones AMP existentes podrían aumentar la expresividad de sus mensajes al asociarse con proveedores de servicios a prueba de almacenamiento. Este es un enfoque sugerido por Lagrange en su artículo Modular Thesis .

Conclusión

La conciencia permite a las empresas de tecnología servir mejor a sus clientes. Desde la identidad del usuario hasta el comportamiento de compra y los gráficos sociales, las empresas de tecnología aprovechan el conocimiento para desbloquear capacidades como la orientación precisa, la segmentación de clientes y el marketing viral. Las empresas de tecnología tradicionales necesitan un permiso explícito de sus usuarios y deben tener cuidado al gestionar los datos de los usuarios. Sin embargo, todos los datos de los usuarios en blockchains sin permiso están disponibles públicamente sin revelar necesariamente la identidad del usuario. Los contratos inteligentes deberían poder aprovechar los datos disponibles públicamente para servir mejor a los usuarios. El desarrollo y la adopción de ecosistemas más especializados harán que la conciencia estatal a lo largo del tiempo y las cadenas de bloques sean un problema cada vez más importante por resolver. Las pruebas de almacenamiento pueden permitir que Ethereum surja como una capa de identidad y propiedad de activos, además de ser una capa de liquidación. Los usuarios podrían mantener su identidad y activos clave en Ethereum, que podrían usarse en múltiples cadenas de bloques sin conectar activos todo el tiempo. Seguimos entusiasmados con las nuevas posibilidades y casos de uso que se desbloquearán en el futuro.

Descargo de responsabilidad:

1. Este artículo se reimprime de [medio]. Todos los derechos de autor pertenecen al autor original [LongHash Ventures]. 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.