TOPICS DISUSSED
- TEST NET DEPRECATION
- Migration from Goerli to Sepolia, affecting L1 and L2 networks.
- GIP-0062 Remove Delegation Parameters Cooldown
- Proposal to remove the “delegation parameters cooldown” feature for Indexers.
- GIP-0061 IMPROVEMENTS TO THE GIP PROCESS
- Key Proposed Changes
- Risks and Security Considerations
- Public Comments on GIP-0061: Discussion on the move from Radical to GitHub and issues related to accessibility.
- GIP-0058 INDEXING FEES (FORMERLY DIPS)
- Proposal on market-driven mechanism for indexing fees.
- Next Steps
- Questions and Answers:
- On Radical and GitHub
- On implementing features pre-Horizon
- ETA on GIP for Horizon
- Public Comments on GIP-0058
- SUBSTREAMS.DEV
- Development plans and components for Substreams.dev.
As always, the community was encouraged to ask questions and participate actively in discussions. Find the full show notes below.
TESTNET DEPRECATION (00:34)
Goerli will be deprecated as a testnet on November 18th, affecting both L1 and L2 networks. In response, a migration from Goerli to Sepolia is needed. This follows a previous successful migration from Rinkeby to Goerli about a year ago. Active testnet users are invited to participate in the discussion on the process which is expected to be finalized by the November 18th deprecation date.
GIP-0062 REMOVE DELEGATION PARAMETERS COOLDOWN (02:40)
GIP-0062 proposes to remove the “delegation parameters cooldown” feature for Indexers. This cooldown field sets a limit on how often Indexers can adjust delegation parameters, like query fees and index rewards. The feature is largely unused as the parameter was last changed by an Indexer on mainnet approximately a year ago, and only one used it on Arbitrum One, resulting in an unintentional long-term lock. The proposal suggests the feature should be removed.
The removal would include marking related variables as deprecated and taking out the minimum cooldown setting that was controlled by governance. The external functions related to cooldown will be removed from the Staking contract on both L1 and L2 networks. If approved, the change will unblock the Indexer currently affected by the cooldown and simplify the protocol. The proposal is in the Draft stage, and community feedback is encouraged. It will undergo an audit within the coming weeks and will be sent to the council for final approval pending the audit.
GIP-0061 IMPROVEMENTS TO THE GIP PROCESS (07:40)
GIP-0061 proposes a series of changes aimed at simplifying and clarifying the Graph Improvement Proposal (GIP) process. The existing framework has lacked clear pathways for community participation and council approval.
KEY PROPOSED CHANGES:
-
CLARIFYING EDITOR ROLES:
The role of Editors in the GIP process is clarified to ensure the process remains as permissionless as possible. Editors should not be able to stall a GIP through inactivity.
-
REMOVAL OF GRP CATEGORY:
The Graph Request for Proposals (GRP) category has never been used and is proposed to be removed to simplify the process.
-
SIMPLIFYING STAGES:
The Strawman and Proposal stages are suggested to be removed and merged into a single Draft stage. This change reflects the evolving nature of proposals.
-
SELF-ASSIGNING GIP NUMBERS:
Authors are encouraged to self-assign GIP numbers following specific rules, with Editors having the ability to re-number to avoid conflicts.
-
CLEARER POST PUBLISHING PROCESS:
More details have been added to outline what needs to be done post-publishing for a GIP to be implemented and accepted, including quality assurance processes for different kinds of changes.
-
ONLINE FORMS:
The introduction of an online form aims to facilitate interactions between authors and the Council or core developers for things like audits, implementation help, and community calls.
These changes are being supported by initiatives such as the formation of the Technical Advisory Board, speaker slot requests for meetings, and a way to request audit slots.
RISKS AND SECURITY CONSIDERATIONS:
The GIP acknowledges potential risks, such as the possibility of spam submissions via the online form and a single point of failure if the form provider experiences downtime. To mitigate these, authors are encouraged to use public channels like forums or Discord to communicate with core developers or the Foundation if needed.
The GIP aims to bring clarity and simplify the process, making it more accessible for contributors to bring their ideas to the community, and easier to implement and deploy accepted proposals. Community feedback on this proposal is highly encouraged! If you have ideas on how to improve the process please share feedback on the forum.
QUESTIONS
QUESTION: Are we putting Radical to bed as part of this GIP?
ANSWER: Yes, Radical hasn’t been used in a while. We’ve been using GitHub as it’s easier to track the source of truth for GIPs. We’re open to using a decentralized solution like Radical in the future, but for now, we’re sticking with GitHub.
COMMENTS
JIM | WAVEFIVE.CO:
Accessibility has been a major problem with Radical from the start, even for people familiar with Git. I’m glad we’re acknowledging this and moving to GitHub. It’s not that we don’t want to use decentralized solutions like Radical, but maybe it’s too early for that. There’s an underlying theme of accessibility in this change. When people want to contribute to discussions at our weekly events or forums, there hasn’t been a formal process. This GIP is an opportunity to address that. We’re focusing on GitHub, which could offer solutions for community participation. We need to improve accessibility so that when someone on Discord wants a new feature, raising a GIP doesn’t intimidate them. I’ll expand on these thoughts in the forum later this week.
GIP-0058 INDEXING FEES - FORMERLY DIPS (24:50)
The status update focused on Direct Indexer Payments (DIPs), now known as “indexing fees,” as a proposed solution for curation inefficiencies within The Graph. This proposal aims to establish a market-driven mechanism where Indexers post a publicly listed price for their services. Consumers can then pay this price to have their subgraphs indexed.
FORUM DISCUSSIONS
On one hand, the proposal is designed to solve systemic inefficiencies in the curation process, offering a more predictable and transparent pricing mechanism. This is considered beneficial for the long-term stability and growth of The Graph’s ecosystem.
On the other hand, the immediate impact of implementing the proposal has raised concerns among smaller Indexers. They worry that the new system may introduce centralization vectors, potentially giving an advantage to larger, more established Indexers. This could create a more challenging environment for smaller players, possibly leading to centralization in the short term.
So, the core conflict is between instituting a system that has long-term benefits for The Graph at the cost of potentially causing short-term disadvantages certain participants, particularly smaller Indexers. The community and the team are working to address these concerns through ongoing discussions and adjustments to the proposal.
Next steps include engaging the council for feedback, developing pricing tools, and planning for UI changes and smart contract modifications. The implementation of this proposal also hinges on the formal introduction of Horizon.
QUESTIONS
QUESTION: So is this GIPs feature something that can be implemented pre-horizon? Or is this something that can only be implemented through the functionality of horizon?
ANSWER: From a technical perspective, the feature can be implemented before Horizon. However, Horizon offers a trust guarantee that ensures economic security when you pay for a service. Implementing it without Horizon would lack these trust guarantees. It’s possible to create a separate trust mechanism within the indexing fees, but if Horizon is going to be implemented anyway, it might make sense to do them together.
QUESTION: What is the ETA on the GIP for Horizon?
ANSWER: I do not know. I’d like to commit to specific time frame, but I can’t.
COMMENTS
JIM | WAVEFIVE.CO:
Running them in parallel is a bigger risk for getting real insight. That’s where a lot of concerns come from, especially from Indexers, around this idea that a mega Indexer comes in and undercuts everybody on query price by 10x. If everybody’s in the same market and there’s not an alternative market, then we might see different behavior. This is all difficult stuff; there’s a lot of friction, different opinions, and pain involved. But we’ve worked out that certain things don’t work, so I’m happy to see the conversation happening. This and Horizon represent foundational changes to the protocol. I’d be keen to hear actual opinions from more of the council and the Technical Advisory Board. Through the process of working through this transformative GIP, I really want to see more public interaction or at least opinion from the council members who are qualified to talk about these things before we finally get to consensus.
SUBSTREAMS.DEV (35:23)
The discussion revolved around the development and plans for Substreams.dev, a registry for Substreams aimed to help people discover and build upon existing work. The team has been working on multiple components, including:
-
A WEB BASED FRONT-END GUI: A developer-centric interface to interact with Substreams streams, offering functionalities to discover data, decode and debug logs.
-
SUBSTREAMS BUILDER: A tool to simplify writing Substreams modules. The Substreams Builder would automate the creation of rust code, handling all data decoding and model creation on the web and build the .spkg for the user.
-
DEPLOYMENT MECHANISMS: Initially, subgraphs served as the primary deployable units, which were fully automated and integrated into the existing infrastructure. Now, new modules like Substreams SQL and Substreams webhooks are emerging as fully defined, deployable units. The value proposition is the ability to fully define, package, and send these deployable units from one entity to another.
The aim is to create a holistic ecosystem where multiple paradigms of deployable units can co-exist, each contributing to the system’s overall functionality. These changes imply that there will be new deployment strategies to adapt to these new types of deployable units.
STAY TUNED!
Join us next month for Core Devs Call #26!
Keep up to date by joining discussions in the forum, following The Graph on X/Twitter or joining the Discord server.
The 25th Core Dev call is happening this Thursday 2023-10-26T15:00:00Z.
Please subscribe to The Graph Foundation’s Ecosystem Calendar , so you don’t miss any of the upcoming calls!
Tentative agenda:
The Graph Core R&D Workspace
Monthly Core Dev updates
The recording will be uploaded here .
