インデキシング

インデクサーは、The Graph Network内のノードオペレーターであり、インデックス化とクエリ処理のサービスを提供するためにGraph Token（GRT）をステークします。インデクサーは、そのサービスに対するクエリ料金とインデックスリワードを獲得します。また、指数的なリベート関数に従ってリベートされるクエリ料金も獲得します。

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

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

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

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

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

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

コミュニティでは報酬を計算するための多くのツールが開発されており、それらはCommunity Guides collectionで整理されています。また、最新のツールのリストはDiscord serverの#Delegatorsおよび#Indexersチャンネルで確認できます。以下に、インデクサーソフトウェアスタックに統合されたrecommended allocation optimiserへのリンクを示します。

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

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

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

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

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

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

Use Etherscan to call getRewards():

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

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

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

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

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

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

クエリ料金はゲートウェイによって収集され、指数リベート関数に従ってインデクサーに分配されます (GIPこちらを参照)。 指数リベート関数は、インデクサーがクエリを忠実に処理することで確実に最良の結果を達成する方法として提案されています。 これは、インデクサーが収集する可能性のあるクエリ料金の額と比較して、大量のステーク (クエリの提供時にエラーが発生した場合に削減される可能性がある) を割り当てるようインデクサーに奨励することによって機能します。

割り当てが閉じられると、リベートはインデクサーによって請求されることができるようになります。請求されると、クエリ料金のリベートは、クエリ料金のカットと指数的なリベート関数に基づいて、インデクサーとその委任者に分配されます。

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

• queryFeeCut - クエリ料金のリベートの%を示します。これが95%に設定されている場合、インデクサーは割り当てが閉じられた際に獲得するクエリ料金の95%を受け取り、残りの5%は委任者に支払われます。

• indexingRewardCut - インデックスリワードの%を示します。これが95%に設定されている場合、インデクサーは割り当てが閉じられた際に獲得するインデックスリワードの95%を受け取り、残りの5%は委任者で分割されます。

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

• キュレーションシグナル - 特定のサブグラフに適用されたネットワークキュレーションシグナルの割合は、そのサブグラフへの関心を示す指標となり、特にクエリのボリュームが増加しているブートストラップ段階では有効となります。

• コレクティド・クエリフィー - 特定のサブグラフに対してコレクティド・クエリフィー量の履歴データは、将来的な需要に対する指標となります。

• ステーク量 - 他のインデクサーの行動を監視したり、特定のサブグラフに割り当てられた総ステーク量の割合を見ることで、インデクサーはサブグラフ・クエリの供給側を監視し、ネットワークが信頼を示しているサブグラフや、より多くの供給を必要としているサブグラフを特定することができます。

• インデックス報酬のないサブグラフ - 一部のサブグラフは、主に IPFS などのサポートされていない機能を使用していたり、メインネット外の別のネットワークをクエリしていたりするため、インデックス報酬を生成しません。 インデクシング・リワードを生成していないサブグラフにはメッセージが表示されます。

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

• オペレーター ウォレット - オペレーター ウォレットを設定することは重要な予防措置です。これにより、インデクサーは、ステークを制御するキーと日々の操作を制御するキーとの間の分離を維持できるようになります。 - デイ オペレーション。手順については、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 コンポーネントは、自分のメトリクスをメトリクス・サーバーにログします。

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

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

• クローンまたはインデクサーリポジトリに移動

• ./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

コマンドを実行する前に、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)

• 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

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

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

2. Graph Node リポジトリのクローンを作成し、cargo build を実行してソースをビルドします

3. 全ての依存関係の設定が完了したら、グラフノードを起動します:

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

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

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

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

./setup.sh

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

docker-compose up

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

• Indexer agent - ネットワークとインデクサー自身のインフラを監視し、どのサブグラフ・デプロイメントがインデキシングされ、チェーンに割り当てられるか、またそれぞれにどれだけの量が割り当てられるかを管理します。

• Indexer service - 外部に公開する必要のある唯一のコンポーネントで、サブグラフのクエリをグラフノードに渡し、クエリの支払いのための状態チャンネルを管理し、重要な意思決定情報をゲートウェイなどのクライアントに共有します。

• Indexer CLI - インデクサーエージェントを管理するためのコマンドラインインターフェイスです。これによって、インデクサーはコストモデル、手動割り当て、アクションキュー、 インデックスルールを管理することができます。

インデクサー エージェントとインデクサー サービスは、グラフ ノード インフラストラクチャと同じ場所に配置する必要があります。 インデクサー コンポーネントの仮想実行環境をセットアップするには、さまざまな方法があります。 ここでは、NPM パッケージまたはソースを使用するか、Google Cloud Kubernetes Engine 上の kubernetes と Docker を介してベアメタル上でそれらを実行する方法を説明します。 これらの設定例がご使用のインフラストラクチャにうまく反映されない場合は、参考となるコミュニティ ガイドがある可能性があります。Discord にお越しください。 インデクサー コンポーネントを起動する前に、忘れずに stake in the protocol してください。

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 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 を公開する必要があります。

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

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 は、@graphprotocol/graph-cli アクセス可能なプラグインですターミナルの graph indexer で。

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

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

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
}

ソースからの使用例：

graph indexer actions get all

graph indexer actions get --status queued

graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000

graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000

graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae

graph indexer actions cancel

graph indexer actions approve 1 3 5

graph indexer actions execute approve

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

• Allocate - 特定のサブグラフの配置にステークを割り当てます。

  • 必要なアクションパラメータを指定します:
    • デプロイメントID
    • 量

• Unallocate - 割り当てを終了し、他の場所に再割り当てするためにステークを解放します。

  • 必要なアクションパラメータを指定します:
    • アロケーションID
    • デプロイメントID
  • 任意のアクションパラメータ：
    • poi
    • force (グラフノードが提供するものと一致しなくても、提供されたPOIを使用することを強制する)

• Reallocate - アロケーションをアトミックにクローズし、同じサブグラフのために新しいアロケーションをオープンします。

  • 必要なアクションパラメータを指定します:
    • アロケーションID
    • デプロイメントID
    • 量
  • 任意のアクションパラメータ：
    • poi
    • force (グラフノードが提供するものと一致しなくても、提供されたPOIを使用することを強制する)

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

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;

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

コストモデルは 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コンポーネントを立ち上げ、ネットワークとのやりとりを開始することができます。

1. ブラウザでRemix appを開きます。

2. File ExplorerでGraphToken.abiというファイルを作成し、 token ABIを指定します。

3. GraphToken.abiを選択してエディタで開いた状態で、Remix のインターフェースの Deploy and Run Transactions セクションに切り替えます。

4. 環境から[Injected Web3] を選択し、Accountでインデクサーアドレスを選択します。

5. GraphToken のコントラクトアドレスの設定 - At Addressの横に GraphToken のコントラクトアドレス(0xc944E90C64B2c07662A292be6244BDf05Cda44a7) を貼り付け、At Addressボタンをクリックして適用します。

6. approve(spender, amount)関数を呼び出し、ステーキング契約を承認します。 spenderにはステーキングコントラクトアドレス（0xF55041E37E12cD407ad00CE2910B8269B01263b9）を、amountにはステークするトークン（単位：wei）を記入します。

1. ブラウザでRemix appを開きます。

2. File ExplorerでStaking.abiという名前のファイルを作成し、Staking ABI を指定します。

3. エディタでStaking.abiを選択して開いた状態で、Remix インターフェースのDeploy and Run Transactionsセクションに切り替えます。

4. 環境から[Injected Web3] を選択し、Accountでインデクサーアドレスを選択します。

5. Staking contract address の設定 - At Addressの横に Staking contract address (0xF55041E37E12cD407ad00CE2910B8269B01263b9) を貼り付け、 At Addressボタンをクリックして適用します。

6. stake()を呼び出して、GRT をプロトコルにステークします。

7. (オプション）インデクサーは、資金を管理する鍵と、サブグラフへの割り当てや（有料の）クエリの提供などの日常的な動作を行う鍵とを分離するために、別のアドレスをインデクサインフラストラクチャのオペレーターとして承認することができます。 オペレーターを設定するには、オペレーターのアドレスを指定してsetOperator()をコールします。

8. (オプション) 報酬の分配を制御し、デリゲータを戦略的に引き付けるために、 インデクサーは 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）とともにクローズされると、そのインデクサー報酬がインデクサーとそのデリゲーターに分配されます（詳細は下記の「報酬の分配方法」を参照してください）

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