Summary
In The Graph’s Core Devs Call #16 we receive a brief update on the MIPs program, listen to progress on File Data Sources and Subgraph Data Pruning, discuss an alternative to GIP-0034 and review upcoming changes to curation on L2.
Topics Include:
- Migration Infrastructure Providers Program Update
- File Data Sources Update
- Subgraph Data Pruning
- Updates on L2 and GIP-0037
- Current State of Curation v1.x and Roadmap to 2.0
Detailed notes regarding each topic with timestamps can be found below.
MIPs Program Brief Update (01:49)
The Graph’s Migration Infrastructure Providers program (MIPs) launched on September 20th 2022. The core objectives of the program are to test network infrastructure, expand the decentralized network to new chains and support the migration of subgraphs.
Indexers will participate in a gamified system of scoring and a leaderboard will be used to distribute awards at the end of each cycle. Points will be gained based on an Indexers subgraph coverage, quality of service and community support. Check out some of the stats below regarding MIPs program applicants:
-
1,782 applications to the MIPs program
-
Only 15% of applicants are current Indexers (many new Indexers applied)
-
55% of applications were individuals
Phase 0 has started! Check out the MIPs homepage on Notion to keep up to date!
File Data Sources (06:28)
There has been much thought regarding file data sources since the update provided in The Graph’s Core Devs Meeting #14. Read below for a quick recap from the Core Devs Meeting #14:
Updates
At Core Devs Meeting #16, Adam Fuller shared an example of how changes to the current inline ipfs.cat model will help with current IPFS issues, open availability to other data sources and move towards deterministic indexing.
This change would be replacing the inline ipfs.cat event to an inline event that is the creation of the file data source which runs asynchronously.
↓↓↓
Benefits
Robust
- Eliminates Race Conditions
- Handling Timeouts
- Temporary Unavailability
Expandable
- Directories
- Arweave
- Ceramic
- IPNS
- HTTP?
Path to Determinism
- File Availability Consensus
- Data Source Removal
Constraints
- Limited Store Access
- Separate Entities
Read more on File Data Sources [here](https://hackmd.io/opoO7onKRR-2GwI3zHnNFg?view)!Question:
What’s the thinking about getting consensus amongst Indexers if a file is available or not?
Answer:
Availability chain, Encourage Indexers to Share Data, or Possibly Utilizing the Gossip Network
Subgraph Data Pruning (17:01)
A subgraph is archival by default which means it keeps a history of its state. This is important for arbitration, access to historical data and if there’s a reorganization in the chain. Conversely, many subgraphs are keeping history that has never been queried and most queries for the subgraph pertain to the chain head. Subgraphs with large amounts of historical data can suffer from slow queries and an increase in indexing cost.
Subgraph pruning would introduce the ability for Indexers to prune historical subgraph data before a specified block. This will help with query speed, Indexer cost and potentially introduce a new class of “lean” Indexers.
Drawbacks to subgraph pruning include the inability to graft before the point of pruning and limited availability for time travel queries.
Pruning is currently undergoing testing and more information will be available soon.
Updates on L2 and GIP-0037 (28:08)
GIP-0037: The Graph Arbitrum Deployment with Linear Rewards Minted in L2 is live on the forum and is presented as an alternative to GIP-0034: Arbitrum Devnet with a New Rewards Issuance and Distribution Mechanism. While GIP-0034 is still an option that could work well (yet more complex), GIP-0037 presents a simpler alternative with different risks and benefits.
GIP-0037 proposes a gradual approach to migration with deployment to L2 in parallel with the current L1 deployment. Indexing rewards would initially be disabled with rewards activating per governance.
Currently, the team is still testing the Arbitrum Bridge. The bridge has undergone testing and an audit, but the team is erring on the side of caution. There is an upcoming Code4rena contest which acts as a decentralized audit on the bridge’s code where anyone can audit the code for a bounty.
The team working on the Arbitrum Bridge and L2 scaling options is looking for feedback on GIP-0037. Please head to the forum to leave your thoughts and feedback.
GIP-0031 Arbitrum GRT Bridge Updates
- Implementation tested on testnet
- Callhooks interface changed to be safer even if whitelisted senders are compromised: callhooks always call an onTokenTransfer function rather than calling any function that the sender wants to call
- Other teams already working on off-chain components to support L2
Current State of Curation v1.x and Roadmap to 2.0 (41:32)
GIP-0039: Curation v1.x aims to patch some of the pain points in the current curation market and pave the way for future developer experience improvements. This GIP would flatten bonding curves and gives Curators query fees in direct comparison to their current percentage of signal. If a Curator provides 15% of signal on a subgraph, they will receive 15% of query fees for the subgraph. GIP-0039 is specific to L2 and will only be applicable to subgraphs deployed on Arbitrum.
Why Its Needed
Problems with bonding curves:
- Large unknown downside risks
- Not incentivized to focus on finding valuable subgraphs
- Complicated to reason about signal
High-Level Goal: Improve Developer User Experience
- No Curator can take another Curator’s signal
- Enable relation between provided signal and quality of service to be predictable
GIP-0039 is live on the forum and feedback is needed from the community!
Question:
Currently, rapid movement between subgraphs is punishable because Curators will lose their shares. With these new concepts, creators may predict when Indexers close their allocations and rush into the subgraph to get query fees and then leave to the next subgraph without being subject to any punishment and continue doing this to get quick fees. Has this been addressed?
Answer:
In the initial stage before query fees, we plan to provide more updates so that a more long-term solution can be brought to light and discussed. You are completely right, one of the downsides of having a flat bonding curve is that people can jump in, collect query fees, and hop back out.
Question on Forum:
Substreams in Subgraphs: Road to the Decentralized Network (xx:xx)
Due to time constraints, this topic was tabled and will be discussed at a later Core Devs Meeting.
Stay Tuned!
Join us next month for Core R&D call #17!
Keep up to date by joining discussions in the forum, following The Graph on Twitter or joining the Discord server.