Déploiement d'un subgraph sur plusieurs réseaux

Cette page explique comment déployer un subgraph sur plusieurs réseaux. Pour déployer un subgraph, vous devez d’abord installer Graph CLI⁠. Si vous n’avez pas encore créé de subgraph, consultez Créer un subgraph.

Déployer le Subgraph sur plusieurs réseaux

Dans certains cas, vous souhaiterez déployer le même Subgraph sur plusieurs réseaux sans dupliquer l’ensemble de son code. La principale difficulté réside dans le fait que les adresses contractuelles de ces réseaux sont différentes.

En utilisant graph-cli

Les commandes graph build (depuis la version v0.29.0) et graph deploy (depuis la version v0.32.0) acceptent deux nouvelles options:

1Options:23      --network <nom>          Configuration du réseau à utiliser à partir du fichier de configuration des réseaux4      --network-file <chemin>  Chemin du fichier de configuration des réseaux (par défaut : "./networks.json")

Vous pouvez utiliser l’option --network pour spécifier une configuration réseau à partir d’un fichier standard json (par défaut networks.json) pour mettre à jour facilement votre Subgraph pendant le développement.

Si vous n’avez pas de fichier networks.json, vous devrez en créer un manuellement avec la structure suivante :

1{2    "network1": { // le nom du réseau3        "dataSource1": { // le nom de la source de données4            "address": "0xabc...", // l'adresse du contrat (facultatif)5            "startBlock": 123456 // le bloc de départ (facultatif)6        },7        "dataSource2": {8            "address": "0x123...",9            "startBlock": 12344410        }11    },12    "network2": {13        "dataSource1": {14            "address": "0x987...",15            "startBlock": 12316        },17        "dataSource2": {18            "address": "0xxyz..",19            "startBlock": 45620        }21    },22    ...23}

Maintenant, supposons que vous vouliez être capable de déployer votre Subgraph sur les réseaux mainnet et sepolia, et voici votre subgraph.yaml :

1# ...2dataSources:3  - kind: ethereum/contract4    name: Gravity5    network: mainnet6    source:7      address: '0x123...'8      abi: Gravity9    mapping:10      kind: ethereum/events

Voici à quoi devrait ressembler votre fichier de configuration réseau :

1{2  "mainnet": {3    "Gravity": {4      "address": "0x123..."5    }6  },7  "sepolia": {8    "Gravity": {9      "address": "0xabc..."10    }11  }12}

Nous pouvons maintenant exécuter l’une des commandes suivantes :

1# En utilisant le fichier networks.json par défaut2yarn build --network sepolia34 # En utilisant un fichier personnalisé5yarn build --network sepolia --network-file chemin/à/configurer

La commande build va mettre à jour votre subgraph.yaml avec la configuration sepolia et ensuite recompiler le Subgraph. Votre fichier subgraph.yaml devrait maintenant ressembler à ceci :

1# ...2dataSources:3  - kind: ethereum/contract4    name: Gravity5    network: sepolia6    source:7      address: '0xabc...'8      abi: Gravity9    mapping:10      kind: ethereum/events

Vous êtes maintenant prêt à utiliser la commande yarn deploy.

1# En utilisant le fichier networks.json par défaut2yarn deploy --network sepolia34 # En utilisant un fichier personnalisé5yarn deploy --network sepolia --network-file chemin/à/configurer

Utilisation du modèle subgraph.yaml

Une façon de paramétrer des aspects tels que les adresses de contrat en utilisant des versions plus anciennes de graph-cli est de générer des parties de celui-ci avec un système de creation de modèle comme Mustache⁠ ou Handlebars⁠.

Pour illustrer cette approche, supposons qu’un Subgraph doive être déployé sur le réseau principal et sur Sepolia en utilisant des adresses contractuelles différentes. Vous pourriez alors définir deux fichiers de configuration fournissant les adresses pour chaque réseau :

1{2  "network": "mainnet",3  "address": "0x123..."4}

et

1{2  "network": "sepolia",3  "address": "0xabc..."4}

Avec ceci, vous remplacerez le nom du réseau et les adresses dans le manifeste par des variables de type {{network}} et {{address}} et renommer le manifeste par exemple subgraph.template.yaml:

1# ...2dataSources:3  - kind: ethereum/contract4    name: Gravity5    network: mainnet6    network: {{network}}7    source:8      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'9      address: '{{address}}'10      abi: Gravity11    mapping:12      kind: ethereum/events

Pour générer un manifeste pour l’un ou l’autre réseau, vous pourriez ajouter deux commandes supplémentaires au fichier package.json ainsi qu’une dépendance à mustache :

1{2  ...3  "scripts": {4    ...5    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",6    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"7  },8  "devDependencies": {9    ...10    "mustache": "^3.1.0"11  }12}

Pour déployer ce Subgraph sur le Mainnet ou Sepolia, il vous suffit de lancer l’une des deux commandes suivantes :

1# Mainnet:2yarn prepare:mainnet && yarn deploy34# Sepolia:5yarn prepare:sepolia && yarn deploy

Un exemple fonctionnel de ceci peut être trouvé ici⁠.

Note : Cette approche peut également être appliquée à des situations plus complexes, dans lesquelles il est nécessaire de remplacer plus que les adresses des contrats et les noms de réseau ou où il est nécessaire de générer des mappages ou alors des ABI à partir de modèles également.

This will give you the chainHeadBlock which you can compare with the latestBlock on your Subgraph to check if it is running behind. synced informs if the Subgraph has ever caught up to the chain. health can currently take the values of healthy if no errors occurred, or failed if there was an error which halted the progress of the Subgraph. In this case, you can check the fatalError field for details on this error.

Subgraph Studio Politique d’archivage de Subgraph

Une version de Subgraph dans Studio est archivée si et seulement si elle répond aux critères suivants :

• La version n’est pas publiée sur le réseau (ou en attente de publication)
• La version a été créée il y a 45 jours ou plus
• Le Subgraph n’a pas été interrogé depuis 30 jours

En outre, lorsqu’une nouvelle version est déployée, si le Subgraph n’a pas été publié, la version N-2 du Subgraph est archivée.

Chaque Subgraph concerné par cette politique a la possibilité de rétablir la version en question.

Vérification de la santé du Subgraphs

Si un Subgraph se synchronise avec succès, c’est le signe qu’il continuera à fonctionner correctement pour toujours. Toutefois, de nouveaux déclencheurs sur le réseau peuvent entraîner une condition d’erreur non testée dans votre Subgraph ou un retard dû à des problèmes de performance ou à des problèmes avec les opérateurs de nœuds.

Graph Node expose un endpoint GraphQL que vous pouvez interroger pour vérifier l’état de votre subgraph. Sur le service hébergé, il est disponible à https://api.thegraph.com/index-node/graphql. Sur un nœud local, il est disponible sur le port 8030/graphql par défaut. Le schéma complet de ce point d’accès peut être trouvé ici⁠. Voici un exemple de requête qui vérifie le statut de la version actuelle d’un subgraph :

1{2  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {3    synced4    health5    fatalError {6      message7      block {8        number9        hash10      }11      handler12    }13    chains {14      chainHeadBlock {15        number16      }17      latestBlock {18        number19      }20    }21  }22}

This will give you the chainHeadBlock which you can compare with the latestBlock on your Subgraph to check if it is running behind. synced informs if the Subgraph has ever caught up to the chain. health can currently take the values of healthy if no errors occurred, or failed if there was an error which halted the progress of the Subgraph. In this case, you can check the fatalError field for details on this error.