<aside> 🚨 Status: this document is now outdated. For the latest version see: https://github.com/graphprotocol/graph-improvement-proposals/pull/73

</aside>

---
GIP: 0066
Title: Introducing Graph Horizon - A data services protocol
Authors: TBD
Created: 2024-05-03
Updated:
Stage: Draft
Discussions-To: <https://forum.thegraph.com/t/><xxxx>
Category: Protocol Logic, Protocol Interfaces, Economic Parameters
Depends-On: GIP-0068
Implementations: <https://github.com/graphprotocol/contracts/pull/944>
Audits:
---

Abstract

In this proposal we present our design for Graph Horizon, a data services protocol which is the next evolution of The Graph. We also introduce the Data Service framework, a library and set of guidelines to develop data services using Graph Horizon primitives; and the Subgraph Service, the first data service built to support the current use case of The Graph, indexing subgraphs.

These changes require a complete redesign, upgrading most of the protocol contracts. A companion GIP-0068 (<link to GIP>) will cover the details of the Subgraph Service. Note however that both GIPs should be treated as a unit, meaning one cannot be implemented without the other.

Finally, the Graph Council has expressed support for the the brownfield approach so we propose a way of safely transitioning from the current version of the protocol to Graph Horizon.

Motivation

The Graph launched over two years ago with the objective of being an efficient and censorship-resistant protocol that can scale to organize all of the world’s public data and information. Since then there have been significant changes in the ecosystem and we’ve learned from conversations with many users and contributors. GIP-0042 introduced the concept of data services, recognizing that other approaches besides subgraphs are possible. Graph Horizon expands on this idea, presenting a modular, composable and permissionless staking and payments protocol that can be leveraged by different data service implementations to offer a wide range of solutions to satisfy all data needs.

Graph Horizon is the result of reconsidering the mechanisms of The Graph from first principles, it’s about iterating upon the existing protocol to ensure The Graph fulfills its mission and remains core and reliable infrastructure for web3.

Prior Art

This proposal is the result of almost two years of work from researchers and developers from various core dev teams in The Graph ecosystem, it ties up a few ideas outlined in The Graph R&D roadmap and enables others. Some of them have already surfaced in one form or another, see: GIP-0042, GIP-0054, GIP-0058 and Graph Horizon explained. Reading the “Graph Horizon Explained” forum post before this proposal is highly encouraged to understand the context and rationale behind the ideas we describe.

High-Level Description

Graph Horizon aims to facilitate permissionless competition of data services, it’s a data services protocol composed of two complementary components: staking and payments. In this section we outline the design and target state of the protocol, later sections will deal with how we get there considering the current state as the starting point.

Before we start, a few definitions:

data service, a service designed to run on Graph Horizon that makes data available for consumers. In general data services will be comprised of both offchain and onchain components, with each one having it’s own smart contracts at the chain level. Potential examples include: Subgraphs, Firehose, Substream, SQL or LLM queries. A data service doesn’t need to be restricted to a data response-request type of service, and can include other types of applications like oracles, challenge systems, and others. Essentially, data services are new protocols built on top of The Graph. We focus on data as the natural extension of subgraphs, but a lot of DePIN use-cases could be served by the same primitives.
service provider, the entity providing the service. In the case of the Subgraph Service they are known as indexers. For most data services this is probably also the case, however to accommodate any future data services where the indexing term might not make sense we utilize a generic term, “service provider”.