Before jumping into the subject, let’s first take some moment to define what is ‘The Graph’ and what is a ‘curator’
The Graph
If you are into the blockchain industry, you might know how is it difficult to collect on-chain data on specific topics. The Graph is an indexing protocol for querying networks like Ethereum and IPFS. The first release of ‘The Graph’ is focusing at the beginning on ETH, but its aim is to index data for all blockchain layer 1 protocols. ‘The Graph’ is open source, anyone can build and publish open APIs, called subgraphs, making data easily accessible.
Developers build and deploy subgraphs, which describe how to ingest and index data from Web3 data sources. Many leading Ethereum projects have already built subgraphs including: Uniswap, ENS, DAOstack, Synthetix, Moloch, and more.
Protocol roles
There are 3 main roles within The Graph protocol:
- Indexers are the node operators of The Graph. They are motivated by earning financial rewards.
- Curators use GRT (The Graph token) to signal what subgraphs are valuable to index. These will typically be developers but they could also be end users (non technical) supporting a service they rely upon or a persona that is purely financially motivated.
- Delegators put GRT at stake on behalf of an Indexer in order to earn a portion of inflation rewards and fees, without having to personally run a Graph Node. They are financially motivated.
Now let’s see how a non technical curator can evaluate subgraphs.
How to evaluate subgraphs
First, lets head to the explorer and search for a specific subgraph to evaluate. In this example I have searched for the keyword ‘KEEP’ and see what’s coming out:
Here we have the ‘All the Keeps’ subgraph which is related to the KEEP / tBTC network, and it should be interesting to evaluate.
When clicking on the subgraph we have the following information:
- we already know the subgraph is running on mainnet
- we have access to the Github repository
- and more importantly we have the subgraph ID
From here we can first have a look into the Github repository
From the first look, we see that things are pretty well organised as we can find a README.md, a subgraph manifest (subgraph.yaml) and a GraphQL schema (schema.graphql)
We know that for evaluating a subgraph we would need to look into the 3 key components which defines what a subgraph is doing:
1- the subgraph manifest which give us a kind of instruction guide on how the graph node is working. It shows where the data is indexed from the Ethereum blockchain.
In this case we can see that we are in front of a complex subgraph where the data is indexed from multiple contracts on the Ethereum blockchain
and this is just a small part of the manifest. Actually it has more than 475 lines describing which contracts are used from the mainnet (there are 10 in total) to extract blockchain data and which events are tracked.
In the picture above, this is just an example of the events that are indexed in the subgraph. When you look into the manifest you will find much more !
2- the GraphQL schema is describing the entities or data objects used in the subgraph to organize the data collected from the blockchain. The entities does not need to be event based. For more information, please have a look in The Graph web site here to get more details on how the GraphQL schema should look like.
Below an example of an entity in the GraphQL schema of the KEEP/tBTC network subgraph
This entity / data object (SetupFailedEvent) is defined by an id, submitter, transaction Hash, timestamp, deposit, operator and the reason why the setup has failed
At this stage beeing able to read the subgraph manifest and the GraphQL schema gives you a good idea on what the subgraph is aiming to do.
3- If you want to deep dive more into what the subgraph is doing, you can look at the mappings file which transforms the lower level Ethereum data into the desired entities that are specified in the GraphQL schema file. To elaborate further, the manifest extracts the raw Ethereum data, and the mappings manipulate this data into the form that is set out in the schema.
Now we had the chance in the subgraph page from The Graph explorer to find a Github repository which has provided us with all this great information. So what could we do if we face this case:
A subgraph without a Github repository … and there comes the ID !
In this case you need to use the ipfs link and add to it the subgraph ID to get the subgraph manifest. In this case we would need to go to: https://ipfs.io/ipfs/Qme4h2FrGwRyguFFzEDTcy29NDyaYDxCwUNoXhEF8jBD43 to access the subgraph manifest
There we can find out that this subgraph is running on the Rinkeby Ethereum testnet, indexing data from a contract named Pollen with the specific address 0x8B9222DAac6F30fB054b44B335852c37a5c17fE0
At the end of the manifest we have an ID to access the corresponding GraphQL schema. In this case we just need to use the same ipfs url and changing the ID at the end by adding the one in the manifest. It this specific case we would need to visit https://ipfs.io/ipfs/QmYwjKAuQbVmg5PGMtHAU2xDiJhgtwwH9ceLzCVg8scyZM to access the GraphQL schema:
We can clearly see the definition of different entities.
Summary
Subgraphs are very powerful to index data and the blockchain and make it easily usable. As we have seen there are different ways for non technical curators to evaluate subgraphs without having to know coding. Off course you can deep dive in details into what the subgraph is doing by evaluating the mappings as well. In this case you would need to have some extra technical skills.
