GIP-0065: Subgraph Availability Manager

Abstract

This GIP proposes increasing the decentralization in The Graph by introducing a new smart contract SubgraphAvailabilityManager.

Motivation

The Subgraph Availability Oracle (SAO) plays a crucial role in The Graph’s ecosystem. Its main function is to verify the availability and validity of subgraph files. Currently there is a single instance of the SAO in operation executing open-source code accessible at The Graph’s Subgraph Oracle repository. This SAO instance runs at five-minute intervals, performing a series of checks to assess the state of subgraph files. In instances where the SAO identifies unavailability or invalidity in a subgraph’s files, it sends a transaction to the RewardsManager contract to deny indexing rewards for that subgraph.

The proposed change aims to enhance the decentralization of the protocol by introducing five separate oracles operators and requiring a minimum of three votes among them before any decisive action is taken. All oracles operators will be bound by the Subgraph Availability Oracle Operator Charter included in this GIP which outlines their roles, responsibilities, and operational guidelines.


The full details about this proposal can be found here: Github PR
Implementation can be found here: Github PR

8 Likes

Hi all.

Sharing some updates on this GIP:

  1. The GIP was reviewed and voted on by the TAB (Technical Advisory Board). Notes below.
  2. The Graph Council officially voted in favor :white_check_mark: of this GIP, with input from the TAB.
  3. Five core dev teams (Edge & Node, GraphOps, Pinax, Semiotic, and The Guild) will now enter the testing phase, each setting up their SAO instance and coordinating future upgrades with dry runs using The Graph’s testnet in preparation for mainnet.

TAB review & vote

:white_check_mark: Approvals: 5/6
:x: Rejections: 1/6
:face_with_monocle: Reviews: 6/6

Approvals :white_check_mark:

@ellipfra, April 17, 2024 :

I see the current implementation as first step in the right direction. We want to move away from having a single operator for key network functions, and it’s better to have an imperfect solution than the status quo. We shouldn’t be surprised when we’ll have to schedule work for phase 2 relatively soon. Let’s keep an eye on operating costs


@hhkyen, April 16, 2024 :
I agree with the criticisms on how this GIP doesn’t completely solve the decentralization problem, nor is the problem itself urgent or a significant improvement to the protocol. I’m approving because I think this is sufficient as an intermediate solution to distribute the responsibility of managing subgraph availability.


@facuspagnuolo, April 16, 2024:

Even though I don’t see this as an urgent priority for now, I think it’s a good idea to start thinking of how this type of process could be decentralized. As mentioned in the review comments, there are many edge cases that should be considered and must be discussed in future opportunities to ensure its proper scalability. That said, I support the idea of spending time on this topic ahead of time.


@DataNexus, April 16, 2024 :
The proposal has a clear benefit and the only issues I foresee would be edge cases around scaling potential in an extreme environment (# of subgraphs and gas costs). In the circumstance where we have millions of subgraphs, the network will have achieved a new level of success and we can look at adjustments. In the event of gas costs, we could move to an offchain consensus and reporting the results back on chain, but that doesn’t seem necessary at this point.


Rejections :x:
@Anirudh Patel April 16, 2024 :
I don’t think there’s a compelling reason to pass this. From what others have said, it’s not a great solution. In addition, from talking to core devs who would be running this, it would actually be extra work to run and maintain. Finally, as far as I know, no one has complained about the current centralisation of the SAO, so I think core devs should instead be allotting time to other, high-priority tasks. Not to be too harsh, but, in summary, this seems like a partial solution to a non-existent problem that adds extra work onto the plates of core devs, distracting from more urgent tasks.


Thanks all TAB members for the thorough review and provided feedback! :saluting_face:

3 Likes