Overview
Last updated
Last updated
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 . 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:
Self-Hosted/Hosted Subgraph
Decentralized Network Subgraph (hosted on the network itself)
Currently The Graph does not support Decentralized Network Subgraphs for the Rootstock 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 Network 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:
Sovryn adds data to the Rootstock blockchain through a transaction on a smart contract.
The smart contract emits one or more events while processing the transaction.
Graph Node continually scans Rootstock for new blocks and the data they may contain for our subgraph.
Graph Node finds Rootstock 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 Rootstock 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 Rootstock. The cycle repeats.
Anyone can query subgraphs. Out-of-the-box support for the flexible GraphQL API, which makes it easier for external developers to interact with data from the Sovryn ecosystem, with no reliance on Sovryn to provide data in a specific format
Robust and reliable data
Less developer effort required to maintain indexing server
Faster iteration for data queries and debugging logic
Better developer experience
Greater transparency of how values are derived from on-chain data
Easy transition to other chains if required
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.
Users are encouraged to explore and use The Graph. Community members on various projects have built entire dashboards around queries to The Graph and similar blockchain databases.
The following repositories contain code and documentation regarding Sovryn subgraphs:
To help users get started, we have provided documentation. We encourage you to ask questions on Discord and make suggestions on how to improve the documentation. Please share your insights with the community if you develop an interesting query.
Sovryn Subgraph:
Zero Subgraph:
AMM APY:
Graph Wrapper:
Graph Protocol documentation:
GraphQL documentation: