グラフネットワーク > インデキシング

インデキシング

インデクサは、グラフネットワークのノードオペレータであり、グラフトークン（GRT）を賭けて、インデックス作成や問い合わせ処理のサービスを提供します。インデクサーは、そのサービスの対価として、クエリフィーやインデックス作成の報酬を得ることができます。また、Cobbs-Douglas Rebate Function に基づいて、ネットワーク貢献者全員にその成果に応じて分配される Rebate Pool からも報酬を得ることもできます。

プロトコルにステークされた GRT は解凍期間が設けられており、インデクサーが悪意を持ってアプリケーションに不正なデータを提供したり、不正なインデックスを作成した場合には、スラッシュされる可能性があります。また、インデクサーはデリゲーターからステークによる委任を受けて、ネットワークに貢献することができます。

インデクサ − は、サブグラフのキュレーション・シグナルに基づいてインデックスを作成するサブグラフを選択し、キュレーターは、どのサブグラフが高品質で優先されるべきかを示すために GRT をステークします。消費者（アプリケーションなど）は、インデクサーが自分のサブグラフに対するクエリを処理するパラメータを設定したり、クエリフィーの設定を行うこともできます。

必要な技術レベル

ADVANCED

よくある質問このセクションへのリンク

ネットワーク上のインデクサーになるために必要な最低ステーク量はいくらですか？このセクションへのリンク

インデクサーの最低ステーク量は、現在 100K GRT に設定されています。

インデクサーの収入源は何ですか？このセクションへのリンク

クエリフィー・リベート - ネットワーク上でクエリを提供するための手数料です。この手数料は、インデクサーとゲートウェイ間のステートチャネルを介して支払われます。ゲートウェイからの各クエリリクエストには手数料が含まれ、対応するレスポンスにはクエリ結果の有効性の証明が含まれます。

インデキシング報酬 - プロトコル全体のインフレーションにより生成される年率 3%のインデキシング報酬は、ネットワークのサブグラフ・デプロイメントのインデキシングを行うインデクサーに分配されます。

インデキシングリワードはどのように配布されますか？このセクションへのリンク

インデキシング報酬は、年間 3％の発行量に設定されているプロトコル・インフレから得られます。報酬は、それぞれのサブグラフにおけるすべてのキュレーション・シグナルの割合に基づいてサブグラフに分配され、そのサブグラフに割り当てられたステークに基づいてインデクサーに分配されます。 特典を受けるためには、仲裁憲章で定められた基準を満たす有効な POI（Proof of Indexing）で割り当てを終了する必要があります。

報酬を計算するために、コミュニティによって多数のツールが作成されています。コミュニティガイドコレクションに整理されたコレクションがあります。また、Discord サーバーの #Delegators チャンネルと #Indexers チャンネルでツールの最新リストを見つけることができます。インデクサーソフトウェアスタックと統合された推奨割り当てオプティマイザー。

POI（proof of indexing）とは何ですか？このセクションへのリンク

POI は、インデクサーが割り当てられたサブグラフにインデックスを作成していることを確認するためにネットワークで使用されます。現在のエポックの最初のブロックに対する POI は、割り当てを終了する際に提出しなければ、その割り当てはインデックス報酬の対象となりません。あるブロックの POI は、そのブロックまでの特定のサブグラフのデプロイに対するすべてのエンティティストアのトランザクションのダイジェストです。

インデキシングリワードはいつ配布されますか？このセクションへのリンク

割り当ては、それがアクティブである間、継続的に報酬を発生させます。報酬はインデクサによって集められ、割り当てが終了するたびに分配されます。これは、インデクサーが強制的に閉じようとしたときに手動で行うか、28 エポックの後にデリゲーターがインデクサーのために割り当てを終了することができますが、この場合は報酬がミントされません。 28 エポックは最大の割り当て期間です（現在、1 エポックは約 24 時間です）

保留中のインデクサーの報酬は監視できますか？このセクションへのリンク

RewardsManager コントラクトには、使用できる読み取り専用の getRewards 関数があります。特定の割り当てに対する保留中の報酬を確認します。

コミュニティが作成したダッシュボードの多くには保留中の報酬値が含まれており、次の手順に従って手動で簡単に確認できます。

メインネット・サブグラフにクエリして、全てのアクティブなアロケーションの ID を取得します。

query indexerAllocations {
  indexer(id: "<Indexer_ADDRESS>") {
    allocations {
      activeForIndexer {
        allocations {
          id
        }
      }
    }
  }
}

Use Etherscan to call getRewards():

報酬契約への Etherscan インターフェイスに移動します。

getRewards()を呼び出します
- 10 を拡大します。 getRewardsのドロップダウン
- 入力欄にallocationIDを入力
- Queryボタンをクリック

争議（disputes）とは何で、どこで見ることができますか？このセクションへのリンク

インデクサークエリとアロケーションは、期間中に The Graph 上で争議することができます。争議期間は、争議の種類によって異なります。クエリ/裁定には 7 エポックスの紛争窓口があり、割り当てには 56 エポックスがあります。これらの期間が経過した後は、割り当てやクエリのいずれに対しても紛争を起こすことはできません。紛争が開始されると、Fishermen は最低 10,000GRT のデポジットを要求され、このデポジットは紛争が最終的に解決されるまでロックされます。フィッシャーマンとは、紛争を開始するネットワーク参加者のことです。

論争には 3 の結果が考えられます。漁師の預金も同様です

争議が却下された場合、フィッシャーマンが預かった GRT はバーンされ、争議中のインデクサーはスラッシュされません。
争議が引き分けた場合、フィッシャーマンのデポジットは返還され、争議中のインデクサーはスラッシュされることはありません。
争議が受け入れられた場合、フィッシャーマンがデポジットした GRT は返却され、争議中のインデクサーはスラッシュされ、フィッシャーマンはスラッシュされた GRT の 50%を獲得します。

紛争は、UI のインデクサーのプロファイルページの紛争タブで確認できます。

クエリフィーリベートとは何ですか、またいつ配布されますか？このセクションへのリンク

クエリフィーは、割り当てが終了するたびにゲートウェイが徴収し、サブグラフのクエリフィーリベートプールに蓄積されます。リベートプールは、インデクサーがネットワークのために獲得したクエリフィーの量にほぼ比例してステークを割り当てるように促すためのものです。プール内のクエリフィーのうち、特定のインデクサーに割り当てられる部分はコブス・ダグラス生産関数を用いて計算されます。インデクサーごとの分配額は、プールへの貢献度とサブグラフでのステークの割り当ての関数となります。

割り当てが終了し、争議期間が経過すると、リベートをインデクサーが請求できるようになります。請求されたクエリフィーのリベートは、クエリフィーカットとデリゲーションプールの比率に基づいて、インデクサーとそのデリゲーターに分配されます。

クエリフィーカットとインデキシングリワードカットとは？このセクションへのリンク

クエリフィーカット とインデキシングリワードカット の値は、インデクサーがクールダウンブロックと共に設定できるデリゲーションパラメータで、インデクサーとそのデリゲーター間の GRT の分配を制御するためのものです。デリゲーションパラメータの設定方法については、Staking in the Protocolの最後のステップを参照してください。

クエリフィーカット - サブグラフに蓄積されたクエリフィーリベートのうち、インデクサーに分配される割合です。これが 95%に設定されていると、割り当てが要求されたときに、インデクサはクエリフィー・リベート・プールの 95%を受け取り、残りの 5%はデリゲータに渡されます。
インデキシング・リワードカット - サブグラフに蓄積されたインデキシング・リワードのうち、インデクサーに分配される割合です。これが 95%に設定されていると、割り当てが終了したときに、インデクサがインデキシング・リワードプールの 95%を受け取り、残りの 5%をデリゲータが分け合うことになります。

インデクサーはどのサブグラフにインデックスを付けるかをどう見分けるのですか？このセクションへのリンク

インデクサーは、サブグラフのインデキシングの決定に高度な技術を適用することで差別化を図ることができますが、一般的な考え方として、ネットワーク内のサブグラフを評価するために使用されるいくつかの主要な指標について説明します。

キュレーションシグナル - 特定のサブグラフに適用されたネットワークキュレーションシグナルの割合は、そのサブグラフへの関心を示す指標となり、特にクエリのボリュームが増加しているブートストラップ段階では有効となります。
コレクティド・クエリフィー - 特定のサブグラフに対してコレクティド・クエリフィー量の履歴データは、将来的な需要に対する指標となります。
ステーク量 - 他のインデクサーの行動を監視したり、特定のサブグラフに割り当てられた総ステーク量の割合を見ることで、インデクサーはサブグラフ・クエリの供給側を監視し、ネットワークが信頼を示しているサブグラフや、より多くの供給を必要としているサブグラフを特定することができます。
インデックス報酬のないサブグラフ - 一部のサブグラフは、主に IPFS などのサポートされていない機能を使用していたり、メインネット外の別のネットワークをクエリしていたりするため、インデックス報酬を生成しません。インデクシング・リワードを生成していないサブグラフにはメッセージが表示されます。

必要なハードウェアは何ですか？このセクションへのリンク

Small - いくつかのサブグラフのインデックス作成を開始するのに十分ですが、おそらく拡張が必要になります
Standard - デフォルトのセットアップであり、k8s/terraform の展開マニフェストの例で使用されているものです
Medium - 100 個のサブグラフと 1 秒あたり 200 ～ 500 のリクエストをサポートするプロダクションインデクサー
Large - 現在使用されているすべてのサブグラフのインデックスを作成し、関連するトラフィックのリクエストに対応します

Setup	Postgres (CPUs)	Postgres (memory in GBs)	Postgres (disk in TBs)	VMs (CPUs)	VMs (memory in GBs)
Small	4	8	1	4	16
Standard	8	30	1	12	48
Medium	16	64	2	32	64
Large	72	468	3.5	48	184

インデクサーが取るべきセキュリティ対策は？このセクションへのリンク

オペレーターウォレット - オペレーターウォレットを設定することは重要な予防措置です。これにより、インデクサーは、ステークを制御するキーと日々の操作を制御するキーとの間の分離を維持できるようになります。 - デイオペレーション。手順については、Stake in Protocol を参照してください。
ファイアウォール - インデクサーサービスのみを公開する必要があり、管理ポートとデータベースアクセスのロックダウンに特に注意を払う必要があります: グラフノード JSON-RPC エンドポイント (デフォルトポート: 8030)、インデクサー管理 API エンドポイント (既定のポート: 18000)、および Postgres データベースエンドポイント (既定のポート: 5432) は公開しないでください。

インフラストラクチャこのセクションへのリンク

インデクサーのインフラストラクチャの中心にあるのは、インデックス化されたネットワークを監視し、サブグラフ定義ごとにデータを抽出してロードし、GraphQL API として提供するグラフノードです。グラフノードは、各インデックス付きネットワークからのデータを公開するエンドポイントに接続する必要があります。データを調達するための IPFS ノード。そのストア用の PostgreSQL データベース。ネットワークとのやり取りを容易にするインデクサーコンポーネント。

PostgreSQL データベース - グラフノードのメインストアで、サブグラフのデータが格納されています。また、インデクササービスとエージェントは、データベースを使用して、ステートチャネルデータ、コストモデル、およびインデクシングルールを保存します。
データエンドポイント - EVM 互換ネットワークの場合、EVM 互換 JSON-RPC API を公開するエンドポイントにグラフノードを接続する必要があります。これは、単一のクライアントの形式をとる場合もあれば、複数の負荷を分散するより複雑なセットアップの場合もあります。特定のサブグラフには、アーカイブモードやパリティトレース API などの特定のクライアント機能が必要になることに注意してください。
IPFS ノード（バージョン 5 未満） - サブグラフのデプロイメタデータは IPFS ネットワーク上に保存されます。グラフノードは、サブグラフのデプロイ時に主に IPFS ノードにアクセスし、サブグラフマニフェストと全てのリンクファイルを取得します。ネットワーク・インデクサーは独自の IPFS ノードをホストする必要はありません。ネットワーク用の IPFS ノードは、https://ipfs.network.thegraph.com でホストされています。
Indexer service - ネットワークとの必要な外部通信を全て処理します。コストモデルとインデキシングのステータスを共有し、ゲートウェイからのクエリ要求をグラフノードに渡し、ゲートウェイとのステートチャンネルを介してクエリの支払いを管理します。
Indexer agent - ネットワークへの登録、グラフノードへのサブグラフのデプロイ管理、割り当ての管理など、チェーン上のインデクサーのインタラクションを容易にします。
Prometheus metrics server - Graph Node と Indexer コンポーネントは、自分のメトリクスをメトリクス・サーバーにログします。

注: アジャイルなスケーリングをサポートするには、クエリとインデックス作成の懸念事項を異なるノードセット (クエリノードとインデックスノード) に分けることをお勧めします。

ポートの概要このセクションへのリンク

重要: ポートを公開する場合は注意してください。管理ポートはロックしておく必要があります。これには、Graph Node JSON-RPC と、以下に詳述するインデクサー管理エンドポイントが含まれます。

グラフノードこのセクションへのリンク

Port	Purpose	Routes	CLI Argument	Environment Variable
8000	GraphQL HTTP server (for subgraph queries)	/subgraphs/id/... /subgraphs/name/.../...	--http-port	-
8001	GraphQL WS (for subgraph subscriptions)	/subgraphs/id/... /subgraphs/name/.../...	--ws-port	-
8020	JSON-RPC (for managing deployments)	/	--admin-port	-
8030	Subgraph indexing status API	/graphql	--index-node-port	-
8040	Prometheus metrics	/metrics	--metrics-port	-

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

Port	Purpose	Routes	CLI Argument	Environment Variable
7600	GraphQL HTTP server (for paid subgraph queries)	/subgraphs/id/... /status /channel-messages-inbox	--port	`INDEXER_SERVICE_PORT`
7300	Prometheus metrics	/metrics	--metrics-port	-

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

Port	Purpose	Routes	CLI Argument	Environment Variable
8000	Indexer management API	/	--indexer-management-port	`INDEXER_AGENT_INDEXER_MANAGEMENT_PORT`

Google Cloud で Terraform を使ってサーバーインフラを構築このセクションへのリンク

注：インデクサーは、AWS、Microsoft Azure、Alibaba を代替的に使用することができます。

インストールの前提条件このセクションへのリンク

Google Cloud SDK
Kubectl コマンドラインツール
Terraform

Google Cloud プロジェクトの作成このセクションへのリンク

クローンまたはインデクサーリポジトリに移動
./terraform ディレクトリに移動し、ここですべてのコマンドを実行

cd terraform

Google Cloud で認証し、新しいプロジェクトを作成

gcloud auth login
project=<PROJECT_NAME>
gcloud projects create --enable-cloud-apis $project

Google Cloud Console の[billing page](課金ページ) を使用して、新しいプロジェクトの課金を有効にします。
Google Cloud の設定を作成します。

proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
gcloud config configurations create $project
gcloud config set project "$proj_id"
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

Google Cloud API の設定

gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com
gcloud services enable servicenetworking.googleapis.com
gcloud services enable sqladmin.googleapis.com

サービスアカウントを作成

svc_name=<SERVICE_ACCOUNT_NAME>
gcloud iam service-accounts create $svc_name \
  --description="Service account for Terraform" \
  --display-name="$svc_name"
gcloud iam service-accounts list
# Get the email of the service account from the list
svc=$(gcloud iam service-accounts list --format='get(email)'
--filter="displayName=$svc_name")
gcloud iam service-accounts keys create .gcloud-credentials.json \
  --iam-account="$svc"
gcloud projects add-iam-policy-binding $proj_id \
  --member serviceAccount:$svc \
  --role roles/editor

データベースと次のステップで作成する Kubernetes クラスター間のピアリングを有効化

gcloud compute addresses create google-managed-services-default \
  --prefix-length=20 \
  --purpose=VPC_PEERING \
  --network default \
  --global \
  --description 'IP Range for peer networks.' gcloud services vpc-peerings connect \
  --network=default \
  --ranges=google-managed-services-default

Terraform 設定ファイルを作成（必要に応じて更新してください）

indexer=<INDEXER_NAME>
cat > terraform.tfvars <<EOF
project = "$proj_id"
indexer = "$indexer"
database_password = "<database passowrd>"
EOF

Terraform を使ってインフラを構築このセクションへのリンク

コマンドを実行する前に、variables.tfに目を通し、このディレクトリにterraform.tfvarsというファイルを作成します（または、前のステップで作成したものを修正します）。デフォルトを上書きしたい、あるいは値を設定したい各変数について、terraform.tfvarsに設定を入力します。

以下のコマンドを実行して、インフラを作成します。

# 必要なプラグインのインストール
terraform init

# 作成されるリソースのプランを見る
terraform plan

# リソースの作成（最大で30分程度かかる見込みです）
terraform apply

kubectl apply -k $dirですべてのリソースをデプロイします。

gcloud container clusters get-credentials $indexer
kubectl config use-context $(kubectl config get-contexts --output='name'
| grep $indexer)

インデクサー用の Kubernetes コンポーネントの作成このセクションへのリンク

k8s/overlaysディレクトリを新しいディレクトリ$dir,にコピーし、$dir/kustomization.yaml内のbasesエントリがk8s/baseディレクトリを指すように調整します。
$dir にあるすべてのファイルを読み、コメントに示されている値を調整します。

Deploy all resources with kubectl apply -k $dir.

グラフノードこのセクションへのリンク

グラフノードはオープンソースの Rust 実装で、Ethereum ブロックチェーンをイベントソースにして、GraphQL エンドポイントでクエリ可能なデータストアを決定論的に更新します。開発者は、サブグラフを使ってスキーマを定義し、ブロックチェーンから供給されるデータを変換するためのマッピングセットを使用します。グラフノードは、チェーン全体の同期、新しいブロックの監視、GraphQL エンドポイント経由での提供を処理します。

ソースからのスタートこのセクションへのリンク

インストールの前提条件このセクションへのリンク

Rust
PostgreSQL
IPFS
Ubuntu ユーザーのための追加要件 - グラフノードを Ubuntu 上で動作させるためには、いくつかの追加パッケージが必要になります。

sudo apt-get install -y clang libpg-dev libssl-dev pkg-config

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

PostgreSQL データベースサーバを起動します。

initdb -D .postgres
pg_ctl -D .postgres -l logfile start
createdb graph-node

Graph Node リポジトリのクローンを作成し、cargo build を実行してソースをビルドします
全ての依存関係の設定が完了したら、グラフノードを起動します:

cargo run -p graph-node --release -- \
  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
  --ethereum-rpc [NETWORK_NAME]:[URL] \
  --ipfs https://ipfs.network.thegraph.com

Docker の使用このセクションへのリンク

前提条件このセクションへのリンク

イーサリアムノード - デフォルトでは、docker compose setup は mainnet: http://host.docker.internal:8545を使ってホストマシン上のイーサリアムノードに接続します。このネットワーク名と URL は、docker-compose.yamlを更新することで置き換えることができます。

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

Graph Node をクローンし、Docker ディレクトリに移動します。

git clone http://github.com/graphprotocol/graph-node
cd graph-node/docker

Linux ユーザーのみ - 付属のスクリプトを使って、docker-compose.yamlの中でhost.docker.internalの代わりにホストの IP アドレスを使用します:

./setup.sh

Ethereum のエンドポイントに接続し、ローカルの Graph Node を起動します:

docker-compose up

インデクサーコンポーネントこのセクションへのリンク

ネットワークへの参加を成功させるためには、ほぼ常に監視と対話を行う必要があるため、Indexers のネットワークへの参加を促進するための一連の Typescript アプリケーションを構築しました。インデクサーには 3 つのコンポーネントがあります:

Indexer agent - ネットワークとインデクサー自身のインフラを監視し、どのサブグラフ・デプロイメントがインデキシングされ、チェーンに割り当てられるか、またそれぞれにどれだけの量が割り当てられるかを管理します。
Indexer service - 外部に公開する必要のある唯一のコンポーネントで、サブグラフのクエリをグラフノードに渡し、クエリの支払いのための状態チャンネルを管理し、重要な意思決定情報をゲートウェイなどのクライアントに共有します。
Indexer CLI - インデクサーエージェントを管理するためのコマンドラインインターフェイスです。これによって、インデクサーはコストモデル、手動割り当て、アクションキュー、インデックスルールを管理することができます。

はじめにこのセクションへのリンク

インデクサーエージェントとインデクサーサービスは、グラフノードインフラストラクチャーと同居している必要があります。ここでは、NPM パッケージやソースを使ってベアメタル上で実行する方法と、Google Cloud Kubernetes Engine 上で kubernetes や docker を使って実行する方法を説明します。これらの設定例があなたのインフラに適用できない場合は、コミュニティガイドを参照するか、Discordでお問い合わせください。インデクサーコンポーネントを起動する前に、プロトコルのステークを忘れないでください。

NPM パッケージからこのセクションへのリンク

npm install -g @graphprotocol/indexer-service
npm install -g @graphprotocol/indexer-agent

# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
npm install -g @graphprotocol/graph-cli
npm install -g @graphprotocol/indexer-cli

# Indexer service
graph-indexer-service start ...

# Indexer agent
graph-indexer-agent start ...

# Indexer CLI
#Forward the port of your agent pod if using Kubernetes
kubectl port-forward pod/POD_ID 18000:8000
graph indexer connect http://localhost:18000/
graph indexer ...

ソースからこのセクションへのリンク

# From Repo root directory
yarn

# Indexer Service
cd packages/indexer-service
./bin/graph-indexer-service start ...

# Indexer agent
cd packages/indexer-agent
./bin/graph-indexer-service start ...

# Indexer CLI
cd packages/indexer-cli
./bin/graph-indexer-cli indexer connect http://localhost:18000/
./bin/graph-indexer-cli indexer ...

Docker の使用このセクションへのリンク

レジストリからイメージを引き出す

docker pull ghcr.io/graphprotocol/indexer-service:latest
docker pull ghcr.io/graphprotocol/indexer-agent:latest

または、ソースからローカルにイメージをビルドします

# Indexer service
docker build \
  --build-arg NPM_TOKEN=<npm-token> \
  -f Dockerfile.indexer-service \
  -t indexer-service:latest \
# Indexer agent
docker build \
  --build-arg NPM_TOKEN=<npm-token> \
  -f Dockerfile.indexer-agent \
  -t indexer-agent:latest \

コンポーネントの実行

docker run -p 7600:7600 -it indexer-service:latest ...
docker run -p 18000:8000 -it indexer-agent:latest ...

注: コンテナーを開始すると、http://localhost:7600 でインデクサーサービスにアクセスできるようになります。であり、インデクサーエージェントは http://localhost:18000/ でインデクサー管理 API を公開する必要があります。

K8s と Terraform の使用このセクションへのリンク

Setup Server Infrastructure Using Terraform on Google Cloud の項を参照ください。

使い方このセクションへのリンク

注：全てのランタイム設定変数は、起動時にコマンドのパラメーターとして適用するか、COMPONENT_NAME_VARIABLE_NAME（例：INDEXER_AGENT_ETHEREUM）という形式の環境変数を使用することができます。

インデクサーエージェントこのセクションへのリンク

graph-indexer-agent start \
  --ethereum <MAINNET_ETH_ENDPOINT> \
  --ethereum-network mainnet \
  --mnemonic <MNEMONIC> \
  --indexer-address <INDEXER_ADDRESS> \
  --graph-node-query-endpoint http://localhost:8000/ \
  --graph-node-status-endpoint http://localhost:8030/graphql \
  --graph-node-admin-endpoint http://localhost:8020/ \
  --public-indexer-url http://localhost:7600/ \
  --indexer-geo-coordinates <YOUR_COORDINATES> \
  --index-node-ids default \
  --indexer-management-port 18000 \
  --metrics-port 7040 \
  --network-subgraph-endpoint https://gateway.network.thegraph.com/network \
  --default-allocation-amount 100 \
  --register true \
  --inject-dai true \
  --postgres-host localhost \
  --postgres-port 5432 \
  --postgres-username <DB_USERNAME> \
  --postgres-password <DB_PASSWORD> \
  --postgres-database indexer \
  --allocation-management auto \
  | pino-pretty

インデクサーサービスこのセクションへのリンク

SERVER_HOST=localhost \
SERVER_PORT=5432 \
SERVER_DB_NAME=is_staging \
SERVER_DB_USER=<DB_USERNAME> \
SERVER_DB_PASSWORD=<DB_PASSWORD> \
graph-indexer-service start \
  --ethereum <MAINNET_ETH_ENDPOINT> \
  --ethereum-network mainnet \
  --mnemonic <MNEMONIC> \
  --indexer-address <INDEXER_ADDRESS> \
  --port 7600 \
  --metrics-port 7300 \
  --graph-node-query-endpoint http://localhost:8000/ \
  --graph-node-status-endpoint http://localhost:8030/graphql \
  --postgres-host localhost \
  --postgres-port 5432 \
  --postgres-username <DB_USERNAME> \
  --postgres-password <DB_PASSWORD> \
  --postgres-database is_staging \
  --network-subgraph-endpoint https://gateway.network.thegraph.com/network \
  | pino-pretty

インデクサー CLIこのセクションへのリンク

インデクサー CLI は、@graphprotocol/graph-cli アクセス可能なプラグインですターミナルの graph indexer で。

graph indexer connect http://localhost:18000
graph indexer status

Indexer CLI によるインデクサー管理このセクションへのリンク

Indexer Management API と対話するための推奨ツールは Indexer CLI で、これは Graph CLI を拡張したものです。インデクサーエージェントは、インデクサーに代わって自律的にネットワークと対話するために、インデクサからの入力を必要とします。インデクサーエージェントの動作を定義する仕組みは、 ** 割り当て管理モードと ** インデックスルール です。auto モードでは、Indexer は indexing rules を使って、インデックスやクエリを提供するサブグラフを選択するための特定の戦略を適用することができます。ルールは、エージェントが提供する GraphQL API を介して管理され、 Indexer Management API として知られています。手動モードでは、Indexer は action queue を使って割り当てアクションを作成し、実行される前に明示的に承認することができます。oversight モードでは、indexing rules を使って action queue を作成し、実行のために明示的な承認が必要です。

使い方このセクションへのリンク

Indexer CLIは、通常ポート・フォワーディングを介してインデクサー・エージェントに接続するため、CLI が同じサーバやクラスタ上で動作する必要はありません。ここでは CLI について簡単に説明します。

graph indexer connect <url> - インデクサー管理 API に接続します。通常、サーバーへの接続はポートフォワーディングによって開かれ、CLI をリモートで簡単に操作できるようになります。 (例：kubectl port-forward pod/<indexer-agent-pod> 8000:8000)
graph インデクサールール get [options] <deployment-id> [<キー1> ...] - all を <deployment-id> として使用して 1 つ以上のインデックス作成ルールを取得し、すべてのルールを取得するか、global< /code> グローバルなデフォルトを取得します。追加の引数 <code>--merged を使用して、展開固有のルールをグローバルルールとマージすることを指定できます。これは、インデクサーエージェントでそれらがどのように適用されるかです。
graph indexer rules set [options] <deployment-id> <key1> <value1> ... - 1 つまたは複数のインデキシング規則を設定します。
graph indexer rules start [options] <deployment-id> - 利用可能な場合はサブグラフ配置のインデックス作成を開始し、decisionBasisをalwaysに設定するので、インデクサー・エージェントは常にインデキシングを選択します。グローバルルールが always に設定されている場合、ネットワーク上のすべての利用可能なサブグラフがインデックス化されます。
graph indexer rules stop [options] <deployment-id> - 配置のインデックス作成を停止し、decisionBasisを never に設定することで、インデックスを作成する配置を決定する際にこの配置をスキップします。
graph indexer rules maybe [options] <deployment-id> - 配置のthedecisionBasis をrulesに設定し、インデクサーエージェントがインデキシングルールを使用して、この配置にインデックスを作成するかどうかを決定するようにします。
graph indexer actions get [options] <action-id> - all を使って一つ以上のアクションを取得するか、 action-id を空にすると全てのアクションを取得します。追加引数 --status は、特定のステータスのアクションをすべて出力するために使用されます。
graph indexer action queue allocate <deployment-id> <allocation-amount> - キューの割り当てアクション。
graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount> - queue reallocate action を実行します。
graph indexer action queue unallocate <deployment-id> <allocation-id> - queue unallocate action を実行します。
graph indexer actions cancel [<action-id> ...] - id が未指定の場合はキュー内の全てのアクションをキャンセル、それ以外はスペースをセパレータとした id の配列をキャンセルします。
graph indexer actions approve [<action-id> ...] - 複数のアクションの実行を承認します。
graph indexer actions execute approve - 承認されたアクションを直ちに実行するようにワーカーを強制します。

出力にルールを表示するすべてのコマンドは、-output引数を使用して、サポートされている出力形式(table, yaml, and json) の中から選択できます。

インデキシングルールこのセクションへのリンク

インデキシングルールは、グローバルなデフォルトとして、または ID を使用して特定のサブグラフデプロイメントに適用できます。 deploymentとdecisionBasisフィールドは必須で、その他のフィールドはすべてオプションです。インデキシングルールがdecisionBasisとしてrules を持つ場合、インデクサー・エージェントは、そのルール上の非 NULL の閾値と、対応する配置のためにネットワークから取得した値を比較します。サブグラフデプロイメントがいずれかのしきい値以上（または以下）の値を持つ場合、それはインデキシングのために選択されます。

例えば、グローバルルールのminStakeが5(GRT) の場合、5(GRT) 以上のステークが割り当てられているサブグラフデプロイメントは、インデックスが作成されます。しきい値ルールには、 maxAllocationPercentage, minSignal, maxSignal, minStake, and minAverageQueryFeesがあります。

データモデル

type IndexingRule {
    identifier: string
    identifierType: IdentifierType
    decisionBasis: IndexingDecisionBasis!
    allocationAmount: number | null
    allocationLifetime: number | null
    autoRenewal: boolean
    parallelAllocations: number | null
    maxAllocationPercentage: number | null
    minSignal: string | null
    maxSignal: string | null
    minStake: string | null
    minAverageQueryFees: string | null
    custom: string | null
    requireSupported: boolean | null
  }

IdentifierType {
  deployment
  subgraph
  group
}

IndexingDecisionBasis {
  rules
  never
  always
  offchain
}

インデックスルールの使用例：

graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK

graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false

graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK

graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK

アクションキュー CLIこのセクションへのリンク

indexer-cli は、アクションキューを手動で操作するための actions モジュールを提供します。これは、アクションキューと対話するために、インデクサ管理サーバによってホストされる Graphql API を使用します。

アクション実行ワーカーは、ActionStatus = approved である場合にのみ、実行するためにキューからアイテムを取得します。推奨されるパスでは、アクションは ActionStatus = queued でキューに追加されるので、オンチェインで実行するためには承認されなければなりません。一般的なフローは次のようになります。

サードパーティのオプティマイザツールや indexer-cli のユーザーによってキューに追加されたアクション
インデクサーは indexer-cli を使って、キューに入れられたすべてのアクションを見ることができます。
インデクサー(または他のソフトウェア) は、キュー内のアクションを indexer-cli を使って承認または取り消すことができます。approve と cancel コマンドは、入力としてアクション ID の配列を取ります。
実行ワーカーは定期的に承認されたアクションのためにキューをポーリングします。キューから approved アクションを取得し、実行を試み、実行状況に応じて db の値を success または failed に更新します。
アクションが成功した場合、ワーカーは、エージェントが auto または oversight モードの間に手動アクションを取るときに便利な、今後どのように割り当てを管理するかを示すインデックス付けルールが存在することを確認します。
インデクサーはアクションキューを監視してアクションの実行履歴を確認し、必要であれば、実行に失敗したアクションアイテムを再承認して更新することができます。アクションキューは、キューに入れられ、実行されたすべてのアクションの履歴を提供します。

データモデル:

Type ActionInput {
    status: ActionStatus
    type: ActionType
    deploymentID: string | null
    allocationID: string | null
    amount: string | null
    poi: string | null
    force: boolean | null
    source: string
    reason: string | null
    priority: number | null
}

ActionStatus {
  queued
  approved
  pending
  success
  failed
  canceled
}

ActionType {
  allocate
  unallocate
  reallocate
  collect
}

ソースからの使用例：

indexer indexer actions get all

indexer indexer actions get --status queued

indexer indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000

indexer indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000

indexer indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae

indexer indexer actions cancel

indexer indexer actions approve 1 3 5

indexer indexer actions execute approve

割り当て管理でサポートされるアクションタイプは、入力要件が異なることに注意してください。

Allocate - 特定のサブグラフの配置にステークを割り当てます。
- 必要なアクションパラメータを指定します:
  - デプロイメント ID
  - 量
Unallocate - 割り当てを終了し、他の場所に再割り当てするためにステークを解放します。
- 必要なアクションパラメータを指定します:
  - アロケーション ID
  - デプロイメント ID
- 任意のアクションパラメータ：
  - poi
  - force (グラフノードが提供するものと一致しなくても、提供された POI を使用することを強制する)
Reallocate - アロケーションをアトミックにクローズし、同じサブグラフのために新しいアロケーションをオープンします。
- 必要なアクションパラメータを指定します:
  - アロケーション ID
  - デプロイメント ID
  - 量
- 任意のアクションパラメータ：
  - poi
  - force (グラフノードが提供するものと一致しなくても、提供された POI を使用することを強制する)

コストモデルこのセクションへのリンク

コストモデルは、マーケットやクエリ属性に基づいて、クエリの動的な価格設定を行います。インデクサーサービスは、クエリに応答する予定の各サブグラフのコストモデルをゲートウェイと共有します。一方、ゲートウェイはコストモデルを使用して、クエリごとにインデクサーの選択を決定し、選択されたインデクサーと支払いの交渉を行います。

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

Agora 言語は、クエリのコストモデルを宣言するための柔軟なフォーマットを提供します。 Agora のコストモデルは、GraphQL クエリのトップレベルのクエリごとに順番に実行される一連のステートメントです。各トップレベルのクエリに対して、それにマッチする最初のステートメントがそのクエリの価格を決定します。

ステートメントは、GraphQL クエリのマッチングに使用される述語と、評価されると decimal GRT でコストを出力するコスト式で構成されます。クエリの名前付き引数の位置にある値は、述語の中に取り込まれ、式の中で使用されます。また、グローバルを設定し、式のプレースホルダーとして代用することもできます。

コストモデルの例:

# This statement captures the skip value,
# uses a boolean expression in the predicate to match specific queries that use `skip`
# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;

# This default will match any GraphQL expression.
# It uses a Global substituted into the expression to calculate cost
default => 0.1 * $SYSTEM_LOAD;

上記のモデルを使用したクエリのコスト計算の例:

クエリ	価格
{ pairs(skip: 5000) { id } }	0.5 GRT
{ トークン { シンボル } }	0.1 GRT
{ pairs(skip: 5000) { id { tokens } symbol } }	0.6 GRT

コストモデルの適用このセクションへのリンク

コストモデルは Indexer CLI を通じて適用され、それをインデクサー・エージェントの Indexer Management API に渡してデータベースに格納します。その後、インデクサーサービスがこれを受け取り、ゲートウェイから要求があるたびにコスト・モデルを提供します。

indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
indexer cost set model my_model.agora

ネットワークとのインタラクションこのセクションへのリンク

プロトコルへのステークこのセクションへのリンク

インデクサーとしてネットワークに参加するための最初のステップは、プロトコルを承認し、資金を拠出し、（オプションで）日常的なプロトコルのやり取りのためにオペレーターアドレスを設定することです。 _ 注: 本説明書ではコントラクトのやり取りに Remix を使用しますが、お好みのツールを自由にお使いください（OneClickDapp, ABItopic, and MyCryptoなどが知られています）

インデクサーがプロトコルに GRT をステークすると、Indexer コンポーネントを立ち上げ、ネットワークとのやりとりを開始することができます。

トークンの承認このセクションへのリンク

ブラウザでRemix appを開きます。
File ExplorerでGraphToken.abiというファイルを作成し、 token ABIを指定します。
GraphToken.abiを選択してエディタで開いた状態で、Remix のインターフェースの Deploy and Run Transactions セクションに切り替えます。
環境から[Injected Web3] を選択し、Accountでインデクサーアドレスを選択します。
GraphToken のコントラクトアドレスの設定 - At Addressの横に GraphToken のコントラクトアドレス(0xc944E90C64B2c07662A292be6244BDf05Cda44a7) を貼り付け、At Addressボタンをクリックして適用します。
approve(spender, amount)関数を呼び出し、ステーキング契約を承認します。 spenderにはステーキングコントラクトアドレス（0xF55041E37E12cD407ad00CE2910B8269B01263b9）を、amountにはステークするトークン（単位：wei）を記入します。

トークンをステークするこのセクションへのリンク

ブラウザでRemix appを開きます。
File ExplorerでStaking.abiという名前のファイルを作成し、Staking ABI を指定します。
エディタでStaking.abiを選択して開いた状態で、Remix インターフェースのDeploy and Run Transactionsセクションに切り替えます。
環境から[Injected Web3] を選択し、Accountでインデクサーアドレスを選択します。
Staking contract address の設定 - At Addressの横に Staking contract address (0xF55041E37E12cD407ad00CE2910B8269B01263b9) を貼り付け、 At Addressボタンをクリックして適用します。
stake()を呼び出して、GRT をプロトコルにステークします。
(オプション）インデクサーは、資金を管理する鍵と、サブグラフへの割り当てや（有料の）クエリの提供などの日常的な動作を行う鍵とを分離するために、別のアドレスをインデクサインフラストラクチャのオペレーターとして承認することができます。オペレーターを設定するには、オペレーターのアドレスを指定してsetOperator()をコールします。
(オプション) 報酬の分配を制御し、デリゲータを戦略的に引き付けるために、インデクサーは indexingRewardCut (parts per million)、 queryFeeCut (parts per million)、 cooldownBlocks (number of blocks) を更新することで、デリゲーションパラメータを更新することができます。これを行うにはsetDelegationParameters()をコールします。次の例では、クエリフィーカットをクエリリベートの 95%をインデクサーに、5%をデリゲーターに分配するように設定し、インデクサーリワードカットをインデキシング報酬の 60%をインデクサーに、40%をデリゲーターに分配するよう設定し、thecooldownBlocks 期間を 500 ブロックに設定しています。

setDelegationParameters(950000, 600000, 500)

アロケーションの寿命このセクションへのリンク

インデクサーによって作成された後、健全なアロケーションは 4 つの状態を経ます。

アクティブ - 割り当てがオンチェーンで作成されると ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/master/contracts/staking/ Staking.sol#L873)) アクティブと見なされます。インデクサー自身および/または委任されたステークの一部は、サブグラフの展開に割り当てられます。これにより、インデックス作成の報酬を要求し、そのサブグラフの展開に対するクエリを提供できます。インデクサーエージェントは、インデクサールールに基づいて割り当ての作成を管理します。
Closed - インデクサーは、1 エポックが経過した時点で自由に割り当てをクローズすることができます（closeAllocation()）また、インデクサエージェントは、maxAllocationEpochs（現在は 28 日）が経過した時点で自動的に割り当てをクローズします。割り当てが有効な POI（Proof of Indexing）とともにクローズされると、そのインデクサー報酬がインデクサーとそのデリゲーターに分配されます（詳細は下記の「報酬の分配方法」を参照してください）
Finalized - 割り当てがクローズすると、争議期間が設けられます。その後、割り当てがfinalizedしたとみなされ、クエリフィーのリベートを請求することができます（claim()）インデクサーエージェントは、ネットワークを監視してfinalized した割り当てを検出し、設定可能な（オプションの）しきい値 —-allocation-claim-thresholdを超えていれば、それを請求できます。
請求 - アロケーションの最終状態で、アクティブなアロケーションとしての期間が終了し、全ての適格な報酬が配布され、クエリ料の払い戻しが請求されます。

インデクサーは、チェーン上に配置を作成する前に、チェーンヘッドにサブグラフの配置を同期させるために、オフチェーン同期機能を利用することを推奨します。この機能は、同期に 28 エポック以上かかる可能性があるサブグラフや、不定期に失敗する可能性があるサブグラフに特に有効です。

.css-1d5t0lt{white-space:normal;}インデキシング

インデクサーの収入源は何ですか？#このセクションへのリンク

インデキシングリワードはどのように配布されますか？#このセクションへのリンク

POI（proof of indexing）とは何ですか？#このセクションへのリンク

インデキシングリワードはいつ配布されますか？#このセクションへのリンク

保留中のインデクサーの報酬は監視できますか？#このセクションへのリンク

争議（disputes）とは何で、どこで見ることができますか？#このセクションへのリンク

クエリフィーリベートとは何ですか、またいつ配布されますか？#このセクションへのリンク

クエリフィーカットとインデキシングリワードカットとは？#このセクションへのリンク

インデクサーはどのサブグラフにインデックスを付けるかをどう見分けるのですか？#このセクションへのリンク

必要なハードウェアは何ですか？#このセクションへのリンク

インデクサーが取るべきセキュリティ対策は？#このセクションへのリンク

インフラストラクチャ#このセクションへのリンク

ポートの概要#このセクションへのリンク

グラフノード.css-bjwmk6{-webkit-margin-start:0.35em;margin-inline-start:0.35em;opacity:0;-webkit-transition:opacity 200ms ease;transition:opacity 200ms ease;}h4:hover .css-bjwmk6,.css-bjwmk6:focus-within{opacity:1;}#このセクションへのリンク

Indexer Service#このセクションへのリンク

Indexer Agent#このセクションへのリンク

Google Cloud で Terraform を使ってサーバーインフラを構築#このセクションへのリンク

インストールの前提条件#このセクションへのリンク

Google Cloud プロジェクトの作成#このセクションへのリンク

Terraform を使ってインフラを構築#このセクションへのリンク

インデクサー用の Kubernetes コンポーネントの作成#このセクションへのリンク

グラフノード#このセクションへのリンク

ソースからのスタート#このセクションへのリンク

インストールの前提条件#このセクションへのリンク

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

Docker の使用#このセクションへのリンク

前提条件#このセクションへのリンク

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

インデクサーコンポーネント#このセクションへのリンク

はじめに#このセクションへのリンク

NPM パッケージから#このセクションへのリンク

ソースから#このセクションへのリンク

Docker の使用#このセクションへのリンク

K8s と Terraform の使用#このセクションへのリンク

使い方#このセクションへのリンク

インデクサーエージェント#このセクションへのリンク

インデクサーサービス#このセクションへのリンク

インデクサー CLI#このセクションへのリンク

Indexer CLI によるインデクサー管理#このセクションへのリンク

使い方#このセクションへのリンク

インデキシングルール#このセクションへのリンク

アクションキュー CLI#このセクションへのリンク

コストモデル#このセクションへのリンク

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

コストモデルの適用#このセクションへのリンク

ネットワークとのインタラクション#このセクションへのリンク

プロトコルへのステーク#このセクションへのリンク

トークンの承認#このセクションへのリンク

トークンをステークする#このセクションへのリンク

アロケーションの寿命#このセクションへのリンク

インデキシング

インデクサーの収入源は何ですか？このセクションへのリンク

インデキシングリワードはどのように配布されますか？このセクションへのリンク

POI（proof of indexing）とは何ですか？このセクションへのリンク

インデキシングリワードはいつ配布されますか？このセクションへのリンク

保留中のインデクサーの報酬は監視できますか？このセクションへのリンク

争議（disputes）とは何で、どこで見ることができますか？このセクションへのリンク

クエリフィーリベートとは何ですか、またいつ配布されますか？このセクションへのリンク

クエリフィーカットとインデキシングリワードカットとは？このセクションへのリンク

インデクサーはどのサブグラフにインデックスを付けるかをどう見分けるのですか？このセクションへのリンク

必要なハードウェアは何ですか？このセクションへのリンク

インデクサーが取るべきセキュリティ対策は？このセクションへのリンク

インフラストラクチャこのセクションへのリンク

ポートの概要このセクションへのリンク

グラフノードこのセクションへのリンク

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

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

Google Cloud で Terraform を使ってサーバーインフラを構築このセクションへのリンク

インストールの前提条件このセクションへのリンク

Google Cloud プロジェクトの作成このセクションへのリンク

Terraform を使ってインフラを構築このセクションへのリンク

インデクサー用の Kubernetes コンポーネントの作成このセクションへのリンク

グラフノードこのセクションへのリンク

ソースからのスタートこのセクションへのリンク

インストールの前提条件このセクションへのリンク

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

Docker の使用このセクションへのリンク

前提条件このセクションへのリンク

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

インデクサーコンポーネントこのセクションへのリンク

はじめにこのセクションへのリンク

NPM パッケージからこのセクションへのリンク

ソースからこのセクションへのリンク

Docker の使用このセクションへのリンク

K8s と Terraform の使用このセクションへのリンク

使い方このセクションへのリンク

インデクサーエージェントこのセクションへのリンク

インデクサーサービスこのセクションへのリンク

インデクサー CLIこのセクションへのリンク

Indexer CLI によるインデクサー管理このセクションへのリンク

使い方このセクションへのリンク

インデキシングルールこのセクションへのリンク

アクションキュー CLIこのセクションへのリンク

コストモデルこのセクションへのリンク

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

コストモデルの適用このセクションへのリンク

ネットワークとのインタラクションこのセクションへのリンク

プロトコルへのステークこのセクションへのリンク

トークンの承認このセクションへのリンク

トークンをステークするこのセクションへのリンク

アロケーションの寿命このセクションへのリンク