User Avatar

Elena Mikhaylova

Web3: The Graph Protocol

4y ago

Follow me for web3 tinkering, and occasional learnings on healthy living and feeling our best. Twitter: @mikleens

Demystifying the inner workings of 'Web3' using The Graph Protocol
Elena Mikhaylova

While the theory of decentralized applications in web3 makes sense, my understanding felt similar to the way I understand my car.

I could get in and drive it anywhere, but ask me to change the oil and I am in trouble.

I had some "aha" moments when I started learning how the Graph Protocol goes about storing data for a decentralized app, and the whole thing seems alot less scary now, and I'd like to share that with you!

We can abandon the changing the the oil as a lost cause.

Some context:

The Graph Protocol exists because blockchain has a problem - querying information written on the blockchain can incredibly inefficient.

Most decentralized applications need to store an accessible copy of the data written on the chain in their own databases, so they can retrieve information quickly.

The Graph Protocol lets applications do this via a subgraph: a decentralized database which indexes an applications data on the blockchain.

We can see dApp activity from its smart contract address.

All decentralized applications have one (or more) smart contracts.

This means their application code lives on a blockchain, accessible and readable to anyone which knows its blockchain address. One of those just looks like this:

0xabEFBc9fD2F806065b4f3C237d4b59D9A97Bcac7

Smart contracts are able to communicate any change to data by sending out an event.

In the case of ERC721-complaint NFTs, anytime a token is transferred, the smart contract must emit an event which communicates to the listeners that "this token was transferred".

The subgraph will store data from smart contract events.

A subgraph can simply listen for events from a specific smart contract address.

For example, we might have a smart contract which powers an NFT marketplace.

If a transaction takes place via that contract, and NFT marketplace will emit an event that UserA transferred an NFT to UserB.

The subgraph would capture this event, and update its own copy of the data: remove the NFT from the UserA entry, and add it to the UserB entry.

Now, if anyone queries that subgraph for UserB, they will see they own an additional NFT, and a query on UserA will show they no longer hold it.

Takeaways

99% of the time, when we are looking at decentralized apps - what we really see is hopefully a really really good copy. We have to rely on these applications to accurately show the information actually written in the chain.

The cool thing about the Graph Protocol is that its ecosystem selects for this through monetary incentives!

Subgraphs which are accurate and have useful data will attract more traffic, and generate higher returns for the network members which are throwing their GRT behind it, and we can get more guarantees that the information is true.