链集成过程概述

为寻求与The Graph协议集成的区块链团队设计了一个透明且基于治理的集成过程，总结如下，分为3个阶段。

• 团队致力于进行Graph Node和非EVM基础链的Firehose技术集成。详细信息请参阅此处。
• 团队通过在here（治理与GIPs下的新数据源子类别）创建一个论坛帖子来启动协议集成过程。强制使用默认的论坛模板。

• 团队与核心开发者、Graph Foundation以及GUI和网络网关的运营者合作，例如Subgraph Studio，以确保顺利的集成过程。这包括提供必要的后端基础设施，如集成链的JSON RPC或Firehose端点。希望避免自行托管这种基础设施的团队可以利用The Graph节点运营者（Indexers）社区来实现，而Foundation可以提供帮助。
• Graph索引人在The Graph的测试网上测试集成。
• 核心开发者和索引人监控稳定性、性能和数据确定性。

• 团队通过提交一个Graph Improvement Proposal (GIP) 并在 feature support matrix 上发起一个拉取请求 (PR) 来提议主网集成（更多详细信息请查看链接）。
• The Graph Council（The Graph理事会）审查请求，并在成功完成第2阶段并获得积极社区反馈的情况下批准主网支持。

如果整个流程看起来令人望而生畏，不用担心！The Graph Foundation致力于通过促进合作、提供重要信息并指导各个阶段的过程来支持集成者，包括引导他们参与治理流程，如Graph Improvement Proposals (GIPs) 和拉取请求。如果您有任何问题，请通过 [email protected] 或通过Discord（可以联系Pedro、The Graph Foundation成员、IndexerDAO或其他核心开发者）与我们联系。

准备好塑造The Graph Network的未来了吗？立即开始您的提案，成为Web3革命的一部分吧！

这个过程与子图数据服务相关，仅适用于新的子图“数据源”。

这只会影响 Substreams 驱动的子图上的索引奖励的协议支持。新的 Firehose 实现需要在测试网上进行测试，遵循了本 GIP 中第二阶段所概述的方法论。同样地，假设实现是高性能且可靠的，那么需要在 Feature Support Matrix 上提出 PR（Substreams 数据源 子图特性），以及一个新的 GIP 来支持索引奖励的协议。任何人都可以创建这个 PR 和 GIP；基金会将协助获得理事会的批准。

主网上线预计还有数周时间，具体取决于集成开发的时间、是否需要额外的研究、测试和漏洞修复，以及始终如一地需要社区反馈的治理过程的时间。

索引奖励的协议支持取决于利益相关者继续进行测试、收集反馈以及处理对核心代码库的贡献（如果适用）的带宽。这与集成的成熟程度以及集成团队的响应能力直接相关（可能是RPC/Firehose实施背后的团队，也可能不是）。基金会将在整个过程中提供支持。

Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process. This is especially true for chains previously supported on the hosted service or those relying on already tested stacks.