チェーン統合プロセスの概要

透明性のあるガバナンスベースの統合プロセスは、integration with The Graph protocol を求めるブロックチェーン チーム向けに設計されました。 以下に要約するように、これは 3 段階のプロセスです。

ステージ 1. 技術的統合

このセクションへのリンク
  • チームは、非 EVM ベースのチェーン用の Graph Node 統合と Firehose に取り組んでいます。 Here's how
  • チームは、プロトコルの統合プロセスを開始するために、hereのフォーラムスレッドを作成します(Governance & GIPsの下にあるNew Data Sourcesのサブカテゴリ内)。デフォルトのフォーラムテンプレートの使用が必須です。

ステージ 2. 統合の検証

このセクションへのリンク
  • チームは、コア開発者、Graph Foundation、および Subgraph Studio のようなGUIやネットワークゲートウェイのオペレーターと協力して、スムーズな統合プロセスを確保しています。これには、統合するチェーンのJSON RPCやFirehoseエンドポイントなどの必要なバックエンドインフラストラクチャを提供することが含まれます。このようなインフラストラクチャをセルフホスティングしたくないチームは、The Graphのノードオペレーター(インデクサー)のコミュニティを活用して、それを行うことができます。これに関しては、Foundationがサポートを提供できます。
  • Graph Indexer は、The Graph のテストネットで統合をテストします。
  • コア開発者とインデクサーは、安定性、パフォーマンス、およびデータの決定性を監視します。

ステージ 3. メインネットの統合

このセクションへのリンク
  • チームは、メインネット統合を提案するために、Graph Improvement Proposal (GIP) を提出し、feature support matrix に関するプルリクエスト(PR)を開始します(詳細はリンクを参照)。
  • Graph Council はリクエストを検討してメインネットのサポートを承認し、ステージ 2 の成功とコミュニティからの肯定的なフィードバックを提供します。

もしプロセスが難しそうに見える場合でも、心配しないでください!Graph Foundationは、協力を促進し、必要な情報を提供し、Graph Improvement Proposals(GIP)やプルリクエストなどのガバナンスプロセスを含むさまざまな段階でガイドすることにコミットしています。質問がある場合は、[email protected] またはDiscord(Pedro、The Graph Foundationメンバー、IndexerDAO、その他のコア開発者など)を通じてお問い合わせください。

The Graph Network の未来を形作る準備はできていますか? Start your proposal 今すぐ、Web3 革命の一員になりましょう。


1. これは World of Data Services GIP とどのように関連していますか?

このセクションへのリンク

このプロセスは、新しいサブグラフの「データソース」にのみ適用される、サブグラフデータサービスに関連しています。

2. ネットワークがメインネットでサポートされた後に Firehose とサブストリームのサポートが追加された場合はどうなりますか?

このセクションへのリンク

これは、サブストリームで動作するサブグラフに対するインデックスリワードのプロトコルサポートに影響を与えるものです。新しいFirehoseの実装は、このGIPのステージ2に概説されている方法論に従って、テストネットでテストされる必要があります。同様に、実装がパフォーマンスが良く信頼性があると仮定して、Feature Support MatrixへのPR(「Substreamsデータソース」サブグラフ機能)が必要です。また、インデックスリワードのプロトコルサポートに関する新しいGIPも必要です。誰でもPRとGIPを作成できますが、Foundationは評議会の承認をサポートします。

3. このプロセスにはどのくらい時間がかかりますか?

このセクションへのリンク

メインネットへの移行にかかる時間は、統合開発の進捗によるもの、追加の調査が必要かどうか、テストとバグ修正、そして常にコミュニティのフィードバックを必要とするガバナンスプロセスのタイミングに応じて異なりますが、数週間を予想しています。

インデックスリワードのプロトコルサポートは、テスト、フィードバックの収集、および必要な場合のコアコードベースへの貢献の取り扱いに関わる関係者の能力に依存します。これは、統合の成熟度と、統合チームのレスポンスの良さ(RPC/Firehose実装の背後にいるかどうかは問わない)に直接関連しています。Foundationは、プロセス全体を通じてサポートを提供するためにここにいます。

4. 優先順位はどのように扱われますか?

このセクションへのリンク

3.と同様、全体的な準備状況や関係者の帯域幅によります。例えば、Firehoseを導入したばかりの新しいチェーンは、すでにテスト済みの統合や、ガバナンスプロセスが進んでいる統合よりも時間がかかるかもしれません。これは特に、以前ホスティングサービスでサポートされていたチェーンや、すでにテスト済みのスタックに依存しているチェーンに当てはまります。

ページを編集

オペレーティンググラフノード
Integrating New Networks
ページを編集