Text and images on this page are derived from the official Graph documentation, and have been modified to more closely describe how The Graph relates to the Sovryn ecosystem: https://thegraph.com/docs/en/about/
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, BNB, or RSK. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.
Projects with complex smart contracts like Sovryn store data on the blockchain, meaning that any data aggregation or larger amounts of historical data need to be processed, indexed and retrieved in a different way, as reading anything other than the current state directly from the blockchain is more complex.
For example, if we wanted to query for all Reward events corresponding to a certain address, and filter by one of its properties, we would not be able to get that information by interacting directly with the contract itself.
To get this data, you would have to process every single Reward event ever emitted, filter by the property, and then perform any additional manipulations to get the required dataset. Even for these types of relatively simple questions, it would take hours or even days for a decentralized application (dApp) running in a browser to get an answer.
You could also build out your own server, process the transactions there, save them to a database, and build an API endpoint on top of it all in order to query the data. However, this option is resource intensive, needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
Blockchain properties like finality, chain reorganizations, or uncled blocks complicate this process further, and make it not just time consuming but conceptually hard to retrieve correct query results from blockchain data.
The Graph solves the problems outlined above with a decentralized protocol that indexes and enables the performant and efficient querying of blockchain data. These APIs (indexed "subgraphs") can then be queried with a standard GraphQL API. Today, there is a hosted/self-hosted service as well as a decentralized protocol with the same capabilities. All of these are backed by the open source implementation of Graph Node. This means that no matter which method is used, the queries used to access the data will never need to change.
When we first launched the Sovryn dApp, we built our own indexing server that listens to, processes and stores transactions, and then an API on top of this. However, this quickly became resource and time consuming to maintain and scale to the levels we require - for this reason we have migrated any of this logic from the original service to our new Sovryn Subgraph.
As mentioned above, the Graph Protocol offers two different methods for capturing and exposing data:
Currently The Graph does not support Decentralized Network Subgraphs for the RSK network so we are using our own Hosted Subgraph - in the future when support for this is added, the transition can easily be made by pointing our Dapp Frontend to the Decentralized Subgraph, without needing to rewrite queries for additional optimizations. In addition, as the queries are written in the same GraphQL syntax regardless of what blockchain is used, this flexibility ensures a smooth migration with minimal changes if Sovryn were ever to branch out to other EVM compatible chains.
Below we have a high level view of how the information flows through the Graph Network to the Sovryn dApp:
The flow follows these steps:
While The Graph is the ideal framework for indexing blockchain data, it does have certain limitations.
One of these is that it can only react to blockchain data, but it cannot run scheduled jobs. Why is this an issue? Say, for example, you want to know what the 24 hour price change is of a token, and you want this data to be updated every 30 seconds. The Graph cannot do this kind of processing at scale. As an aside, the graph can respond to individual blocks instead of events, but this leads to much slower syncing times.
Our solution has been to build a suite of microservices that use data from The Graph (and sometimes directly from the contracts) to handle these types of cases. Our suite of microservices and API endpoints use The Graph as their source of truth, add some additional logic/processing, and serve this data as an API in the format that the Sovryn dApp (or other products/parties) require.
Our microservices are easily maintainable and extensible, and have paid off a large amount of the technical debt in our backend data services.