Uma análise profunda dos dados de blockchain

Cada Blockchain mantém um registro imutável de transações e eventos. Aplicações Web3 dependem de dados de blockchain para alertas, dashboards, tomada de decisão ou criação de novas funcionalidades. Isso é essencial para o Web3, pois viabiliza tudo, desde aplicações descentralizadas até infraestrutura e NFTs.

Este guia abordará todos os aspectos dos dados de blockchain, desde dados onchain e offchain até indexação de blockchain e subgraphs. Ao final deste guia, você terá um entendimento mais profundo de como os dados de blockchain são criados, armazenados e acessados.

O que são dados onchain?

Dados onchain são simplesmente todas as informações armazenadas em uma rede blockchain. É o registro imutável de todas as transações que já ocorreram na rede e está publicamente disponível para todos verem. Existem muitos tipos diferentes de dados onchain, tais como:

• Dados de transação: cobrem informações sobre cada transação na blockchain, como remetente e destinatário, valor da transferência e taxas de transação.
• Dados de bloco: cobrem informações sobre cada bloco na blockchain, como o hash do bloco anterior, as transações incluídas no bloco, o timestamp do bloco, além das taxas e recompensas do minerador.
• Dados de smart contract: cobrem informações sobre todos os smart contracts implantados na blockchain, como o próprio código do contrato, o estado do contrato e os eventos emitidos pelo contrato.

Diferente dos dados offchain, os dados onchain não podem ser alterados, o que é importante para obter uma visão completa de uma rede blockchain. Esses dados podem ser usados para rastrear a movimentação de ativos em uma blockchain, verificar se as transações foram concluídas com sucesso e gerar insights sobre a atividade da rede.

O desafio com dados onchain é que acessá-los de forma eficaz pode ser trabalhoso. Apesar de estarem prontamente disponíveis, os dados onchain são codificados em um formato legível por máquina; isso prioriza a segurança, mas sacrifica a legibilidade humana. Formatos legíveis por humanos podem ser tipos como JSON e XML, e é aí que entram as ABIs (application binary interfaces).

Como as estruturas de dados são definidas?

Como mencionado anteriormente, os dados onchain não são armazenados como dados comuns. Em vez disso, geralmente são armazenados em formatos legíveis por máquina, como bytecode.

As ABIs (application binary interfaces) ajudam os desenvolvedores a monitorar e decodificar os dados para um formato legível por humanos. As estruturas de dados em smart contracts são definidas usando a ABI. A ABI atua como um seletor de função que ajuda a definir como interagir com smart contracts, bem como os tipos de dados que cada função aceita e retorna. Em outras palavras, é uma forma padronizada de representar estruturas de dados de maneira facilmente compreendida tanto por humanos quanto por máquinas.

Onde os dados de blockchain são armazenados?

Os dados de blockchain geralmente são armazenados em um ledger distribuído, ou seja, não ficam em um único local, mas sim em uma rede de nodes. Os nodes são um componente fundamental para armazenar e garantir a segurança dos dados de blockchain, já que cada node mantém uma cópia dos dados. Abaixo estão descritos alguns tipos diferentes de nodes e como funcionam em linhas gerais:

• Full nodes: como o nome sugere, os full nodes armazenam o histórico completo da blockchain, além do estado mais recente da rede (os últimos 128 blocos). O estado mais recente é o que todos os clientes precisam para verificar transações recebidas. Todos os estados anteriores podem, teoricamente, ser derivados de um full node, porém isso exige uma quantidade significativa de poder computacional. Os desenvolvedores devem consultar full nodes para obter dados quando precisam acessar o estado e os dados mais recentes da blockchain. Para contextualizar, na Ethereum o tempo médio para produzir um novo bloco é de cerca de 13 segundos, e você só consegue recuperar os estados da chain dos últimos 28-29 minutos.
• Archive nodes: além do histórico completo da blockchain, os archive nodes também mantêm um registro do estado histórico de cada bloco. Isso permite que os archive nodes atendam requisições de dados históricos de forma muito mais eficiente em comparação com os full nodes. Os desenvolvedores devem consultar archive nodes quando precisarem de dados históricos, já que isso não exige a regeneração de estado como nos full nodes. Para desenvolvedores que criam ferramentas de análise e outras ferramentas que exigem acesso rápido ao histórico, os archive nodes são ideais.
• Light nodes: esses nodes armazenam apenas os cabeçalhos de bloco; o mínimo de dados necessário para transacionar na rede. Os desenvolvedores podem optar por consultar light nodes ao recuperar dados básicos de blockchain a partir dos cabeçalhos de bloco.

Os nodes não são a única forma de armazenar dados. Os dados também podem ser armazenados offchain em bancos de dados, serviços de armazenamento em nuvem, ou até mesmo em servidores locais. Armazenar dados offchain pode não ser tão seguro quanto onchain, porém ainda é útil para muitas aplicações, pois é mais barato e rápido de acessar. Quando os dados são armazenados offchain, geralmente apenas as informações necessárias para localizar os dados offchain são armazenadas na blockchain.

Smart contracts e armazenamento em blockchain

Os smart contracts são armazenados na blockchain dentro de nodes, porém os próprios smart contracts têm mecanismos para armazenamento de dados. Os dados são armazenados em smart contracts em algo chamado contract storage layout. Contract storage layout se refere às regras que determinam como as variáveis de armazenamento dos contratos são organizadas na memória de longo prazo.

Para Solidity (uma linguagem de programação de alto nível para construir smart contracts), existem 3 tipos diferentes de memória que podem instruir a EVM sobre onde armazenar suas variáveis: memory, calldata e storage.

Memory: usada para armazenar dados temporários necessários durante a execução de uma função

Calldata: um local de dados especial que contém os argumentos da função

Storage: onde os dados são armazenados permanentemente na blockchain

Armazenamento de dados vs. armazenamento de arquivos

Armazenamento de dados, em sua forma mais simples, é o processo de salvar dados para que possam ser recuperados e usados posteriormente. Já o armazenamento de arquivos é separado do armazenamento de dados quando os arquivos propriamente ditos são armazenados em um local diferente dos metadados sobre os arquivos. Essa separação geralmente é feita para melhorar o desempenho, reduzir custos ou aumentar a segurança.

Uma forma comum de separar o armazenamento de arquivos do armazenamento de dados é usando um sistema de armazenamento de arquivos descentralizado, como IPFS ou Arweave. Esses sistemas permitem que os usuários armazenem arquivos em uma rede distribuída de computadores e podem ser mais econômicos ao reduzir a quantidade de dados que precisam ser armazenados na própria blockchain.

Em linhas gerais, os metadados sobre o arquivo são armazenados onchain, enquanto o arquivo em si é armazenado offchain. Quando uma aplicação precisa acessar o arquivo, ela pode recuperar a URL do IPFS ou Arweave a partir dos metadados. A aplicação pode então usar essa URL para baixar o arquivo do IPFS ou Arweave.

O que é IPFS?

O IPFS usa um sistema endereçado por conteúdo, onde cada arquivo é identificado com base em um CID (content identifier). Os CIDs são hashes únicos que sempre se referem ao mesmo arquivo, independente de onde ele esteja armazenado.

Isso significa que, se o arquivo mudar ou for atualizado, o hash também mudará. Esse sistema endereçado por conteúdo permite que os arquivos sejam armazenados e recuperados com base em seu CID, em vez de sua localização.

O fluxo geral de funcionamento do IPFS é o seguinte:

1. Um CID é criado para o arquivo
2. O arquivo é então enviado para a rede IPFS
3. O IPFS armazena informações sobre qual node da rede possui o arquivo associado ao CID em uma DHT (distributed hash table)
4. A DHT pode então ser consultada com o hash para encontrar o node que armazena o arquivo
5. O CID é armazenado no smart contract do token

Arweave

Arweave é outra solução de armazenamento distribuído que também usa CIDs para armazenar e acessar conteúdo, além de referenciar conteúdo em metadados. A principal diferença é que a Arweave adota uma abordagem diferente em relação a incentivos e permanência, incentivando os nodes a manter os dados permanentemente.

Publicação de dados vs. armazenamento de dados vs. disponibilidade de dados

Para entender melhor os dados de blockchain, também precisamos entender o que significam publicação de dados, armazenamento e disponibilidade. Para definir esses termos de forma simples: publicação de dados é o processo de tornar os dados disponíveis para outros em uma blockchain, armazenamento de dados é o processo de manter os dados em uma blockchain, e disponibilidade de dados é a garantia de que os dados podem ser acessados por todos os participantes de uma rede blockchain.

A disponibilidade de dados é importante porque, quando os validadores adicionam blocos à blockchain Ethereum, eles precisam transmitir todos os dados de transação daquele bloco para os outros validadores da rede. Os validadores têm a tarefa de executar todos os dados de transação, o que significa que as blockchains só conseguem processar tantas transações quanto seus validadores conseguem executar - isso, em resumo, descreve o problema da disponibilidade de dados.

Um dos principais problemas de disponibilidade de dados é saber se um bloco foi publicado ou não sem ter acesso ao bloco inteiro (publicação de dados).

Os principais desafios com a publicação de dados são que os produtores de blocos não produzirão blocos em cima de blocos que contenham conteúdo desconhecido. Isso significa que blocos com dados não publicados podem ser completamente ignorados. O armazenamento de dados entra em cena assim que os dados são publicados, porém não fica claro por quanto tempo os dados serão armazenados pelos full nodes. Isso pode ser preocupante, já que não podemos forçar os nodes a manter os dados, o que gera ainda mais preocupações em relação à disponibilidade de dados.

Blockchains modulares e disponibilidade de dados alternativa

Blockchains modulares são blockchains que tratam de funções específicas. Por exemplo, uma blockchain modular pode focar em disponibilidade de dados enquanto depende de outras blockchains ou sistemas para outras tarefas, como execução ou consenso.

As blockchains modulares criam camadas alternativas de disponibilidade de dados para tornar a publicação de calldata mais barata do que publicá-la na Ethereum, usando uma variedade de técnicas como armazenamento de dados offchain, compressão de dados, sharding, entre outras.

Um exemplo de blockchain modular que usa uma camada alternativa de disponibilidade de dados é a EigenDA. A EigenDA é uma camada de disponibilidade de dados descentralizada construída sobre a Arweave. A EigenDA permite que os usuários publiquem calldata na Arweave e depois provem à Ethereum que a calldata foi publicada. Isso permite que os usuários publiquem calldata para a Ethereum sem precisar pagar as altas taxas de gas associadas ao armazenamento de calldata onchain.

Tipos de dados onchain

Agora que já cobrimos o que são dados onchain, vamos nos aprofundar nos diferentes tipos de dados onchain e como eles são gerados, armazenados e acessados.

O que são dados de transação?

Os dados de transação contêm todas as informações relacionadas a uma transação na blockchain, tais como:

• Remetente
• Destinatário
• Valor da transferência
• Taxa de transação
• Timestamp da transação

Esses dados são gerados sempre que um usuário faz uma transação em uma blockchain. Eles são então transmitidos para os nodes da rede para validar a transação e adicioná-la ao ledger.

Os dados de transação podem ser armazenados e verificados por um tipo de estrutura de dados em árvore chamada Merkle tree. Merkle trees são árvores binárias que permitem verificação rápida de dados, onde cada node na árvore é um hash dos dados que contém. Para verificar a integridade dos dados em uma Merkle tree, basta ter o hash raiz da árvore. Armazenar dados em Merkle trees é útil para manter o tamanho da blockchain o menor possível. Como há muito mais detalhes sobre Merkle trees, você pode ler mais sobre Merkle trees na documentação da Alchemy. Para a Ethereum em particular, os dados são armazenados usando Patricia Merkle Tries - uma combinação de um radix trie (Patricia trie) e uma Merkle tree.

Quando se trata de acessar rapidamente dados de transação, você pode simplesmente usar um blockchain explorer como o Etherscan para transações na Ethereum. Os blockchain explorers permitem que os usuários visualizem e pesquisem todos os dados de transação e podem ser usados para rastrear a movimentação de tokens, identificar transações fraudulentas, desenvolver aplicações de blockchain, entre outros. Para encontrar dados sobre uma transação específica, você precisará do hash da transação. Se você precisa acessar dados de blockchain rotineiramente para sua aplicação, a Alchemy pode ajudar.

Metadados

Metadados são dados que fornecem informações adicionais sobre as transações e os ativos em uma blockchain. Isso pode incluir detalhes adicionais como:

• o nome ou símbolo de um ativo
• o supply total de um ativo
• o histórico de propriedade de um ativo
• o endereço do contrato de um ativo

Diferente dos dados de transação, os metadados não são essenciais para o funcionamento de uma blockchain, mas são úteis para os desenvolvedores na criação de aplicações como block explorers, wallets e dashboards, para citar alguns exemplos. Os metadados podem ser gerados automaticamente conforme definido pelo smart contract ou pela blockchain (por exemplo, metadados de transação), ou manualmente conforme definido por um usuário (por exemplo, metadados de ativos).

Para acessar metadados, os desenvolvedores podem usar queries getMetadata. Para usar essas queries, os desenvolvedores precisam usar uma API de blockchain como a Alchemy API. Usando queries getMetadata, os desenvolvedores podem construir uma variedade de aplicações que ajudam os usuários a entender e interagir com redes blockchain.

Dados de eventos

Dados de eventos referem-se aos dados emitidos por smart contracts quando eles executam transações. Esses dados podem incluir informações como:

• O tipo de evento que ocorreu
• O endereço do smart contract que emitiu o evento
• Detalhes sobre o evento (por exemplo, a quantidade de tokens transferidos, o novo proprietário do ativo, etc.)

Essas informações são úteis para permitir que os desenvolvedores monitorem a atividade de um smart contract e podem ser acessadas via logs. Logs são registros de todos os eventos que ocorreram em uma blockchain e são gerados por smart contracts. Esses logs podem ser encontrados em recibos de transação e podem ser visualizados fazendo uma requisição para eth_getLogs.

Calldata

Calldata são os dados passados para um smart contract quando uma função é chamada. Em outras palavras, é uma forma de armazenamento temporário de dados onde os argumentos da função vindos de um chamador externo são armazenados antes de serem passados para o smart contract. A calldata pode conter qualquer tipo de dado, seja inteiros, strings, arrays, entre outros. É importante porque permite que os smart contracts se comuniquem entre si e com os usuários; por exemplo, a calldata pode ser usada para transferir a propriedade de um NFT para um usuário em um smart contract de NFT.

Taxas de gas são cobradas para todas as operações na blockchain, e o uso de calldata não é exceção. Quando uma transação de L2 é publicada na Ethereum, a calldata é incluída na transação. Isso ocorre porque a calldata é necessária para que a rede Ethereum verifique a transação e execute a função do smart contract que está sendo chamada. O gas usado pela calldata é determinado pelo tamanho da calldata e pelo tipo de dado contido nela. Para a Ethereum, a calldata máxima que cada bloco pode conter é 1.048.576 bytes.

Blobs

Blobs (binary large objects) são projetados para tornar a verificação de transações mais eficiente, fazendo com que a rede confirme que o blob anexado a um bloco carrega os dados corretos. Os blobs foram introduzidos em relação ao proto-danksharding, uma proposta para reduzir os custos de calldata e aumentar o tamanho de calldata por bloco.

Diz-se que o proto-danksharding torna a calldata mais barata na blockchain ao introduzir um novo tipo de transação chamado blob-carrying transaction. As blob-carrying transactions são semelhantes a transações comuns, mas podem conter data blobs.

As blob-carrying transactions são mais baratas que as transações comuns porque não exigem tanto gas para serem processadas. Isso ocorre porque os data blobs são armazenados offchain e não precisam ser incluídos na transação.

A introdução dos data blobs e das blob-carrying transactions tornará possível armazenar e processar grandes quantidades de dados na blockchain Ethereum de forma mais barata.

O que é indexação de blockchain?

Um índice em um livro contém os números de página onde palavras-chave e ideias são mencionadas. De forma semelhante, a indexação de blockchain é o processo de organizar e armazenar dados de blockchain de uma forma que facilite a busca e a consulta. Isso é importante entender quando se trata de dados de blockchain, pois permite que os usuários acessem e analisem os dados de forma mais eficiente e eficaz.

Como as blockchains seguem uma estrutura ordenada por tempo, os dados podem estar espalhados por diversos blocos e ficar emaranhados. A indexação tem como objetivo resolver esse problema criando um índice de dados de blockchain.

Esse índice é um banco de dados que armazena um subconjunto dos dados de blockchain de uma forma otimizada para busca e consulta. Para indexar os dados, existem vários métodos de indexação diferentes, como: indexação de informações relacionadas a transações, indexação de endereços, indexação de interações com smart contracts, entre outros. Os dados indexados podem então ser acessados pelos desenvolvedores por meio de APIs fornecidas pelo GraphQL, Alchemy e outros protocolos Web3.

Casos de uso comuns de indexação

Agora que sabemos o quão útil a indexação de blockchain é para os desenvolvedores buscarem e consultarem dados de forma mais eficiente, vamos analisar alguns casos de uso comuns de indexação.

Indexação do histórico de transações - pode ser usada para rastrear o volume de negociação e a liquidez de coisas como o pool do Uniswap, bem como identificar os maiores traders e whales.

Indexação para analytics e relatórios - pode ser usada para gerar relatórios sobre várias métricas, como volume de transações, taxas de gas e atividade dos usuários. Pode ser especialmente útil ao rastrear e analisar o desempenho de um smart contract específico, criptomoeda, tendência de mercado, ou para entender a atividade dos usuários (por exemplo, número de wallets ativas, número de transações processadas, etc.)

Indexação de metadados - pode ser usada para rastrear a propriedade e a transferência de NFTs. Um exemplo prático disso pode ser uma ferramenta de análise de NFT onde você pode consultar um índice de transações de uma coleção de NFT específica para entender o histórico de compra/propriedade, entre outros detalhes relevantes.

Indexação de eventos de smart contracts - pode ser usada para rastrear a movimentação de tokens (por exemplo, eventos de transferência de um determinado token ERC-20), atividade de lending e borrowing, ou para entender melhor o mercado de NFT, para citar alguns exemplos específicos. No geral, a indexação de eventos de smart contracts nos ajuda a monitorar a atividade dos smart contracts, o que pode ajudar a identificar fraquezas ou até mesmo oportunidades para novas aplicações e serviços.

Índices offchain e onchain

Os índices podem ser armazenados onchain ou offchain, cada um com seus respectivos benefícios e tradeoffs. A Satsuma, por exemplo, é um protocolo de indexação onchain adquirido pela Alchemy. A Satsuma usa GraphQL, uma linguagem de consulta para APIs, e funciona usando subgraphs que escaneiam blocos da rede e smart contracts para coletar dados de várias fontes em uma única chamada de API. Os protocolos de indexação offchain funcionam salvando índices no armazenamento local de um node (por exemplo, SubQuery) ou armazenando-os em servidores de nuvem tradicionais como a AWS, o que pode ser mais rápido que a indexação onchain. Seja com protocolos de indexação offchain ou onchain, os desenvolvedores podem facilmente usar linguagens de consulta:

• GraphQL - um desenvolvedor poderia usar GraphQL para consultar subgraphs em busca do histórico de transferência de um determinado token ERC20.
• SQL - um desenvolvedor poderia usar SQL para consultar um índice offchain em busca da lista de todos os smart contracts implantados em uma determinada blockchain.
• Elasticsearch - um desenvolvedor poderia usar Elasticsearch para consultar um índice offchain em busca dos NFTs mais populares em uma determinada blockchain.

Como os dados de blockchain são acessados?

Agora que aprendemos um pouco sobre dados onchain e como eles são armazenados, podemos nos aprofundar em como os dados de blockchain podem realmente ser acessados pelos desenvolvedores.

Consultando nodes

Uma das formas mais diretas de acessar dados de blockchain é consultando nodes, porém isso também pode ser o mais custoso em termos de recursos.

Para consultar nodes, você precisa usar JSON-RPC para acessar os dados via full ou archive nodes (nodes que contêm uma cópia completa da blockchain, como discutido anteriormente). Para consultar um node usando JSON-RPC, os desenvolvedores precisam enviar um objeto JSON para o node contendo o método que deseja chamar, os parâmetros do método e a versão do JSON-RPC.

Isso pode ser feito facilmente por meio de soluções como a Alchemy, que fornece uma API JSON-RPC que pode ser usada para consultar nodes.

Filtros de eventos também podem ser úteis ao consultar nodes em busca de eventos específicos de blockchain. Para usar um filtro de eventos, você precisa especificar o tipo de evento que deseja filtrar e os parâmetros do evento. Uma forma fácil de usar filtros de eventos é por meio da Node API da Alchemy. A Node API da Alchemy é um serviço totalmente gerenciado que inclui toda a infraestrutura necessária para rodar um node, além de APIs e SDKs que facilitam a interação e a consulta de nodes.

Streaming de dados com webhooks

O streaming de dados com webhooks é uma forma de receber atualizações em tempo real sobre dados de blockchain. Dados de eventos podem ser transmitidos usando webhooks personalizados e variáveis de webhook. Isso é feito escolhendo um serviço de indexação de blockchain como a Alchemy, criando um endpoint de webhook em seu servidor, se inscrevendo nos eventos e configurando as variáveis de webhook. A Alchemy, em particular, permite que os usuários criem webhooks personalizados que podem ser acionados por uma variedade de eventos de blockchain, como novas transações, novas implantações de smart contracts e mudanças no estado de smart contracts. A Alchemy também atualizou recentemente seus webhooks personalizados para ajudar os desenvolvedores a refinar os fluxos de dados para maior precisão, e atualizar facilmente as queries de webhook usando variáveis.

Consultando Subgraphs

Subgraphs são APIs de código aberto criadas pela comunidade e usadas para recuperar dados de blockchain de Indexers, Curators e Delegators. Como os subgraphs são construídos usando GraphQL, os desenvolvedores podem usar a API GraphQL para consultar o subgraph. Os subgraphs podem ser hospedados ou auto-hospedados. Subgraphs hospedados podem ser consultados enviando uma query GraphQL para a URL da API GraphQL. Subgraphs auto-hospedados podem ser consultados implantando o subgraph no servidor GraphQL. Isso pode ser feito por meio de soluções como a Satsuma, que permitem que os desenvolvedores implantem seus próprios subgraphs.

Consultando data warehouses

Data warehouses são otimizados para consultar dados históricos, geralmente em um formato estruturado. Já os data lakes armazenam grandes quantidades de dados que costumam ser não estruturados ou semiestruturados. O Dune Analytics é uma ferramenta que pode ser usada para consultar, extrair e visualizar dados de data lakes. O Dune faz isso fornecendo ferramentas como seu dataset explorer, permitindo que você explore dados em diferentes chains, datasets, dados brutos de blockchain, entre outros. Você também pode criar seu próprio data lake fazendo o backfill de um banco de dados e transmitindo dados via webhooks personalizados.

Conclusão

Em resumo, entender os dados de blockchain é útil para qualquer desenvolvedor que queira usar ou construir infraestrutura ou aplicações Web3. Os dados onchain são armazenados na blockchain e podem ser divididos em diferentes tipos, como dados de transação, metadados, dados de eventos, calldata e blobs. Esses dados são então armazenados em nodes e podem ser acessados de várias formas, dependendo do caso de uso de cada um.