GIP-0042 A World Of Data Services

Governance & GIPs Graph Improvement Proposals (GIP)
9

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 :slight_smile: 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.

9 Likes