SUMMARY
The meeting covered major updates and initiatives within The Graph ecosystem, focusing on updates from StreamingFast, exploring Subgraph Composition, GIP-80 Optimistic EBO, and GIP-81 Indexer payments.
TABLE OF CONTENTS
| Topic | Details Covered |
|---|---|
| StreamingFast Updates | Overview Enhancements in Substreams integration with The Graph, introduction of revamped substreams.dev, and a bounty feature to reward popular packages. Solana Support Prioritized support for Solana, achieving faster performance and new features for developers. Substreams Dev Container and Codegen Details on streamlined development tools, commands, and SQL/Graph integration for data handling. Non-EVM Chain Integrations Updates on integrating Mantra, Injective, Starknet, and Sei for broader adoption. Success Story Highlights Propeller Heads’ contributions and the impact of their tools on platforms like CoW Swap. |
| Subgraph Composition | Introduction Updates on modularity, reusability, and scalability in subgraphs for developers and Indexers. Roadmap Highlights Key milestones for 2025, including single subgraph composition and CLI/UX enhancements. Implications and Benefits Efficiency gains, reduced redundancy, and reusable building blocks for data infrastructure. Engagement and Next Steps Demos, educational content, and collaboration plans for Q1 2025. Q&A Responses to questions on Indexer impacts and upcoming demo availability. |
| GIP-80: Optimistic EBO | Background Challenges with the current Epoch Block Oracle system and its risks. Optimistic EBO Solution Introduction to a decentralized, scalable system leveraging an Optimistic Oracle. Comparative Overview Key differences between the current and proposed EBO models. Benefits and Considerations Advantages such as gas efficiency, modularity, and improved security. Conclusion Summary of the Optimistic EBO’s impact on decentralization and scalability. |
| GIP-81: Indexer Payments | Overview Proposed mechanism for gateways to directly compensate Indexers, focusing on predictability and flexibility. Key Features Details on direct payments, escrowed agreements, and developer benefits. Workflow Summary Explanation of Indexing Agreements and proof-based compensation system. Minimum Viable Product Initial deployment details with off-chain components. Indexer Selection Algorithm (IISA) Selection process based on QoS metrics and developer preferences. Implementation Timeline Plans for MVP release in Q2 2025 and transition to full decentralization. Open Questions Invitation for feedback on pricing models and Indexer Selection Algorithm refinements. |
- STREAMINGFAST UPDATES
INTRO
StreamingFast has been enhancing Substreams integration with The Graph, aiming to provide a robust data service that improves user experience and aligns with network requirements. The revamped substreams.dev serves as a hub, offering reusable packages, detailed documentation, Dev Containers, and key management tools.
To foster engagement, a new bounty feature rewards popular packages weekly. The inaugural week recorded 87 unique users engaging with a leading package.
SOLANA SUPPORT
Support for Solana has been prioritized due to its growing adoption among decentralized applications. Substreams now processes data without limits on throughput and latency, achieving speeds approximately 300 milliseconds faster than traditional RPC setups.
This improvement is made possible by optimized plugins that enhance data handling efficiency and responsiveness. New features, such as Account Changes and Native IDL Decodings, provide deeper data modeling (e.g., balance changes, transaction traces) and seamless transitions for developers from EVM to Solana.
SUBSTREAMS DEV CONTAINER AND CODEGEN
The Substreams Dev Container continues to serve as a vital tool for developers building projects. While no major changes were introduced, performance optimizations and reliability improvements were implemented, with further DevX upgrades planned for the next quarter.
REFRESHER
WHAT IS IT?
The Substreams Dev Container is a development tool designed to streamline the creation of Substreams projects, enabling developers to build subgraphs or SQL-based solutions for data handling. By running the container remotely via GitHub Codespaces or locally through the substreams-starter repository, developers can use commands like substreams init to generate projects, and substreams build to create Protobuf files. With Substreams codegen, developers can configure sinks for querying data:
-
Subgraphs:
substreams codegen subgraphauto-generatesschema.graphqlandmappings.tsfiles for defining entities based on extracted data. -
SQL Databases:
substreams codegen sqlsets up SQL-based queries for efficient database integration.
Deployment options include local graph-nodes or Subgraph Studio, while tools like help and dev-status ensure troubleshooting is straightforward. The container simplifies complex workflows and supports both experienced and novice users with minimal or automated paths for configuration.
CHAIN INTEGRATIONS
Ongoing integration with The Graph ensures that users can discover and leverage Substreams-powered subgraphs tailored to their needs. Recent enhancements have also included non-EVM chains such as Mantra, Injective, Starknet, and Sei. Substreams optimized its data services for Sei through parallelization to align with its unique chain structure.
SUCCESS STORY: PROPELLER HEADS
A notable success involves Propeller Heads, whose open-source tools built with Substreams are foundational for multiple platforms. The Tycho client uses Substreams to deliver real-time, efficient, and accurate state updates for decentralized exchanges by leveraging Substreams’ high-performance data indexing and processing capabilities across blockchains. Substreams enables Tycho to replay state changes, handle reorganizations, and provide fast, accurate data streams, eliminating the need for costly archive nodes or excessive RPC calls. Their Tycho client, streamlining solver integration, has captured over 15% of the order flow on CoW Swap, exemplifying open-source standards for infrastructure layers.
- SUBGRAPH COMPOSITION
INTRO
Alex Pakalniskis, Product Manager at Edge & Node, provided an update on Subgraph Composition, a feature set within the broader initiative of next generation subgraphs. This effort focuses on enhancing the modularity, reusability, and scalability of subgraphs, creating a more efficient and interconnected ecosystem for developers and indexers.
Subgraph Composition enables developers to extend existing subgraphs with new features, eliminating redundant work and fostering a network of reusable data artifacts. In this paradigm, subgraphs can serve as data sources for other subgraphs, improving developer efficiency and reducing operational overhead for indexers.
TARGETS
- Q1 2025: Launch of single subgraph data source composition.
- Q2 2025 and Beyond: Enhancements to the CLI and UX experience for data discovery and authoring, alongside exploration of the possibility for multi-chain subgraphs.
IMPLICATIONS & BENEFITS
Subgraph Composition transforms the development experience by reducing redundancy and creating reusable building blocks for data infrastructure. Developers can focus on innovation and feature extension, while indexers benefit from automated tools that streamline composed subgraph management, lowering costs and complexity…
QUESTIONS & ANSWERS
CHAT QUESTIONS
Question: “How will composition affect indexers? If a composed subgraph includes other subgraphs, does the indexer need to index all related subgraphs?”
Answer: “Indexers will need to support the underlying subgraphs involved in a composition, similar to grafting. However, we’re working on automating this experience for indexers in Q1 2025, ensuring it’s seamless and hassle-free.”
Question: “Did you say demos were coming in January as well?”
Answer: “We have one demo that’s available. It’s a little more complex, and so we’re working on a few that are simplified. And so I can share links to the more complicated demo that you can perhaps share with the recording. And we’ll share more basically in Q1. We plan on having a lot more content.”
NEXT STEPS
Preliminary demos for Subgraph Composition are available, with simplified examples and educational content planned for Q1 2025. The team will also collaborate with core developers on applying composition in chain-specific contexts to expand its utility.
For further details or feedback, Alex encouraged engagement via GitHub or X. Live demos are planned for future core developer calls
DEMO
- GIP-80: OPTIMISTIC EPOCH BLOCK ORACLE (EBO)
BACKGROUND
The current Epoch Block Oracle (EBO) system is integral to synchronizing epochs and calculating rewards across chains indexed by The Graph. However, its reliance on Arbitrum One and a single operator introduces risks, including:
- Single Operator Risk: A single point of failure jeopardizes the system’s reliability.
- Liveness Risk: Operator downtime interrupts epoch synchronization.
- Fork Risks: Chain forks create ambiguity and complicate updates.
The existing EBO system employs a Rust process to read RPC data, a Data Edge contract for posting updates, and a Subgraph for indexing the Data Edge.
OPTIMISTIC EBO
The Optimistic EBO aims to replace the centralized EBO with a decentralized, scalable system leveraging an Optimistic Oracle. Its key features include:
- Permissionless Participation: Enabled through Prophet, a modular oracle system.
- Bond Escalation Mechanism: Efficient dispute resolution minimizes governance intervention.
- Horizon Integration: Enhances staking and slashing mechanisms.
The workflow begins with request creation and progresses through participant responses and dispute resolution. Unresolved disputes are escalated to the governance-appointed Resolution Council.
CAMPARISONS
COMPARISON TABLE
The following table highlights the key differences between the current EBO and the proposed Optimistic EBO:
| ASPECT | CURRENT EBO (GIP-0038) | OPTIMISTIC EBO (GIP-0080) |
|---|---|---|
| Operator Model | Single operator, centralized. | Decentralized and permissionless with multiple optimistic operators. |
| Trust Model | Relies on the trustworthiness of a single operator. | Employs a modular optimistic oracle to minimize trust assumptions. |
| Dispute Resolution | Handled by a centralized arbitrator. | Utilizes an escalating bond mechanism; unresolved disputes go to a governance-appointed Resolution Council. |
| Fault Tolerance | High risk of downtime if the single operator fails. | Redundancy with multiple participants ensures robustness. |
| Scalability | Limited due to centralized operation and linear updates. | Highly scalable with parallel updates per chain and modular design. |
| Gas Costs | Updates are expensive due to direct on-chain operations. | More gas-efficient due to off-chain computation and selective on-chain posting. |
| Fork Handling | Limited handling, relies on manual intervention. | Timestamp comparison reduces ambiguity; automated handling via disputes. |
| Data Synchronization | Linear and subject to operator liveness. | Decentralized synchronization with optimistic assumptions and configurable delays. |
| Integration | Relies on centralized maintenance of Data Edge and Subgraph. | Modular design using Prophet for flexibility and integration with Horizon for staking. |
| Security | Vulnerable to single point of failure and operator bias. | Enhanced security through incentivized dispute resolution and configurable parameters. |
| Governance Involvement | Minimal, limited to oversight of operator actions. | Active role in appointing the Resolution Council and upgrading parameters. |
| Economic Model | Indexers are reliant on centralized updates for rewards. | Bonds and penalties incentivize honest participation, improving economic security. |
BENEFITS
The Optimistic EBO introduces a robust architecture that minimizes gas costs for valid proposals, enhances redundancy through broader participation, and provides modularity for future adaptability. Its security measures include multi-layered dispute resolution and configurable parameters like bond thresholds and escalation rounds to balance efficiency and security.
FEEDBACK
By decentralizing epoch synchronization and addressing the limitations of the current system, the Optimistic EBO represents a significant step toward enhancing The Graph’s network reliability and scalability. Its integration with Prophet and Horizon ensures a resilient and economically secure ecosystem, paving the way for future decentralization efforts.
For more details, refer to the GIP-80 Proposal, Prophet documentation, or reach out to 0xShaito and the Wonderland team.
LINKS
GIP: github.com/graphprotocol/graph-improvement-proposals/pull/53
EBO-core: github.com/defi-wonderland/EBO-core
EBO-agent: github.com/defi-wonderland/EBO-agent
Prophet core: github.com/defi-wonderland/prophet-core
Prophet Modules: github.com/defi-wonderland/prophet-modules
Documentation: docs.prophet.tech/
- GIP-0081 INDEXER PAYMENTS
INTRO
GIP-0081 proposes Indexing Payments, a mechanism designed to allow gateways to directly compensate Indexers for serving subgraphs. This new system complements the existing curation and rewards model, focusing on improving predictability, flexibility, and quality-of-service guarantees for developers while adhering to The Graph’s decentralization principles.
KEY FEATURES
Indexing Payments offer several advantages for developers. They enable direct payments, including fiat options, eliminating the need for GRT acquisition and holding. Payments are regular, upfront, and predictable, making budgeting more manageable. Additionally, developers benefit from clearer performance expectations and the ability to switch Indexers if necessary. This mechanism addresses gaps in the current system, such as supporting subgraphs and chains that are ineligible for rewards and providing predictable costs in scenarios where curation is insufficient.
MECHANISMS
The system is built around Indexing Agreements, which define the terms of service between gateways and Indexers. These agreements specify details such as the subgraph to index, maximum payments, pricing per unit of work (e.g., blocks indexed or entities processed), and payment intervals. Payments are escrowed, ensuring trustless compensation for Indexers. Agreements are flexible, allowing cancellation with safeguards to ensure Indexers are compensated for completed work.
WORKFLOW
The workflow begins with gateways offering Indexing Agreements off-chain. Indexers then accept these agreements on-chain and start their work. Proof of Indexing (PoI) is submitted to claim payments. Meanwhile, gateways monitor performance metrics such as latency and uptime to ensure quality. If needed, agreements can be reallocated to maintain network efficiency and reliability.
BENEFITS
This proposal specifically addresses use cases where the current system falls short. It provides a solution for indexing subgraphs or chains not eligible for rewards due to network conditions and ensures predictable costs and performance guarantees. These improvements aim to make The Graph Network more accessible and reliable for developers with diverse needs.
MVP
The MVP will use existing off-chain components to facilitate initial deployment. Payments will rely on proxies like the number of blocks indexed and entities processed. This approach allows the community to test pricing models and adoption patterns before transitioning to the fully decentralized solution built on Graph Horizon and Subgraph Service.
INDEXER SELECTION ALGORITHM (IISA)
The Indexer Selection Algorithm (IISA) is a crucial component of the proposal, enabling gateways to select Indexers based on historical Quality of Service (QoS) metrics such as latency, uptime, and error rate. It also considers factors like available stake to ensure a fair balance of network needs, performance, and economic security. The algorithm is key to maintaining a high standard of service while optimizing resource allocation.
CHAT COMMENTS ON IISA
Pablo Carranza Vélez
Pablo suggested focusing on a selection of preferences rather than selecting specific Indexers. He emphasized that the gateway is better suited to select Indexers based on the provided preferences.
Paka
Building on Pablo’s idea, Paka proposed a menu-based approach where developers could specify preferences such as:
- Georedundancy
- Location requirements (e.g., located or non-located in a specific region)
IMPLEMENTATION TIMELINE
The MVP is planned for release in early Q2 2025, with full decentralization dependent on the rollout of Graph Horizon. Updates to the Indexer stack and gateway deployments will be necessary for the initial phase, paving the way for a more robust and scalable solution.
Open Questions and Next Steps
The proposal invites community feedback on pricing models for units of work and refinements to the Indexer Selection Algorithm. These discussions aim to finalize a transparent, fair framework for cost determination and Indexer selection, ensuring the mechanism aligns with the broader goals of The Graph ecosystem.