Rooted in decentralization with the Graph
While building Root’s blockchain stack, we put a lot of thought into how to improve user experience without compromising the decentralization philosophy of web3. And I can proudly say that at Root we have managed to achieve this for our web2 native users. Digital assets made or bought from Root are completely owned by the user, and we do this without ruining the user experience at any point. From the ownership of the NFT contract to the profit made from sales all goes to the user-owned non-custodial wallets.
We were able to achieve this thanks to several web3 tools built by different teams like web3auth for social logins that create non-custodial wallets on behalf of users using multi-part computation. This means the user with his exact device + social + password can only access his wallet, no centralized entity has all 3 components except the user. We use open zeppelin defender for creating a relay server that pays for the user's transaction so that all blockchain interactions through Root are gasless. Though these minor details will only be noticed by seasoned web3 natives. Any normal internet user will feel like they are using just another web2 application.
And the most important service that has helped Root go from MVP to beta in 3 months was the Graph. I cannot overstate how much graph protocol has helped us reach this stage with zero overhead on database infrastructure. Every interaction user makes on the blockchain through Root had to be indexed or saved in a local database for easy and faster access. Like the user nonce of meta transactions, addresses of collections, token Id of minted NFTs, the balance of NFTs, seaport sales, used referral codes, etc. But we already have 2 databases for user-related data and nft-related data. So creating another one or adding to the existing databases would have complicated things a lot and it would require more time fixing bugs than building it. That’s when I remembered the graph protocol workshop by Nader dabit which I attended at ETHDubai. I had some idea of what the graph was about from the workshop so I decided to give it a try. And the result was we successfully launched our pilot project in 3 months. It was a seamless and fast experience as a user and as a developer too.
And the best thing is it doesn’t end here, I already know a lot of other use cases that subgraphs can do better than any other web3 api services out there. If I have any requirement I don’t have to look for services that provide that particular endpoint. I just create a subgraph with the correct schema. And in a few hours, my API is ready for almost any chain and based on any contract. A subgraph is a set of rules you write for a particular contract you have chosen and asks the graph protocol to index it for you, in a way that you want to query it. Subgraph is to graph protocol what git repo is to GitHub. Anyone can deploy a subgraph, and anyone can query it. Now when it comes to the cost the graph keeps surprising you because the data is indexed and served by a decentralized network of indexing servers. So by combining the network of indexers with the tokenomics of GRT token, they have created a healthy market competition for API services. Which means better prices for consumers. In the end, you only pay for what you use.
There are some shortcomings in the current version of subgraphs. Right now, the subgraphs mainly focus on indexing logged event data and contract function calls (but function calls are indexed slower than logs). It doesn’t index EOA-based transactions or contract calls. Also indexing almost every contract for general-purpose API will take days to sync on data-heavy chains like Polygon. Though I believe the team is already working on solutions like substreams. From what I understand it helps developers index data much faster and writes composable subgraphs. I am definitely excited about the future of The Graph. Looking forward to utilizing graph protocol and building Root with decentralization at its core.
