# GIP-0042 A World Of Data Services

**URL:** <https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761>\
**Category:** Graph Improvement Proposals (GIP)\
**Created:** [December 1, 2022, 2:05pm UTC](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761 "2022-12-01T14:05:02Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![Sam](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/sam/32/757_2.png) [@Sam](https://forum.thegraph.com/u/Sam)\
**Post date:** [February 17, 2023, 4:30am UTC](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761/9 "2023-02-17T04:30:50Z")

</div>

I’m really excited about this proposal. I’d like to focus on the topic of the verifiability router and propose some reframing.

In changes we have:

> 1. Verifiability router: Instead of using a single dispute mechanism, expand the  
> contracts to allow a different dispute mechanism for each supported data  
> service type, and to allow this dispute mechanisms to change over time. The  
> existing disputes mechanism is kept for subgraphs. Additional data service  
> types can then specify their own contract based on disputes or verifiable  
> proofs.

Would it be appropriate to expand the scope of “dispute mechanisms” to encompass “consensus mechanisms”? I see a dispute as something that happens after there has been a failure in consensus. I would be excited to see us move toward a “programmable consensus” future where a consumer gets to decide what consensus and dispute mechanism they require. Here are three examples of different consensus and dispute mechanisms. I’m focusing on subgraphs, but I think the reasoning can extend to all of our future data services:

1. Subgraph A deployment: no consensus required. Consumers of this deployment trust that Indexers in The Graph are doing their best job. Not willing to pay for zk, POI checking, human arbitration, or anything other than the query result. Likely only used for low-impact data. Cheap but no dispute is available.
2. Subgraph B deployment: `n` out of `m` Indexer query results required. This consumer only trusts `m` Indexers in The Graph and will pay `n` out of `m` of them to return the query result. No dispute is available.
3. Subgraph C deployment: zk-proofs of indexing and querying will be returned with all queries. If a proof does not verify, the Indexer gets slashed. Expensive but useful for critical data and does not require trusted relationships.

The VI/VQ discussion is still early, but in general, there is chatter among core devs that different subgraphs may require different approaches for verifiability. (And of course, substreams, Firehose, etc. will, as already said in the GIP intro.) E.g. erc-20 vs. erc-721 vs. custom contract may be more efficiently verified in different ways. Additionally, as given in use case 1, some subgraph data may not be valuable enough to have any verifiability guarantees.

Basically, I would like consumers to have as much flexibility as possible/practical in deciding the verifiability guarantees that come along with their data. From the above, I hope it’s clear that I like this idea because it would allow us to price queries more efficiently. But that’s not the only reason 🙂 I’m also a fan of programmable consensus because it could potentially more quickly get us to instant verifiability and dispute resolution for some use cases. For example, I would love to get access to verified aggregated erc-20 data that’s always up to the chain head, e.g. the average USDC-ETH ratio. Such data, when authenticated, could then be immediately used as calldata on-chain with The Graph serving as a just-in-time oracle.

---

_[View the full topic](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)._