Do blockchain ao LLM, uma interpretação aprofundada da evolução e dos desafios da tecnologia de indexação de dados

Desde que Satoshi Nakamoto decidiu incorporar uma mensagem no bloco genesis, a estrutura de dados da cadeia Bitcoin passou por uma série de mudanças.

Comecei a estudar o desenvolvimento de blockchain em profundidade em 2022, e o primeiro livro que li foi "Mastering Ethereum". Este livro é excelente e me forneceu uma compreensão profunda dos fundamentos do Ethereum e do Blockchain. No entanto, da perspectiva de hoje, algumas das técnicas de desenvolvimento do livro tornaram-se um tanto desatualizadas. As etapas preliminares envolvem a execução de um nó em um laptop pessoal, mesmo para a carteira dApp, exigindo que um nó leve seja baixado por conta própria. Isso reflete o padrão de comportamento dos primeiros desenvolvedores e hackers no ecossistema de desenvolvimento de blockchain entre 2015 e 2018.

Em 2017, não tínhamos nenhum provedor de serviços de nó. Do ponto de vista da oferta e demanda, sua principal função é realizar transações devido à atividade limitada do usuário. Isso significa que manter ou hospedar um nó completo por conta própria não é um fardo muito grande, pois não há muitas solicitações de RPC para processar e as solicitações de transferência são pouco frequentes. A maioria dos primeiros usuários do Ethereum são geeks de tecnologia. Esses primeiros usuários têm uma compreensão profunda do desenvolvimento de blockchain e são usados para manter diretamente os nós Ethereum, criar transações e gerenciar contas por meio da linha de comando ou ambiente de desenvolvimento integrado.

Portanto, podemos observar que os primeiros projetos costumam ter uma UI/UX muito limpa. Alguns desses projetos nem sequer têm um front-end e a atividade do usuário é bastante baixa. As características desses projetos são determinadas principalmente por dois fatores: o comportamento do usuário e a estrutura de dados da cadeia.

A ascensão dos provedores de nós

À medida que mais e mais usuários sem experiência em programação ingressam na rede blockchain, a arquitetura técnica dos aplicativos descentralizados também mudou. O modo original de hospedagem de nós pelos usuários mudou gradualmente para hospedagem de nós pelas partes do projeto

As pessoas tendem a escolher os serviços de hospedagem de nós, principalmente porque o rápido crescimento dos dados na cadeia faz com que o custo dos nós de hospedagem pessoal aumente gradualmente com o tempo.

No entanto, a auto-hospedagem de nós pelas equipes de projeto continua sendo um desafio para desenvolvedores de pequenos projetos, exigindo investimento contínuo em manutenção e custos de hardware. Portanto, esse complexo processo de hospedagem de nós geralmente é confiado a empresas especializadas em manutenção de nós. Vale a pena mencionar que o momento da construção em larga escala e captação de recursos dessas empresas coincide com a tendência crescente de serviços em nuvem na indústria de tecnologia norte-americana.

| Projeto | Categoria | Estabelecido desde | | --- | --- | --- | | Alquimia | Nós | 2017 | | Infura | Nós | 2016 | | AgoraNós | Nós | 2019 | | QuickNodes | Nós | 2017 | | âncora | nós | 2017 | | ChainStack | Nós | 2018 |

Simplesmente hospedar nós remotamente não pode resolver completamente o problema, especialmente agora que protocolos relacionados, como DeFi e NFT, estão surgindo. Os desenvolvedores precisam lidar com muitos problemas de dados, porque os dados fornecidos pelos próprios nós da blockchain são chamados de dados brutos, que não são padronizados e limpos. Os dados nele precisam ser extraídos, limpos e carregados.

Por exemplo, suponha que eu seja um desenvolvedor de um projeto NFT e queira realizar transações NFT ou exibir NFTs. Então, meu front-end precisa ler os dados NFT na conta EOA pessoal em tempo real. NFT é realmente apenas uma forma padronizada de token. Possuir um NFT significa que possuo um token com um ID exclusivo gerado pelo contrato NFT, e a imagem do NFT é na verdade metadados, que podem ser dados SVG ou um link para uma imagem no IPFS. Embora o cliente Geth da Ethereum forneça instruções de indexação, para alguns projetos com grandes requisitos de front-end, é impraticável solicitar Geth continuamente e depois retornar ao front-end. Para algumas funções, como leilão de pedidos e agregação de transações NFT, elas devem ser realizadas fora da cadeia para coletar instruções do usuário e, em seguida, enviar essas instruções à cadeia no momento apropriado.

Portanto, uma camada de dados simples nasceu. Para atender aos requisitos de tempo real e precisão dos usuários, a parte do projeto precisa construir seu próprio banco de dados e funções de análise de dados.

**Como evoluiu o indexador de dados? **

Começar um projeto geralmente é um assunto relativamente simples. Você tem uma ideia, define algumas metas, encontra os melhores engenheiros e constrói um protótipo funcional, que geralmente inclui um front-end e alguns contratos inteligentes.

No entanto, é muito difícil fazer a escala do projeto. É preciso pensar profundamente sobre a estrutura do projeto desde o primeiro dia do projeto. Caso contrário, você pode ter problemas rapidamente, que geralmente chamo de "problemas de gelo".

Peguei emprestado esse termo do filme "Homem de Ferro" e parece ser muito adequado para descrever a situação da maioria das startups. Quando as startups crescem rapidamente (atraem muitos usuários), elas geralmente se deparam com problemas porque não previram isso em primeiro lugar. No filme, o vilão nunca esperou que seu equipamento de guerra voasse para o espaço porque ele não contava com o "problema do gelo". Da mesma forma, para desenvolvedores de muitos projetos Web3, o "problema de congelamento" envolve lidar com o aumento da carga de adoção em massa de usuários. Isso coloca uma forte pressão no lado do servidor, pois o número de usuários cresce dramaticamente. Também existem problemas relacionados ao próprio blockchain, como problemas de rede ou desligamentos de nós.

Na maioria das vezes é um problema de back-end. Por exemplo, em alguns protocolos de jogo blockchain, essa situação não é incomum. Quando planejaram adicionar mais servidores e contratar mais engenheiros de dados para analisar os dados na cadeia, não previram a participação de tantos usuários. Quando perceberam isso, já era tarde demais. E esses problemas técnicos não podem ser resolvidos apenas adicionando mais engenheiros de back-end. Como eu disse antes, essas considerações devem ser incorporadas ao plano desde o início.

O segundo problema envolve a adição de novos blockchains. Você provavelmente evitou problemas do lado do servidor em primeiro lugar e contratou um monte de bons engenheiros. No entanto, seus usuários podem não estar satisfeitos com o blockchain atual. Eles querem que seu serviço também seja executado em outras cadeias populares, como cadeias zk ou cadeias L2. A estrutura do seu projeto pode acabar ficando assim:

Nesse tipo de sistema, você tem total controle sobre seus dados, o que permite um melhor gerenciamento e maior segurança. O sistema limita as solicitações de chamadas, reduzindo o risco de sobrecarga e aumentando a eficiência. E a configuração é compatível com o front-end, garantindo integração perfeita e experiência do usuário.

No entanto, os custos de operação e manutenção se multiplicam, o que pode sobrecarregar seus recursos. Adicionar um novo blockchain a cada vez requer trabalho repetido, que pode ser demorado e ineficiente. A seleção de dados de grandes conjuntos de dados pode reduzir os tempos de consulta, tornando o processo mais lento. Devido a problemas de rede blockchain, como reversões e reorganizações, os dados podem ser corrompidos, comprometendo a integridade e a confiabilidade dos dados.

Os projetos são projetados para refletir os membros de sua equipe. Adicionar mais nós e tentar construir um sistema focado em back-end significa que você precisa contratar mais engenheiros para operar esses nós e decodificar os dados brutos.

Esse modelo é semelhante aos primeiros dias da Internet, quando plataformas de comércio eletrônico e desenvolvedores de aplicativos optaram por construir suas próprias instalações de IDC (Internet Data Center). No entanto, o custo anda de mãos dadas com a complexidade do projeto do programa à medida que as solicitações do usuário aumentam e o estado da rede blockchain explode. Além disso, esta abordagem impede a rápida expansão do mercado. Alguns blockchains públicos de alto desempenho exigem operações de nó intensivas em hardware, enquanto a sincronização e limpeza de dados consomem recursos humanos e custos de tempo.

Se você está tentando construir um mercado NFT baseado em blockchain ou um jogo legal, não é surpreendente que 65% dos membros de sua equipe sejam back-end e engenheiros de dados?

**Talvez os desenvolvedores se perguntem por que ninguém decodifica e transmite esses dados on-chain para eles, para que possam se concentrar na criação de produtos melhores. **

**Acredito que é por isso que os indexadores existem. **

Para reduzir a dificuldade de acessar aplicativos Web3 e redes blockchain, muitas equipes de desenvolvimento, incluindo nós, optam por integrar etapas como manutenção de nó de arquivo, ETL de dados on-chain (extrair, transformar, carregar) e chamadas de banco de dados. Essas tarefas originalmente exigiam que a equipe do projeto se mantivesse, mas agora eles realizaram operações integradas fornecendo dados de várias cadeias e APIs de nó.

Com a ajuda dessas APIs, os usuários podem personalizar os dados on-chain de acordo com suas necessidades. Isso abrange tudo, desde metadados NFT populares, monitoramento de atividades na cadeia de endereços específicos, até rastreamento de dados de transações de pools de liquidez de tokens específicos. Costumo me referir a essa abordagem como parte da estrutura dos projetos Web3 modernos.

O financiamento e a construção dos projetos da camada de dados e da camada de índice serão realizados principalmente em 2022. Acredito que as práticas de negócios desses projetos de camada de índice e camada de dados estão intimamente relacionadas ao design de sua arquitetura de dados subjacente, especialmente ao design de sistemas OLAP (On-Line Analytical Processing). Adotar um mecanismo de núcleo adequado é a chave para otimizar o desempenho da camada de índice, inclusive melhorando a velocidade de indexação e garantindo sua estabilidade. Os mecanismos comumente usados incluem Hive, Spark SQL, Presto, Kylin, Impala, Druid, ClickHouse, etc. Entre eles, o ClickHouse é um poderoso banco de dados amplamente utilizado em empresas de Internet, foi aberto em 2016 e recebeu um financiamento de 250 milhões de dólares americanos em 2021.

Portanto, o surgimento de uma nova geração de bancos de dados e arquiteturas aprimoradas de otimização de índice de dados levou à criação da camada de índice de dados Web3. Isso permite que as empresas desse campo forneçam serviços de API de dados de maneira mais rápida e eficiente.

No entanto, a construção da indexação de dados on-chain ainda está envolta em duas nuvens negras.

Duas Nuvens Negras

A primeira nuvem escura é sobre o impacto da estabilidade da rede blockchain no lado do servidor. Embora a rede blockchain tenha forte estabilidade, não é o caso durante a transmissão e processamento de dados. Por exemplo, eventos como reorganizações (reorgs) e reversões (rollbacks) do blockchain podem representar desafios para a estabilidade dos dados do indexador.

Uma reorganização da blockchain ocorre quando os nós perdem temporariamente a sincronização, fazendo com que duas versões diferentes da blockchain existam ao mesmo tempo. Tais situações podem ser desencadeadas por falhas do sistema, atrasos na rede ou até mesmo comportamento malicioso. Quando os nós forem sincronizados novamente, eles convergirão para uma única cadeia oficial e os blocos "bifurcados" alternativos anteriores serão descartados.

No momento em que ocorre a reorganização, o indexador pode ter processado dados de blocos que eventualmente foram descartados, poluindo o banco de dados. Portanto, os indexadores devem se adaptar a essa situação, descartando dados em cadeias inválidas e reprocessando dados em cadeias recém-aceitas.

Esses ajustes podem resultar em maior uso de recursos e potencialmente atrasar a disponibilidade de dados. Em casos extremos, reorganizações de blocos frequentes ou em grande escala podem afetar gravemente a confiabilidade e o desempenho dos serviços que dependem de indexadores, incluindo os aplicativos Web3 que usam APIs para buscar dados.

Além disso, enfrentamos problemas relacionados à compatibilidade do formato de dados e à diversidade de padrões de dados nas redes blockchain.

No campo da tecnologia blockchain, existem muitas redes diferentes, cada uma com seus próprios padrões de dados exclusivos. Por exemplo, existem cadeias compatíveis com EVM (Ethereum Virtual Machine), cadeias não EVM e cadeias zk (conhecimento zero), cada uma com sua própria estrutura e formato de dados especiais.

Este é, sem dúvida, um grande desafio para os indexadores. Para fornecer dados úteis e precisos por meio de APIs, os indexadores precisam ser capazes de lidar com esses diversos formatos de dados. No entanto, como não existe um padrão universal para dados de blockchain, diferentes indexadores podem usar diferentes padrões de API. Isso pode levar a problemas de compatibilidade de dados, onde os dados extraídos e transformados de um indexador podem não ser utilizáveis em outro sistema.

Além disso, à medida que os desenvolvedores exploram esse mundo multicadeia, eles geralmente enfrentam o desafio de lidar com esses diferentes padrões de dados. Uma solução que funciona para uma rede blockchain pode não funcionar para outra, dificultando o desenvolvimento de aplicativos que possam interagir com várias redes.

De fato, os desafios enfrentados pela indústria de indexação de blockchain lembram dois problemas não resolvidos na física identificados por Lord Kelvin no início do século 20, que eventualmente deram origem a campos revolucionários como a mecânica quântica e a termodinâmica.

Diante desses desafios, a indústria de fato tomou algumas medidas, como introduzir latência ou integrar streaming no pipeline Kafka e até mesmo estabelecer um consórcio de padrões para fortalecer a indústria de indexação de blockchain. Atualmente, essas medidas são capazes de lidar com a instabilidade das redes blockchain e a diversidade de padrões de dados, para que os indexadores possam fornecer dados precisos e confiáveis.

No entanto, assim como o advento da teoria quântica revolucionou nossa compreensão do mundo físico, também podemos considerar maneiras mais radicais de melhorar a infraestrutura de dados blockchain.

**Afinal, a infraestrutura existente, com seus armazéns de dados e pilhas bem organizados, pode parecer perfeita e bonita demais para ser verdade. **

Então, ** Existe alguma outra maneira? **

Encontrando padrões

Vamos voltar ao tópico original sobre o surgimento de provedores de nó e indexadores e considerar um problema peculiar. Por que os operadores de nós não apareceram em 2010, mas os indexadores apareceram repentinamente em grande número e receberam muito investimento em 2022?

Acredito que o que foi dito acima respondeu parcialmente a essas perguntas. Isso ocorre devido ao uso generalizado de tecnologias de computação em nuvem e armazenamento de dados na indústria de software, não apenas no campo da criptografia.

No mundo da criptografia, algo especial também aconteceu, especialmente quando os padrões ERC20 e ERC721 se tornaram populares na mídia pública. Além disso, o verão DeFi tornou os dados na cadeia mais complicados. Várias transações de chamada são roteadas em diferentes contratos inteligentes, em vez de dados de transação simples como no estágio inicial, o formato e a complexidade dos dados na cadeia sofreram mudanças e crescimento surpreendentes.

Embora na comunidade de criptomoedas sempre tenha sido enfatizado separar-se da tecnologia Web2 tradicional, o que não podemos ignorar é que o desenvolvimento da infraestrutura de criptomoeda depende de desenvolvimento contínuo e avanços nas áreas de matemática, criptografia, tecnologia de nuvem e big data. . Semelhante à tradicional estrutura chinesa de encaixe e espiga, os vários componentes do ecossistema de criptomoedas estão intimamente conectados.

O progresso e a aplicação inovadora da ciência e da tecnologia sempre estarão vinculados a alguns princípios objetivos. Por exemplo, sem o suporte básico da tecnologia de criptografia de curva elíptica, nosso ecossistema de criptomoeda hoje não pode existir. Da mesma forma, a aplicação prática de provas de conhecimento zero não teria sido possível sem o importante trabalho de pesquisa sobre provas de conhecimento zero publicado pelo MIT em 1985. Então vemos um padrão interessante. ** A ampla aplicação e expansão dos provedores de serviços de nó baseia-se no rápido crescimento dos serviços de nuvem globais e da tecnologia de virtualização. ** Ao mesmo tempo, O desenvolvimento da camada de dados na cadeia é baseado no desenvolvimento vigoroso de excelentes serviços e arquitetura de banco de dados de código aberto,** essas arquiteturas são as soluções de dados que muitos produtos de inteligência de negócios contar com nos últimos anos **. Esses são todos os pré-requisitos técnicos que as startups devem atender para alcançar a viabilidade comercial. Quando se trata de projetos Web3, aqueles que empregam infraestrutura avançada tendem a ter uma vantagem sobre aqueles que dependem de arquiteturas ultrapassadas. A erosão da participação de mercado da OpenSea por trocas NFT mais rápidas e fáceis de usar é um exemplo vívido.

Além disso, também podemos ver uma tendência óbvia: a inteligência artificial (IA) e a tecnologia LLM amadureceram gradualmente e têm a possibilidade de ampla aplicação.

**Portanto, surge uma questão importante: como a IA mudará o padrão de dados na cadeia? **

Adivinhação

Prever o futuro é sempre repleto de dificuldades, mas podemos explorar possíveis respostas ao entender os problemas encontrados no desenvolvimento da blockchain. **Os desenvolvedores têm uma demanda clara por dados on-chain: o que eles precisam é de dados on-chain precisos, oportunos e fáceis de entender. **

Um dos problemas que enfrentamos atualmente é que consultas SQL complexas são necessárias para obter ou exibir determinados dados em lotes. É por isso que a funcionalidade SQL de código aberto fornecida pelo Dune é tão popular na comunidade criptográfica. Os usuários não precisam escrever sql para criar gráficos do zero, eles só precisam bifurcar e modificar o endereço do contrato inteligente ao qual desejam prestar atenção e, em seguida, podem criar os gráficos de que precisam. No entanto, isso ainda é muito complicado para o usuário médio que deseja apenas visualizar os dados de liquidez ou airdrop sob certas condições.

Na minha opinião, o primeiro passo para resolver esse problema é utilizar o LLM e o processamento de linguagem natural.

Podemos construir uma interface de "consulta de dados" mais centrada no usuário e aproveitar as técnicas LLM. Nos casos existentes, os usuários devem usar linguagens de consulta complexas, como SQL ou GraphQL, para extrair os dados on-chain correspondentes da API ou Studios. No entanto, usando o LLM, podemos introduzir uma maneira mais intuitiva e humana de fazer perguntas. Desta forma, os usuários podem expressar suas perguntas em "linguagem natural" e o LLM as traduzirá em consultas adequadas e fornecerá aos usuários as respostas de que precisam.

Do ponto de vista dos desenvolvedores, a inteligência artificial também pode otimizar a análise de eventos de contrato na cadeia e a decodificação ABI. Atualmente, os detalhes de muitos contratos DeFi exigem que os desenvolvedores os analisem e decodifiquem manualmente. No entanto, se a inteligência artificial for introduzida, podemos melhorar significativamente várias técnicas de desmontagem de contratos e recuperar rapidamente a ABI correspondente. Combinada com um modelo de linguagem grande (LLM), essa configuração pode analisar assinaturas de função de maneira inteligente e lidar com vários tipos de dados com eficiência. Além disso, quando o sistema é combinado com a estrutura de processamento "stream computing", ele pode processar a análise dos dados da transação em tempo real para atender às necessidades imediatas dos usuários.

De uma perspectiva mais global, o objetivo de um indexador é fornecer dados precisos aos usuários. Como destaquei antes, um problema potencial com a camada de dados on-chain é que partes individuais dos dados estão espalhadas em diferentes bancos de dados do indexador e isoladas umas das outras. Para atender às diversas necessidades de dados, alguns designers optam por integrar todos os dados da cadeia em um banco de dados, para que os usuários possam selecionar as informações necessárias em um único conjunto de dados. Alguns protocolos optam por incluir apenas alguns dados, como dados DeFi e dados NFT. Mas o problema de padrões de dados incompatíveis ainda existe. Às vezes, os desenvolvedores precisam buscar dados de várias fontes e reformatá-los em seu próprio banco de dados, o que sem dúvida aumenta a carga de manutenção. Além disso, eles não podem migrar para outro provedor em tempo hábil caso haja um problema com um provedor de dados.

Então, como o LLM e a IA podem resolver esse problema? O LlamaIndex me deu uma revelação. E se os desenvolvedores não precisarem de um indexador, mas usarem um serviço de proxy implantado (agente) para ler diretamente os dados brutos na cadeia? Este agente combina as tecnologias de indexador e LLM. Do ponto de vista do usuário, ele não precisa saber nada sobre a API ou a linguagem de consulta, só precisa fazer perguntas e obter feedback instantâneo.

Equipado com LLM e tecnologia de inteligência artificial, o Agent entende e processa dados brutos e os converte em um formato de fácil compreensão para os usuários. Isso elimina a necessidade de os usuários enfrentarem APIs ou linguagens de consulta complexas, e eles podem simplesmente fazer perguntas em linguagem natural e obter feedback em tempo real. Esse recurso aumenta a acessibilidade e a facilidade de uso dos dados, atraindo uma base de usuários mais ampla para acessar dados on-chain.

Além disso, a forma de atendimento do agente (Agent) resolve o problema de incompatibilidade de padrão de dados. Como foi projetado com a capacidade de analisar e processar dados brutos na cadeia, ele pode se adaptar a diferentes formatos e padrões de dados. Como resultado, os desenvolvedores não precisam reformatar dados de fontes diferentes, reduzindo sua carga de trabalho.

Claro, isso é apenas uma especulação sobre a futura trajetória de desenvolvimento dos dados on-chain. Mas na tecnologia, muitas vezes são essas ideias e teorias ousadas que impulsionam o progresso revolucionário. Devemos lembrar que, seja a invenção da roda ou o nascimento do blockchain, todos os grandes avanços começam a partir da suposição de alguém ou de uma ideia "maluca".

À medida que abraçamos a mudança e a incerteza, também somos desafiados a ultrapassar continuamente os limites da possibilidade. Neste cenário, vislumbramos um mundo onde a combinação de IA, LLM e blockchain criará um campo tecnológico mais aberto e inclusivo.

A Chainbase mantém essa visão e está empenhada em torná-la realidade.

Nossa missão na Chainbase é criar uma infraestrutura de dados criptografados aberta, amigável, transparente e sustentável. Nosso objetivo é simplificar o uso desses dados pelos desenvolvedores, eliminando a necessidade de refatoração complexa da pilha de tecnologia de back-end. Dessa forma, esperamos inaugurar um futuro em que a tecnologia não apenas sirva aos usuários, mas também os capacite.

No entanto, devo esclarecer que este não é o nosso roteiro. Em vez disso, esta é minha reflexão pessoal sobre o recente desenvolvimento e progresso dos dados on-chain na comunidade como representante de relações com desenvolvedores.