Simulez avant d'envoyer : exécuter des transactions à blanc avec eth_simulateV1

Avant de diffuser des transactions sur un réseau blockchain, les exécuter à blanc permet aux développeurs d'inspecter les résultats d'exécution, de vérifier les transitions d'état des contrats et d'observer les logs d'événements à l'avance, évitant ainsi des frais de gas inutiles causés par des reverts de contrat.

La couche d'exécution d'Ethereum propose plusieurs méthodes pour évaluer les transactions avant leur envoi :

• eth_call : exécute un appel de message unique en lecture seule sans persistance d'état entre les appels successifs.
• eth_estimateGas : calcule la limite de gas requise pour l'exécution, mais ne fournit pas les transitions d'état séquentielles multi-transactions ni les logs d'événements complets.
• eth_simulateV1 : définie dans la spécification standard des API d'exécution d'Ethereum (Ethereum Execution APIs), cette méthode permet la simulation séquentielle de plusieurs transactions à travers les blocs, accumule les changements d'état entre les transactions et prend en charge le remplacement (override) des paramètres de bloc et de l'état des comptes.

Chaînes prises en charge et politique de méthodes

Les capacités des réseaux sont publiées dynamiquement via GET /v1/chains. Lisez methods.allow dans cette réponse pour voir quelles chaînes autorisent eth_simulateV1 ; une chaîne où cette méthode n'est pas répertoriée rejette l'appel avec l'erreur JSON-RPC -32601 (method not available, non facturée).

Conditions d'état du nœud

eth_simulateV1 est une méthode d'interrogation d'état :

• Verrou de synchronisation (-32010) : lorsque le nœud de la chaîne cible est en cours de synchronisation et n'est pas encore prêt, l'appel renvoie -32010 (node is syncing, non facturé).
• Fenêtre d'état (-32011) : sur Robinhood Chain, les requêtes ciblant des blocs plus anciens que le paramètre state_window_blocks de la chaîne (GET /v1/chains), ou spécifiant les balises de bloc safe, finalized ou earliest, renvoient -32011 (non facturé). La balise de bloc par défaut est latest.

Structure de la requête et exemple de base

Conformément à la spécification de la couche d'exécution (définition d'eth_simulateV1 dans les Ethereum Execution APIs), eth_simulateV1 accepte deux paramètres positionnels :

1. Objet de charge utile (payload) :
   • blockStateCalls (tableau obligatoire) : un tableau d'objets de blocs simulés. Chaque objet contient un tableau d'appels de transactions calls, des remplacements d'en-tête de bloc optionnels blockOverrides, et des remplacements d'état de compte optionnels stateOverrides.
   • validation (booléen optionnel, par défaut false) : lorsque défini sur false, se comporte comme eth_call ; sur true, exécute toutes les validations EVM à l'exception des vérifications de signature.
   • traceTransfers (booléen optionnel) : lorsque défini sur true, renvoie les logs d'événements pour les transferts de jetons natifs.
2. Balise de bloc (block tag) (chaîne optionnelle, par défaut 'latest') : numéro de bloc, hash de bloc ou balise de bloc.

Exemple de base : exécuter un transfert ERC-20 à blanc

L'exemple suivant exécute à blanc un appel ERC-20 transfer(address,uint256) sur Robinhood Chain. Remplacez $BLOCKVECTRA_API_KEY par votre véritable API key :

export BLOCKVECTRA_API_KEY=rgw_your_api_key

curl -s "https://api.blockvectra.com/v1/robinhood_mainnet" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $BLOCKVECTRA_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_simulateV1",
    "params": [
      {
        "blockStateCalls": [
          {
            "calls": [
              {
                "from": "0x1111111111111111111111111111111111111111",
                "to": "0x2222222222222222222222222222222222222222",
                "data": "0xa9059cbb00000000000000000000000033333333333333333333333333333333333333330000000000000000000000000000000000000000000000000de0b6b3a7640000",
                "value": "0x0"
              }
            ]
          }
        ]
      },
      "latest"
    ]
  }'

Inspection de la structure de réponse

Selon la spécification d'exécution d'Ethereum, le champ result contient un tableau de résultats de blocs simulés avec le schéma suivant :

Champs au niveau du bloc

• number : numéro de bloc du bloc simulé (chaîne hexadécimale).
• hash : hash du bloc simulé (chaîne hexadécimale de 32 octets).
• parentHash : hash du bloc parent.
• timestamp : horodatage du bloc (chaîne hexadécimale).
• gasLimit : limite de gas du bloc.
• gasUsed : gas total consommé par l'ensemble des appels simulés dans ce bloc.
• baseFeePerGas : frais de base par unité de gas (base fee per gas) pour le bloc.
• miner : adresse coinbase recevant les frais de bloc.
• calls : tableau des résultats d'exécution pour chaque appel simulé.

Champs au niveau de l'appel (éléments du tableau calls)

• status : statut de l'appel sous forme de chaîne hexadécimale. 0x1 indique un succès, tandis que 0x0 indique un échec ou un revert.
• gasUsed : gas réel consommé par cet appel (chaîne hexadécimale).
• maxUsedGas (optionnel) : pic de gas utilisé pendant l'exécution avant les remboursements.
• returnData : données de retour encodées en hexadécimal. Lors d'un transfert ERC-20 réussi, contient le booléen true ; en cas de revert, contient le sélecteur d'erreur ou les données de revert.
• logs : tableau des logs d'événements émis par l'appel. En cas de succès, contient des logs d'événements tels que Transfer :
  • address : adresse du contrat ayant émis l'événement.
  • topics : tableau de hashs de topic de 32 octets (topics[0] est le hash de signature de l'événement, comme la signature de l'événement Transfer).
  • data : données d'événement non indexées encodées en hexadécimal.
  • blockNumber, blockHash, transactionHash, transactionIndex, logIndex, removed.
• error (présent en cas d'échec) : objet contenant code (3 pour un revert, -32015 pour une erreur de VM) et message (comme execution reverted).

Tarification et pondérations en CU

BlockVectra mesure la consommation en Compute Units (CU). La pondération de chaque méthode JSON-RPC est publiée dynamiquement par GET /v1/plans :

Pour les formules de conversion d'unités et les modalités de recharge, visitez la page Tarifs.

Les requêtes rejetées — y compris nœud en cours de synchronisation (-32010), hors de la fenêtre d'état (-32011) ou méthode non disponible (-32601) — ne sont pas facturées. Consultez Quelles requêtes sont gratuites pour connaître l'intégralité des règles de facturation.

Utilisation avec les agents IA et MCP

Les agents IA autonomes peuvent invoquer eth_simulateV1 directement via le serveur Model Context Protocol (MCP) de BlockVectra.

L'outil avec clé rpc_call permet d'exécuter des méthodes JSON-RPC sur les chaînes prises en charge. L'API key doit être configurée dans les en-têtes HTTP du client MCP (x-api-key: {api_key} ou Authorization: Bearer {api_key}), et ne doit jamais être transmise dans les paramètres de l'outil ou les invites de conversation.

Exemple de charge utile d'invocation de l'outil rpc_call sur Robinhood Chain :

{
  "chain": "robinhood_mainnet",
  "method": "eth_simulateV1",
  "params": [
    {
      "blockStateCalls": [
        {
          "calls": [
            {
              "from": "0x1111111111111111111111111111111111111111",
              "to": "0x2222222222222222222222222222222222222222",
              "data": "0xa9059cbb00000000000000000000000033333333333333333333333333333333333333330000000000000000000000000000000000000000000000000de0b6b3a7640000",
              "value": "0x0"
            }
          ]
        }
      ]
    },
    "latest"
  ]
}

Les agents peuvent vérifier status === "0x1" pour valider l'interaction avec le contrat et évaluer la consommation de gas avant de soumettre des transactions brutes. Pour les instructions de configuration et d'utilisation, consultez le guide d'intégration des agents IA.

Étapes suivantes

• Consulter le forfait gratuit et les tarifs pour vérifier ce que comprend votre compte.
• Se connecter à la console pour créer une API key.