Perguntas Frequentes dos Programadores

Reading time: 7 min

Um subgraph é uma API personalizada construída em dados de blockchains. Subgraphs são consultados com a linguagem GraphQL e lançados a um Graph Node usando o Graph CLI. Quando lançados e editados à rede descentralizada do The Graph, os Indexadores processam subgraphs e os disponibilizam para serem consultados em query por consumidores de subgraphs.

Não é possível apagar subgraphs após a sua criação.

Não. Quando um subgraph é criado, não é possível mudar o seu nome. Pense com cuidado antes de criar o seu subgraph para poder ser facilmente buscável e identificável por outros dapps.

Não. Quando um subgraph é criado, não há mais como mudar a conta do GitHub associada a ele. Pense nisto com cuidado antes de criar o seu subgraph.

É altamente recomendado que estruture os seus contratos inteligentes para terem eventos associados com dados que tens interesse de consultar em query. Handlers de eventos no subgraph são ativados por eventos de contratos e são, de longe, a forma mais rápida de conseguir dados úteis.

Se os contratos com os quais trabalha não contêm eventos, o seu subgraph pode usar handlers de chamadas e blocos para ativar o indexing. Porém, isto não é recomendado, porque retarda muito o desempenho do subgraph.

Precisará fazer nomes separados para várias redes. Enquanto não podes ter subgraphs diferentes sob o mesmo nome, há várias maneiras convenientes de ter uma única base de código para várias redes. Leia mais na nossa documentação: Como Relançar um Subgraph

Modelos (templates) permitem criar fontes de dados na hora, enquanto o seu subgraph está no processo de indexação. Pode ser que o seu contrato gerará novos contratos enquanto as pessoas interagem com ele, e como queres saber o formato destes contratos (ABI, eventos, etc.) à vista, pode definir como quer indexá-los em um modelo; e quando gerados, o seu subgraph criará uma fonte de dados dinâmica ao fornecer o endereço do contrato.

Confira a seção "como instanciar um modelo de fontes de dados" em: Modelos de fontes de dados.

Podes executar o seguinte comando:

docker pull graphprotocol/graph-node:latest

NOTA: O docker / docker-compose sempre usará a versão do graph-node que foi puxada na primeira vez que a executou, então é importante fazer isto para garantir que está em dia com a versão mais recente do graph-node.

Confira o estado Access to smart contract dentro da seção AssemblyScript API.

Sim. No próprio comando graph init, é possível adicionar várias fontes de dados ao inserir contratos um após o outro. O comando graph add também pode adicionar uma nova fonte de dados.

• graph-node
• graph-tooling
• graph-docs
• graph-client

Se só uma entidade for criada durante o evento e não houver nada melhor disponível, então o hash da transação + o index do log será original. Podes ofuscá-los ao converter aquilo em Bytes e então o colocar pelo crypto.keccak256, mas isto não o fará mais original.

Dentro de um subgraph, os eventos são sempre processados na ordem em que aparecem nos blocos, mesmo sendo ou não através de vários contratos.

Sim. Isto é possível ao importar o graph-ts como no exemplo abaixo:

import { dataSource } from '@graphprotocol/graph-ts'

dataSource.network()
dataSource.address()

Sim. O Sepolia apoia handlers de blocos, chamadas e eventos. Vale notar que handlers de eventos têm desempenho muito melhor do que os outros dois e têm apoio em todas as redes compatíveis com EVMs.

Não no momento, já que mapeamentos são escritos em AssemblyScript. Outra solução seria armazenar dados puros em entidades e desempenhar lógicas que requerem bibliotecas JS no cliente.

Sim. dataSources.source.startBlock no arquivo subgraph.yaml especifica o número do bloco que a fonte de dados começa a indexar. Na maioria dos casos, sugerimos usar o bloco no qual o contrato foi criado: Blocos de início

Sim. Confira o recurso opcional de bloco inicial (start blcok) para começar a indexar do bloco em que o contrato foi lançado: Blocos iniciais

Sim! Execute o seguinte comando, com "organization/subgraphName" substituído com a organização sob a qual ele foi publicado e o nome do seu subgraph:

curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql

Veja a lista das redes apoiadas aqui.

Deve relançar o subgraph, mas se a ID do subgraph (hash IPFS) não mudar, ele não precisará sincronizar do começo.

A Federation ainda tem apoio, mas queremos apoiá-la no futuro. No momento, vale usar costura de schemas no cliente ou através de um serviço proxy.

Normalmente, respostas a consultas são limitadas a 100 itens por coleção. Se quiser receber mais, pode subir para até 1000 itens por coleção; além disto, pode paginar com:

someCollection(first: 1000, skip: <number>) { ... }

Atualmente, a abordagem recomendada para um dApp é adicionar a chave ao frontend e expô-la para utilizadores finais. Dito isto, pode limitar aquela chave a um hostname, como seudapp.io e um subgraph. A gateway está atualmente a ser executada pelo Edge & Node. Parte da responsabilidade de uma gateway é monitorar comportamentos abusivos e bloquear tráfego de clientes maliciosos.

Vá para o Serviço Hospedado para achar subgraphs lançados por você ou outros ao Serviço Hospedado. Veja aqui.

The Graph nunca cobrará pelo Serviço Hospedado. Este é um protocolo descentralizado, e cobrar por um serviço centralizado não condiz com os valores do Graph. O Serviço Hospedado sempre foi um degrau temporário para chegar à rede descentralizada; os programadores terão tempo suficiente para migrar à rede descentralizada quando estiverem preparados.

Se for um programador de subgraph, você pode lançar uma nova versão do seu subgraph ao Subgraph Studio com a CLI. O subgraph será privado até lá, mas se estiver contente com ele, você pode publicá-lo no Graph Explorer descentralizado. Isto criará uma nova versão do seu subgraph em que Curadores podem começar a sinalizar.

Primeiro, handlers de eventos e chamadas são organizados pelo índice de transações dentro do bloco. Handlers de evento e chamada dentro da mesma transação são organizados com uma convenção: handlers de eventos primeiro e depois handlers de chamadas, com cada tipo a respeitar a ordem em que são definidos no manifest. Handlers de blocos são executados após handlers de eventos e chamadas, na ordem em que são definidos no manifest. Estas regras de organizações estão sujeitas a mudanças.

Com a criação de novas fontes de dados dinâmicas, os handlers definidos para fontes de dados dinâmicas só começarão a processar após o processamento dos handlers das fontes, e se repetirão na mesma sequência sempre que acionados.