--- title: "Análisis profundo de datos blockchain" description: "Aprende cómo se crean, almacenan, acceden y usan los datos blockchain en la infraestructura y aplicaciones de web3." --- # Análisis profundo de datos blockchain Cada Blockchain mantiene un registro inmutable de transacciones y eventos. Las aplicaciones Web3 dependen de datos de blockchain para alertas, dashboards, toma de decisiones o el desarrollo de nuevas funcionalidades. Es fundamental para Web3 ya que impulsa todo, desde aplicaciones descentralizadas hasta infraestructura y NFTs. Esta guía cubrirá todos los aspectos de los datos de blockchain, desde datos onchain y offchain hasta indexación de blockchain y subgraphs. Al final de esta guía deberías tener una comprensión más profunda de cómo se crean, almacenan y acceden los datos de blockchain. ## **¿Qué son los datos onchain?** Los datos onchain son simplemente toda la información almacenada en una red de blockchain. Es el registro inmutable de todas las transacciones que han ocurrido en la red y está disponible públicamente para que cualquiera lo vea. Existen muchos tipos diferentes de datos onchain, tales como: - **Datos de transacción:** cubre información sobre cada transacción en la blockchain, como el emisor y receptor, el valor de la transferencia y las comisiones de transacción. - Datos de bloque: cubre información sobre cada bloque en la blockchain, como el hash del bloque anterior, las transacciones incluidas en el bloque, la marca de tiempo del bloque, así como las comisiones y recompensas del minero. - **Datos de smart contract:** cubre información sobre todos los smart contracts que se han desplegado en la blockchain, como el código del contrato en sí, el estado del contrato y los eventos emitidos por el contrato. A diferencia de los datos offchain, los datos onchain no se pueden alterar, lo cual es importante para obtener una vista integral de una red de blockchain. Estos datos se pueden usar para rastrear el movimiento de activos en una blockchain, verificar que las transacciones se hayan completado exitosamente y generar información sobre la actividad de la red. El desafío con los datos onchain es que acceder a ellos de manera efectiva puede ser complicado. A pesar de estar fácilmente disponibles, los datos onchain están codificados en un formato legible por máquina; esto prioriza la seguridad pero sacrifica la legibilidad humana. Los formatos legibles por humanos pueden ser tipos como JSON y XML, y es aquí donde entran en juego los ABIs \(application binary interfaces\). ### **¿Cómo se definen las estructuras de datos?** Como se mencionó anteriormente, los datos onchain no se almacenan como datos regulares. En cambio, a menudo se almacenan en formatos legibles por máquina como bytecode. Los ABIs \(application binary interfaces\) ayudan a los desarrolladores a monitorear y decodificar los datos a un formato legible por humanos. Las estructuras de datos en los smart contracts se definen usando el ABI. El ABI actúa como un selector de funciones que ayuda a definir cómo interactuar con los smart contracts, así como los tipos de datos que cada función acepta y retorna. En otras palabras, es una forma estándar de representar estructuras de datos de manera que sea fácilmente entendida tanto por humanos como por máquinas. ### **¿Dónde se almacenan los datos de blockchain?** Los datos de blockchain generalmente se almacenan en un ledger distribuido, lo que significa que no se almacenan en una sola ubicación sino en una red de nodos. Los nodos son un componente fundamental para almacenar y garantizar la seguridad de los datos de blockchain, ya que cada nodo mantiene una copia de los datos. A continuación se describen algunos tipos diferentes de nodos y cómo funcionan a un alto nivel: - Full nodes: como su nombre lo indica, los full nodes almacenan todo el historial de la blockchain así como el estado más reciente de la red \(los últimos 128 bloques\). El estado más reciente es lo que todos los clientes necesitan para verificar las transacciones entrantes. Todos los estados anteriores pueden teóricamente derivarse de un full node, sin embargo, esto usa una cantidad significativa de poder computacional. Los desarrolladores deberían consultar full nodes para obtener datos cuando necesiten acceder a los datos y el estado más recientes de la blockchain. Como contexto, en Ethereum el tiempo promedio para producir un nuevo bloque es de aproximadamente 13 segundos, por lo que solo se pueden recuperar los estados de la cadena de los últimos 28-29 minutos. - Archive nodes: además del historial completo de la blockchain, [los archive nodes también mantienen un registro del estado histórico de cada bloque](https://www.alchemy.com/overviews/archive-nodes). Esto permite que los archive nodes atiendan solicitudes de datos históricos de manera mucho más eficiente en comparación con los full nodes. Los desarrolladores deberían consultar archive nodes cuando se necesiten datos históricos, ya que no requiere la regeneración del estado como sí lo hacen los full nodes. Para desarrolladores que crean herramientas de análisis y otras herramientas que requieren acceso rápido al historial, los archive nodes son ideales. - Light nodes: estos nodos son aquellos que solo almacenan los headers de bloque; los datos mínimos necesarios para transaccionar en la red. Los desarrolladores pueden optar por consultar light nodes al recuperar datos básicos de blockchain a partir de los headers de bloque. Los nodos no son la única forma de almacenar datos. Los datos también se pueden almacenar offchain en bases de datos, servicios de almacenamiento en la nube, o incluso en servidores on-premise. Almacenar datos offchain puede no ser tan seguro como onchain, sin embargo, sigue siendo útil para muchas aplicaciones ya que es más barato y rápido de acceder. Cuando los datos se almacenan offchain, típicamente solo se almacena en la blockchain la información necesaria para localizar los datos offchain. ### Smart contracts y almacenamiento de blockchain Los smart contracts se almacenan en la blockchain dentro de los nodos, sin embargo, los smart contracts en sí mismos tienen mecanismos para el almacenamiento de datos. Los datos se almacenan en los smart contracts en algo llamado contract storage layout. [El contract storage layout se refiere a las reglas que rigen cómo se organizan las variables de almacenamiento de los contratos en la memoria a largo plazo](https://www.alchemy.com/docs/smart-contract-storage-layout). Para [Solidity](https://www.alchemy.com/overviews/solidity) \(un lenguaje de programación de alto nivel para construir smart contracts\), existen 3 tipos diferentes de memoria que pueden indicarle al EVM dónde almacenar sus variables: memory, calldata y storage. Memory: se usa para almacenar datos temporales necesarios durante la ejecución de una función Calldata: es una ubicación de datos especial que contiene los argumentos de la función Storage: es donde los datos se almacenan de forma permanente en la blockchain ### **Almacenamiento de datos vs. almacenamiento de archivos** El almacenamiento de datos, en su forma más simple, es el proceso de guardar datos para que puedan recuperarse y usarse posteriormente. El almacenamiento de archivos, por otro lado, es distinto del almacenamiento de datos cuando los archivos reales se almacenan en una ubicación diferente a los metadatos sobre los archivos. Esta separación típicamente se realiza para mejorar el rendimiento, reducir costos o mejorar la seguridad. Una forma común de separar el almacenamiento de archivos del almacenamiento de datos es usando un sistema de almacenamiento de archivos descentralizado como IPFS o Arweave. Estos sistemas permiten a los usuarios almacenar archivos en una red distribuida de computadoras y pueden ser rentables al reducir la cantidad de datos que necesitan almacenarse en la blockchain misma. A un alto nivel, los metadatos sobre el archivo se almacenan onchain, mientras que el archivo en sí se almacena offchain. Cuando una aplicación necesita acceder al archivo, puede recuperar la URL de IPFS o Arweave desde los metadatos. La aplicación puede entonces usar esta URL para descargar el archivo desde IPFS o Arweave. #### **¿Qué es IPFS?** IPFS usa un sistema de direccionamiento por contenido donde cada archivo se identifica en base a un CID \(content identifier\). Los CIDs son hashes únicos que siempre hacen referencia al mismo archivo, sin importar dónde esté almacenado. Esto significa que si el archivo cambia o se actualiza, el hash también cambiará. Este sistema de direccionamiento por contenido permite que los archivos se almacenen y recuperen en base a su CID, en lugar de su ubicación. El flujo general de cómo funciona IPFS es el siguiente: 1. Se crea un CID para el archivo 1. El archivo luego se sube a la red IPFS 1. IPFS almacena información sobre qué nodo en la red posee el archivo asociado con el CID en una DHT \(distributed hash table\) 1. Luego se puede consultar la DHT con el hash para encontrar el nodo que almacena el archivo 1. El CID se almacena en el smart contract del token #### **Arweave** Arweave es otra solución de almacenamiento distribuido que también usa CIDs para almacenar y acceder al contenido, así como para referenciar contenido en los metadatos. La principal diferencia es que Arweave adopta un enfoque diferente en cuanto a incentivos y permanencia al incentivar a los nodos a mantener los datos de forma permanente. ### **Publicación de datos vs. almacenamiento de datos vs. disponibilidad de datos** Para comprender mejor los datos de blockchain, también debemos entender qué significan la publicación de datos, el almacenamiento y la disponibilidad. Para definir estos términos de forma simple: la **publicación de datos** es el proceso de hacer que los datos estén disponibles para otros en una blockchain, el **almacenamiento de datos** es el proceso de mantener los datos en una blockchain, y la **disponibilidad de datos** es la garantía de que los datos puedan ser accedidos por todos los participantes de una red de blockchain. La disponibilidad de datos es importante porque cuando los validadores agregan bloques a la blockchain de Ethereum, deben transmitir todos los datos de transacción de ese bloque a los demás validadores de la red. Los validadores tienen la tarea de ejecutar todos los datos de transacción, lo que significa que las blockchains solo pueden manejar tantas transacciones como sus validadores puedan ejecutar; esto, en pocas palabras, describe el problema de la disponibilidad de datos. Uno de los problemas centrales de disponibilidad de datos es saber si un bloque fue publicado o no sin tener acceso al bloque completo \(publicación de datos\). Los principales desafíos con la publicación de datos son que los productores de bloques no producirán bloques encima de bloques que contengan contenido desconocido. Esto significa que los bloques con datos no publicados pueden ser ignorados por completo. El almacenamiento de datos entra en escena una vez que los datos se publican, sin embargo, no está claro cuánto tiempo los full nodes almacenarán los datos. Esto puede ser preocupante ya que no podemos obligar a los nodos a conservar los datos, lo que agrega más preocupaciones respecto a la disponibilidad de datos. #### Blockchains modulares y disponibilidad de datos alternativa Las blockchains modulares son blockchains que abordan funciones específicas. Por ejemplo, una blockchain modular puede enfocarse en la disponibilidad de datos mientras depende de otras blockchains o sistemas para otras tareas como la ejecución o el consenso. Las blockchains modulares crean capas alternativas de disponibilidad de datos para hacer que publicar calldata sea más económico que publicarlo en Ethereum, usando una variedad de técnicas como el almacenamiento de datos offchain, la compresión de datos, el sharding y más. Un ejemplo de una blockchain modular que usa una capa alternativa de disponibilidad de datos es EigenDA. EigenDA es una capa de disponibilidad de datos descentralizada construida sobre Arweave. EigenDA permite a los usuarios publicar calldata en Arweave y luego demostrarle a Ethereum que el calldata ha sido publicado. Esto permite a los usuarios publicar calldata en Ethereum sin tener que pagar las altas comisiones de gas asociadas con almacenar calldata onchain. ### **Tipos de datos onchain** Ahora que hemos cubierto qué son los datos onchain, profundizaremos en los diferentes tipos de datos onchain y cómo se generan, almacenan y acceden. #### **¿Qué son los datos de transacción?** Los datos de transacción contienen toda la información relacionada con una transacción en la blockchain, tales como: - Emisor - Receptor - Monto de la transferencia - Comisión de transacción - Marca de tiempo de la transacción Estos datos se generan cada vez que un usuario realiza una transacción en una blockchain. Luego se transmiten a los nodos de la red para validar la transacción y agregarla al ledger. Los datos de transacción pueden almacenarse y verificarse mediante un tipo de estructura de datos en árbol llamada Merkle trees. Los Merkle trees son árboles binarios que permiten una verificación rápida de datos, donde cada nodo del árbol es un hash de los datos que contiene. Para verificar la integridad de los datos en un Merkle tree, solo se necesita el hash raíz del árbol. Almacenar datos en Merkle trees es útil para mantener el tamaño de la blockchain lo más pequeño posible. Dado que hay mucho más detalle que se puede profundizar sobre los Merkle trees, puedes leer [más sobre Merkle trees en la documentación de Alchemy](https://www.alchemy.com/docs/merkle-trees-in-blockchains). Para Ethereum en particular, los datos se almacenan usando [Patricia Merkle Tries](https://www.alchemy.com/docs/patricia-merkle-tries): una combinación de un radix trie \(Patricia trie\) y un Merkle tree. Cuando se trata de acceder rápidamente a los datos de transacción, simplemente puedes usar un explorador de blockchain como [Etherscan](https://www.alchemy.com/dapps/etherscan) para transacciones de Ethereum. Los exploradores de blockchain permiten a los usuarios ver y buscar todos los datos de transacción y pueden usarse para rastrear el movimiento de tokens, identificar transacciones fraudulentas, desarrollar aplicaciones de blockchain, y más. Para encontrar datos sobre una transacción específica, necesitarás el hash de la transacción. Si necesitas acceder rutinariamente a datos de blockchain para tu aplicación, Alchemy puede ayudarte. #### **Metadatos** Los metadatos son datos que proporcionan información adicional sobre las transacciones y activos en una blockchain. Esto podría incluir detalles adicionales como: - el nombre o símbolo de un activo - el suministro total de un activo - el historial de propiedad de un activo - la dirección del contrato de un activo A diferencia de los datos de transacción, los metadatos no son esenciales para el funcionamiento de una blockchain, pero son útiles para los desarrolladores al crear aplicaciones como exploradores de bloques, wallets y dashboards, por nombrar algunos ejemplos. Los metadatos pueden generarse automáticamente según lo definido por el smart contract o la blockchain \(por ejemplo, metadatos de transacción\), o manualmente según lo defina un usuario \(por ejemplo, metadatos de activos\). Para acceder a los metadatos, los desarrolladores pueden usar consultas **getMetadata**. Para usar estas consultas, los desarrolladores necesitan usar una API de blockchain como la [Alchemy API](https://www.alchemy.com/docs/reference/nft-api-quickstart). Al usar consultas **getMetadata**, los desarrolladores pueden construir una variedad de aplicaciones que pueden ayudar a los usuarios a entender e interactuar con las redes de blockchain. #### **Datos de eventos** Los datos de eventos se refieren a los datos que emiten los smart contracts cuando ejecutan transacciones. Estos datos pueden incluir información como: - El tipo de evento que ocurrió - La dirección del smart contract que emitió el evento - Detalles sobre el evento \(por ejemplo, la cantidad de tokens transferidos, el nuevo propietario del activo, etc.\) Esta información es útil para permitir a los desarrolladores monitorear la actividad de un smart contract y se puede acceder a ella a través de logs. Los logs son registros de todos los eventos que han ocurrido en una blockchain y son generados por los smart contracts. Estos logs se pueden encontrar en los recibos de transacción y se pueden ver haciendo una solicitud a [eth_getLogs](https://www.alchemy.com/docs/deep-dive-into-eth_getlogs). #### **Calldata** Calldata son los datos que se pasan a un smart contract cuando se llama a una función. En otras palabras, es una forma de almacenamiento temporal de datos donde se guardan los argumentos de la función provenientes de un llamador externo antes de pasarlos al smart contract. Calldata puede contener cualquier tipo de dato, ya sean enteros, strings, arrays y más. Es importante porque permite que los smart contracts se comuniquen entre sí y con los usuarios; por ejemplo, calldata podría usarse para transferir la propiedad de un NFT a un usuario en un smart contract de NFT. Se cobran comisiones de gas por todas las operaciones en la blockchain y el uso de calldata no es la excepción. Cuando una transacción de L2 se publica en Ethereum, el calldata se incluye en la transacción. Esto se debe a que el calldata es necesario para que la red de Ethereum verifique la transacción y ejecute la función del smart contract que se está llamando. El gas usado por el calldata está determinado por el tamaño del calldata y el tipo de datos que contiene. Para Ethereum, el calldata máximo que puede contener cada bloque es de [1,048,576 bytes](https://eips.ethereum.org/EIPS/eip-4488). #### **Blobs** Los blobs \(binary large objects\) están diseñados para hacer más eficiente la verificación de transacciones al hacer que la red confirme que el blob adjunto a un bloque contiene los datos correctos. Los blobs se introdujeron en relación con el [proto-danksharding](https://www.alchemy.com/overviews/danksharding), una propuesta para reducir los costos de calldata y aumentar el tamaño de calldata por bloque. Se dice que el proto-danksharding hace que el calldata sea más económico en blockchain al introducir un nuevo tipo de transacción llamado transacción blob-carrying. Las transacciones blob-carrying son similares a las transacciones regulares, pero pueden contener blobs de datos. Las transacciones blob-carrying son más económicas que las transacciones regulares porque no requieren tanto gas para procesarse. Esto se debe a que los blobs de datos se almacenan offchain y no necesitan incluirse en la transacción. La introducción de los blobs de datos y las transacciones blob-carrying hará posible almacenar y procesar grandes cantidades de datos en la blockchain de Ethereum de manera más económica. ## **¿Qué es la indexación de blockchain?** Un índice en un libro contiene los números de página donde se mencionan palabras clave e ideas. De manera similar, la indexación de blockchain es el proceso de organizar y almacenar datos de blockchain de una manera que facilite su búsqueda y consulta. Esto es importante de entender cuando se trata de datos de blockchain porque permite a los usuarios acceder y analizar los datos de una manera más eficiente y efectiva. Dado que las blockchains siguen una estructura ordenada temporalmente, los datos pueden estar dispersos en numerosos bloques y pueden volverse entrelazados. La indexación busca resolver este problema creando un índice de *datos* de blockchain. Este índice es una base de datos que almacena un subconjunto de los datos de blockchain de una manera optimizada para la búsqueda y consulta. Para indexar los datos, existen múltiples métodos de indexación diferentes, como: indexar información relacionada con transacciones, indexar direcciones, indexar interacciones con smart contracts, y más. Luego, los desarrolladores pueden acceder a los datos indexados a través de APIs proporcionadas por GraphQL, Alchemy y otros protocolos Web3. ### **Casos de uso comunes de indexación** Ahora que sabemos qué tan útil es la indexación de blockchain para que los desarrolladores busquen y consulten datos de manera más eficiente, veamos algunos casos de uso comunes de la indexación. **Indexación del historial de transacciones**: esto se puede usar para rastrear el volumen de trading y la liquidez de cosas como el pool de [Uniswap](https://www.alchemy.com/dapps/uniswap), así como para identificar a los traders más grandes y las ballenas. **Indexación para análisis y reportes**: esto se puede usar para generar reportes sobre varias métricas como el volumen de transacciones, las comisiones de gas y la actividad de usuarios. Puede ser especialmente útil al rastrear y analizar el rendimiento de un smart contract particular, criptomoneda, tendencia de mercado, o para entender la actividad de usuarios \(por ejemplo, número de wallets activas, número de transacciones procesadas, etc.\) **Indexación de metadatos**: esto se puede usar para rastrear la propiedad y transferencia de NFTs. Un ejemplo práctico de esto podría ser una herramienta de análisis de NFT donde puedes consultar un índice de transacciones para una colección de NFT específica para entender el historial de compra/propiedad, entre otros detalles relevantes. **Indexación de eventos de smart contracts**: esto se puede usar para rastrear el movimiento de tokens \(por ejemplo, eventos de transferencia de un token ERC-20 particular\), la actividad de préstamos y garantías, o para comprender mejor el [mercado de NFT](https://www.alchemy.com/dapps/best/nft-marketplaces), por nombrar algunos ejemplos específicos. En general, indexar eventos de smart contracts nos ayuda a monitorear la actividad de los smart contracts, lo que puede ayudar a identificar debilidades o incluso oportunidades para nuevas aplicaciones y servicios. #### **Índices offchain y onchain** Los índices pueden almacenarse onchain u offchain, cada uno con sus propios beneficios y compensaciones. Satsuma, por ejemplo, es un protocolo de indexación onchain adquirido por Alchemy. Satsuma usa [GraphQL](https://www.alchemy.com/dapps/graphql), un lenguaje de consulta para APIs, y funciona usando subgraphs que escanean bloques de red y smart contracts para recopilar datos de varias fuentes en una sola llamada a la API. Los protocolos de indexación offchain funcionan ya sea guardando índices en el almacenamiento local de un nodo \(por ejemplo, SubQuery\) o almacenándolos en servidores en la nube tradicionales como AWS, lo cual puede ser más rápido que la indexación onchain. Con protocolos de indexación tanto offchain como onchain, los desarrolladores pueden usar fácilmente lenguajes de consulta: - **GraphQL**: un desarrollador podría usar GraphQL para consultar subgraphs en busca del historial de transferencias de un token ERC20 particular. - SQL: un desarrollador podría usar SQL para consultar un índice offchain en busca de la lista de todos los smart contracts que se han desplegado en una blockchain particular. - Elasticsearch: un desarrollador podría usar Elasticsearch para consultar un índice offchain en busca de los NFTs más populares en una blockchain particular. ## **¿Cómo se accede a los datos de blockchain?** Ahora que hemos aprendido un poco sobre los datos onchain y cómo se almacenan, podemos profundizar en cómo los desarrolladores pueden acceder realmente a los datos de blockchain. ### **Consultar nodos** Una de las formas más directas de acceder a los datos de blockchain es consultando nodos, sin embargo, esto también puede ser lo más intensivo en recursos. Para consultar nodos, debes usar JSON-RPC para acceder a los datos a través de full nodes o archive nodes \(nodos que contienen una copia completa de la blockchain, como se discutió anteriormente\). Para consultar un nodo usando JSON-RPC, los desarrolladores deben enviar un objeto JSON al nodo que contenga el método que se desea llamar, los parámetros para el método y la versión de JSON-RPC. Esto se puede hacer fácilmente a través de soluciones como Alchemy que proporcionan una API JSON-RPC que se puede usar para consultar nodos. Los filtros de eventos también pueden ser útiles al consultar nodos en busca de eventos específicos de blockchain. Para usar un filtro de eventos, debes especificar el tipo de evento que deseas filtrar y los parámetros del evento. Una manera fácil de usar filtros de eventos es a través de la [Node API de Alchemy](https://www.alchemy.com/supernode). La Node API de Alchemy es un servicio totalmente gestionado que incluye toda la infraestructura para ejecutar un nodo, así como APIs y SDKs que facilitan la interacción y consulta de nodos. ### **Transmisión de datos con webhooks** Transmitir datos con webhooks es una forma de recibir actualizaciones en tiempo real sobre los datos de blockchain. Los datos de eventos se pueden transmitir usando webhooks personalizados y variables de webhook. Esto se hace eligiendo un servicio de indexación de blockchain como Alchemy, creando un endpoint de webhook en tu servidor, suscribiéndote a los eventos, y configurando las variables de webhook. Alchemy en particular permite a los usuarios crear [webhooks personalizados](https://www.alchemy.com/docs/reference/custom-webhook-variables) que pueden activarse por una variedad de eventos de blockchain, como nuevas transacciones, nuevos despliegues de smart contracts, y cambios en el estado de smart contracts. Alchemy también ha [actualizado recientemente sus webhooks personalizados](https://www.alchemy.com/blog/custom-webhooks-variables-filters-block-freshness) para ayudar a los desarrolladores a acotar los flujos de datos para mayor precisión, y actualizar fácilmente las consultas de webhook usando variables. ### **Consultar Subgraphs** Los subgraphs son APIs de código abierto creadas por la comunidad y se usan para recuperar datos de blockchain de Indexers, Curators y Delegators. Dado que los subgraphs se construyen usando GraphQL, los desarrolladores pueden usar la API de GraphQL para consultar el subgraph. Los subgraphs pueden ser hosted o self-hosted. Los subgraphs hosted se pueden consultar enviando una consulta GraphQL a la URL de la API de GraphQL. Los subgraphs self-hosted se pueden consultar desplegando el subgraph en el servidor de GraphQL. Esto se puede hacer a través de soluciones como Satsuma que permiten a los desarrolladores desplegar sus propios subgraphs. ### **Consultar data warehouses** Los data warehouses están optimizados para consultar datos históricos, generalmente en un formato estructurado. Los data lakes, por otro lado, almacenan grandes cantidades de datos que típicamente no están estructurados o están semi-estructurados. [Dune Analytics](https://www.alchemy.com/dapps/dune-analytics) es una herramienta que se puede usar para consultar, extraer y visualizar datos de data lakes. Dune hace esto proporcionando herramientas como su explorador de datasets, permitiéndote explorar datos en diferentes chains, datasets, datos crudos de blockchain, y más. También puedes crear tu propio data lake haciendo un backfill de una base de datos y transmitiendo datos a través de webhooks personalizados. ## **Conclusión** En resumen, entender los datos de blockchain es útil para cualquier desarrollador que busque usar o construir infraestructura o aplicaciones Web3. Los datos onchain se almacenan en la blockchain y pueden desglosarse en diferentes tipos como datos de transacción, metadatos, datos de eventos, calldata y blobs. Estos datos luego se almacenan en nodos y se pueden acceder de diversas maneras dependiendo del caso de uso de cada quien.