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.

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

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.

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.

Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the Community Guides collection. You can also find an up to date list of tools in the #Delegators and #Indexers channels on the Discord server. Here we link a recommended allocation optimiser integrated with the indexer software stack.

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.

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).

The RewardsManager contract has a read-only getRewards function that can be used to check the pending rewards for a specific allocation.

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 subgraph du mainnet pour obtenir les ID 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():
  • Expand the 9. getRewards dropdown.
  • Saisissez le allocationID dans l'entrée.
  • Cliquez sur le bouton Requête.

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.

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.

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.

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.

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

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

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.

• Google Cloud SDK
• Outil de ligne de commande kubectl
• Terraform

• Clone or navigate to the Indexer repository.

• Navigate to the ./terraform directory, this is where all commands should be executed.

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

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)

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

Graph Node is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.

• 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

2. Clonez le dépôt Graph Node et créez la source en exécutant cargo build

3. 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

• 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

2. 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

3. Démarrez un nœud graph local qui se connectera à votre point de terminaison Ethereum :

docker-compose up

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 !

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

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

Consultez la section Configurer l'infrastructure du serveur à l'aide de Terraform sur 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

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

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ère 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 imprimer 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.

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

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)

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 :

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

The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.

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.

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. With GraphToken.abi selected and open in the editor, switch to the Deploy and run transactions section in the Remix interface.

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).

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. With Staking.abi selected and open in the editor, switch to the Deploy and run transactions section in the Remix interface.

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)

The setDelegationParameters() function in the staking contract is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.

To set the delegation parameters using Graph Explorer interface, follow these steps:

1. Navigate to Graph Explorer.
2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
3. Connect the wallet you have as a signer.
4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
5. Submit the transaction to the network.

Après avoir été créée par un indexeur, une allocation saine passe par quatre états.

• Active - Once an allocation is created on-chain (allocateFrom()) it is considered active. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.

• Closed - An Indexer is free to close an allocation once 1 epoch has passed (closeAllocation()) or their Indexer agent will automatically close the allocation after the maxAllocationEpochs (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators (learn more).

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.