Além dos tokens de moeda criptográfica, a cadeia de bloqueio também permite aos analistas obter uma imagem mais clara de praticamente qualquer projecto GameFi, NFT, marketplace, ou protocolo DeFi, graças ao Footprint.
Na Footprint, criámos uma metodologia que compila e agrega de forma significativa os dados brutos da cadeia de bloqueios. E isto aplica-se às integrações de programação.
1 . Formas de trabalhar com os dados da cadeia de bloqueios
Primeira palestra sobre métodos de integração de programação. Existem algumas formas diferentes de trabalhar com dados em cadeia de bloqueio, e a abordagem escolhida dependerá das suas necessidades e objectivos específicos. Aqui está uma rápida visão geral:
1.1 Blockchain explorers
A blockchain explorer é um website ou ferramenta que lhe permite visualizar os dados armazenados numa cadeia de bloqueio. Esta pode ser uma forma rápida e fácil de aceder à informação sobre transacções específicas, blocos, e outros dados sobre a cadeia de blocos.
Os exploradores de cadeias de blocos podem ser uma ferramenta útil para aceder e visualizar dados armazenados numa cadeia de blocos, mas têm algumas limitações para a integração de software. Aqui estão alguns exemplos de coisas que os exploradores de cadeias de blocos podem não ter:
- Muito concentrado em dados brutos. Os exploradores de cadeias de blocos normalmente exibem dados brutos da cadeia de blocos. Isto requer a implementação das abstracções sobre os dados em bruto, que podem ser enfadonhas, especialmente para projectos centrados na entrega e não nos detalhes técnicos de certas cadeias de blocos.
- Opções de personalização: Os exploradores de cadeias de blocos são tipicamente concebidos para serem de fácil utilização, o que significa que podem não oferecer muitas opções de personalização. Isto pode dificultar a adaptação do explorador às suas necessidades ou preferências específicas.
- Funcionalidade de pesquisa avançada: Os exploradores de cadeias de bloqueio têm frequentemente a funcionalidade de pesquisa básica mas podem não suportar características de pesquisa mais avançadas, tais como operadores booleanos ou expressões regulares. Isto pode tornar difícil a pesquisa de informação específica sobre a cadeia de bloqueios.
- Interactividade: Muitos exploradores de cadeias de bloqueio são essencialmente ferramentas apenas de leitura.
Embora os exploradores de cadeias de bloqueio possam ser uma forma útil de aceder e visualizar os dados em bruto das cadeias de bloqueio, têm algumas limitações que deve ter em conta antes de decidir implementar a sua infra-estrutura de solução baseada neles.
1.2 Solução de indexação própria
A configuração do seu próprio indexador para trabalhar com dados da cadeia de bloqueio pode ter várias vantagens e potenciais desvantagens. Aqui estão alguns exemplos de cada uma delas:
Vantagens:
- Customização: Ao configurar o seu indexador, tem total controlo sobre a forma como os dados são indexados e acedidos. Isto pode permitir-lhe adaptar o indexador às suas necessidades e preferências específicas.
- Independência: Ao configurar o seu indexador, não depende de um serviço de terceiros para manter e actualizar o índice. Isto pode proporcionar maior controlo e flexibilidade no seu trabalho com os dados da cadeia de bloqueio.
- Segurança melhorada: Ao configurar o seu próprio indexador, pode implementar as suas próprias medidas de segurança para proteger os dados e impedir o acesso não autorizado.
Desvantagens:
- Complexidade: A configuração do seu indexador pode ser um processo complexo e demorado, especialmente se for novo no trabalho com tecnologia de cadeias de bloqueio. Terá de compreender a tecnologia subjacente e estar disposto a investir o tempo e o esforço necessários para pôr o indexador a funcionar.
- Manutenção: Uma vez instalado o indexador, será responsável pela sua manutenção e actualização. Isto pode exigir conhecimentos técnicos e recursos contínuos, o que pode ser uma desvantagem se não tiver os conhecimentos ou apoio necessários.
- Custo: A instalação do seu próprio indexador pode ser dispendiosa, uma vez que terá de adquirir o hardware e software necessários para executar o indexador e pagar por quaisquer custos associados, tais como electricidade e largura de banda.
Overall, a criação do seu próprio indexador para trabalhar com dados em cadeia de bloqueio pode proporcionar um maior controlo e personalização, mas também pode ser um processo complexo e dispendioso. É importante considerar cuidadosamente as vantagens e desvantagens antes de decidir se esta é a abordagem correcta.
1.3 Base de dados como um serviço
Usar um indexador de terceiros para trabalhar com dados da cadeia de bloqueio pode ter várias vantagens e potenciais desvantagens. Aqui estão alguns exemplos de cada uma delas:
Vantagens:
- Facilidade de utilização: Os indexadores de terceiros são normalmente concebidos para serem fáceis de utilizar, o que significa que pode começar a trabalhar com os dados da cadeia de bloqueio rapidamente e sem ter de aprender muitos detalhes técnicos ou executar a sua solução de indexação personalizada (não importa se é auto-desenvolvida ou um SDK pronto a usar)
- Funcionalidade de pesquisa avançada: Muitos indexadores de terceiros oferecem funcionalidade de pesquisa avançada, tais como operadores booleanos e expressões regulares, facilitando a pesquisa de informação específica sobre a cadeia de bloqueios. Estes podem ter muitas implementações reais, mas os dados indexados são muitas vezes adicionados a uma base de dados relacional, o que implica um suporte SQL completo.
- Scalabilidade: Os indexadores de terceiros são frequentemente concebidos para tratar grandes volumes de dados, o que significa que podem ser uma boa opção se for necessário pesquisar ou aceder a dados de uma grande cadeia de bloqueios.
- Reliabilidade: Os indexadores de terceiros são tipicamente geridos por organizações profissionais com os recursos e perícia necessários para assegurar que o índice esteja sempre actualizado e preciso. As soluções nem sempre são descentralizadas, uma vez que se concentram no processamento de enormes quantidades de dados, mas a grande maioria é de fonte aberta, o que aumenta a confiança dos utilizadores no serviço.
Desvantagens:
- Dependência: Utilizando um indexador de terceiros, conta com esse serviço para manter e actualizar o índice. Se o indexador tiver problemas técnicos ou ficar offline, poderá não ser possível aceder aos dados da cadeia de bloqueio.
- Personalização limitada: Os indexadores de terceiros são normalmente concebidos para serem fáceis de utilizar, o que significa que podem não oferecer muitas opções de personalização. Isto pode dificultar a personalização do indexador em função das suas necessidades ou preferências específicas.
- Custo: Alguns indexadores de terceiros podem cobrar uma taxa pelos seus serviços, o que pode ser uma desvantagem se trabalhar com um orçamento apertado.
Em resumo, utilizar um indexador de terceiros para trabalhar com dados da cadeia de bloqueio pode ser uma opção conveniente e eficaz, mas limitada e por vezes carece de personalização.
1.4 Resumo
O objectivo da Pegada Ecológica é principalmente baixar a barra para entrar na análise e trabalhar com dados da web3. Esta abordagem é um equilíbrio entre a facilidade de utilização e a flexibilidade. É por isso que um dos nossos serviços é DaaS (Base de dados como o tipo de serviço). Antes de analisarmos mais de perto as vantagens do nosso serviço, analisaremos também outra opção de implementação para o indexador, nomeadamente uma solução auto-escrita ou SDK.
Nos próximos capítulos, exploraremos a característica central que as APIs de cadeia de bloqueio só de leitura devem ter. Analisaremos o problema a partir de diferentes ângulos e consideraremos soluções alternativas. Algumas das características mais importantes das APIs de cadeia de bloqueio incluem o seguinte:
- Facilidade de utilização e flexibilidade
- Scalabilidade
- Compatibilidade
Facilidade de utilização e flexibilidade são duas características importantes das APIs de cadeia de bloqueio. Uma API em cadeia que é fácil de utilizar facilitará aos programadores a construção de aplicações baseadas em cadeias de blocos, permitindo-lhes rapidamente fazer protótipos e testar as suas ideias sem gastar muito tempo a aprender como utilizar a API.
A flexibilidade, por outro lado, refere-se à capacidade de um API de cadeia de bloqueios para suportar uma vasta gama de casos de utilização e aplicações. Um API flexível de cadeia de bloqueio permitirá aos programadores aceder a diferentes partes da cadeia de bloqueio e construir aplicações que interagem com diferentes tipos de contratos inteligentes e outros bens baseados na cadeia de bloqueio. Isto pode ser especialmente importante para os programadores que procuram construir aplicações que possam ser utilizadas em várias indústrias e contextos.
Em geral, ter uma API de blockchain que seja simultaneamente fácil de usar e flexível pode facilitar aos programadores a construção de aplicações inovadoras e úteis que possam tirar partido das características e capacidades únicas da tecnologia blockchain.
1.5 Analítica de pegada
A facilidade de utilização e flexibilidade é assegurada pela nossa organização de dados, que afecta todos os aspectos das interacções com o ecossistema da Pegada Ecológica. A Pegada Ecológica tem um API construído em cima deste modelo de dados que permite aos utilizadores construírem tubagens de dados completas para análise de dados e aplicações de aprendizagem de máquinas. Chamamos-lhe uma API de dados. Estamos simultaneamente a suportar dois tipos de API e dois subtipos dentro de um deles para cobrir a maior parte dos casos: API de repouso e API SQL.
A API REST permite-nos integrar rapidamente uma aplicação, uma vez que cada endpoint é um script pré-criado e codificado que identificámos como um dos mais populares. Todos os endpoints vêm com ferramentas fáceis de usar para filtragem, classificação e paginação.
Fancos à interface mais adaptável da API SQL, pode obter isto para casos mais específicos. Uma vantagem de utilizar as mesmas consultas SQL tanto na aplicação web como na API é que pode simplificar o desenvolvimento e a manutenção. Ao utilizar as mesmas consultas em ambas as interfaces, os programadores podem evitar a necessidade de escrever e manter conjuntos separados de consultas para a aplicação web e para a API. Isto pode poupar tempo e esforço e reduzir o risco de erros ou inconsistências entre as duas interfaces.
Adicionalmente, usando as mesmas consultas SQL tanto na aplicação web como na API pode facilitar aos programadores a criação de uma experiência de utilizador sem descontinuidades. Ao utilizar as mesmas consultas, os programadores podem assegurar que os dados acedidos e manipulados pela aplicação web e pela API são consistentes, permitindo aos utilizadores alternar entre as duas interfaces sem encontrar quaisquer inconsistências ou perturbações.
1.6 Outras plataformas
Muitas soluções analíticas alternativas permitem ao utilizador analisar diferentes redes de acordo com vários níveis de requisitos. Contudo, na sua maioria, as soluções alternativas tendem a ir aos extremos, implementando ou um produto muito flexível que requer conhecimento de linguagens de consulta ou mesmo linguagens de programação ou uma interface muito simples com scripts preparados e, consequentemente, uma baixa flexibilidade.
Soluções como Moralis e Quicknode só têm uma interface REST API. Embora existam muitos pontos finais, ainda limita o programador na flexibilidade dos dados devolvidos.
A Dune introduziu recentemente a sua API. Esta solução assíncrona implica a existência preliminar de uma consulta na plataforma sob um determinado id (dune.com/query/{{query id}}), através da qual é possível executar consultas sob a forma de SQL. A principal limitação desta solução é a necessidade de pré-modificar a SQL na plataforma para que a consulta actualizada seja posteriormente executada.
Chainbase libera SQL API da mesma forma que Footprint. Ainda assim, ao contrário de Footprint, Chainbase não tem ETL tão sofisticada, pelo que as consultas SQL só podem ser executadas para transacções em bruto.
2. Escalabilidade
Blockchain APIs devem ser capazes de lidar com grandes volumes de dados e transacções, permitindo aos programadores construir aplicações que possam ser utilizadas por muitos utilizadores em simultâneo.
2.1 Analítica de pegada
2.1.1 Pilha de dados aberta moderna
A equipa Footprint fez várias actualizações arquitectónicas desde o seu lançamento em Agosto de 2021, graças à sua forte capacidade de explorar e iterar sobre a tecnologia. Em menos de um ano e meio, a equipa foi capaz de implementar estas mudanças com sucesso. Isto é uma prova da habilidade e perícia da equipa em tecnologia e ciência de dados.
Através da experimentação, Footprint efectuou iterativamente três actualizações arquitectónicas globais, acabando por chegar a uma arquitectura que satisfaz os requisitos dos vários casos de utilização da plataforma. Mais informações sobre a evolução da implementação podem ser encontradas no próximo artigo:
https://www.footprint.network/article/iceberg-spark-trino-a-modern-opensource-data-stack-for-blockchain-fp-HGZpPm3D
2.1.2 Sinc e execuções assíncronas
Within Footprint, existem dois modos para executar consultas à API SQL – síncrona e assíncrona. As chamadas API para o endpoint síncrono implicam que a consulta SQL será executada pelos servidores Footprint assim que um pedido HTTP for recebido da aplicação, mantendo assim a ligação. Isto faz sentido quando se utilizam pedidos leves, pois, neste caso, a aplicação não tem de esperar muito tempo pela execução. Os detalhes podem ser encontrados na página seguinte:
https://docs.footprint.network/reference/post_native
Para pedidos pesados, recomenda-se a utilização de um pedido assíncrono. Ao contrário de um pedido síncrono, a aplicação cliente não tem de manter uma ligação com o servidor durante a execução. Em vez disso, pode obter imediatamente o pedido-id, segundo o qual, após algum tempo, obter separadamente os resultados da execução. Como parte da API assíncrona, devem ser cobertos dois passos para obter os dados – o seguinte ponto final será utilizado para enviar uma “ordem” para execução SQL:
https://docs.footprint.network/reference/post_native-async
O segundo passo consiste em enviar um pedido para receber resultados através do identificador obtido ao aceder ao parâmetro anterior. O ponto final para esta segunda etapa é descrito na página seguinte:
https://docs.footprint.network/reference/get_native-execution-id-results
2.2 Outras soluções
DuneV2 altera toda a arquitectura da base de dados. Dune está agora a fazer a transição de uma base de dados PostgreSQL para uma Instância de [[Apache Spark]] alojada em [[Databricks]]. Apenas API assíncrona.
3. Compatibilidade
Blockchain APIs devem ser compatíveis com uma vasta gama de linguagens de programação e ambientes de desenvolvimento para que os programadores possam utilizar as ferramentas e frameworks com as quais estão mais familiarizados.
REST é mais fácil de integrar uma vez que cada linguagem de programação tem muitas bibliotecas que proporcionam um trabalho confortável com este tipo de API. No entanto, no final, tanto as APIs SQL como REST funcionam sobre HTTP, pelo que a experiência de desenvolvimento é quase idêntica no que respeita ao envio de um pedido por defeito.
4. Resumo
Como analisámos, na maioria dos casos, é suficiente que uma aplicação utilize soluções DaaS prontas a usar, pelo facto de poderem devolver abstracções (não apenas dados em bruto) e poupar muito tempo e dinheiro, uma vez que acabam por permitir que as equipas se concentrem não nas infra-estruturas mas no valor do produto. Passar por várias soluções no mercado DaaS,
A pegada parece ser a mais ideal para integrar, uma vez que tem o modelo mais flexível para gerar pedidos ao mesmo tempo que é fácil de usar e também tem a moderna pilha de dados de código aberto debaixo da capota, o que garante uma execução ininterrupta e, mais importante, rápida dos pedidos mais complexos.
