Vue d’ensemble de l’indexation

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.

Indexers select Subgraphs to index based on the Subgraph’s curation signal, where Curators stake GRT in order to indicate which Subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their Subgraphs and set preferences for query fee pricing.

FAQ

Quelle est le staking minimal requise pour être Indexeur sur le réseau ?

Le staking minimal pour un Indexeur est actuellement fixée à 100 000 GRT.

Quelles sont les sources de revenus d’un Indexeur ?

Rabais de frais de requête - Paiements pour servir les requêtes sur le réseau. Ces paiements sont effectués par l’intermédiaire de canaux d’état entre un Indexeur et une passerelle. Chaque demande de requête provenant d’une passerelle contient un paiement et la réponse correspondante est une preuve de la validité du résultat de la requête.

Indexing rewards - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing Subgraph deployments for the network.

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

Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across Subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that Subgraph. An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.

De nombreux outils ont été créés par la communauté pour calculer les récompenses ; vous en trouverez une collection organisée dans la Collection des guides de la communauté⁠. Vous pouvez également trouver une liste actualisée d’outils dans les canaux #Delegators et #Indexers sur le serveur Discord⁠. Nous présentons ici un lien vers un optimiseur d’allocation recommandé⁠ intégré à la pile logicielle de l’Indexeur.

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

POIs are used in the network to verify that an Indexer is indexing the Subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific Subgraph deployment up to and including that block.

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

Les allocations accumulent continuellement des récompenses tant 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 lorsque leurs allocations sont fermées. Cela se fait soit manuellement, lorsque l’Indexeur veut forcer la fermeture, soit après 28 époques, un Déléguateur peut fermer l’allocation pour l’Indexeur, mais cela n’entraîne pas de récompenses. 28 époques est la durée de vie maximale d’une allocation (actuellement, une époque dure environ 24 heures).

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

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

De nombreux tableaux de bord élaborés par la communauté comprennent des valeurs de récompenses en attente et il est facile de les vérifier manuellement en suivant les étapes suivantes :

1. Query the mainnet Subgraph to get the IDs for all active allocations:

1query indexerAllocations {2  indexer(id: "<INDEXER_ADDRESS>") {3    allocations {4      activeForIndexer {5        allocations {6          id7        }8      }9    }10  }11}

Utilisez Etherscan pour appeler getRewards() :

• Naviguer vers [l’Interface Etherscan pour le contrat de récompenses] (https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract⁠)
• Pour appeler getRewards() :
  • Développez la liste déroulante 9. getRewards.
  • Saisissez l’allocationID dans le champ de saisie.
  • Cliquez sur le bouton Query.

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

Les requêtes et les allocations des Indexeurs peuvent toutes deux être contestées sur The Graph pendant la période de contestation. La période de contestation varie en fonction du type de contestation. Les requêtes/attestations ont une fenêtre de contestation de 7 époques, tandis que les attributions ont une fenêtre de 56 époques. Une fois ces périodes écoulées, il n’est plus possible d’ouvrir un litige contre une allocation ou une requête. Lorsqu’un litige est ouvert, un dépôt d’un minimum de 10 000 GRT est exigé par les Fisherman, qui sera bloqué jusqu’à ce que le litige soit finalisé et qu’une résolution ait été donnée. Les Fisherman sont tous les participants au réseau qui ouvrent des litiges.

Les litiges ont trois issues possibles, tout comme le dépôt des Fishermen.

• Si le litige est rejeté, les GRT déposées par le Fishermen seront brûlées et l’Indexeur accusé n’est pas « slashed » (aucune pénalité).
• Si le litige se solde par un match nul, la caution du Fisherman sera restituée et l’Indexeur mis en cause n’est pas pénalisé.
• Si le litige est accepté, les GRT déposés par le Fisherman lui seront restitués, l’Indexeur mis en cause sera pénalisé (slashed) et le Fisherman recevra 50 % des GRT ainsi confisqués.

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

Que sont les query fee rebates et quand sont-ils distribués ?

Les frais de requête sont collectés par la passerelle et distribués aux Indexeurs selon la fonction de ristourne exponentielle (exponential rebate function, voir GIP à ce sujet ici⁠). Cette fonction est proposée comme un moyen de garantir que les Indexeurs obtiennent le meilleur résultat en répondant fidèlement aux requêtes. Elle incite les Indexeurs à allouer un montant élevé de staking (qui peut être réduit en cas d’erreur lors du service d’une requête) par rapport au montant des frais de requête qu’ils peuvent percevoir.

Une fois l’allocation clôturée, les ristournes peuvent être réclamées par l’Indexeur. Une fois réclamées, ces ristournes sur les frais de requête sont partagées entre l’Indexeur et ses Délégateurs, conformément au query fee cut et à la fonction de ristourne exponentielle.

Que sont les query fee cut et l’indexing reward cut ?

Les valeurs queryFeeCut et indexingRewardCut sont des paramètres de délégation que l’Indexeur peut définir avec les cooldownBlocks pour contrôler la distribution des GRT entre l’Indexeur et ses Déléguateurs. Voir les dernières étapes de Staking dans le Protocol pour les instructions sur la définition des paramètres de délégation.

• queryFeeCut - le pourcentage des remises sur les frais de requête qui sera distribué à l’Indexeur. Si cette valeur est fixée à 95 %, l’indexeur recevra 95 % des frais de requête perçus lors de la clôture d’une allocation, les 5 % restants revenant aux Déléguateurs.

• indexingRewardCut - le pourcentage des récompenses d’indexation qui sera distribué à l’Indexeur. Si cette valeur est fixée à 95 %, l’Indexeur recevra 95 % des récompenses d’indexation lorsqu’une allocation est clôturée et les Déléguateurs se partageront les 5 % restants.

How do Indexers know which Subgraphs to index?

Indexers may differentiate themselves by applying advanced techniques for making Subgraph indexing decisions but to give a general idea we’ll discuss several key metrics used to evaluate Subgraphs in the network:

• Curation signal - The proportion of network curation signal applied to a particular Subgraph is a good indicator of the interest in that Subgraph, especially during the bootstrap phase when query volume is ramping up.

• Query fees collected - The historical data for volume of query fees collected for a specific Subgraph is a good indicator of future demand.

• Amount staked - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific Subgraphs can allow an Indexer to monitor the supply side for Subgraph queries to identify Subgraphs that the network is showing confidence in or Subgraphs that may show a need for more supply.

• Subgraphs with no indexing rewards - Some Subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a Subgraph if it is not generating indexing rewards.

Quelles sont les exigences en matière de matériel ?

• Small - Enough to get started indexing several Subgraphs, will likely need to be expanded.
• Standard - Configuration par défaut, c’est ce qui est utilisé dans les manifestes de déploiement de l’exemple k8s/terraform.
• Medium - Production Indexer supporting 100 Subgraphs and 200-500 requests per second.
• Large - Prepared to index all currently used Subgraphs and serve requests for the related traffic.

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

• Portefeuille de l’opérateur - La mise en place d’un portefeuille de l’opérateur est une précaution importante car elle permet à un Indexeur de maintenir une séparation entre les clés qui contrôlent le stajing et celles qui contrôlent les opérations quotidiennes. Voir Staking dans le Protocol pour les instructions.

• Firewall - Seul le service de l’Indexeur doit être exposé publiquement et une attention particulière doit être portée au verrouillage des ports d’administration et de l’accès à la base de données : l’endpoint JSON-RPC de Graph Node (port par défaut : 8030), l’endpoint de l’API de gestion de l’Indexeur (port par défaut : 18000), et l’enpoint de la base de données Postgres (port par défaut : 5432) ne doivent pas être exposés.

Infrastructure

At the center of an Indexer’s infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a Subgraph definition and serves it as a GraphQL API. The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.

• PostgreSQL database - The main store for the Graph Node, this is where Subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.

• Data endpoint - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It’s important to be aware that certain Subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.

• IPFS node (version less than 5) - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during Subgraph deployment to fetch the Subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.thegraph.com⁠.

• Service de l’Indexeur - Gère toutes les communications externes requises avec le réseau. Il partage les modèles de coûts et les états d’indexation, transmet les requêtes des passerelles à un Graph Node et gère les paiements des requêtes via des canaux d’état avec la passerelle.

• Indexer agent - Facilitates the Indexers interactions onchain including registering on the network, managing Subgraph deployments to its Graph Node/s, and managing allocations.

• Serveur de métriques Prometheus - Les composants Graph Node et Indexeur enregistrent leurs métriques sur le serveur de métriques.

Remarque : pour permettre une mise à l’échelle souple, il est recommandé de séparer les préoccupations de requête et d’indexation soient séparés différents ensembles de nœuds : les nœuds de requête et les nœuds d’indexation.

Vue d’ensemble des ports

Nœud de The Graph

Service d’Indexeur

Indexer Agent

Mise en place d’une infrastructure de serveurs à l’aide de Terraform sur Google Cloud

Installer les prérequis

• SDK Google Cloud
• Outil en ligne de commande Kubectl
• Terraform

Créer un projet Google Cloud

• Cloner ou naviguer vers la repo de l’Indexeur⁠.

• Naviguez jusqu’au répertoire ./terraform, c’est là que toutes les commandes doivent être exécutées.

1cd terraform

• Authentifiez-vous auprès de Google Cloud et créez un nouveau projet.

1gcloud auth login2project=<PROJECT_NAME>3gcloud projects create --enable-cloud-apis $project

• Utilisez la page de facturation de la Google Cloud Console pour activer la facturation du nouveau projet.

• Créez une configuration Google Cloud.

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

• Activer les API Google Cloud requises.

1gcloud services enable compute.googleapis.com2gcloud services enable container.googleapis.com3gcloud services enable servicenetworking.googleapis.com4gcloud services enable sqladmin.googleapis.com

• Créer un compte de service.

1svc_name=<SERVICE_ACCOUNT_NAME>2gcloud iam service-accounts create $svc_name \3  --description="Service account for Terraform" \4  --display-name="$svc_name"5gcloud iam service-accounts list6# Obtenir l'email du compte de service à partir de la liste7svc=$(gcloud iam service-accounts list --format='get(email)'8--filter="displayName=$svc_name")9gcloud iam service-accounts keys create .gcloud-credentials.json \10  --iam-account="$svc"11gcloud projects add-iam-policy-binding $proj_id \12  --member serviceAccount:$svc \13  --role roles/editor

• Activer le peering entre la base de données et le cluster Kubernetes qui sera créé à l’étape suivante.

1gcloud compute addresses create google-managed-services-default \2  --prefix-length=20 \3  --purpose=VPC_PEERING \4  --network default \5  --global \6  --description 'IP Range for peer networks.'7gcloud services vpc-peerings connect \8  --network=default \9  --ranges=google-managed-services-default

• Créer un fichier de configuration minimal pour terraform (mettre à jour si nécessaire).

1indexer=<INDEXER_NAME>2cat > terraform.tfvars <<EOF3project = "$proj_id"4indexer = "$indexer"5database_password = "<database password>"6EOF

Utiliser Terraform pour créer une infrastructure

Avant de lancer une commande, 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 pour laquelle vous voulez remplacer la valeur par défaut, ou pour laquelle vous avez besoin de définir une valeur, entrez un paramètre dans terraform.tfvars.

• Exécutez les commandes suivantes pour créer l’infrastructure.

1# Installer les plugins nécessaires2terraform init34# Visualiser le plan des ressources à créer5terraform plan67# Créer les ressources (cela peut prendre jusqu'à 30 minutes)8terraform apply

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

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

Création des composants Kubernetes pour l’Indexeur

• Copiez le répertoire k8s/overlays dans un nouveau répertoire $dir, et ajustez l’entrée bases dans $dir/kustomization.yaml pour qu’elle pointe vers le répertoire k8s/base.

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

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

Nœud de The Graph

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.

Démarrer à partir des sources

Installer les prérequis

• Rust

• PostgreSQL

• IPFS

• Exigences supplémentaires pour les utilisateurs d’Ubuntu - Pour faire fonctionner un Graph Node sur Ubuntu, quelques packages supplémentaires peuvent être nécessaires.

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

Configuration

1. Démarrer un serveur de base de données PostgreSQL

1initdb -D .postgres2pg_ctl -D .postgres -l logfile start3createdb graph-node

2. Clonez la repo Graph Node⁠ et compilez les sources en lançant cargo build

3. Maintenant que toutes les dépendances sont installées, démarrez Graph Node :

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

Commencer à utiliser Docker

Prérequis

• Nœud Ethereum - Par défaut, l’installation de docker compose utilisera mainnet : http://host.docker.internal:8545⁠ pour se 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.

Configuration

1. Clonez Graph Node et accédez au répertoire Docker :

1git clone https://github.com/graphprotocol/graph-node2cd 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 en utilisant le script inclus :

1./setup.sh

3. Démarrez un Graph Node local qui se connectera à votre endpoint Ethereum :

1docker-compose up

Indexer components

Pour participer avec succès au réseau, il faut une surveillance et une interaction presque constantes. C’est pourquoi nous avons créé une suite d’applications Typescript pour faciliter la participation d’un Indexeur au réseau. Il y a trois Indexer components :

• Indexer agent - The agent monitors the network and the Indexer’s own infrastructure and manages which Subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.

• Indexer service - The only component that needs to be exposed externally, the service passes on Subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.

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

Pour commencer

L’Indexer agent et l’Indexer service doivent être situés au même endroit que votre infrastructure Graph Node. Il existe de nombreuses façons de mettre en place des environnements d’exécution virtuels pour vos Indexer components; nous expliquerons ici comment les exécuter sur baremetal en utilisant les packages NPM ou les sources, ou via kubernetes et docker sur Google Cloud Kubernetes Engine. Si ces exemples de configuration ne s’appliquent pas à votre infrastructure, il y aura probablement un guide communautaire à consulter, venez nous dire bonjour sur Discord⁠ ! N’oubliez pas de staker sur le protocole avant de démarrer vos Indexer components !

A partir des packages NPM

1npm install -g @graphprotocol/indexer-service2npm install -g @graphprotocol/indexer-agent34# Indexer CLI est un plugin pour Graph CLI, les deux doivent donc être installés :5npm install -g @graphprotocol/graph-cli6npm install -g @graphprotocol/indexer-cli78# Indexer service9graph-indexer-service start ...1011# Indexer agent12graph-indexer-agent start ...1314# Indexer CLI15#Transférer le port de votre pod agent si vous utilisez Kubernetes.16kubectl port-forward pod/POD_ID 18000:800017graph indexer connect http://localhost:18000/18graph indexer ...

Depuis la source

1# Depuis le répertoire racine de Repo2yarn34# Indexer Service5cd packages/indexer-service6./bin/graph-indexer-service start ...78# Indexer agent9cd packages/indexer-agent10./bin/graph-indexer-service start ...1112# Indexer CLI13cd packages/indexer-cli14./bin/graph-indexer-cli indexer connect http://localhost:18000/15./bin/graph-indexer-cli indexer ...

Utilisation de Docker

• Extraire des images du registre

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

Ou construire des images localement à partir des sources

1# Indexer service2docker build \3  --build-arg NPM_TOKEN=<npm-token> \4  -f Dockerfile.indexer-service \5  -t indexer-service:latest \6# Indexer agent7docker build \8  --build-arg NPM_TOKEN=<npm-token> \9  -f Dockerfile.indexer-agent \10  -t indexer-agent:latest \

• Exécuter les composants

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

NOTE : Après le démarrage des conteneurs, le service Indexer doit être accessible à l’adresse http://localhost:7600⁠ et l’agent Indexer doit exposer l’API de gestion de l’Indexeur à l’adresse http://localhost:18000/⁠.

En utilisant K8s et Terraform

Voir la section Configuration de l’infrastructure du serveur à l’aide de Terraform sur Google Cloud

Usage

Indexer agent

1graph-indexer-agent start \2  --ethereum <MAINNET_ETH_ENDPOINT> \3  --ethereum-network mainnet \4  --mnemonic <MNEMONIC> \5  --indexer-address <INDEXER_ADDRESS> \6  --graph-node-query-endpoint http://localhost:8000/ \7  --graph-node-status-endpoint http://localhost:8030/graphql \8  --graph-node-admin-endpoint http://localhost:8020/ \9  --public-indexer-url http://localhost:7600/ \10  --indexer-geo-coordinates <YOUR_COORDINATES> \11  --index-node-ids default \12  --indexer-management-port 18000 \13  --metrics-port 7040 \14  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \15  --default-allocation-amount 100 \16  --register true \17  --inject-dai true \18  --postgres-host localhost \19  --postgres-port 5432 \20  --postgres-username <DB_USERNAME> \21  --postgres-password <DB_PASSWORD> \22  --postgres-database indexer \23  --allocation-management auto \24  | pino-pretty

Indexer service

1SERVER_HOST=localhost \2SERVER_PORT=5432 \3SERVER_DB_NAME=is_staging \4SERVER_DB_USER=<DB_USERNAME> \5SERVER_DB_PASSWORD=<DB_PASSWORD> \6graph-indexer-service start \7  --ethereum <MAINNET_ETH_ENDPOINT> \8  --ethereum-network mainnet \9  --mnemonic <MNEMONIC> \10  --indexer-address <INDEXER_ADDRESS> \11  --port 7600 \12  --metrics-port 7300 \13  --graph-node-query-endpoint http://localhost:8000/ \14  --graph-node-status-endpoint http://localhost:8030/graphql \15  --postgres-host localhost \16  --postgres-port 5432 \17  --postgres-username <DB_USERNAME> \18  --postgres-password <DB_PASSWORD> \19  --postgres-database is_staging \20  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \21  | pino-pretty

Indexer CLI

L’Indexer CLI est un plugin pour @graphprotocol/graph-cli⁠ accessible dans le terminal à graph indexer.

1graph indexer connect http://localhost:180002graph indexer status

Gestion de l’Indexeur à l’aide de l’Indexer CLI

The suggested tool for interacting with the Indexer Management API is the Indexer CLI, an extension to the Graph CLI. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are allocation management mode and indexing rules. Under auto mode, an Indexer can use indexing rules to apply their specific strategy for picking Subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using actions queue and explicitly approve them before they get executed. Under oversight mode, indexing rules are used to populate actions queue and also require explicit approval for execution.

Usage

L’Indexer CLI se connecte à l’Indexer agent, généralement par le biais d’une redirection de port, de sorte que le CLI n’a pas besoin d’être exécuté sur le même serveur ou cluster. Pour vous aider à démarrer, et pour vous donner un peu de contexte, nous allons décrire brièvement le CLI.

• graph indexer connect <url> - Se connecter à l’API de gestion de l’Indexeur. Généralement, la connexion au serveur est ouverte via une redirection de port, afin que le CLI puisse être facilement utilisé à distance. (Exemple : kubectl port-forward pod/<indexer-agent-pod> 8000:8000)

• graph indexer rules get [options] <deployment-id> [<key1> ...] - Obtenir 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’elles sont appliquées dans l’Indexer agent.

• graph indexer rules set [options] <deployment-id> <key1> <value1> ... - Définir une ou plusieurs règles d’indexation.

• graph indexer rules start [options] <deployment-id> - Start indexing a Subgraph deployment if available and set its decisionBasis to always, so the Indexer agent will always choose to index it. If the global rule is set to always then all available Subgraphs on the network will be indexed.

• graph indexer rules stop [options] <deployment-id> - Arrête l’indexation d’un déploiement et met sa decisionBasis à never, de sorte qu’il ignorera ce déploiement lorsqu’il décidera des déploiements à indexer.

• graph indexer rules maybe [options] <deployment-id> — Définit la decisionBasis pour un déploiement à rules, afin que l’agent d’Indexeur utilise les 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 laisse 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.

• graph indexer action queue allocate <deployment-id> <allocation-amount> - Action d’allocation de la file d’attente

• graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount> - Action de réallocation de la file d’attente

• graph indexer action queue unallocate <deployment-id> <allocation-id> - Action de désallocation de la file d’attente

• graph indexer actions cancel [<action-id> ...] - Annule toutes les actions de la file d’attente si id n’est pas spécifié, sinon annule un tableau d’id avec un espace comme séparateur

• graph indexer actions approve [<action-id> ...] - Approuver l’exécution de plusieurs actions

• graph indexer actions execute approve - Force le worker à exécuter immédiatement les actions approuvées

Toutes les commandes qui affichent des règles dans la sortie peuvent choisir entre les formats de sortie supportés (table, yaml, et json) en utilisant l’argument -output.

Règles d’indexation

Indexing rules can either be applied as global defaults or for specific Subgraph deployments using their IDs. The deployment and decisionBasis fields are mandatory, while all other fields are optional. When an indexing rule has rules as the decisionBasis, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the Subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.

For example, if the global rule has a minStake of 5 (GRT), any Subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include maxAllocationPercentage, minSignal, maxSignal, minStake, and minAverageQueryFees.

Modèle de données :

1type IndexingRule {2    identifier: string3    identifierType: IdentifierType4    decisionBasis: IndexingDecisionBasis!5    allocationAmount: number | null6    allocationLifetime: number | null7    autoRenewal: boolean8    parallelAllocations: number | null9    maxAllocationPercentage: number | null10    minSignal: string | null11    maxSignal: string | null12    minStake: string | null13    minAverageQueryFees: string | null14    custom: string | null15    requireSupported: boolean | null16  }1718IdentifierType {19  deployment20  subgraph21  group22}2324IndexingDecisionBasis {25  rules26  never27  always28  offchain29}

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

1graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK23graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false45graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK67graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK

File d’attente d’actions CLI

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

L’agent d’exécution des actions ne récupère les éléments de la file d’attente pour les exécuter que s’ils ont un ActionStatus = approved. Dans le chemin recommandé, les actions sont ajoutées à la file d’attente avec ActionStatus = queued, de ce fait elles doivent donc être approuvées pour être exécutées onchain. Le flux général se présente comme suit :

• Action ajoutée à la file d’attente par l’outil d’optimisation tiers ou l’utilisateur d’indexer-cli
• L’Indexeur peut utiliser indexer-cli pour visualiser toutes les actions en attente
• L’Indexeur (ou un autre logiciel) peut approuver ou annuler des actions dans la file d’attente en utilisant l’indexer-cli. Les commandes approve et cancel prennent en entrée un tableau d’identifiants d’actions.
• L’agent d’exécution interroge régulièrement la file d’attente pour les actions approuvées. Il récupère les actions approuvées de la file d’attente, tente de les exécuter, et met à jour les valeurs dans la base de données en fonction du statut de l’exécution, success ou failed.
• Si une action est réussie, le worker s’assurera qu’il y a une règle d’indexation présente qui indique à l’agent comment gérer l’allocation à l’avenir, ce qui est utile pour prendre des actions manuelles lorsque l’agent est en mode auto ou oversight.
• L’indexeur peut surveiller la file d’attente des actions pour voir l’historique de l’exécution des actions et, si nécessaire, réapprouver et mettre à jour les éléments d’action dont l’exécution a échoué. La file d’attente des actions fournit un historique de toutes les actions mises en attente et exécutées.

Modèle de données :

1Type ActionInput {2    status: ActionStatus3    type: ActionType4    deploymentID: string | null5    allocationID: string | null6    amount: string | null7    poi: string | null8    force: boolean | null9    source: string10    reason: string | null11    priority: number | null12}1314ActionStatus {15  queued16  approved17  pending18  success19  failed20  canceled21}2223ActionType {24  allocate25  unallocate26  reallocate27  collect28}

Exemple d’utilisation de la source :

1graph indexer actions get all23graph indexer actions get --status queued45graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 500067graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 5500089graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae1011graph indexer actions cancel1213graph indexer actions approve 1 3 51415graph indexer actions execute approve

Notez que les types d’action pris en charge pour la gestion de l’allocation ont des exigences différentes en matière de données d’entrée :

• Allocate - allocate stake to a specific Subgraph deployment

  • paramètres d’action requis :
    • deploymentID
    • amount

• Unallocate - ferme l’allocation, libérant le staking pour le réallouer ailleurs

  • paramètres d’action requis :
    • allocationID
    • deploymentID
  • paramètres d’action optionnels :
    • poi
    • force (force à utiliser le POI fourni même s’il ne correspond pas à ce que graph-node fournit)

• Reallocate - atomically close allocation and open a fresh allocation for the same Subgraph deployment

  • paramètres d’action requis :
    • allocationID
    • deploymentID
    • amount
  • paramètres d’action optionnels :
    • poi
    • force (force à utiliser le POI fourni même s’il ne correspond pas à ce que graph-node fournit)

Modèles de coûts

Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each Subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.

Agora

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 lui correspond détermine le prix de cette requête.

Une déclaration 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, lorsqu’elle est évaluée, produit un coût en GRT décimal. Les valeurs de l’argument nommé d’une requête peuvent être capturées dans le prédicat et utilisées dans l’expression. Les 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 :

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

Exemple de calcul des coûts d’une requête à l’aide du modèle ci-dessus :

Application du modèle de coût

Les modèles de coûts sont appliqués via l’Indexer CLI, qui les transmet à l’API de gestion de l’Indexer agent pour qu’ils soient stockés dans la base de données. L’Indexer Service les récupère ensuite et fournit les modèles de coûts aux passerelles chaque fois qu’elles le demandent.

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

Interaction avec le réseau

Staker dans le protocol

Les premières étapes de la participation au réseau en tant qu’Indexeur consistent à approuver le protocole, à staker des fonds et (éventuellement) à créer une adresse d’opérateur pour les interactions quotidiennes avec le protocole.

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

1. Ouvrir l’application Remix⁠ dans un navigateur

2. Dans l’explorateur de fichiers, créez un fichier nommé GraphToken.abi avec le token ABI⁠.

3. Avec GraphToken.abi sélectionné et ouvert dans l’éditeur, passez à la section Deploy and run transactions dans l’interface Remix.

4. Sous environnement, sélectionnez Injected Web3 et sous Account sélectionnez votre adresse d’Indexeur.

5. Définir l’adresse du contrat GraphToken - Collez l’adresse du contrat GraphToken (0xc944E90C64B2c07662A292be6244BDf05Cda44a7) à côté de At Address et cliquez sur le bouton At Address pour l’appliquer.

6. Appeler la fonction approve(spender, amount) pour approuver le contrat de Staking. Remplissez spender avec l’adresse du contrat de staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9) et amount avec les jetons à staker (en wei).

Staker les jetons

1. Ouvrir 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 Deploy and run transactions dans l’interface Remix.

4. Sous environnement, sélectionnez Injected Web3 et sous Account sélectionnez votre adresse d’Indexeur.

5. Définir l’adresse du contrat de staking - Collez l’adresse du contrat de staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9) à côté de At Address et cliquez sur le bouton At address pour l’appliquer.

6. Appeler stake() pour staker les GRT dans le protocole.

7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on Subgraphs and serving (paid) queries. In order to set the operator call setOperator() with the operator address.

8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call setDelegationParameters(). The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCut to distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set the cooldownBlocks period to 500 blocks.

1setDelegationParameters(950000, 600000, 500)

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

La fonction setDelegationParameters() du contrat de staking⁠ est essentielle pour les Indexeurs, car elle leur permet de définir les paramètres qui définissent leurs interactions avec les Déléguateurs, en influençant le partage des récompenses et la capacité de délégation.

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

Pour définir les paramètres de délégation à l’aide de l’interface Graph Explorer, procédez comme suit :

1. Naviguez jusqu’à Graph Explorer.
2. Connectez votre portefeuille. Choisissez multisig (comme Gnosis Safe) et sélectionnez ensuite 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 ‘Paramètres’ et sélectionnez ‘Paramètres de délégation’. Ces paramètres doivent être configurés de manière à obtenir une réduction effective dans la fourchette souhaitée. En saisissant des valeurs dans les champs de saisie prévus à cet effet, l’interface calculera automatiquement la réduction effective. Ajustez ces valeurs si nécessaire pour obtenir le pourcentage de réduction effective souhaité.
5. Soumettre la transaction au réseau.

La durée de vie d’une allocation

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

• Active - Once an allocation is created onchain (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 - Un indexeur est libre de clôturer une allocation une fois qu’une époque s’est écoulée (closeAllocation()⁠) ou son agent d’Indexeur clôturera automatiquement l’allocation après le maxAllocationEpochs (actuellement 28 jours). Lorsqu’une allocation est clôturée avec une preuve d’indexation (POI) valide, les récompenses d’indexation sont distribuées à l’Indexeur et à ses délégués (en savoir plus).

Indexers are recommended to utilize offchain syncing functionality to sync Subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for Subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.