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
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.
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 . Vous pouvez également trouver une liste à jour des outils dans les canaux #Delegators et #Indexers sur le . Nous recommandons intégré à la pile logicielle de l'Indexeur.
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).
Le contrat RewardsManager a une fonction 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 :
query indexerAllocations {indexer(id: "<INDEXER_ADDRESS>") {allocations {activeForIndexer {allocations {id}}}}}
Utilisez Etherscan pour appeler getRewards()
:
- Appeller
getRewards()
:- Déroulez le menu 9. getRewards.
- 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]( -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 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é.
Installation | Postgres (CPUs) | Postgres (mémoire en Gbs) | Postgres (disque en TB) | VMs (CPUs) | VMs (mémoire en Gbs) |
---|---|---|---|---|---|
Petit | 4 | 8 | 1 | 4 | 16 |
Standard | 8 | 30 | 11 | 12 | 48 |
Moyen | 16 | 64 | 2 | 32 | 64 |
Large | 72 | 468 | 3.5 | 48 |
-
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 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'. 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 .
-
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.
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.
Port | Objectif | Routes | Argument CLI | Variable d'environnement |
---|---|---|---|---|
8000 | Serveur HTTP GraphQL (pour les requêtes de subgraphs) | /subgraphs/id/... /subgraphs/name/.../... | --http-port | - |
8001 | GraphQL WS (pour les abonnements aux subgraphs) | /subgraphs/id/... /subgraphs/name/.../... | --ws-port | - |
8020 | JSON-RPC (pour gérer les déploiements) | / | --admin-port | - |
8030 | API de statut d'indexation des subgraphs | /graphq | --index-node-port | - |
8040 | Métriques Prometheus | /metrics | --metrics-port | - |
Port | Objectif | Routes | Argument CLI | Variable d'environnement |
---|---|---|---|---|
7600 | Serveur HTTP GraphQL (pour les requêtes payantes de subgraphs) | /subgraphs/id/... /status /channel-messages-inbox | --port | INDEXER_SERVICE_PORT |
7300 | Métriques Prometheus | /metrics | --metrics-port | - |
Port | Objectif | Routes | Argument CLI | Variable d'environnement |
---|---|---|---|---|
8000 | API de gestion des indexeurs | / | --indexer-management-port | INDEXER_AGENT_INDEXER_MANAGEMENT_PORT |
Note : Les indexeurs peuvent alternativement utiliser AWS, Microsoft Azure ou Alibaba.
- Google Cloud SDK
- Outil de ligne de commande kubectl
- Terraform
-
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 loginproject=<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 $projectgcloud config set project "$proj_id"gcloud config set compute/region us-central1gcloud config set compute/zone us-central1-a
- Activez les API Google Cloud requises.
gcloud services enable compute.googleapis.comgcloud services enable container.googleapis.comgcloud services enable servicenetworking.googleapis.comgcloud 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 listsvc=$(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 <<EOFproject = "$proj_id"indexer = "$indexer"database_password = "<database passowrd>"EOF
Avant d'exécuter des commandes, lisez 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 Requisterraform init# Afficher le plan des ressources à créerterraform 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 $indexerkubectl 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éebases
dans$dir/kustomization.yaml
pour qu'il pointe vers le répertoirek8s/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
.
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.
-
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
- Démarrer un serveur de base de données PostgreSQL
initdb -D .postgrespg_ctl -D .postgres -l logfile startcreatedb graph-node
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 : 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
.
- Clonez Graph Node et accédez au répertoire Docker :
git clone https://github.com/graphprotocol/graph-nodecd graph-node/docker
- Pour les utilisateurs Linux uniquement - Utilisez l'adresse IP de l'hôte au lieu de
host.docker.internal
dans ledocker-compose.yaml
à l'aide du script inclus :
./setup.sh
- 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 ! N'oubliez pas de avant de démarrer vos composants Indexer !
npm install -g @graphprotocol/indexer-servicenpm install -g @graphprotocol/indexer-agent# Indexer CLI is a plugin for Graph CLI, so both need to be installed:npm install -g @graphprotocol/graph-clinpm install -g @graphprotocol/indexer-cli# Indexer servicegraph-indexer-service start ...# Indexer agentgraph-indexer-agent start ...# Indexer CLI#Forward the port of your agent pod if using Kuberneteskubectl port-forward pod/POD_ID 18000:8000graph indexer connect http://localhost:18000/graph indexer ...
# From Repo root directoryyarn# Indexer Servicecd packages/indexer-service./bin/graph-indexer-service start ...# Indexer agentcd packages/indexer-agent./bin/graph-indexer-service start ...# Indexer CLIcd 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:latestdocker pull ghcr.io/graphprotocol/indexer-agent:latest
Ou créez des images localement à partir de la source
# Indexer servicedocker build \--build-arg NPM_TOKEN=<npm-token> \-f Dockerfile.indexer-service \-t indexer-service:latest \# Indexer agentdocker 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 and the Indexer agent should be exposing the Indexer management API at .
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
).
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
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 accessible dans le terminal à graph indexer
.
graph indexer connect http://localhost:18000graph 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 utilisantall
comme<deployment-id>
pour obtenir toutes les règles, ouglobal
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 sadecisionBasis
surtoujours
, 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 sadecisionBasis
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 ledecisionBasis
pour un déploiement surrules
, 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 utilisantall
ou laissezaction-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
.
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: stringidentifierType: IdentifierTypedecisionBasis: IndexingDecisionBasis!allocationAmount: number | nullallocationLifetime: number | nullautoRenewal: booleanparallelAllocations: number | nullmaxAllocationPercentage: number | nullminSignal: string | nullmaxSignal: string | nullminStake: string | nullminAverageQueryFees: string | nullcustom: string | nullrequireSupported: boolean | null}IdentifierType {deploymentsubgraphgroup}IndexingDecisionBasis {rulesneveralwaysoffchain}
Exemple d'utilisation de la règle d'indexation :
graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEKgraph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported falsegraph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEKgraph 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 sursuccè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: ActionStatustype: ActionTypedeploymentID: string | nullallocationID: string | nullamount: string | nullpoi: string | nullforce: boolean | nullsource: stringreason: string | nullpriority: number | null}ActionStatus {queuedapprovedpendingsuccessfailedcanceled}ActionType {allocateunallocatereallocatecollect}
Exemple d'utilisation à partir de la source :
graph indexer actions get allgraph indexer actions get --status queuedgraph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2aegraph indexer actions cancelgraph indexer actions approve 1 3 5graph 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
- paramètres d'action requis :
-
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)
- paramètres d'action requis :
-
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)
- paramètres d'action requis :
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 globalquery { 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ûtdefault => 0.1 * $SYSTEM_LOAD;
Exemple de calcul des coûts de requête utilisant le modèle ci-dessus :
Query | Price |
---|---|
{ pairs(skip: 5000) { id } } | 0.5 GRT |
{ tokens { symbol } } | 0.1 GRT |
{ pairs(skip: 5000) { id } tokens { symbol } } | 0.6 GRT |
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
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 (, , et sont quelques autres outils connus).
Une fois qu'un indexeur a staké des GRT dans le protocole, les peuvent être démarrés et commencer leurs interactions avec le réseau.
Dans
File Explorer
, créez un fichier nommé GraphToken.abi avec l'.Avec
GraphToken.abi
sélectionné et ouvert dans l'éditeur, passez à la sectionDéployer et exécuter des transactions
dans l’interface de Remix.Sous Environnement, sélectionnez
Injected Web3
et sousCompte
sélectionnez votre adresse d'indexeur.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.Appelez la fonction
approve(spender, montant)
pour approuver le contrat de Staking. Remplissezspender
avec l'adresse du contrat de Staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9
) etmontant
avec les jetons à miser (en wei).
Dans l'
Explorateur de fichiers
, créez un fichier nommé Staking.abi avec l'ABI de staking.Avec
Staking.abi
sélectionné et ouvert dans l'éditeur, passez à la sectionDéployer et exécuter des transactions
dans l’interface de Remix.Sous Environnement, sélectionnez
Injected Web3
et sousCompte
sélectionnez votre adresse d'indexeur.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.Appelez
stake()
pour implanter GRT dans le protocole.(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.(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éfinitthecooldownBlocks
. période à 500 blocs.
setDelegationParameters(950000, 600000, 500)
La fonction setDelegationParameters()
dans le 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.
Pour définir les paramètres de délégation à l'aide de l'interface Graph Explorer, suivez ces étapes :
- Naviguez vers .
- Connectez votre portefeuille. Choisissez multisig (comme Gnosis Safe) puis sélectionnez mainnet. Note : Vous devrez répéter ce processus pour Arbitrum One.
- Connectez le portefeuille que vous avez en tant que signataire.
- 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é.
- Soumettez la transaction au réseau.
Note : Cette transaction devra être confirmée par les signataires du portefeuille multisig.
After being created by an Indexer a healthy allocation goes through two states.
-
Active - Une fois qu'une allocation est créée on-chain () 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 () 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 ().
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.
Comment sont distribuées les récompenses d’indexation ?
#Lien vers cette section