Hi all.
Sharing some updates on this GIP:
- The GIP was reviewed and voted on by the TAB (Technical Advisory Board). Notes below.
- The Graph Council officially voted in favor
of this GIP, with input from the TAB. - 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
Approvals: 5/6
Rejections: 1/6
Reviews: 6/6
Approvals
@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
@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! 