Web3 has been under fire by skeptics who think decentralized applications (dApps) will never be made compelling enough for widespread adoption. I believe that Web3 is going to be the next big platform and that millions of dApps will come to market and displace Web 2.0 monopolies.
If you have been paying attention in DeFi you may have heard of The Graph, a data availability platform that makes it easier for dApps to access important on chain data quickly and easily. They recently launched their Curator Program, where they are engaging the community to learn how to become active contributors to The Graph’s growing decentralized data API.
The Graph Introduction
The Graph is a decentralized protocol for indexing and querying data from blockchains, starting with Ethereum. It makes it possible to query data that is difficult to query directly.
How The Graph Works
The Graph learns what and how to index Ethereum data based on subgraph descriptions, known as the subgraph manifest. The subgraph description defines the smart contracts of interest for a subgraph, the events in those contracts to pay attention to, and how to map event data to data that The Graph will store in its database.
Once you have written a subgraph manifest, you use the Graph CLI to store the definition in IPFS and tell the hosted service to start indexing data for that subgraph.
This diagram gives more detail about the flow of data once a subgraph manifest has been deployed, dealing with Ethereum transactions:
The flow follows these steps:
- A decentralized application adds data to Ethereum through a transaction on a smart contract.
- The smart contract emits one or more events while processing the transaction.
- Graph Node continually scans Ethereum for new blocks and the data for your subgraph they may contain.
- Graph Node finds Ethereum events for your subgraph in these blocks and runs the mapping handlers you provided. The mapping is a WASM module that creates or updates the data entities that Graph Node stores in response to Ethereum events.
- The decentralized application queries the Graph Node for data indexed from the blockchain, using the node’s GraphQL endpoint. The Graph Node in turn translates the GraphQL queries into queries for its underlying data store in order to fetch this data, making use of the store’s indexing capabilities.
- The decentralized application displays this data in a rich UI for end-users, which they use to issue new transactions on Ethereum.
- The cycle repeats.
How to query the Subgraph？
With the subgraph deployed, visit the Graph Explorer to open up a GraphiQL interface where you can explore the deployed GraphQL API for the subgraph by issuing queries and viewing the schema.
An example is provided below, but please see the Query API for a complete reference on how to query the subgraph’s entities.
Example
My first subgraph wich I analyzed was gnosis/protocol. I was assigned the gnosis/protocol as one of my five subgraphs.
First of all I looked to subgraph manifest and found contract which interact with this subgraph. So I visit the git repo of gnosis/protocol. And I find subgraph manifest file “subgraph.yaml.mustache”.
We could find that address is in another config file.
Finally, I find that in mainnet.json. The contract address is “0x6F400810b62df8E13fded51bE75fF5393eaa841F”.
So, it was contract of BatchExchange . After that I checked site of this project.
Now, we should evaluate the gnosis/protocol subgraph.
We are able to use GrapgQL to query the data of gnosis/protocol dex.
For example, using example query blow.
{
tokens(first: 5) {
id
address
fromBatchId
symbol
}
prices(first: 5) {
id
token {
id
}
batchId
priceInOwlNumerator
}
}We could get the result from gragh node.
{
"data": {
"prices": [
{
"batchId": "5267142",
"id": "0-5267142",
"priceInOwlNumerator": "1",
"token": {
"id": "0"
}
},
{
"batchId": "5267420",
"id": "0-5267420",
"priceInOwlNumerator": "1",
"token": {
"id": "0"
}
},
{
"batchId": "5267422",
"id": "0-5267422",
"priceInOwlNumerator": "1",
"token": {
"id": "0"
}
},
{
"batchId": "5267424",
"id": "0-5267424",
"priceInOwlNumerator": "1",
"token": {
"id": "0"
}
},
{
"batchId": "5267429",
"id": "0-5267429",
"priceInOwlNumerator": "1",
"token": {
"id": "0"
}
}
],
"tokens": [
{
"address": "0x1a5f9352af8af974bfc03399e3767df6370d82e4",
"fromBatchId": "5266038",
"id": "0",
"symbol": "OWL"
},
{
"address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"fromBatchId": "5266039",
"id": "1",
"symbol": "WETH"
},
{
"address": "0xfe18be6b3bd88a2d2a7f928d00292e7a9963cfc6",
"fromBatchId": "5267195",
"id": "10",
"symbol": "sBTC"
},
{
"address": "0xa0ecee77edff26f45a626d7de6bac9f33f15c366",
"fromBatchId": "5321515",
"id": "100",
"symbol": "G21"
},
{
"address": "0x5541f443df194869e9956de85316d51b24b089c3",
"fromBatchId": "5321515",
"id": "101",
"symbol": "G23"
}
]
}
}Also, as a curator , I should test this subgraph for all shchema such as token, Price, User, Deposit, Withdraw Request, Withdraw, Order, Trade, Batch, and Solution.
Here are the basic questions recommended by The Graph that a Curator should answer to determine if a graph is good or bad:
- How would you describe what the subgraph does? This is a subgraph for displaying basic information about the dex. The first step is to find the contract’s address from the subgraph data, or directly from Etherscan. The query shows basic data. Maybe they never needed that data and didn’t complete it. This works like I’d expect, but could include a lot more metadata that might be useful.
- Does this subgraph look production ready? Yes, the data of Token, Price, User, Deposit, WithdrawRequest, Withdraw, Order, Trade, Batch, and Solution could be queried successfully. This subgraph is great and useful.
- Does this subgraph look like it would be useful to others? This subgraph is moderately useful to others.
- What changes would you make to the schema including additions or modifications to entities, fields, field types, relationships, or any other improvements? No, this subgraph is great enough.
- Are there any other subgraphs that do similar things? How does this one compare? No, this is the only subgraph deployed for this dex, by its developer, presumably.
- Identify the degree of completeness, complexity and accuracy of the implementation. Completeness: High. Complexity: low. Accuracy: not quite there.
Why Curate?
The Graph has created a very interesting set of incentives for the different participants in the network. For Curators, if you can identify weak-but-popular subgraphs and improve on them, you could stand to make profit by being first to stake GNT on the new graphs and getting the community to switch over to them. It is a standing, open, job that anyone can take with the knowledge and skills to complete it.
