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

Reading time: 6 min

Cette page explique comment déployer un subgraph sur plusieurs réseaux. Pour déployer un subgraph, vous devez premièrement installer le Graph CLI. Si vous n'avez pas encore créé de subgraph, consultez Creation d'un subgraph.

Dans certains cas, vous souhaiterez déployer le même subgraph sur plusieurs réseaux sans dupliquer tout son code. Le principal défi qui en découle est que les adresses contractuelles sur ces réseaux sont différentes.

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

Options:

      --network <nom>          Configuration du réseau à utiliser à partir du fichier de configuration des réseaux
      --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 de réseau à partir d'un fichier standard json (par défaut networks.json) pour facilement mettre à jour 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 :

{
    "network1": { // le nom du réseau
        "dataSource1": { // le nom de la source de données
            "address": "0xabc...", // l'adresse du contrat (facultatif)
            "startBlock": 123456 // le bloc de départ (facultatif)
        },
        "dataSource2": {
            "address": "0x123...",
            "startBlock": 123444
        }
    },
    "network2": {
        "dataSource1": {
            "address": "0x987...",
            "startBlock": 123
        },
        "dataSource2": {
            "address": "0xxyz..",
            "startBlock": 456
        }
    },
    ...
}

Supposons maintenant que vous souhaitiez déployer votre subgraph sur les réseaux mainnet et sepolia, et que ceci est votre fichier subgraph.yaml :

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    source:
      address: '0x123...'
      abi: Gravity
    mapping:
      kind: ethereum/events

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

{
  "mainnet": {
    "Gravity": {
      "address": "0x123..."
    }
  },
  "sepolia": {
    "Gravity": {
      "address": "0xabc..."
    }
  }
}

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

# En utilisant le fichier networks.json par défaut
yarn build --network sepolia

 # En utilisant un fichier personnalisé
yarn build --network sepolia --network-file chemin/à/configurer

La commande build mettra à jour votre fichier subgraph.yaml avec la configuration sepolia puis recompilera le subgraph. Votre fichier subgraph.yaml devrait maintenant ressembler à ceci:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: sepolia
    source:
      address: '0xabc...'
      abi: Gravity
    mapping:
      kind: ethereum/events

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

# En utilisant le fichier networks.json par défaut
yarn deploy --network sepolia

 # En utilisant un fichier personnalisé
yarn deploy --network sepolia --network-file chemin/à/configurer

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 (mainnet) et sur Sepolia en utilisant des adresses de contrat différentes. Vous pourriez alors définir deux fichiers de configuration fournissant les adresses pour chaque réseau :

{
  "network": "mainnet",
  "address": "0x123..."
}

et

{
  "network": "sepolia",
  "address": "0xabc..."
}

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:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    network: {{network}}
    source:
      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      address: '{{address}}'
      abi: Gravity
    mapping:
      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 :

{
  ...
  "scripts": {
    ...
    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
  },
  "devDependencies": {
    ...
    "mustache": "^3.1.0"
  }
}

Pour déployer ce subgraph pour mainnet ou Sepolia, vous devez simplement exécuter l'une des deux commandes suivantes :

# Mainnet:
yarn prepare:mainnet && yarn deploy

# Sepolia:
yarn 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.

Cela vous donnera le chainHeadBlock que vous pouvez comparer avec le latestBlock sur votre subgraph pour vérifier s'il est en retard. synced vous informe si le subgraph a déjà rattrapé la chaîne. health peut actuellement prendre les valeurs de healthy si aucune erreur ne s'est produite, ou failed s'il y a eu une erreur qui a stoppé la progression du subgraph. Dans ce cas, vous pouvez vérifier le champ fatalError pour les détails sur cette erreur.

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

De plus, 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 dispose d'une option de restauration de la version en question.

Si un subgraph se synchronise avec succès, c'est un bon signe qu'il continuera à bien fonctionner pour toujours. Cependant, de nouveaux déclencheurs sur le réseau peuvent amener votre subgraph à rencontrer une condition d'erreur non testée ou il peut commencer à prendre du retard en raison de problèmes de performances ou de 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 à l'adresse 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 cet endpoint peut être trouvé ici. Voici un exemple de requête qui vérifie l'état de la version actuelle d'un subgraph:

{
  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
    synced
    health
    fatalError {
      message
      block {
        number
        hash
      }
      handler
    }
    chains {
      chainHeadBlock {
        number
      }
      latestBlock {
        number
      }
    }
  }
}

Cela vous donnera le chainHeadBlock que vous pouvez comparer avec le latestBlock sur votre subgraph pour vérifier s'il est en retard. synced vous informe si le subgraph a déjà rattrapé la chaîne. health peut actuellement prendre les valeurs de healthy si aucune erreur ne s'est produite, ou failed s'il y a eu une erreur qui a stoppé la progression du subgraph. Dans ce cas, vous pouvez vérifier le champ fatalError pour les détails sur cette erreur.