What is The Graph Decentralized Network?
The decentralized network of The Graph is the ecosystem where the activities of the various actors involved in the protocol take place. This network allows decentralized applications (DApps) to perform complex queries quickly and efficiently without relying on centralized servers. To achieve this, the protocol is based on an ecosystem of participants with specific roles, incentivized by the network's native token, GRT.
The main participants are:
- Indexers: They are the node operators of the network. They stake their GRT tokens to process the data defined in subgraphs. They compete to offer the best indexing services and receive GRT rewards for processing consumer queries.
- Curators: Community members who identify and signal which subgraphs are of high quality and should be indexed by the network. They stake GRT on the subgraphs they consider valuable and, in return, receive a portion of the query fees generated by those subgraphs. Their role is key to ensuring data quality in the marketplace.
- Delegators: Participants who delegate (stake) their GRT tokens to indexers they consider reliable and efficient. They do not need to run a node themselves but contribute to the security and operation of the network. In return, they receive a share of the rewards earned by the indexer they support.
- Consumers: The end users of the network, usually DApps and developers, who pay query fees in GRT to indexers to obtain the data they need from subgraphs.
The relationship between participants in The Graph is governed decentrally through a set of smart contracts deployed on Arbitrum One.
Subgraph Production Deployment
Starting from a previously deployed subgraph in Subgraph Studio, publishing to the decentralized network only requires having ETH on the Arbitrum One network.
It is recommended to review the correctness and accuracy of the subgraph's metadata beforehand to avoid incurring additional gas costs if you need to modify them later.
Soon after publication, the subgraph should begin to be indexed at least by the default indexer, the upgrade indexer. This is infrastructure provided by the project that gives immediate coverage in the short term to any newly published subgraph as a preliminary step to a long-term decentralized indexing strategy. Subgraphs indexed only by the upgrade indexer have the following responsible use limitations:
- Maximum storage of 10GB.
- Bandwidth usage within reasonable limits.
- Not being inactive for more than 14 days (without indexing new events).
- Time Travel Queries are not supported (the subgraph is automatically purged).
Below is an example of a subgraph visualized in the Graph Explorer indexed only by the upgrade indexer:
Production Endpoint
Once the subgraph is published, you should start using the production URL to access its data, thus avoiding the limitations seen for the development endpoint in my first article about blockchain data indexing.
As a novelty, this URL requires the use of an API-KEY that authorizes queries on the subgraph and allows proper billing to generate returns for network participants. Currently, each data consumer is allowed 100K requests per month for free, and a paid plan is required to exceed this limit (query fees).
To protect the legitimate use of API-KEYs from DApps, several limits can be set: maximum monthly spend, list of authorized subgraphs to query, and list of valid origin domains.
Subgraph Signaling
This is the essential mechanism for a subgraph to attract other indexers and receive long-term support beyond the upgrade indexer, the default indexer.
The process can be summarized as follows:
- Curators signal a specific subgraph with GRT tokens because they expect to earn profits, including 10% of the query fees based on the percentage of GRT tokens staked.
- Indexers pay attention to signaled subgraphs to get an idea of which ones might be more profitable, as they also receive direct benefits from both query fees and indexing rewards.
A minimum signal of 3,000 GRT tokens is recommended for a new subgraph to attract at least one indexer. From Subgraph Studio, you can become the first curator of the subgraph by signaling it during the publication process.
Best Practices in Subgraph Design
To facilitate indexing and optimize query times, several strategies are detailed in a catalog of best practices.
The most notable and easy to implement are the use of immutable entities and defining the subgraph identifier as Bytes.
Entities are defined as immutable in the "schema.graphql" file:
type IpfsMetadata @entity(immutable: true) {
id: Bytes!
metaData: String!
}
This way, the entity cannot be updated or deleted. Also, its identifier must be unique, as versions are not allowed. The default unique identifier created in mapping files is the concatenation of the transaction hash where the event is emitted (transactionHash) with the event index within the log section of the same transaction (logIndex).
Additionally, to define the identifier of entities as Bytes, you must consider the type conversions allowed in AssemblyScript.
Conclusion: Ensuring Reliable Access to Indexed Data
The use of indexers is essential to access structured on-chain data from DApps. In this context, the decentralized network of the The Graph protocol is a robust and reliable alternative.
By deploying a decentralized ecosystem where different participants share interests through incentives centered on the GRT token, stability is promoted for a network of independent nodes responsible for indexing blockchain data and making the various published subgraphs available to consumers.
Furthermore, the network goes a step further and enables access to other types of data to accommodate other use cases:
- Substreams: high-performance data sources for real-time processing. Useful for applications that need to reflect the blockchain state with no latency, such as trading.
- Token API: instant access to normalized data of blockchain tokens without prior configuration.
In summary, with The Graph, the web3 ecosystem has a reliable mechanism to have stable data sources from the blockchain in the long term.
Have you participated in The Graph decentralized network beyond data consumption? Do you know of any other network that complements or competes with The Graph's proposal for on-chain data indexing? I would love to hear about your experiences.
If you need to publish a subgraph for your DApp, contact me. I can advise you on the best strategies to optimize your results.
