I would like to see more discussion about future iterations of curation. Recently most of the official talk I have seen has focused on the ideas to mitigate the issues caused by the current version of curation (for example implement indexing fees so dapp developers don’t have to worry about curation). However not much has been said about what curation could look like in horizon to the point that I suspect many would be fine with the roll being lost altogether. I personally do not think that is a good idea. The roll of curator was not envisioned to be just a way for dapp developers to get their subgraph indexed. It is bad at that job because that’s not what it was for. Instead I think the role of curator should focus on the work and input of ideas and direction from the curator in making a web3 that is within the vision and ethos of the graph community. Or rather their own ethos which one would hope is aligned.
We need better incentives and mechanisms for curators to contribute effectively.
I think this is where it mostly boils down. The current direction The Graph seems to be taking, is to ensure customers gets the lowest price for their query needs, and indexer gets the most revenue. Which can be a major blocker to curation as a role in the ecosystem.
Better incentives for curators will come at the expense of customers or indexers, there’s no way around it.
For me as a delegator and someone who tried curation for a bit, the move to arbitrum decreased my fear of trying out curation as the cost to do things in the network has decreased significantly.
The problem now is more to that the query fees collected are barely worth it for me to curate. While it can be seen as a public good, I think mostly we are all still profit driven, so it is quite difficult for us to be convinced to curate something that does not bring in much fees.
I do think that if the only reason curators want to curate is to make money, we might as well just all move to delegating. Curation will only exist if it serves a purpose.
A poll to see how the spread looks. I think that there needs to be some purpose to curation beyond generating profit for the curator or it won’t exist. Why would the indexers and dapps want to have that middle man adding inefficiency? I believe that there could be another purpose as I started to outline in my main post.
It would make sense to me to export curation as a data service that a dapp, such as Geo, can provide to users who want it, without creating the Curation impediment we have now with the core protocol.
I do think that if the only reason curators want to curate is to make money, we might as well just all move to delegating. Curation will only exist if it serves a purpose.
I would tend to agree, but I do still think profit incentive is still going to be the best incentive driver for curation.
Maybe if there is a way to couple delegation and curation, i.e. delegators need to select few subgraphs to pledge/curate their stake to regularly, and they can earn more rather than delegates that does not.
Thanks yaniv, when reading about horizon and listening to Zac Burns on grtiq I was troubled when he shared his vision for the direction he wants to take the graph. I’m paraphrasing, you can check me by listening to the episode, but he said something to the effect of ‘i want the graph to be modular so it can be what everyone wants at once and we dont have to all agree to change it’. I may be blowing this out of proportion, the changes he was referring to may be that they want to tweak little things and not bring on sweeping changes and splinter The Graph.
My read of the situation:
It seems like there are problems and inefficiencies in the protocol that people would like to address, and there is in addition this alignment or unity issue. I know from experience working at a school in a challenging district that unity doesn’t come easily but it is invaluable. I personally do not think that solving the inefficiencies through a loss of unity is a good idea.
The Graph doesn’t need to be a monster platform that solves everyone’s problems. It needs to be trust minimized, permissionless, resilient, and easy to access for the world. It takes data that already exists and delivers it along with proof that this information hasn’t been tampered with.
Platforms like Geo, or the data processing platforms that Streamingfast use The Graph because it’s the best platform for it’s purpose but do not need to be build inside of it. Geo uses polygon and ipfs in addition to The Graph.
If someone wants to build something that is significantly different to what has been agreed to by the union of Graph stakeholders they should build a new platform, perhaps using The Graph for what they need from it.
In short I’m glad to hear that you are seeking to get the core devs on the same page. To me this is of utmost priority and is make or break for this whole endeavor!
Thank you @Athsrueas. I agree with your read entirely.
The team that worked on Horizon was chiefly concerned with creating a permissionless efficient marketplace at the base layer where anyone can publish any data service they want. I think they’ve done groundbreaking work that is truly excellent, but I don’t think it encapsulates everything that needs to be done.
I think the original vision of The Graph has been overlooked a bit as we’ve become a developer tool for teams to easily pull data from blockchains. I think that having the best tools for extracting data from blockchains is really important. Both for improving the lives and productivity of developers, and to realize the vision of decentralization.
But from my perspective, that was not the full vision of The Graph. For me The Graph was always about building a global interconnected graph of data that people could trust. I think that data should come from a combination of developers that are building their own protocols and applications, developers that are writing scripts to pull data from various data sources, and from consumers and experts in their various fields.
My initial problem statement for the role of Curator was “We need a role that incentivizes normal people to add knowledge and information onto The Graph.” I think it’s clear that the initial implementation did not accomplish this goal. Instead it was a mechanism to predict query fees for a subgraph that had already been created by a developer. We didn’t give normal people the tools to add knowledge and information onto The Graph, and we didn’t properly incentivize that behavior.
Now that we have a design for Horizon, I view The Graph in 2 layers:
A permissionless marketplace of data services where anyone can provide and consume any data with full freedom
A curation layer for organizing knowledge and information that people can trust
By definition, a permissionless marketplace is not itself something that people can trust. We have to decide if we want organizing knowledge and information to be in scope for The Graph. I believe that it should be. I believe that in order to have a healthy society, we need systems where groups of people can come together and get to agreement on facts and goals. I think that the loss of faith in the institutions that used to perform that function is the cause of most of our societal problems. I believe that The Graph can be the solution that heals our wounds and creates the path forward for a healthy and vibrant society in the internet age. I believe that we need tools both for personal freedom and individual rights, and for social coordination and collective action.
For me the goal of The Graph should be to empower communities to organize and serve all the world’s public knowledge and information in a decentralized way. That goal requires empowering and incentivizing developers and non-developers to add and organize knowledge and information on The Graph. That was supposed to be the goal of Curation.
If we can get the community behind this goal, I think we can make it happen.
Yes, we built Geo on the side because it was a pretty novel project and we couldn’t get agreement from all the core devs about how it should work and what the goals should be. I could explain what Geo Genesis is today, what the Geo browser is going to be, and what I think The Graph should be.
Today, Geo Genesis is a way for communities to organize and get to consensus on knowledge and information in a decentralized way. It includes both data and pages for presentation.
Geo browser should be the best possible user interface for browsing and interacting with The Graph.
The Graph, in addition to what it does today should:
Have the concept of communities
Have the concept of knowledge
Incentivize people (curators) to add knowledge and information to The Graph
Become something that people can trust as the source of truth for knowledge and information
These are my views. And I hope to get consensus amongst the community and core devs.
Thank you @Athsrueas, @CryptoWing, @Yaniv, and others on this thread, for your thoughtful contribution. I broadly agree, particularly at the meta-level of ‘Let’s work together to shape the future of The Graph’.
I’m new here. I have had the privilege of spending many hours talking to Zac and others about the Horizon vision, but my knowledge is far from complete! Please allow me to explore freely, without presuming my exploration represents the Edge & Node consensus.
It seems that we broadly agree:
Effective curation would increase the value of the network for participants and users.
We do not yet have effective curation.
‘Let’s work together to … ensure curation plays a meaningful role’!
I do think though that some of the ideas of curation need to live on and that in the future, we should design more mechanisms [… to] meet the needs of that.
[…] I think that those ideas deserve ongoing discussion and maybe mechanisms can also be put in place in Horizon which actually meet those goals. But we haven’t yet gone through the effort of designing those mechanisms […].
And later more generally about Horizon (at 00:50:19):
Community feedback is absolutely one of the most important pieces of this initiative.
Horizon is a big step to making the protocol work as originally intended based on what we have learnt. Horizon does not by itself solve all the challenges we need to solve. We still need to solve curation. Many of us have nascent ideas, but I don’t yet know of a coherent solution.
First I want to listen more, and explore more. It is a non-trivial problem, and I encourage everyone to participate.
I would like to propose some structure to help us be productive:
Clearly articulate why we need curation. What problem(s) are we trying to solve? (There is already good material, collating it will help align and facilitate participation.)
Guided by the problem articulation, gather ideas about and explore potential solution approaches. Ultimately to agree on a coherent approach.
Finally, how will it be implemented?
Will that help? If so, I can start a new thread based on that structure, and I hope that we can encourage more people to contribute.
Maybe a thread focused only on number 1: why we need curation first. That way we keep everything from going all over the place. I’ll be following these discussions and try to keep things more organized in the future. Thanks for your response!
Having written the post, that on its own feels like a big topic.
Thank you for starting this thread, and BTW I think you structured it very well!
I am looking forward to diverse input on that thread. I deliberately left it open as an initial post, and I hope we capture and consolidate ideas from this thread and elsewhere.
I wanted to share my thoughts and observations on the curation model, particularly in the context of protocol query fees. It’s clear that the original design was more applicable when the protocol incurred actual query fees. In the early stages, with the implementation of the bonding curve, the absence of significant query fees led to a reliance on speculative curation. This approach, however, had its drawbacks.
One major issue was the potential for ‘rug pulls’, which understandably left many curators with reservations. The initial bonding curve mechanism contributed to losses for some, as early curators often took profits, impacting those who joined later.
The transition to Arbitrum and the adoption of a flat bonding curve has been a positive change. This shift has mitigated the risk associated with speculative curation, presenting a more stable and predictable landscape.
Today, we’re witnessing a notable increase in query fees compared to earlier times or even a year ago. This trend is clearly illustrated in the Dapplooker dashboard (Graph Network Billing Dashboard - Arbitrum). The data from this dashboard indicates that an increasing number of protocols are utilizing The Graph and, consequently, incurring query fees.
While I don’t have a definitive solution to propose for the current model, it’s noteworthy that its effectiveness has improved compared to previous iterations. There are query fee producing subgraphs with signal that is not self signal, that helps indexers find productive subgraphs. I believe that as we move forward, especially after the sunset of the hosted service, the model will play an increasingly positive role. At that time, when query fees are fully accounted for, discussions around further modifications or replacements will be more justified.
My delegation experience makes me think that indexers are time poor, just have auto re allocations happening, need reminding about re allocations (not a generalisation of indexers just my experience So far) So I think curation would be a very important role for indexers to use to choose sub graphs. Has to be a good financial incentive for the role. At the end of the day people at the bottom, not filthy rich, want to earn money.
