RESEARCH REPORT ABOUT THE GRAPH NETWORK

CoinEx Institution

Published in

Crypto Currency Hub

24 min readNov 3, 2020

Author: Gamals Ahmed, CoinEx Business Ambassador

ABSTRACT

The Graph is a protocol for organizing blockchain data and making it easily accessible. It’s powering many of the most used applications in DeFi and the broader Web3 ecosystem today. Anyone can build and publish subgraphs, which are open APIs that applications can query with GraphQL. Subgraphs make it easy for developers to build on blockchains. What Google does for search, The Graph does for blockchains.

Currently, The Graph’s hosted service is processing over 4 billion monthly queries for applications like Uniswap, CoinGecko and Synthetix, for data like token prices, past trade volumes, and liquidity. However, The Graph’s mission is not to run a hosted service in perpetuity but to eliminate the possibility for APIs, servers and databases becoming single points of failure and control. This is why they are building The Graph Network to create an open marketplace of Indexers and Curators that work together to efficiently index and serve all the data for DeFi and Web3 in a decentralized way.

1.INTRODUCTION

Anyone who has ever tried to build distributed applications (dApps) on the (Ethereum) blockchain would concur: Although blockchains are conceptually quite close to databases, querying databases feels like a different world entirely compared to querying blockchains.

First off, there are notable performance issues with storing data on blockchains. These have a lot to do with the distributed nature of blockchains, and the penalty imposed by the combination of consensus protocols and cryptography.

Databases would be slow, too, if they were comprised of a network of nodes in which every node kept a full copy of the entire database, and every transaction had to be verified by every node. This is why people have been experimenting with various approaches to use blockchains as a database, including altering blockchain structure.

The Graph does something different: it lets blockchains be, but offers a way to index and query data stored on them efficiently using GraphQL.

QUERYING BLOCKCHAINS

Actually, performance is only part of the issue with retrieving data from blockchains. It gets worse: Blockchains have no query language to speak of. Imagine a database with no query language! How would you ever get what you need out of it? How do people build dApps, really? With a lot of effort, and brittle, ad-hoc code.

Blockchain data access is challenging mainly due to three fundamental reasons: Decentralization, Opacity, and Sequential Data Storage. So people are left with a few choices:

Writing custom code to locate the data they need on blockchains, and either repeating those (expensive) calls every time they need the data, or retrieving the data once and storing in an off-chain database, and building an index to point to the original blockchain data.

Why querying data on blockchains is hard. Image: Jesus Rodriguez

This is where The Graph comes in. The Graph is a decentralized protocol for indexing and querying blockchain data. But it’s more than just a protocol: The Graph also has an implementation, which is open source and uses GraphQL.

GraphQL is a query language for APIs, developed and open sourced by Facebook. GraphQL has taken a life of its own, it’s gaining in popularity and being used to access databases, too — see Prisma or FaunaDB, for example.

ZDNet had a Q&A with The Graph’s co-founders, project lead Yaniv Tal and research lead Brandon Ramirez.

In Tal’s words, right now, teams working on dApps have to write a ton of custom code and deploy proprietary indexing servers in order to efficiently serve applications. Because all of this code is custom there’s no way to verify that indexing was done correctly or outsource this computation to public infrastructure.

By defining a standardized way of doing this indexing and serving queries deterministically, Tal went on to add, developers will be able to run their indexing logic on public open infrastructure where security can be enforced.

The Graph have open sourced all their main components including: Graph Node (an implementation of an indexing node built in Rust), Graph TS (AssemblyScript helpers for building mappings), and Graph CLI (Command line tools for speeding up development).

1.1 OVERVIEW ABOUT THE GRAPH NETWORK

The Graph is a decentralized protocol for indexing and querying data from blockchains, starting with Ethereum. It makes it possible to query data that is difficult to query directly.

The Graph is a protocol for building decentralized applications (dApps) quickly on Ethereum and IPFS using GraphQL. The idea behind The Graph is to provide a way to query a blockchain in a simple yet fast manner.

The Graph includes a Graph Node, which is an application that processes the entire blockchain and allows subgraphs to be registered on it. These subgraphs define what contracts to listen to and how to process the data when events are triggered on the contracts.

The Graph Network decentralizes the query and API layer of Web3, removing a tradeoff dApp developers struggle with today: whether to build an application that is performant or to build an app that is truly decentralized.

Today, developers can run a Graph Node on their own infrastructure, or they can build on their hosted service. Developers build and deploy subgraphs, which describe how to ingest and index data from Web3 data sources. Many leading Ethereum projects have already built subgraphs including: Uniswap, ENS, DAOstack, Synthetix, Moloch, and more. In The Graph Network, any Indexer will be able to stake Graph Tokens (GRT) to participate in the network and earn fees as well as inflation rewards for serving queries.

Consumers will be able to use this growing set of Indexers by paying for their metered usage, proving a model where the laws of supply and demand sustain the services provided by the protocol.

Today, it can be easy to retrieve some information from a blockchain like an account’s balance or the status of a specific transaction. However, things become more complicated when we want to query specific information, such as a transaction list for an account of a particular contract. Sometimes the data persisted in a contract cannot be used directly for specific purposes, and transformations need to be done. Here is where The Graph and its subgraphs become really helpful.

The Graph Network is core infrastructure for Web3 — a necessary component for delivering decentralized applications with consumer-grade performance.

The Graph network will allow apps to be serverless — making them truly unstoppable since they’ll no longer rely on a single server or database but rather a network of nodes that are incentivized to keep the service running. The Graph Network also lets diverse, active participants earn income for providing data services rather than giving that power to data monopolies.

The Graph is transforming the existing data economy to one with better incentives, safer data sources, curated APIs and more expressive querying. The Graph Network will be launching later this year.

Quick Take:

The Graph, a San Francisco-based startup, has developed an indexing protocol that organizes all the information on the blockchain in an efficient way.
Many Ethereum applications are using the protocol to improve user experience.
The firm plans to use its latest funding to eliminate single points-of-failure.

1.1.1 FULL-STACK DECENTRALIZATION

The mission of The Graph is to enable internet applications that are entirely powered by public infrastructure.

Full-stack decentralization will enable applications that are resistant to business failures and rent seeking and also facilitate an unprecedented level of interoperability. Users and developers will be able to know that software they invest time and money into can’t suddenly disappear.

Today, most “decentralized” applications only adopt such a model in the bottom layer of the stack — the blockchain — where users pay for transactions that modify application state. The rest of the stack continues to be operated by centralized businesses and is subject to arbitrary failures and rent seeking.

1.1.2 THE GRAPH NETWORK ORIGINS

The cofounders — Jannis Pohlmann, Brandon Ramirez. They spent considerable time thinking about how to build software faster. They built frameworks, developer tools, and infrastructure to make application development more productive.

When they started diving into Ethereum in early 2017, it was apparent that the tooling and lack of mature protocols made it difficult to build dApps. The idea of making open data more accessible became an obsession of thier and The Graph was born.

They built the first prototype in late 2017. They spent months iterating on the design over whiteboard sessions, prototyping, and conversations with developers. They wanted to find a productive developer experience for writing indexing logic that could be securely operated on a decentralized network.

1.1.3 THE GRAPH, AN OPEN SOURCE PROTOCOL AND IMPLEMENTATION

As per Tal, the core of what The Graph have done? is to define a deterministic way of doing indexing. Graph Node defines a store abstraction that they implement using Postgres:

“Everything you need to run a subgraph is open source. Right now, we use Postgres under the hood as the storage engine. Graph Node defines a store abstraction that we implement using Postgres and we reserve the right to change the underlying DB in the future. We’ve written a lot of code but it’s all open source so none of this is proprietary.” Tal said.

The subgraph that Tal refers to here is simply a part of the blockchain used to store data for specific dApps. Defining a subgraph is the first step to use The Graph. Subgraphs for popular protocols and dApps are in use already, and can be browsed using the Graph Explorer, which provides a user interface to execute GraphQL queries against specific smart contracts or dApps.

When The Graph was introduced in July 2018, Tal mentioned they would launch a local node, a hosted service, and then a fully decentralized network. The hybrid network is a version of the protocol design that bridges the gap between the hosted service, which is mostly centralized, and the fully decentralized protocol.

Users can run their own instance of The Graph, or they can use the hosted service. This inevitably leads to the question about the business model employed by The Graph, as running a hosted service costs money.

2. THE GRAPH NETWORK ARCHITECTURE

The Graph Network includes smart contracts that run on Ethereum combined with a variety of additional services and clients that operate off-chain.

2.1 QUERY MARKET

The query market serves a similar purpose to an API in a traditional cloud-based application — efficiently serving data required by a front end running on a user’s device. The key difference is that whereas a traditional API is operated by a single economic entity that users have no say over, the query market comprises a decentralized network of Indexers, all competing to provide the best service at the best price.

The typical flow interacting with the query market.

Service Discovery. The consumer asks The Graph which Indexers have the data they are interested in.
Indexer Selection. The consumer selects an Indexer to transact with based on which they deem most likely to provide the highest quality service at the best price.
Query + Conditional Micropayment. The consumer sends the Indexer a query along with a conditional micropayment that specifies how much they are willing to pay for compute and bandwidth.
Response + Attestation. If the Indexer accepts the price offered by the consumer, then they process the query and respond with the resulting data, as well as an attestation that this response is correct. Providing this attestation unlocks the conditional micropayment.
The attestation is produced deterministically and is uniquely attributable to the Indexer for the purposes of verification and dispute resolution elsewhere in the protocol.
A single decentralized application querying The Graph may use multiple subgraphs indexed by different Indexers and in that case would go through the above flow for each subgraph being queried.

2.2 PROTOCOL ROLES

These are the roles that interact with the system, the behaviors they must engage in for the protocol to function correctly. And what incentives motivate them?

Consumers. Consumers pay Indexers for queries. These will typically be end users but could also be web services or middleware that integrate with The Graph.
Indexers. Indexers are the node operators of The Graph. They are motivated by earning financial rewards.
Curators. Curators use GRT to signal what subgraphs are valuable to index. These will typically be developers but they could also be end users supporting a service they rely upon or a persona that is purely financially motivated.
Delegators. Delegators put GRT at stake on behalf of an Indexer in order to earn a portion of inflation rewards and fees, without having to personally run a Graph Node. They are financially motivated.
Fishermen. Fishermen secure the network by checking if query responses are accurate. Fishermen are altruistically motivated, and for that reason, The Graph will initially operate a fisherman service for the network.
Arbitrators. Arbitrators determine whether Indexers should be slashed or not during dispute resolution. They may be financially or altruistically motivated.

2.3 USES OF THE GRAPH PROTOCOL

1. For Developers

For developers, the APIs for building a subgraph will remain largely the same as it is using a local or hosted Graph Node.

One notable difference is in how developers deploy subgraphs. Rather than deploying to a local or hosted Graph Node, they will deploy their subgraph to a registry hosted on Ethereum and deposit a stake of GRT to curate that subgraph. This serves as a signal to Indexers that this subgraph should be indexed.

2. For End Users

For end users, the major difference is that rather than interacting with centralized APIs that are subsidized, they will need to begin paying to query a decentralized network of Indexers. This will be done via a query engine running on their machine — either in the browser, as an extension, or embedded in the dApp.

The query engine allows the user to safely query the vast amounts of data stored on The Graph without having to personally do the work to compute and store that data. The query engine also acts as a trading engine, making decisions such as which Indexers to do business with or how much to pay, based on the dApp being used or the user’s preferences.

For the query engine to provide a good user experience, it will need to automatically sign micropayment transactions on behalf of users rather than prompting them for every transaction that needs signing. We’re working with several state channel teams building on Ethereum to make sure that the wallets and functionality they ship meets the needs of metered usage protocols like The Graph. In the meantime, we will host a gateway that allows dApps to subsidize queries on behalf of users.

3. For Indexers

Indexers will be able to join The Graph by staking GRT and running a version of Graph Node.

They will also want to run an indexer agent that programmatically monitors their resource usage, sets prices, and decides which subgraphs to index. The indexer agent will be pluggable, and we expect that node operators will experiment with their own pricing models and strategies to gain a competitive edge in the marketplace over other Indexers.

For Curators and Delegators

Curators and delegators will curate and delegate via Graph Explorer. When we launch the network, Graph Explorer will be a fully decentralized application, and using it will require a dApp-enabled browser with an Ethereum wallet.

4. USING GRAPHQL WITH DAPPS

Now, GraphQL is popular, and it certainly beats having no query language at all. But there are also some popular misconceptions around it, and it’s good to be aware of them when considering The Graph, too. A significant part of GraphQL, added relatively recently, is its SDL (Schema Definition Language). This may enable tools to center the development process around a GraphQL schema.

Developers may create their domain model in SDL, and then use it not just to validate the JSON returned by GraphQL, but also to generate code, in MDD (Model Driven Development) fashion. In any case, using GraphQL does not “magically” remove the complexity of mapping across many APIs. It simply abstracts and transposes it to the GraphQL resolver.

So unless there is some kind of mapping automation/maintenance mechanism there, the team that uses the APIs abstracted via GraphQL may have a better experience, but this is at the expense of the team that maintains the API mappings. There’s no such thing as a free lunch, and the same applies for blockchains.

Even more so, in fact, as smart contracts cannot at this point be driven by GraphQL Schema. You first need to create a smart contract, then the GraphQL Schema and resolver for it. This makes for a brittle and tiresome round-trip to update schema and resolver each time the smart contract changes. Ramirez acknowledged this, and elaborated on the process of accessing smart contract data via GraphQL:

“The GraphQL schema is used to express a data model for the entities, which will be indexed as part of a subgraph. This is a read-schema, and is only exposed at layer two, not in the smart contracts themselves. Ethereum doesn’t have the semantics to express rich data models with entities and relationships, which is one reason that projects find querying Ethereum via The Graph particularly useful.

If a smart contract ABI changed in breaking ways, then this could require mappings to be updated if they were relying on the parts of the interface, but this isn’t a Graph specific problem, as any application or service fetching data directly from that smart contract would have similar problems. Generally making breaking changes to an API with real usage is a bad idea, and is very unlikely to happen in the smart contract world once shipped to production and widely used (defeats the purpose). Part of the “magic” of The Graph is that they auto-generate a “read schema” and resolvers

based on your data model. No need to maintain anything but the data model schema and the mappings, which shouldn’t need to change often. We’re also adding support for custom resolvers, however, for more advanced users.”

2.4 GRAPH TOKENS

To support the functioning of the query market, the protocol introduces a native token: Graph Tokens (GRT).

Graph Tokens have two primary uses in the protocol:

Indexer Staking. Indexers deposit Graph Tokens to be discoverable in the query market and to provide economic security for the work they are performing.
Curator Signaling. Curators deposit Graph Tokens in a curation market, where they are rewarded for correctly predicting which subgraphs will be valuable to the network.

Consumers will be able to pay for queries in ETH or DAI. Payments will be settled, however, in GRT to ensure a common unit of account across the protocol.

According to Ramirez, The Graph’s business (token) model is the work token model, which will kick off when they launch the hybrid network. Indexing Nodes, which have staked to index a particular dataset, will be discoverable in the data retrieval market for that dataset. Payment in tokens will be required to use various functions of the service.

The hosted service, Ramirez went on to add, ingests blocks from Ethereum, watches for “triggers,” and runs WASM mappings, which update the Postgres store. There are currently no correctness guarantees in the hosted service, as you must trust The Graph as a trusted party.

In the hybrid network there will be economic security guarantees that data is correct, and in the fully decentralized network, there will be cryptographic guarantees as well. The goal would be to transition everyone on the hosted service to the hybrid network once it launches, although Ramirez said they wouldn’t do this in a way that would disrupt existing users.

2.4.1 INDEXER STAKING

The Graph adopts a work token model, where Indexers must stake Graph Tokens in order to sell their services in the query market. This serves two primary functions.

It provides economic security, as the staked GRT can be slashed if Indexers perform their work maliciously. Once GRT is staked, it may only be withdrawn subject to a thawing period, which provides ample opportunity for verification and dispute resolution.
It provides a Sybil resistance mechanism. Having fake or low quality Indexers on a given subgraph makes it slower to find quality service providers. For this reason we only want Indexers who have skin in the game to be discoverable.

In order for the above mechanisms to function correctly, it’s important that Indexers are incentivized to hold GRT roughly in proportion to the amount of useful work they’re doing in the network.

A naive approach would be to try to make it so that each GRT staked entitles an Indexer to perform a specified amount of work on the network. There are two problems with this: first, it sets an arbitrary upper bound on the amount of work the network can perform; and second, it is nearly impossible to enforce in a way that is scalable, since it would require that all work be centrally coordinated on-chain.

A better approach has been pioneered by the team at 0x, and it involves collecting a protocol fee on all transactions in the protocol, and then rebating those fees to participants as a function of their proportional stake and proportional fees collected for the network, using the Cobb-Douglas production function.

2.4.2 CURATOR SIGNALING

For a consumer to query a subgraph, the subgraph must first be indexed — a process which can take hours or even days. If Indexers had to blindly guess which subgraphs they should index on the off-chance that they would earn query fees, the market would not be very efficient.

Curator signaling is the process of depositing GRT into a bonding curve for a subgraph to indicate to Indexers that the subgraph should be indexed.

Indexers can trust the signal because when curators deposit GRT into the bonding curve, they mint curation signal for the respective subgraph, entitling them to a portion of future query fees collected on that subgraph. A rationally self-interested curator should signal GRT toward subgraphs that they predict will generate fees for the network.

Using bonding curves — a type of algorithmic market maker where price is determined by a function — means that the more curation signal are minted, the higher the exchange rate between GRT and curation signal becomes. Thus, successful curators could take profits immediately if they feel that the value of future curation fees has been correctly priced in. Similarly, they should withdraw their GRT if they feel that the market has priced the value of curation signal too high.

This dynamic means that the amount of GRT signaled toward a subgraph should provide an ongoing and valuable market signal as to the market’s prediction for future query volume on a subgraph.

2.5 INDEXER INFLATION REWARD

Another mechanism they employ related to indexer staking and curator signaling is the indexer inflation reward.

This reward is intended to incentivize Indexers to index subgraphs that don’t yet have significant query volume. This helps to solve the bootstrapping problem for new subgraphs, which may not have pre-existing demand to attract Indexers.

The way it works is that each subgraph in the network is allotted a portion of the total network inflation reward, based on the proportional amount of total curation signal that subgraph has. That amount, in turn, is divided between all the Indexers staked on that subgraph proportional to their amount of contributed stake.

2.6 GRAPH EXPLORER AND GRAPH NAME SERVICE

Curating subgraphs for Indexers is only half of the story when it comes to surfacing valuable subgraphs. They also want to surface valuable subgraphs for developers.

This is one of the core value propositions of The Graph — to help developers find useful data to build on and make it effortless to incorporate data from a variety of underlying protocols and decentralized data sources into a single application.

Currently, developers accomplish this by navigating to Graph Explorer:

In The Graph Network, Graph Explorer will be a dApp, built on top of a subgraph that indexes the Graph Protocol smart contracts (meta, I know!) — including the Graph Name Service (GNS), an on-chain registry of subgraphs.

A subgraph is defined by a subgraph manifest, which is immutable and stored on IPFS. The immutability is important for having deterministic and reproducible queries for verification and dispute resolution. The GNS performs a much needed role by allowing teams to attach a name to a subgraph, which can then be used to point to consecutive immutable subgraph “versions.”

These human readable names, along with other metadata stored in the GNS, allows users of Graph Explorer to get a better sense for the purpose and possible utility of a subgraph in a way that a random string of alphanumeric characters and compiled WASM byte code does not.

In The Graph Network, discovering useful subgraphs will be even more important, as they will be shipping subgraph composition. Rather than simply letting dApps build on multiple separate subgraphs, subgraph composition will allow brand new subgraphs to be built that directly reference entities from existing subgraphs.

This reuse of the same subgraphs across many dApps and other subgraphs is one of the core efficiencies that The Graph unlocks. Compare this approach to the current state of the world where each new application deploys their own database and API servers, which often go underutilized.

2.7 INCENTIVES IN THE GRAPH NETWORK

GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Curators and Delegators cannot be slashed for bad behavior, yet there is a withdrawal tax on Curators and Delegators to disincentivize poor decision making that could harm the integrity of the network. Curators also earn fewer query fees if they choose to curate on a low-quality

subgraph, since there will be fewer queries to process or fewer indexers to process those queries.

2.7.1 QUERY MARKETPLACE

Indexers that stake GRT operate in a query marketplace where they earn query fees for indexing services and serving queries to subgraphs — like serving Uniswap trade data on Uniswap.info. The price of these queries will be set by Indexers and vary based on cost to index the subgraph, the demand for queries, the amount of curation signal and the market rate for blockchain queries. Since Consumers (ie. applications) are paying for queries, the aggregate cost is expected to be much lower than the costs of running a server and database.

A Gateway can be used to allow consumers to connect to the network and to facilitate payments. The team behind The Graph will initially run a set of gateways that allows applications to cover the query costs on behalf of their users. These gateways facilitate connecting to The Graph Network. Anyone will be able to run their own gateways as well. Gateways handle state channel logistics for query fees, and route to Indexers as a function of price, performance and security that is predetermined by the application paying for those queries.

2.7.2 INDEXING REWARDS

In addition to query fees, Indexers and Delegators will earn indexing rewards in the form of GRT that is new token issuance distributed proportional to Curator signal and allocated stake. Indexing rewards will start at 3% annually. Future GRT monetary policy will be set by an independent technical governance which will be established as we approach network launch.

The Graph Network will have epochs which are measured in blocks and are used for the Indexing Rewards calculations.

2.7.3 COBBS-DOUGLAS PRODUCTION FUNCTION

In addition to query fees and indexing rewards, there is a Rebate Pool that rewards all network participants based on their contributions to The Graph Network. The rebate pool is designed to encourage Indexers to allocate stake in rough proportion to the amount of query fees they earn for the network.

A portion of query fees contributed to the Rebate Pool are distributed as rebate rewards using the Cobbs-Douglas Production Function, a function of contributions to the pool and their allocation of stake on a subgraph where the query fees were generated. This reward function has the property that when Indexers allocate stake in proportion to their share of contribution of fees to the rebate pool, they will receive back exactly 100% of their contributed fees back as a rebate. This is also the optimal allocation.

2.7.4 PROTOCOL SINKS & BURNS

A portion of protocol query fees are burned, expected to start at ~1% of total protocol query fees and subject to future technical governance. The aforementioned withdrawal tax that is incurred by Curators and Delegators withdrawing their GRT is also burned, as well as any unclaimed rebate rewards.

2.7.5 DELEGATION PARAMETERS

Each Indexer specifies how Delegators are rewarded based on the following two delegation parameters:

Reward cut — The % of indexing rewards that the Indexer keeps.
Fee cut — The % of query fees that the Indexer keeps.

Indexers accept delegated stake according to a delegation capacity, which is a multiple of their own contributed stake. This ratio between Indexer and Delegator stake will be set through technical governance.

2.8 CONDITIONAL MICROPAYMENTS

Payment channels is a technology that has been developed for scalable, off-chain, trust-minimized payments. It involves two parties locking funds on-chain in an escrow where the funds may only be used to exchange funds off-chain between them until a transaction is submitted on-chain to withdraw funds from the escrow.

Traditionally, payment channel designs have emphasized securely sending a micropayment off-chain without regard for whether or not the service or good being paid for was actually received.

There has been some work, however, toward atomic swaps of micropayments for some digital good or outsourced computation, which the graph’s team build on here. They call their construction WAVE Locks. WAVE stands for work, attestation, verification, expiration, and the general design is as follows:

1. Work. A consumer sends a locked micropayment with a description of the work to be performed. This specification of the work acts as the lock on the micropayment.

2. Attestation. A service provider responds with the digital good or service being requested along with a signed attestation that the work was performed correctly.

3. Verification. The attestation is verified using some method of verification. There may be penalties, such as slashing, for attesting to work which was incorrectly performed.

4. Expiration. The service provider must either receive a confirmation of receipt from the consumer or submit their attestation on-chain to receive their micropayment before the locked micropayment expires.

2.9 VERIFICATION

In order for the WAVE Locks construction and indexer staking to be meaningful, there must be an effective verification mechanism that is capable of reproducing the work performed by an Indexer, identifying faults and slashing offending Indexers.

In the first phase of The Graph Network, this is handled through an on-chain dispute resolution process, which is decided through arbitration.

Fishermen submit disputes along with a bond, as well as an attestation signed by an Indexer. If the Indexer is found to have attested to an incorrect query response, the fisherman

receives a portion of the slashed amount as a reward. Conversely, the fisherman’s bond is forfeit if the dispute is unsuccessful.

Importantly, the fisherman’s reward must be less than the slashed amount. Otherwise, malicious Indexers could simply slash themselves to get around thawing periods or avoid slashing by someone else.

In the long run, as the network becomes more reliable, the Graph’s team would expect the reward to active fishermen to dwindle to near zero. Thus, even though there is a fisherman’s reward, they consider this actor to be motivated by altruistic incentives.

For that reason, initially, there will be a fisherman service where consumers may post attestations, and they will take on the responsibility of verifying query responses and submitting disputes on-chain. Of course, anyone who wishes may also perform this role.

Additionally, in the early days of the network, there will be an arbitration service set via protocol governance, which will act as the sole arbitrator in the dispute resolution. This allows the team to exercise judgment when incorrect queries may arise because of bugs in the software, Indexers missing events from the blockchain, or other accidental factors that could lead to a slashable offense.

Eventually, as the software matures, Indexers will be expected to develop the operational expertise to avoid these sorts of errors.

2.10 THE FUTURE WORK

The crypto economy is a radical new imagining of the future of work. Open protocols will create transparency and opportunity, enabling anyone in the world to contribute their talents to a global economy. The Graph want to support this vision and help developers build the new coordination mechanisms of the internet age.

Future work on The Graph Network involves exploring new market mechanisms and parameterization of existing mechanisms, which will make the query market more dynamic and efficient. The latter will involve running agent-based and dynamic simulations on the existing mechanism design, as well as analyzing the network after launch.

The contracts will be upgradeable so the protocol can continue to be improved after launch.

In the longer term, the Graph would like to eliminate the roles of fisherman and arbitrator altogether, by relying on authenticated data structures, consensus and cryptographic proofs.

3. THE GRAPH PROTOCOL COMMUNITY

Website: https://thegraph.com/

Twitter: 14.6k followers https://twitter.com/graphprotocol

Medium: https://medium.com/graphprotocol

Telegram: 8.9k subscribers https://t.me/graphprotocol

Reddit: 278 members https://www.reddit.com/r/thegraph/

Github: https://github.com/graphprotocol

4. REFERENCES

Don’t forget to give us your 👏 !