Summary
In this meeting, we learn about the design lead at Edge & Node from the host of the GRTiQ podcast, protocol updates are discussed, data demos utilizing Bubbletea are presented, and the governance process is reviewed. Also, The Graph Foundation has a new team member!
Topics Include:
- George Adams joins The Graph
- GGP-0005 approval
- Messari Mainnet
- Carl Hagerling
- Wave 3 RFP & Grant Ideas
- Bubbletea
- Firehose & Sparkle by StreamingFast
- Governance Process
- Improvements
Detailed notes regarding each topic with timestamps can be found below.
George Adams (1:09)
The Graph Foundation has a new team member! George Adams has a background in strategy and finance and joined The Graph Foundation team last week.
“I want my goal at The Graph to make our financial data, anything, the foundation’s financials as accessible and digestible to all the stakeholders involved, including the community, including any decision makers, so that we can lead to better decision making.”
General Updates (3:35)
GGP-0005: Batch GNS transactions has been approved by The Graph Council and will soon be implemented in the protocol. This allows subgraph developers to deploy their subgraph and be the first to signal on it.
Messari Mainnet (5:01)
Mainnet is a crypto event organized by the company Messari. The event takes place in New York for three days and The Graph will have a booth set up where you can pick up some swag. Eva Beylin, Tegan Kline and Joseph from Figment will be speaking at the event. Also, PARTY!
GRTiQ & Carl Hagerling (6:30)
Carl Hagerling, the design lead at Edge & Node was recently a featured guest on episode 28 of the GRTiQ podcast. Carl is an industrial designer who built his pedigree designing for the likes of Facebook and Tesla. He moved to San Francisco from Sweden when his wife started a job there. He met the founders of The Graph early on as the design lead and cofounder of Edge & Node. In the episode, Hagerling details the process for designing The Graph’s logo and branding elements.
Wave 3 RFP & Grant Ideas (9:15)
Reem Chahrour of The Graph Foundation posted in the Grants & Initiatives category of the forum asking for community RFP ideas. Teams that already have an idea or project in mind submit grant applications, but The Graph also has RFPs available. RFP stands for Request for Proposal. They are projects that come with details and requirements that anybody can apply for. Please visit the forum or reach out to Reem on discord with any ideas you may have for an RFP!
Bubbletea (12:44)
Bubbletea is a python-based library that makes it easier to build data applications on top of The Graph. The library will assist dapp developers and data scientists by simplifying data visualization and extraction. Bubbletea solves three main obstacles:
-
The library offers a workaround for the API’s 1000 request limit. Users will only need to execute one call function.
-
Beta Load Subgraphs – Bubbletea uses a function called beta load subgraphs that allows the user to visualize data from multiple subgraphs in parallel.
-
It offers a generic data aggregation function that when paired with the graphical library Altair, allows developers to display charted data.
In demos (1,2) presented by Huang Kuan, financial data for AAVE is visualized by utilizing Bubbletea.
Firehose & Sparkle (25:25)
The Firehose is an alternative way to ingest blockchain data into the database that The Graph Node reads from.
Indexing Goals
Providing a way to index data which:
- is capable of handling high throughput chains (network bound)
- increases linear indexing performances
- increases backfilling performance & maximize data agility by enabling parallel processing
- reduces risks of non-deterministic output
- improves testability and developer experience when iterating on subgraphs
- simplifies the operations of an indexer by relying on flat data files instead of live processes like an archive node
- reduces the need for RPC calls to nodes
An in-depth reading of the Firehose approach can be read here.
Sparkle is how StreamingFast implements parallelization. Instead of ingesting blockchain data in a linear sequence, Sparkle allows for the indexing of data in parallel chunks, increasing indexing speed up to 300x. It currently takes approximately 3-4 weeks to index Sushi Swap. With Sparkle, it takes approximately two hours. Sparkle is currently only utilized by StreamingFast externally as there are many QA factors to consider before being protocol ready.
Questions (30:10)
Will this technology enable people to eventually index Solana quickly?
“Solana is a very fast chain, and they don’t have any reliable history solutions. As it stands currently it does not service Solana completely. We know we can tackle parts of it, and it’s part of our roadmap in the near future.” – Josh | StreamingFast
Can this approach be replicated against other complex subgraphs (E.g. Uniswap, NFT subgraphs)? (31:50)
“The main thing to know is that our sparkle integration right now is written in GO. We’ve gone through and we’re rewriting. When we did the Pancake Swap or right now when were doing the Sushi Swap, we’re rewriting their subgraph in a different language in go… Our goal is not to be another hosted network for The Graph. Our goal is to empower all indexers to all this. While we’d like to go and help everyone one by one, we know that won’t scale. We want to make sure all the indexers can do the scaling for us, because that means all the delegators get the rewards, the curators get the rewards; We want to drive as much as we can into the decentralized network.” – Josh | StreamingFast
In terms of data storage, how much does it difference in comparison with current indexed data by indexers? (34:24)
“I don’t know the numbers offhand, but if you go into the discord channel, #indexer-firehose, that’s where a lot of that has been talked about… I can get that data if you ping me on discord.” – Josh | StreamingFast
Governance (36:01)
Forum
The Graph forum is the best placed to interact with The Graph’s broad community. Users can sort through different categories, offer opinions and visions for The Graph’s future, and participate in the governance process.
This is where graph improvement proposals (GIPs) start their journey. GIPs are posted to the forum and the community of developers and community members can discuss if the proposal is beneficial to the protocol’s future. The GIP is then sent to a community snapshot vote (Yes/No) on whether the GIP should be implemented in the protocol. This provides a specific measure of support The Graph council can interpret, and subsequently decide if it should be implemented in the protocol.
Improvements (42:20)
Transparency
There will be an improved push for transparency in everything being worked on for The Graph in order to improve overall community engagement with proposals and to make sure everyone understands where proposals are in the pipeline. There is currently a working group focused on putting more definition to the processes that ensure GIPs follow a specific lifecycle.
Questions (45:32)
Is there any effort or push to have different blockchain subgraphs moved to The Graph Studio?
“We don’t have a proper timeline in place yet, but we are working on a roadmap… Hopefully in a couple of weeks we will have a blog post highlighting all of this roadmap and it should be a bit clearer.” – Pedro | The Graph Foundation
Stay Tuned!
Join us next month for Community Talk #4!
Keep up to date by joining discussions in the forum, following The Graph on Twitter or joining the Discord server.
For further discussion on the topics covered in The Graph’s Core Devs meetings, attend Indexer Office hours in the Graph Stage voice channel every Tuesday.
Access a full transcript of Community Talk #3 here, or watch it on YouTube!