ノードオペレーターIndexerについて｜Graph Nodeのセットアップ方法

インデクサーは、インデックス作成およびクエリ処理サービスを提供するためにグラフトークン（GRT）をステークするグラフネットワークのノードオペレーターです。

インデクサーは、サービスに対してクエリ料金とインデックス報酬を獲得します。また、Cobbs-Douglasリベート機能に従って、作業に比例してすべてのネットワーク貢献者と共有されるリベートプールからも収益を得ることができます。

プロトコルにステークされているGRTは解凍期間の対象であり、インデクサーが悪意を持ってアプリケーションに誤ったデータを提供する場合、またはインデックスが正しくない場合は、大幅に削減される可能性があります。インデクサーは、ネットワークに貢献するために、デリゲイターからステークを委任することもできます。

インデクサーは、サブグラフのキュレーション信号に基づいてインデックスを作成するサブグラフを選択します。キュレーターは、どのサブグラフが高品質で優先されるべきかを示すためにGRTを使用します。コンシューマー（アプリケーションなど）は、インデクサーがサブグラフのクエリを処理するパラメーターを設定したり、クエリ料金の価格設定の設定を行ったりすることもできます。

FAQ 

ネットワーク上のインデクサーになるために必要な最小の利害関係は何ですか？

インデクサーの最小ステークは現在100KGRTに設定されています。

インデクサーの収益源は何ですか？

クエリ料金のリベート-ネットワーク上でクエリを処理するための支払い。これらの支払いは、インデクサーとゲートウェイの間の状態チャネルを介して仲介されます。ゲートウェイからの各クエリ要求には、支払いと、クエリ結果の有効性を証明する対応する応答が含まれています。

インデックス報酬-年率3％のプロトコル全体のインフレによって生成されたインデックス報酬は、ネットワークのサブグラフ展開にインデックスを付けているインデクサーに配布されます。

報酬はどのように分配されますか？

インデックスの報酬は、3％の年間発行に設定されているプロトコルインフレから来ています。それらは、それぞれのすべてのキュレーション信号の比率に基づいてサブグラフ全体に分散され、次に、そのサブグラフに割り当てられたステークに基づいてインデクサーに比例して分散されます。報酬の対象となるには、仲裁憲章によって設定された基準を満たす有効な索引付け証明（POI）を使用して割り当てを閉じる必要があります。

報酬を計算するための多数のツールがコミュニティによって作成されています。コミュニティガイドコレクションに整理されたそれらのコレクションがあります。また、Discordサーバーの#delegatorsチャネルと#indexersチャネルでツールの最新リストを見つけることができます。

インデックス作成の証明（POI）とは何ですか？

POIは、インデクサーが割り当てられたサブグラフにインデックスを付けていることを確認するためにネットワークで使用されます。現在のエポックの最初のブロックのPOIは、その割り当ての割り当てを閉じるときに、インデックス報酬の対象となるために送信する必要があります。ブロックのPOIは、そのブロックまでの特定のサブグラフ展開のすべてのエンティティストアトランザクションのダイジェストです。

インデックス報酬はいつ配布されますか？

割り当ては、アクティブである間、継続的に報酬を獲得しています。報酬はインデクサーによって収集され、割り当てが閉じられるたびに配布されます。これは、インデクサーがそれらを強制的に閉じたいときはいつでも手動で、または28エポック後に委任者がインデクサーの割り当てを閉じることができるときに発生しますが、これにより報酬は作成されません。28エポックが最大割り当てライフタイムです（現在、1エポックは約24時間続きます）。

保留中のインデクサー報酬を監視できますか？

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

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

メインネットサブグラフをクエリして、すべてのアクティブな割り当てのIDを取得します。

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

Etherscanを使用してgetRewards()を呼び出します：

・Rewards contractへのEtherscanインターフェースに移動します
・getRewards()をコールします：

10.getRewardsドロップダウンを展開します。

入力にallocationIDを入力します。

[クエリ]ボタンをクリックします。

紛争とは何ですか？どこで見ることができますか？

インデクサーのクエリと割り当ては、紛争期間中にグラフ上で紛争を起こす可能性があります。紛争期間は、紛争の種類によって異なります。クエリ/アテステーションには7エポックの紛争ウィンドウがありますが、割り当てには56エポックがあります。これらの期間が経過すると、割り当てまたはクエリのいずれに対しても紛争を開くことはできません。

紛争が発生すると、Fishermenは最低10,000 GRTの保証金を要求します。この保証金は、紛争が終了して解決が行われるまでロックされます。Fishermenは、紛争を引き起こすネットワーク参加者です。

紛争には3つの可能性のある結果があり、Fishermenの預金も同様です。

紛争が却下された場合、Fishermenによって寄託されたGRTは燃やされ、紛争中のインデクサーは削減されません。

係争が引き分けとして解決された場合、Fishermenの保証金は返還され、係争中のインデクサーは削減されません。

係争が受け入れられた場合、Fishermenによって寄託されたGRTは返還され、係争中のインデクサーは削減され、Fishermenは削減されたGRTの50％を獲得します。

紛争は、Disputesタブの下にあるインデクサーのプロファイルページのUIで表示でき ます。

クエリ料金のリベートとは何ですか？いつ配布されますか？

クエリ料金は、割り当てが閉じられ、サブグラフのクエリ料金リベートプールに蓄積されるたびに、ゲートウェイによって収集されます。リベートプールは、インデクサーがネットワークに対して獲得したクエリ料金の金額にほぼ比例して株式を割り当てることを奨励するように設計されています。特定のインデクサーに割り当てられるプール内のクエリ料金の部分は、コッブダグラス生産関数を使用して計算されます。インデクサーごとの分配額は、プールへの貢献度とサブグラフの株式の割り当ての関数です。

割り当てが終了し、紛争期間が経過すると、インデクサーはリベートを請求できるようになります。請求時に、クエリ料金のリベートは、クエリ料金の削減と委任プールの比率に基づいて、インデクサーとその委任者に分配されます。

クエリ料金の削減とインデックス報酬の削減とは何ですか？

queryFeeCutそしてindexingRewardCut値がインデクサは、インデクサとその委任者との間のGRTの分布を制御するcooldownBlocksとともに設定してもよいことを委任パラメータです。委任パラメータの設定手順については、プロトコルでのステーキングの最後の手順を参照してください。

queryFeeCut-インデクサーに配布されるサブグラフに累積されたクエリ料金リベートの割合。これが95％に設定されている場合、割り当てが要求されたときにインデクサーはクエリ料金のリベートプールの95％を受け取り、残りの5％は委任者に送られます。

indexingRewardCut-インデクサーに配布されるサブグラフに蓄積されたインデックス報酬の割合。これが95％に設定されている場合、割り当てが閉じられたときにインデクサーはインデックス報酬プールの95％を受け取り、委任者は残りの5％を分割します。

インデクサーは、インデックスを作成するサブグラフをどのように知るのですか？

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

キュレーション信号-特定のサブグラフに適用されるネットワークキュレーション信号の割合は、特にクエリのボリュームが増加しているブートストラップフェーズ中に、そのサブグラフへの関心を示す良い指標です。

収集されたクエリ料金-特定のサブグラフに対して収集されたクエリ料金の量の履歴データは、将来の需要の良い指標です。

賭け金-他のインデクサーの動作を監視したり、特定のサブグラフに割り当てられた総賭け金の割合を調べたりすることで、インデクサーはサブグラフクエリの供給側を監視して、ネットワークが信頼を示しているサブグラフまたは必要性を示している可能性のあるサブグラフを特定できます。より多くの供給。

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

ハードウェア要件は何ですか？

小さい-いくつかのサブグラフのインデックス作成を開始するのに十分であり、拡張する必要がある可能性があります。

標準-デフォルトのセットアップ。これは、k8s / terraformデプロイメントマニフェストの例で使用されているものです。

中-1秒あたり100のサブグラフと200〜500のリクエストをサポートするプロダクションインデクサー。

大-現在使用されているすべてのサブグラフにインデックスを付け、関連するトラフィックのリクエストを処理する準備ができています。

インデクサーが取るべき基本的なセキュリティ対策は何ですか？

オペレーターウォレット-オペレーターウォレットを設定することは、インデクサーがステークを制御するキーと日常の操作を制御するキーの間の分離を維持できるようにするため、重要な予防策です。手順については、Stake inProtocolを参照してください。

ファイアウォール-インデクサーサービスのみを公開する必要があり、管理ポートとデータベースアクセスのロックダウンに特に注意を払う必要があります：グラフノードJSON-RPCエンドポイント（デフォルトポート：8030）、インデクサー管理APIエンドポイント（デフォルトポート：18000） ）、およびPostgresデータベースエンドポイント（デフォルトポート：5432）は公開しないでください。

インフラストラクチャ

インデクサーのインフラストラクチャの中心にあるのは、イーサリアムを監視し、サブグラフ定義ごとにデータを抽出してロードし、それをGraphQLAPIとして機能させるグラフノードです。グラフノードは、イーサリアムEVMノードエンドポイント、およびデータをソーシングするためのIPFSノードに接続する必要があります。そのストア用のPostgreSQLデータベース。ネットワークとの相互作用を容易にするインデクサーコンポーネント。

PostgreSQLPostgreSQLデータベース-グラフノードのメインストア。ここにサブグラフデータが保存されます。インデクサーサービスとエージェントは、データベースを使用して、状態チャネルデータ、コストモデル、およびインデックス作成ルールも格納します。

イーサリアムエンドポイント-イーサリアムJSON-RPCAPIを公開するエンドポイント。これは、単一のイーサリアムクライアントの形をとるか、複数の負荷分散を行うより複雑なセットアップである可能性があります。特定のサブグラフには、アーカイブモードやトレースAPIなどの特定のイーサリアムクライアント機能が必要になることに注意することが重要です。

IPFSノード（バージョン5未満） -サブグラフ展開メタデータはIPFSネットワークに保存されます。グラフノードは、主にサブグラフの展開中にIPFSノードにアクセスして、サブグラフマニフェストとすべてのリンクされたファイルをフェッチします。ネットワークインデクサーは独自のIPFSノードをホストする必要はありません。ネットワークのIPFSノードはhttps://ipfs.network.thegraph.comでホストされます。

インデクサーサービス-ネットワークとの必要なすべての外部通信を処理します。コストモデルとインデックス作成ステータスを共有し、ゲートウェイからのクエリ要求をグラフノードに渡し、ゲートウェイとの状態チャネルを介してクエリの支払いを管理します。

インデクサーエージェント-ネットワークへの登録、グラフノードへのサブグラフ展開の管理、割り当ての管理など、チェーン上のインデクサーの相互作用を促進します。Prometheusメトリクスサーバー-グラフノードおよびインデクサーコンポーネントは、メトリクスをメトリクスサーバーに記録します。

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

ポートの概要

重要：ポートを公開する場合は注意が必要です。管理ポートはロックダウンしておく必要があります。これには、グラフノードJSON-RPCと以下に詳述するインデクサー管理エンドポイントが含まれます。

グラフノード

インデクサーサービス

インデクサーエージェント

Google CloudでTerraformを使用してサーバーインフラストラクチャをセットアップする

前提条件をインストールする

・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の[請求ページ] （請求ページ）を使用して、新しいプロジェクトの請求を有効にします。

GoogleCloud構成を作成します。

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

必要なGoogleCloudAPIを有効にします。

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

最小限のテラフォーム構成ファイルを作成します（必要に応じて更新します）。

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

Terraformを使用してインフラストラクチャを作成する

コマンドを実行する前に、variables.tfを読みterraform.tfvars、このディレクトリにファイルを作成します（または、前の手順で作成したファイルを変更します）。デフォルトをオーバーライドする変数、または値を設定する必要がある変数ごとに、に設定を入力しますterraform.tfvars。

次のコマンドを実行して、インフラストラクチャを作成します。

# Install required plugins
terraform init

# View plan for resources to be created
terraform plan

# Create the resources (expect it to take up to 30 minutes)
terraform apply

新しいクラスターのクレデンシャルをにダウンロード~/.kube/configし、デフォルトのコンテキストとして設定します。

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

インデクサーのKubernetesコンポーネントの作成

ディレクトリk8s/overlaysを新しいディレクトリにコピーし、ディレクトリを指すようにエントリ$dir,を調整します。

bases$dir/kustomization.yamlk8s/base

$dir内のすべてのファイルを読み、コメントに示されている値を調整します。

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

グラフノード

Graph NodeはオープンソースのRust実装であり、イベントがイーサリアムブロックチェーンをソースして、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 グラフノードリポジトリのクローンを作成し、実行してソースを構築しま。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の使用を開始する

前提条件

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

セットアップ

1 グラフノードのクローンを作成し、Dockerディレクトリに移動します。

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

Linuxユーザーのみの場合-使用の代わりに、ホストIPアドレスhost.docker.internalでdocker-compose.yaml 使用して含まれているスクリプト：

./setup.sh

イーサリアムエンドポイントに接続するローカルグラフノードを開始します。

docker-compose up

インデクサーコンポーネント

ネットワークに正常に参加するには、ほぼ一定の監視と対話が必要であるため、インデクサーネットワークへの参加を容易にするためのTypescriptアプリケーションのスイートを構築しました。3つのインデクサーコンポーネントがあります。

インデクサーエージェント-エージェントは、ネットワークとインデクサー自体のインフラストラクチャを監視し、チェーン上でインデックスが作成されて割り当てられるサブグラフの展開と、それぞれに割り当てられる量を管理します。

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

インデクサCLI -インデクサエージェントを管理するためのコマンドラインインタフェース。これにより、インデクサーはコストモデルとインデックス作成ルールを管理できます。

Getting started

インデクサーエージェントとインデクサーサービスは、グラフノードインフラストラクチャと同じ場所に配置する必要があります。インデクサーコンポーネントの仮想実行環境をセットアップする方法はたくさんあります。ここでは、NPMパッケージまたはソースを使用してベアメタルで実行する方法、またはGoogle Cloud KubernetesEngineの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 source

# 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の使用

「GoogleCloudでTerraformを使用したサーバーインフラストラクチャのセットアップ」セクションを参照してください

使用法

注：すべてのランタイム構成変数は、起動時にコマンドのパラメーターとして適用するか、形式の環境変数を使用して適用できます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 \
| 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

インデクサーCLIを使用したインデクサー管理

インデクサーエージェントは、インデクサーに代わってネットワークと自律的に対話するために、インデクサーからの入力を必要とします。インデクサーエージェントの動作を定義するメカニズムは、インデックス作成ルールです。インデクサーは、インデックス作成ルールを使用して、サブグラフを選択するための特定の戦略を適用して、インデックスを作成し、クエリを提供できます。ルールは、エージェントが提供するGraphQL APIを介して管理され、インデクサー管理APIと呼ばれます。対話するための提案ツールインデクサ管理APIがあるインデクサCLIへの拡張グラフCLI。

使用法

インデクサCLIは、 CLIは、同じサーバーまたはクラスター上で実行する必要はありませんので、一般的にポートフォワーディング経由、インデクサエージェントに接続します。開始を支援し、コンテキストを提供するために、ここではCLIについて簡単に説明します。

graph indexer connect <url>-インデクサー管理APIに接続します。通常、サーバーへの接続はポートフォワーディングを介して開かれるため、CLIをリモートで簡単に操作できます。（例kubectl port-forward pod/<indexer-agent-pod> 8000:8000）

graph indexer rules get [options] <deployment-id< [<key1> ...]-を使用allして1つ以上のインデックスルールを<deployment-id>取得し、すべてのルールglobalを取得するか、グローバルデフォルトを取得します。追加の引数--mergedを使用して、デプロイメント固有のルールをグローバルルールとマージするように指定できます。これは、それらがインデクサーエージェントに適用される方法です。

graph indexer rules set [options] <deployment-id> <key1> <value1> ... -1つ以上のインデックスルールを設定します。

graph indexer rules start [options] <deployment-id>-利用可能とする設定した場合、スタート部分グラフの展開のインデックスを作成decisionBasisするためにalways、インデクサエージェントは常にインデックスそれに選択するようにします。グローバルルールが常にに設定されている場合、ネットワーク上で使用可能なすべてのサブグラフにインデックスが付けられます。

graph indexer rules stop [options] <deployment-id>-デプロイメントのインデックス作成を停止しdecisionBasis、neverに設定します。これにより、インデックスを作成するデプロイメントを決定するときに、このデプロイメントがスキップされます。

graph indexer rules maybe [options] <deployment-id>—thedecisionBasisデプロイメントをに設定しますrules。これにより、インデクサーエージェントはインデックスルールを使用して、このデプロイメントにインデックスを付けるかどうかを決定します。

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

インデックス作成ルール

インデックス付けルールは、グローバルデフォルトとして適用することも、IDを使用して特定のサブグラフ展開に適用することもできます。deploymentそしてdecisionBasis他のすべてのフィールドはオプションである一方、フィールドは、必須です。インデックス作成ルールがrulesとしてを持っているdecisionBasis場合、インデクサーエージェントは、そのルールのnull以外のしきい値を、対応する展開のためにネットワークからフェッチされた値と比較します。サブグラフの展開の値がいずれかのしきい値を上回っている（または下回っている）場合は、インデックス作成用に選択されます。

たとえば、グローバルルールのaminStakeが5（GRT）の場合、5（GRT）を超えるステークが割り当てられているサブグラフ展開にはインデックスが付けられます。しきい値ルールが含まれmaxAllocationPercentage、minSignal、maxSignal、minStake、とminAverageQueryFees。

データ・モデル：

type IndexingRule {
 deployment: string
 allocationAmount: string | null
 parallelAllocations: number | null
 decisionBasis: IndexingDecisionBasis
 maxAllocationPercentage: number | null
 minSignal: string | null
 maxSignal: string | null
 minStake: string | null
 minAverageQueryFees: string | null
 custom: string | null
}
IndexingDecisionBasis {
 rules
 never
 always
}

コストモデル

コストモデルは、市場およびクエリ属性に基づいてクエリの動的価格設定を提供します。インデクサーサービスは、クエリに応答する予定の各サブグラフのゲートウェイとコストモデルを共有します。次に、ゲートウェイはコストモデルを使用して、クエリごとにインデクサーの選択を決定し、選択したインデクサーと支払いをネゴシエートします。

アゴラ

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

ステートメントは、GraphQLクエリのマッチングに使用される述語と、評価時にコストを10進数の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;

上記のモデルを使用したクエリ原価計算の例：

コストモデルの適用

コストモデルは、データベースに保存するためにインデクサーエージェントのインデクサー管理APIに渡すインデクサーCLIを介して適用されます。インデクサーサービスはそれらを取得し、ゲートウェイが要求するたびにコストモデルをゲートウェイに提供します。

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

ネットワークとの相互作用

プロトコルのステーク

インデクサーとしてネットワークに参加するための最初のステップは、プロトコルを承認し、資金を賭け、（オプションで）日常のプロトコル対話用のオペレーターアドレスを設定することです。注：これらの手順では、Remixを契約のやり取りに使用しますが、選択したツールを自由に使用してください（OneClickDapp、ABItopic、およびMyCryptoは他のいくつかの既知のツールです）。

インデクサーがプロトコルにGRTを固定すると、インデクサーコンポーネントを起動して、ネットワークとの相互作用を開始できます。

トークンを承認する

1 ブラウザでRemixアプリを開きます

2 File ExplorerでトークンABIをGraphToken.abiという名前のファイルを作成。

3 GraphToken.abi選択し、エディタで開いて、配備に切り替えるRun Transactionsリミックスインタフェースにセクション。

4 環境の下で選択しInjected Web3、下でAccountインデクサアドレスを選択します。

5 GraphToken契約アドレスを設定します-0xc944E90C64B2c07662A292be6244BDf05Cda44a7横にGraphToken契約アドレス（）を貼り付けAt Address、At addressボタンをクリックして適用します。

6 approve(spender, amount)関数を呼び出して、ステーキング契約を承認します。記入spenderかしめ契約アドレスを（0xF55041E37E12cD407ad00CE2910B8269B01263b9）とamount（魏中）株式へのトークンと。

ステークトークン

1 ブラウザでRemixアプリを開きます

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

3 でStaking.abi選択し、エディタで開いて、に切り替えるDeployとRun Transactionsリミックスインタフェースにセクション。

4 環境の下で選択しInjected Web3、下でAccountインデクサアドレスを選択します。

5 ステーキング契約アドレスの設定-ステーキング契約アドレス（0xF55041E37E12cD407ad00CE2910B8269B01263b9）を横に貼り付けAt Address、At addressボタンをクリックして適用します。

6 stake()プロトコルにGRTを賭けるように呼びかけます。

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

8 （オプション）報酬の分配を制御し、委任者を戦略的に引き付けるために、インデクサーは、indexingRewardCut（parts per million）、queryFeeCut（parts per million）、およびcooldownBlocks（ブロック数）を更新することにより、委任パラメーターを更新できます。これを行うには、を呼び出しますsetDelegationParameters()。次の例では、queryFeeCutを設定してクエリリベートの95％をインデクサーに、5％を委任者に配布し、indexingRewardCutを設定してインデックス報酬の60％をインデクサーに、40％を委任者に配布し、thecooldownBlocks期間を500ブロックに設定します。

setDelegationParameters(950000, 600000, 500)

The life of an allocation

インデクサーによって作成された後、正常なallocationは4つの状態を通過します。

Active-allocationがallocateFromのチェーン上で作成されると、アクティブと見なされます。

contracts/Staking.sol at dev 揃 graphprotocol/contracts

インデクサー自身および/または委任された株式の一部は、サブグラフの展開に割り当てられます。これにより、インデクサーは、インデックスの報酬を請求し、そのサブグラフの展開に対するクエリを提供できます。インデクサーエージェントは、インデクサールールに基づいて割り当ての作成を管理します。

インデクサーは、1エポックがcloseAllocationを通過すると、allocationを自由に閉じることができます。そうしないと、インデクサーエージェントはmaxAllocationEpochs（現在28日）後にallocationを自動的に閉じます。

contracts/Staking.sol at dev 揃 graphprotocol/contracts

有効なインデックス作成証明（POI）を使用して割り当てが閉じられると、インデックス作成の報酬がインデクサーとその委任者に配布されます（詳細については、以下の「how are rewards distributed」を参照してください）。

Finalized -割り当てがクローズされると、割り当てが確定したと見なされる紛争期間があり、クエリ料金のリベートを請求できます（claim（））。インデクサーエージェントは、ネットワークを監視して最終的なallocationを検出し、構成可能な（およびオプションの）しきい値である—-allocation-claim-thresholdを超えている場合はそれらを要求します。

Claimed-allocationの最終状態。コースはアクティブな割り当てとして実行され、対象となるすべての報酬が配布され、クエリ料金のリベートが請求されています。

Indexer | Graph Docs