indexing > Overview

Indexage

Reading time: 29 min

Les indexeurs sont des opérateurs de nœuds dans The Graph Network qui mettent en jeu des jetons Graph (GRT) afin de fournir des services d'indexation et de traitement de requêtes. Les indexeurs perçoivent des frais de requête et des récompenses d'indexation pour leurs services. Ils perçoivent également des frais de requête qui sont réduits selon une fonction de remise exponentielle.

Le GRT intégré au protocole est soumis à une période de décongélation et peut être réduit si les indexeurs sont malveillants et fournissent des données incorrectes aux applications ou s'ils indexent de manière incorrecte. Les indexeurs gagnent également des récompenses pour la participation déléguée des délégués, afin de contribuer au réseau.

Les indexeurs sélectionnent les subgraphs à indexer en fonction du signal de curation du subgraph, où les curateurs misent du GRT afin d'indiquer quels subgraphs sont de haute qualité et doivent être priorisés. Les consommateurs (par exemple les applications) peuvent également définir les paramètres pour lesquels les indexeurs traitent les requêtes pour leurs subgraphs et définir les préférences pour la tarification des frais de requête.

Niveau technique exigé

ADVANCED

Questions fréquemment posées

Lien vers cette section

Quelle est la mise minimale requise pour être indexeur sur le réseau ?

Lien vers cette section

La mise minimale pour un indexeur est actuellement fixée à 100 000 GRT.

Quelles sont les sources de revenus pour un indexeur ?

Lien vers cette section

Remises sur les frais de requête : paiements pour le traitement des requêtes sur le réseau. Ces paiements sont acheminés via des canaux étatiques entre un indexeur et une passerelle. Chaque requête de requête provenant d'une passerelle contient un paiement et la réponse correspondante une preuve de validité du résultat de la requête.

Récompenses d'indexation : générées via une inflation annuelle de 3 % à l'échelle du protocole, les récompenses d'indexation sont distribuées aux indexeurs qui indexent les déploiements de subgraphs pour le réseau.

Comment sont distribuées les récompenses d’indexation ?

Lien vers cette section

Les récompenses de l'indexation proviennent de l'inflation du protocole qui est fixée à 3 % par an. Ils sont répartis entre les subraphs en fonction de la proportion de tous les signaux de curation sur chacun, puis distribués proportionnellement aux indexeurs en fonction de leur participation allouée sur ce subgraph. Une allocation doit être clôturée avec une preuve d'indexation (POI) valide et répondant aux normes fixées par la charte d'arbitrage afin d'être éligible aux récompenses.

De nombreux outils ont été créés par la communauté pour calculer les récompenses ; vous trouverez une collection de ces outils organisés dans la collection de guides communautaires. Vous pouvez également trouver une liste à jour des outils dans les canaux #Delegators et #Indexers sur le serveur Discord. Nous recommandons un optimiseur d'allocation intégré à la pile logicielle de l'Indexeur.

Qu'est-ce qu'une preuve d'indexation (POI) ?

Lien vers cette section

Les POI sont utilisés dans le réseau pour vérifier qu'un indexeur indexe les subgraphs sur lesquels ils ont été alloués. Un POI pour le premier bloc de l'époque actuelle doit être soumis lors de la clôture d'une allocation pour que cette allocation soit éligible aux récompenses d'indexation. Un POI pour un bloc est un résumé de toutes les transactions du magasin d'entités pour un déploiement de subgraph spécifique jusqu'à ce bloc inclus.

Quand les récompenses d’indexation sont-elles distribuées ?

Lien vers cette section

Les allocations accumulent continuellement des récompenses pendant qu'elles sont actives et allouées dans un délai de 28 époques. Les récompenses sont collectées par les indexeurs et distribuées chaque fois que leurs allocations sont clôturées. Cela se produit soit manuellement, chaque fois que l'indexeur souhaite forcer leur fermeture, soit après 28 époques, un délégant peut fermer l'allocation pour l'indexeur, mais cela n'entraîne aucune récompense. 28 époques est la durée de vie maximale de l'allocation (à l'heure actuelle, une époque dure environ 24 heures).

Les récompenses d’indexation en attente peuvent-elles être surveillées ?

Lien vers cette section

Le contrat RewardsManager a une fonction getRewards en lecture seule qui peut être utilisée pour vérifier les récompenses en attente pour une allocation spécifique.

De nombreux tableaux de bord créés par la communauté incluent des valeurs de récompenses en attente et ils peuvent être facilement vérifiés manuellement en suivant ces étapes :

  1. Interrogez le réseau principal de subgraphs pour obtenir les identifiants de toutes les allocations actives :
query indexerAllocations {
indexer(id: "<INDEXER_ADDRESS>") {
allocations {
activeForIndexer {
allocations {
id
}
}
}
}
}

Utilisez Etherscan pour appeler getRewards() :

  • Naviguer vers Interface d'étherscan pour le contrat de récompenses
  • Appeller getRewards():
    • Déroulez le menu 9. getRewards.
    • Saisissez le allocationID dans l'entrée.
    • Cliquez sur le bouton Requête.

Que sont les litiges et où puis-je les consulter ?

Lien vers cette section

Les requêtes et les allocations de l'indexeur peuvent toutes deux être contestées sur The Graph pendant la période de contestation. Le délai de contestation varie selon le type de litige. Les requêtes/attestations ont une fenêtre de contestation de 7 époques, tandis que les allocations ont 56 époques. Passé ces délais, aucun litige ne peut être ouvert ni contre les attributions ni contre les requêtes. Lorsqu'un litige est ouvert, une caution d'un minimum de 10 000 GRT est exigée par les pêcheurs, qui sera verrouillée jusqu'à ce que le litige soit finalisé et qu'une résolution soit trouvée. Les pêcheurs sont tous les participants au réseau qui ouvrent des différends.

Les différends sur trois enjeux possibles, tout comme la prudence des pêcheurs.

  • Si la contestation est rejetée, le GRT déposé par les Pêcheurs sera brûlé, et l'Indexeur contesté ne sera pas sabré.
  • Si le différend est réglé par un match nul, la caution du pêcheur sera restituée et l'indexeur contesté ne sera pas réduit.
  • Si la contestation est acceptée, le GRT déposé par les Pêcheurs sera restitué, l'Indexeur contesté sera réduit et les Pêcheurs gagneront 50% du GRT réduit.

Les litiges peuvent être consultés dans l'interface utilisateur sur la page de profil d'un indexeur sous l'onglet Différends.

Que sont les remises sur les frais de requête et quand sont-elles distribuées ?

Lien vers cette section

Les frais de requête sont collectés par la passerelle et distribués aux indexeurs selon la fonction de remise exponentielle (voir GIP [ici](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for -indexers/4162)). La fonction de remise exponentielle est proposée comme moyen de garantir que les indexeurs obtiennent le meilleur résultat en répondant fidèlement aux requêtes. Il fonctionne en incitant les indexeurs à allouer une part importante (qui peut être réduite en cas d'erreur lors de la réponse à une requête) par rapport au montant des frais de requête qu'ils peuvent percevoir.

Une fois qu'une allocation a été clôturée, les remises peuvent être réclamées par l'indexeur. Lors de la réclamation, les remises sur les frais de requête sont distribuées à l'indexeur et à leurs délégués en fonction de la réduction des frais de requête et de la fonction de remise exponentielle.

Qu'est-ce que la réduction des frais de requête et la réduction des récompenses d'indexation ?

Lien vers cette section

Les valeurs queryFeeCut et indexingRewardCut sont des paramètres de délégation que l'indexeur peut définir avec cooldownBlocks pour contrôler la distribution du GRT entre l'indexeur et ses délégués. Consultez les dernières étapes dans Jalonnement dans le protocole pour obtenir des instructions sur la définition des paramètres de délégation.

  • queryFeeCut : % de remise sur les frais de requête qui sera distribuée à l'indexeur. Si ce taux est fixé à 95 %, l'indexeur recevra 95 % des frais de requête gagnés lorsqu'une allocation est clôturée, les 5 % restants étant reversés aux délégateurs.

  • indexingRewardCut - le % de récompenses d'indexation qui seront distribuées à l'indexeur. Si ce taux est fixé à 95 %, l'indexeur recevra 95 % des récompenses d'indexation lorsqu'une allocation est clôturée et les délégateurs se partageront les 5 % restants.

Comment les indexeurs savent-ils quels subgraphs indexer ?

Lien vers cette section

Les indexeurs peuvent se différencier en appliquant des techniques avancées pour prendre des décisions d'indexation de subgraphs, mais pour donner une idée générale, nous discuterons de plusieurs mesures clés utilisées pour évaluer les subgraphs du réseau :

  • Signal de curation : la proportion de signal de curation de réseau appliquée à un subgraph particulier est un bon indicateur de l'intérêt porté à ce subgraph, en particulier pendant la phase d'amorçage lorsque le volume des requêtes augmente. .

  • Frais de requête collectés : les données historiques sur le volume des frais de requête collectés pour un subgraph spécifique sont un bon indicateur de la demande future.

  • Montant mis en jeu : surveiller le comportement des autres indexeurs ou examiner les proportions de la mise totale allouées à des subgraphs spécifiques peut permettre à un indexeur de surveiller l'offre pour les requêtes de subgraphs afin d'identifier les subgraphs qui le réseau fait preuve de confiance dans des subgraphs qui peuvent montrer un besoin d'approvisionnement accru.

  • Subgraphs sans récompenses d'indexation : certains subgraphs ne génèrent pas de récompenses d'indexation principalement parce qu'ils utilisent des fonctionnalités non prises en charge comme IPFS ou parce qu'ils interrogent un autre réseau en dehors du réseau principal. Vous verrez un message sur un subgraph s'il ne génère pas de récompenses d'indexation.

Quelle est la configuration matérielle requise ?

Lien vers cette section
  • Petit - Assez pour commencer à indexer plusieurs subgraphs, il faudra probablement l'étendre.
  • Standard - Configuration par défaut, c'est ce qui est utilisé dans l'exemple de manifeste de déploiement k8s/terraform.
  • Moyen - Indexeur de production prenant en charge 100 subgraphs et 200 à 500 requêtes par seconde.
  • Large : Prêt à indexer tous les subgraphs actuellement utilisés et à répondre aux demandes pour le trafic associé.
InstallationPostgres
(CPUs)
Postgres
(mémoire en Gbs)
Postgres
(disque en TB)
VMs
(CPUs)
VMs
(mémoire en Gbs)
Petit481416
Standard830111248
Moyen166423264
Large724683.548

Quelles sont les précautions de sécurité de base qu’un indexeur doit prendre ?

Lien vers cette section
  • Portefeuille d'opérateur : la configuration d'un portefeuille d'opérateur est une précaution importante car elle permet à un indexeur de maintenir une séparation entre ses clés qui contrôlent la participation et celles qui contrôlent les opérations quotidiennes. opérations de jour. Voir Participation dans le protocole pour les instructions.

  • Pare-feu : seul le service Indexer doit être exposé publiquement et une attention particulière doit être accordée au verrouillage des ports d'administration et de l'accès à la base de données : le point de terminaison JSON-RPC de Graph Node (port par défaut : 8030), le point de terminaison de l'API de gestion de l'indexeur (port par défaut : 18000) et le point de terminaison de la base de données Postgres (port par défaut : 5432) ne doivent pas être exposés.

Infrastructure

Lien vers cette section

Au centre de l'infrastructure d'un indexeur se trouve le nœud Graph qui surveille les réseaux indexés, extrait et charge les données selon une définition de subgraph et le sert d'API GraphQL.. Le nœud graph doit être connecté à un point de terminaison exposant les données de chaque réseau indexé ; un nœud IPFS pour la recherche de données ; une base de données PostgreSQL pour son magasin ; et des composants d'indexeur qui facilitent ses interactions avec le réseau.

  • Base de données PostgreSQL - Le magasin principal du nœud graph, c'est là que les données du subgraph sont stockées. Le service et l'agent Indexeur utilisent également la base de données pour stocker les données du canal d'état, les modèles de coûts, les règles d'indexation et les actions d'allocation.

  • Point de terminaison des données : pour les réseaux compatibles EVM, Graph Node doit être connecté à un point de terminaison qui expose une API JSON-RPC compatible EVM. Cela peut prendre la forme d'un client unique ou d'une configuration plus complexe qui équilibre la charge sur plusieurs. Il est important de savoir que certains subgraphs nécessiteront des fonctionnalités client particulières telles que le mode archive et/ou l'API de traçage de parité.

  • Nœud IPFS (version inférieure à 5) : les métadonnées de déploiement de Subgraph sont stockées sur le réseau IPFS. Le nœud Graph accède principalement au nœud IPFS pendant le déploiement du subgraph pour récupérer le manifeste du sugraph et btous les fichiers liés. Les indexeurs de réseau n'ont pas besoin d'héberger leur propre nœud IPFS, un nœud IPFS pour le réseau est hébergé sur https://ipfs.network.thegraph.com.

  • Service d'indexation : gère toutes les communications externes requises avec le réseau. Partage les modèles de coûts et les statuts d'indexation, transmet les demandes de requête des passerelles à un nœud graphlm et gère les paiements des requêtes via les canaux d'état avec la passerelle.

  • Agent indexeur - Facilite les interactions des indexeurs sur la chaîne, y compris l'enregistrement sur le réseau, la gestion des déploiements de subgraphs sur son(ses) nœud(s) graph(s) et la gestion des allocations.

  • Serveur de métriques Prometheus : les composants Graph Node et Indexer enregistrent leurs métriques sur le serveur de métriques.

Remarque : Pour prendre en charge la mise à l'échelle agile, il est recommandé de séparer les problèmes de requête et d'indexation entre différents ensembles de nœuds : nœuds de requête et nœuds d'index.

Aperçu des ports

Lien vers cette section

Important : Soyez prudent lorsque vous exposez les ports publiquement : les ports d'administration doivent être maintenus verrouillés. Cela inclut les points de terminaison de gestion Graph Node JSON-RPC et Indexer détaillés ci-dessous.

Nœud de The Graph

Lien vers cette section
PortObjectifRoutesArgument CLIVariable d'environnement
8000Serveur HTTP GraphQL
(pour les requêtes de subgraphs)
/subgraphs/id/...
/subgraphs/name/.../...
--http-port-
8001GraphQL WS
(pour les abonnements aux subgraphs)
/subgraphs/id/...
/subgraphs/name/.../...
--ws-port-
8020JSON-RPC
(pour gérer les déploiements)
/--admin-port-
8030API de statut d'indexation des subgraphs/graphq--index-node-port-
8040Métriques Prometheus/metrics--metrics-port-

Service d'indexation

Lien vers cette section
PortObjectifRoutesArgument CLIVariable d'environnement
7600Serveur HTTP GraphQL
(pour les requêtes payantes de subgraphs)
/subgraphs/id/...
/status
/channel-messages-inbox
--portINDEXER_SERVICE_PORT
7300Métriques Prometheus/metrics--metrics-port-

Agent indexeur

Lien vers cette section
PortObjectifRoutesArgument CLIVariable d'environnement
8000API de gestion des indexeurs/--indexer-management-portINDEXER_AGENT_INDEXER_MANAGEMENT_PORT

Configurer l'infrastructure du serveur à l'aide de Terraform sur Google Cloud

Lien vers cette section

Note : Les indexeurs peuvent alternativement utiliser AWS, Microsoft Azure ou Alibaba.

Conditions préalables à l'installation

Lien vers cette section
  • Google Cloud SDK
  • Outil de ligne de commande kubectl
  • Terraform

Créer un projet Google Cloud

Lien vers cette section
  • Cloner ou naviguez vers le répertoire de l'Indexeur.

  • Accédez au répertoire ./terraform, c'est là que toutes les commandes doivent être exécutées.

cd terraform
  • Authentifiez-vous auprès de Google Cloud et créez un nouveau projet.
gcloud auth login
project=<PROJECT_NAME>
gcloud projects create --enable-cloud-apis $project
  • Utilisez la page de facturation de Google Cloud Console pour activer la facturation du nouveau projet.

  • Créez une configuration 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
  • Activez les API Google Cloud requises.
gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com
gcloud services enable servicenetworking.googleapis.com
gcloud services enable sqladmin.googleapis.com
  • Créez un compte de service.
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
  • Activez le peering entre la base de données et le cluster Kubernetes qui sera créé à l'étape suivante.
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
  • Créez un fichier de configuration Terraform minimal (mettez à jour si nécessaire).
indexer=<INDEXER_NAME>
cat > terraform.tfvars <<EOF
project = "$proj_id"
indexer = "$indexer"
database_password = "<database passowrd>"
EOF

Utiliser Terraform pour créer une infrastructure

Lien vers cette section

Avant d'exécuter des commandes, lisez variables.tf et créez un fichier terraform .tfvars dans ce répertoire (ou modifiez celui que nous avons créé à la dernière étape). Pour chaque variable dont vous souhaitez remplacer la valeur par défaut ou pour laquelle vous devez définir une valeur, entrez un paramètre dans terraform.tfvars.

  • Exécutez les commandes suivantes pour créer l'infrastructure.
# Installer les Plugins Requis
terraform init
# Afficher le plan des ressources à créer
terraform plan
# Créez les ressources (attendez-vous à ce que cela prenne jusqu'à 30 minutes)
terraform apply

Téléchargez les informations d'identification du nouveau cluster dans ~/.kube/config et définissez-le comme contexte par défaut.

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

Création des composants Kubernetes pour l'indexeur

Lien vers cette section
  • Copiez le répertoire k8s/overlays dans un nouveau répertoire $dir, et ajustez l'entrée bases dans $dir/kustomization.yamlpour qu'il pointe vers le répertoire k8s/base.

  • Lisez tous les fichiers dans $dir et ajustez les valeurs comme indiqué dans les commentaires.

Déployez toutes les ressources avec kubectl apply -k $dir.

Nœud de The Graph

Lien vers cette section

Graph Node est une implémentation open source en Rust qui source les événements de la blockchain Ethereum pour mettre à jour de manière déterministe un magasin de données pouvant être interrogé via l'endpoint GraphQL. Les développeurs utilisent des subgraphs pour définir leur schéma et un ensemble de mappages pour transformer les données provenant de la blockchain et le Graph Node gère la synchronisation de toute la chaîne, surveille les nouveaux blocs et les sert via un endpoint GraphQL.

Commencer à partir des sources

Lien vers cette section

Conditions préalables à l'installation

Lien vers cette section
  • Rust

  • PostgreSQL

  • IPFS

  • Exigences supplémentaires pour les utilisateurs d'Ubuntu - Pour exécuter un nœud graphique sur Ubuntu, quelques packages supplémentaires peuvent être nécessaires.

sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
  1. Démarrer un serveur de base de données PostgreSQL
initdb -D .postgres
pg_ctl -D .postgres -l logfile start
createdb graph-node
  1. Clonez le dépôt Graph Node et créez la source en exécutant cargo build

  2. Maintenant que toutes les dépendances sont configurées, démarrez le Graph Node :

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

Démarrer avec Docker

Lien vers cette section

Conditions préalables

Lien vers cette section
  • Nœud Ethereum – Par défaut, la configuration de Docker Compose utilisera le réseau principal : http:// host.docker.internal:8545 pour vous connecter au nœud Ethereum sur votre machine hôte. Vous pouvez remplacer ce nom de réseau et cette Url en mettant à jour docker-compose.yaml.
  1. Clonez Graph Node et accédez au répertoire Docker :
git clone https://github.com/graphprotocol/graph-node
cd graph-node/docker
  1. Pour les utilisateurs Linux uniquement - Utilisez l'adresse IP de l'hôte au lieu de host.docker.internal dans le docker-compose.yamlà l'aide du script inclus :
./setup.sh
  1. Démarrez un nœud graph local qui se connectera à votre point de terminaison Ethereum :
docker-compose up

Composants de l'indexeur

Lien vers cette section

Pour participer avec succès au réseau, il faut une surveillance et une interaction presque constantes. Nous avons donc créé une suite d'applications Typescript pour faciliter la participation au réseau des indexeurs. Il existe trois composants d'indexeur :

  • Agent indexeur - L'agent surveille le réseau et la propre infrastructure de l'indexeur et gère les déploiements de subgraphs qui sont indexés et alloués sur la chaîne et la quantité allouée à chacun.

  • Service d'indexation : seul composant qui doit être exposé en externe, le service transmet les requêtes de subgraph au nœud de graph, gère les canaux d'état pour les paiements des requêtes, partage des informations importantes pour la prise de décision. aux clients comme les passerelles.

  • Indexer CLI - L'interface de ligne de commande pour gérer l'agent Indexer. Il permet aux indexeurs de gérer les modèles de coûts, les allocations manuelles, la file d'attente d'actions et les règles d'indexation.

L’agent Indexer et le service Indexer doivent être colocalisés avec votre infrastructure Graph Node. Il existe de nombreuses façons de configurer des environnements d'exécution virtuels pour vos composants Indexer ; nous expliquerons ici comment les exécuter sur baremetal à l'aide des packages ou de la source NPM, ou via kubernetes et docker sur Google Cloud Kubernetes Engine. Si ces exemples de configuration ne s'adaptent pas bien à votre infrastructure, il y aura probablement un guide communautaire à consulter, venez nous dire bonjour sur Discord ! N'oubliez pas de participer au protocole avant de démarrer vos composants Indexer !

À partir des packages NPM

Lien vers cette section
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 ...

Utiliser docker

Lien vers cette section
  • Extraire les images du registre
docker pull ghcr.io/graphprotocol/indexer-service:latest
docker pull ghcr.io/graphprotocol/indexer-agent:latest

Ou créez des images localement à partir de la source

# 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 \
  • Exécutez les composants
docker run -p 7600:7600 -it indexer-service:latest ...
docker run -p 18000:8000 -it indexer-agent:latest ...

NOTE: After starting the containers, the Indexer service should be accessible at http://localhost:7600 and the Indexer agent should be exposing the Indexer management API at http://localhost:18000/.

Utilisation de K8s et Terraform

Lien vers cette section

Consultez la section Configurer l'infrastructure du serveur à l'aide de Terraform sur Google Cloud

REMARQUE : Toutes les variables de configuration d'exécution peuvent être appliquées soit en tant que paramètres à la commande au démarrage, soit en utilisant des variables d'environnement au format COMPONENT_NAME_VARIABLE_NAME (ex. INDEXER_AGENT_ETHEREUM).

Indexer agent

Lien vers cette section
graph-indexer-agent start \
--ethereum <ENDPOINT_RESEAU_PRINCIPAL_ETHEREUM> \
--ethereum-network mainnet \
--mnemonic <MNEMONIC> \
--indexer-address <ADRESSE_DE_LINDEXEUR> \
--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 <VOS COORDONNEES> \
--index-node-ids default \
--indexer-management-port 18000 \
--metrics-port 7040 \
--network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
--default-allocation-amount 100 \
--register true \
--inject-dai true \
--postgres-host localhost \
--postgres-port 5432 \
--postgres-username <NOM_D_UTILISATEUR_DE_LA_BD> \
--postgres-password <MOT_DE_PASSE_DE_LA_BD> \
--postgres-database indexer \
--allocation-management auto \
| pino-pretty

Indexer service

Lien vers cette section
SERVER_HOST=localhost \
SERVER_PORT=5432 \
SERVER_DB_NAME=is_staging \
SERVER_DB_USER=<NOM_D_UTILISATEUR_DE_LA_BD> \
SERVER_DB_PASSWORD=<MOT_DE_PASSE_DE_LA_BD> \
graph-indexer-service start \
--ethereum <ENDPOINT_RESEAU_PRINCIPAL_ETHEREUM> \
--ethereum-network mainnet \
--mnemonic <MNEMONIC> \
--indexer-address <ADRESSE_DE_LINDEXEUR> \
--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 <NOM_D_UTILISATEUR_DE_LA_BD> \
--postgres-password <MOT_DE_PASSE_DE_LA_BD> \
--postgres-database is_staging \
--network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
| pino-pretty

L'interface de ligne de commande de l'indexeur est un plugin pour @graphprotocol/graph-cli accessible dans le terminal à graph indexer.

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

Gestion de l'indexeur à l'aide de l'indexeur CLI

Lien vers cette section

L'outil suggéré pour interagir avec l'API de gestion de l'indexeur est la CLI de l'indexeur, une extension de l'Graphique CLI. L'agent indexeur a besoin de l'entrée d'un indexeur afin d'interagir de manière autonome avec le réseau au nom de l'indexeur. Le mécanisme permettant de définir le comportement de l'agent Indexeur est le mode de gestion des allocations et les règles d'indexation. En mode automatique, un indexeur peut utiliser des règles d'indexation pour appliquer sa stratégie spécifique de sélection des subgraphs à indexer et pour lesquels servir des requêtes. Les règles sont gérées via une API GraphQL servie par l'agent et connue sous le nom d'API de gestion de l'indexeur. En mode manuel, un indexeur peut créer des actions d'allocation à l'aide de la file d'attente d'actions et les approuver explicitement avant qu'elles ne soient exécutées. En mode surveillance, les règles d'indexation sont utilisées pour remplir la file d'attente des actions et nécessitent également une approbation explicite pour l'exécution.

La Indexer CLI se connecte à l'agent Indexer, généralement via la redirection de port, de sorte que la CLI n'a pas besoin de s'exécuter sur le même serveur ou cluster. Pour vous aider à démarrer et pour fournir un certain contexte, la CLI sera brièvement décrite ici.

  • La Indexer CLI se connecte à l'agent Indexer, généralement via la redirection de port, de sorte que la CLI n'a pas besoin de s'exécuter sur le même serveur ou cluster. Pour vous aider à démarrer et pour fournir un certain contexte, la CLI sera brièvement décrite ici

  • Les règles de l'indexeur de graphs obtiennent [options] <deployment-id> [<clé1> ...] - Obtenez une ou plusieurs règles d'indexation en utilisant all comme <deployment-id> pour obtenir toutes les règles, ou global pour obtenir les valeurs par défaut globales. Un argument supplémentaire --merged peut être utilisé pour spécifier que les règles spécifiques au déploiement sont fusionnées avec la règle globale. C'est ainsi qu'ils sont appliqués dans l'agent Indexeur.

  • ensemble de règles de l'indexeur de graphs [options] <deployment-id> <touche1> <valeur1> ... - Définissez une ou plusieurs règles d'indexation.

  • graph indexer Rules start [options] <deployment-id> - Commencez à indexer un déploiement de subgraph si disponible et définissez sa decisionBasis sur toujours, donc l'agent Indexeur choisira toujours de l'indexer. Si la règle globale est définie sur toujours, tous les sugraphs disponibles sur le réseau seront indexés.

  • graph indexer Rules stop [options] <deployment-id> - Arrêtez d'indexer un déploiement et définissez sa decisionBasis sur jamais, de sorte qu'il ignorera ce déploiement lors de la décision sur les déploiements à indice.

  • règles de l'indexeur graphique peut-être [options] <deployment-id> — Définissez le decisionBasis pour un déploiement sur rules, afin que l'agent indexeur utilisez des règles d'indexation pour décider d'indexer ou non ce déploiement.

  • graph indexer actions get [options] <action-id> - Récupérez une ou plusieurs actions en utilisant all ou laissez action-id vide pour obtenir toutes les actions. Un argument supplémentaire --status peut être utilisé pour afficher toutes les actions d'un certain statut.

  • file d'attente d'action de l'indexeur de graphs alloue <deployment-id> <allocation-amount> - Action d'allocation de file d'attente

  • réaffectation de la file d'attente des actions de l'indexeur de graphs <deployment-id> <Id-allocation> <allocationAmount> - Action de réaffectation de la file d'attente

  • file d'attente d'action de l'indexeur de graphs désallouer <id-deployment> <allocation-id> - Mettre en file d'attente l'action de désallocation

  • Les actions de l'indexeur de graphs annulent [<action-id> ...] - Annuler toutes les actions dans la file d'attente si l'identifiant n'est pas spécifié, sinon annuler le tableau d'identifiants avec un espace comme séparateur

  • les actions de l'indexeur de graphs approuvent [<action-id> ...] - Approuver plusieurs actions à exécuter

  • les actions de l'indexeur de graphs exécutent l'approbation - Force le travailleur à exécuter immédiatement les actions approuvées

Toutes les commandes qui affichent les règles dans la sortie peuvent choisir entre les formats de sortie pris en charge (table, yaml et json) à l'aide du - argument de sortie.

Règles d'indexation

Lien vers cette section

Les règles d'indexation peuvent être appliquées soit comme valeurs par défaut globales, soit pour des déploiements de subgraphs spécifiques à l'aide de leurs ID. Les champs deployment et decisionBasis sont obligatoires, tandis que tous les autres champs sont facultatifs. Lorsqu'une règle d'indexation a rules comme decisionBasis, l'agent indexeur comparera les valeurs de seuil non nulles sur cette règle avec les valeurs extraites du réseau pour le déploiement correspondant. Si le déploiement du subgraph a des valeurs supérieures (ou inférieures) à l'un des seuils, il sera choisi pour l'indexation.

Par exemple, si la règle globale a un minStake de 5 (GRT), tout déploiement de subgraph ayant plus de 5 (GRT) d'enjeu qui lui est alloué seront indexés. Les règles de seuil incluent maxAllocationPercentage, minSignal, maxSignal, minStake et minAverageQueryFees.

Modèle de données:

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
}

Exemple d'utilisation de la règle d'indexation :

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 de la file des actions

Lien vers cette section

L'indexer-cli fournit un module actions pour travailler manuellement avec le fichier d'attente d'actions. Il utilise l'API Graphql hébergée par le serveur de gestion de l'indexeur pour interagir avec le fichier d'attente des actions.

Le travailleur d'exécution d'action ne récupérera les éléments de la file d'attente à exécuter que s'ils ont ActionStatus = approved. Dans le chemin recommandé, les actions sont ajoutées à la file d'attente avec ActionStatus = queued, elles doivent donc ensuite être approuvées afin d'être exécutées en chaîne. Le flux général ressemblera à :

  • Action ajoutée à la file d'attente par l'outil d'optimisation tiers ou l'utilisateur indexeur-cli
  • L'indexeur peut utiliser indexer-cli pour afficher toutes les actions en file d'attente
  • L'indexeur (ou un autre logiciel) peut approuver ou annuler les actions dans la file d'attente à l'aide du indexer-cli. Les commandes d'approbation et d'annulation prennent un tableau d'identifiants d'action en entrée.
  • L'agent d'exécution interroge régulièrement la file d'attente pour connaître les actions approuvées. Il récupérera les actions approuvées de la file d'attente, tentera de les exécuter et mettra à jour les valeurs dans la base de données en fonction de l'état d'exécution sur succès ou échec.
  • Si une action réussit, le travailleur s'assurera qu'il existe une règle d'indexation qui indique à l'agent comment gérer l'allocation à l'avenir, utile lors de la réalisation d'actions manuelles lorsque l'agent est en mode auto ou . mode surveillance.
  • L'indexeur peut surveiller la file d'attente des actions pour consulter un historique de l'exécution des actions et, si nécessaire, réapprouver et mettre à jour les éléments d'action en cas d'échec de leur exécution. La file d'attente des actions fournit un historique de toutes les actions mises en file d'attente et entreprises.

Modèle de données:

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
}

Exemple d'utilisation à partir de la source :

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

Notez que les types d'actions pris en charge pour la gestion des allocations ont des exigences d'entrée différentes :

  • Allocate - allouer une participation à un déploiement de subgraph spécifique

    • paramètres d'action requis :
      • deploymentID
      • amount
  • Annuler l'allocation - clôturer l'allocation, libérant la mise pour la réaffecter ailleurs

    • paramètres d'action requis :
      • ID d'allocation
      • deploymentID
    • paramètres d'action facultatifs :
      • poi
      • force (force l'utilisation du POI fourni même s'il ne correspond pas à ce que fournit le nœud graph)
  • Réallouer - fermer atomiquement l'allocation et ouvrir une nouvelle allocation pour le même déploiement de subgraph

    • paramètres d'action requis :
      • ID d'allocation
      • deploymentID
      • amount
    • paramètres d'action facultatifs :
      • poi
      • force (force l'utilisation du POI fourni même s'il ne correspond pas à ce que fournit le nœud graph)

Modèles de coûts

Lien vers cette section

Les modèles de coûts fournissent une tarification dynamique pour les requêtes en fonction des attributs du marché et des requêtes. Le service Indexeur partage un modèle de coût avec les passerelles pour chaque subgraph pour lequel elles ont l'intention de répondre aux requêtes. Les passerelles, à leur tour, utilisent le modèle de coût pour prendre des décisions de sélection des indexeurs par requête et pour négocier le paiement avec les indexeurs choisis.

Le langage Agora fournit un format flexible pour déclarer des modèles de coûts pour les requêtes. Un modèle de prix Agora est une séquence d'instructions qui s'exécutent dans l'ordre pour chaque requête de niveau supérieur dans une requête GraphQL. Pour chaque requête de niveau supérieur, la première instruction qui y correspond détermine le prix de cette requête.

Une instruction est composée d'un prédicat, qui est utilisé pour faire correspondre les requêtes GraphQL, et d'une expression de coût qui, une fois évaluée, génère un coût en GRT décimal. Les valeurs dans la position d'argument nommé d'une requête peuvent être capturées dans le prédicat et utilisées dans l'expression. Des éléments globaux peuvent également être définis et remplacés par des espaces réservés dans une expression.

Exemple de modèle de coût :

# Cette instruction capture la valeur de saut,
# utiliser une expression booléenne dans le prédicat pour correspondre aux requêtes spécifiques qui utilisent `skip`
# et une expression de coût pour calculer le coût en fonction de la valeur `skip` et du SYSTEM_LOAD global
query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
# Cette valeur par défaut correspondra à n'importe quelle expression GraphQL.
# Il utilise un Global substitué dans l'expression pour calculer le coût
default => 0.1 * $SYSTEM_LOAD;

Exemple de calcul des coûts de requête utilisant le modèle ci-dessus :

QueryPrice
{ pairs(skip: 5000) { id } }0.5 GRT
{ tokens { symbol } }0.1 GRT
{ pairs(skip: 5000) { id } tokens { symbol } }0.6 GRT

Application du modèle de coût

Lien vers cette section

Les modèles de coûts sont appliqués via la CLI Indexer, qui les transmet à l'API de gestion de l'indexeur de l'agent Indexer pour les stocker dans la base de données. Le service d'indexation les récupérera ensuite et fournira les modèles de coûts aux passerelles chaque fois qu'elles les demanderont.

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

Interagir avec le réseau

Lien vers cette section

Enjeu dans le protocole

Lien vers cette section

Les premières étapes pour participer au réseau en tant qu'Indexeur sont d'approuver le protocole, de staker des fonds et (facultativement) de configurer une adresse opérateur pour les interactions quotidiennes avec le protocole.

Note : Pour les besoins de ces instructions, Remix sera utilisé pour l'interaction avec le contrat, mais n'hésitez pas à utiliser l'outil de votre choix (OneClickDapp, ABItopic, et MyCrypto sont quelques autres outils connus).

Une fois qu'un indexeur a staké des GRT dans le protocole, les composants de l'indexeur peuvent être démarrés et commencer leurs interactions avec le réseau.

Approuver les jetons

Lien vers cette section
  1. Ouvrez l'application Remix dans un navigateur

  2. Dans File Explorer, créez un fichier nommé GraphToken.abi avec l'ABI du jeton.

  3. Avec GraphToken.abi sélectionné et ouvert dans l'éditeur, passez à la section Déployer et exécuter des transactions dans l’interface de Remix.

  4. Sous Environnement, sélectionnez Injected Web3 et sous Compte sélectionnez votre adresse d'indexeur.

  5. Définissez l'adresse du contrat GraphToken : collez l'adresse du contrat GraphToken (0xc944E90C64B2c07662A292be6244BDf05Cda44a7) à côté de À l'adresse et cliquez sur le bouton À l'adresse pour appliquer.

  6. Appelez la fonction approve(spender, montant) pour approuver le contrat de Staking. Remplissez spender avec l'adresse du contrat de Staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9) et montant avec les jetons à miser (en wei).

Jetons de mise

Lien vers cette section
  1. Ouvrez l'application Remix dans un navigateur

  2. Dans l'Explorateur de fichiers, créez un fichier nommé Staking.abi avec l'ABI de staking.

  3. Avec Staking.abi sélectionné et ouvert dans l'éditeur, passez à la section Déployer et exécuter des transactions dans l’interface de Remix.

  4. Sous Environnement, sélectionnez Injected Web3 et sous Compte sélectionnez votre adresse d'indexeur.

  5. Définissez l'adresse du contrat de jalonnement - Collez l'adresse du contrat de jalonnement (0xF55041E37E12cD407ad00CE2910B8269B01263b9) à côté de À l'adresse et cliquez sur le bouton À l'adresse pour appliquer.

  6. Appelez stake() pour implanter GRT dans le protocole.

  7. (Facultatif) Les indexeurs peuvent approuver une autre adresse pour être l'opérateur de leur infrastructure d'indexeur afin de séparer les clés qui contrôlent les fonds de celles qui effectuent des actions quotidiennes telles que l'allocation sur des sugraphes et la réponse à des requêtes (payantes). Afin de définir l'opérateur, appelez setOperator() avec l'adresse de l'opérateur.

  8. (Facultatif) Afin de contrôler la distribution des récompenses et d'attirer stratégiquement les délégués, les indexeurs peuvent mettre à jour leurs paramètres de délégation en mettant à jour leur indexingRewardCut (parties par million), queryFeeCut (parties par million) et cooldownBlocks (nombre de blocs). Pour ce faire, appelez setDelegationParameters(). L'exemple suivant définit queryFeeCut pour distribuer 95 % des remises sur les requêtes à l'indexeur et 5 % aux délégués, définit indexingRewardCut pour distribuer 60 % des récompenses d'indexation à l'indexeur et 40 % aux délégués, et définit thecooldownBlocks. période à 500 blocs.

setDelegationParameters(950000, 600000, 500)

Définition des paramètres de délégation

Lien vers cette section

La fonction setDelegationParameters() dans le contrat de staking est essentielle pour les Indexeurs, leur permettant de définir des paramètres qui définissent leurs interactions avec les Délégateurs, influençant leur partage des récompenses et leur capacité de délégation.

Comment définir les paramètres de délégation

Lien vers cette section

Pour définir les paramètres de délégation à l'aide de l'interface Graph Explorer, suivez ces étapes :

  1. Naviguez vers Graph Explorer.
  2. Connectez votre portefeuille. Choisissez multisig (comme Gnosis Safe) puis sélectionnez mainnet. Note : Vous devrez répéter ce processus pour Arbitrum One.
  3. Connectez le portefeuille que vous avez en tant que signataire.
  4. Accédez à la section "Settings" puis sélectionnez "Delegation Parameters". Ces paramètres doivent être configurés afin d’obtenir un taux effectif dans la fourchette souhaitée. Une fois les valeurs saisies dans les champs prévus, l’interface calcule automatiquement ce taux effectif. Ajustez les valeurs selon vos besoins pour atteindre le pourcentage effectif désiré.
  5. Soumettez la transaction au réseau.

Note : Cette transaction devra être confirmée par les signataires du portefeuille multisig.

La durée de vie d'une allocation

Lien vers cette section

After being created by an Indexer a healthy allocation goes through two states.

  • Active - Une fois qu'une allocation est créée on-chain (allocateFrom()) elle est considérée comme active. Une partie du staking de l'Indexeur et/ou du staking délégué est allouée à un déploiement de subgraph, ce qui leur permet de réclamer des récompenses d'indexation et de servir des requêtes pour ce déploiement de subgraph. L'agent Indexeur gère la création des allocations en fonction des règles de l'Indexeur.

  • Closed - Un Indexeur est libre de fermer une allocation une fois qu'une époque est passée (closeAllocation()) ou son agent Indexeur fermera automatiquement l'allocation après le maxAllocationEpochs (actuellement 28 jours). Lorsqu'une allocation est fermée avec une preuve d'indexation (POI) valide, leurs récompenses d'indexation sont distribuées à l'Indexeur et à ses Délégateurs (en savoir plus).

Il est recommandé aux indexeurs d'utiliser la fonctionnalité de synchronisation hors chaîne pour synchroniser les déploiements de subgraphs avec Chainhead avant de créer l'allocation en chaîne. Cette fonctionnalité est particulièrement utile pour les sous-graphes dont la synchronisation peut prendre plus de 28 époques ou qui risquent d'échouer de manière indéterministe.

Modifier une page

Précédente
FAQ
Suivante
Nœud de graph opérationnel
Modifier une page