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

> Source: https://docs.blockvectra.com/fr/guides/simulate-transactions/

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](https://ethereum.github.io/execution-apis/api/methods/eth_simulateV1)), `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 :

**cURL**

```bash
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"
    ]
  }'
```


  **TypeScript (viem)**

```ts
import { createPublicClient, http } from "viem";

const apiKey = process.env.BLOCKVECTRA_API_KEY!;
const client = createPublicClient({
  transport: http(`https://api.blockvectra.com/v1/robinhood_mainnet/${apiKey}`),
});

// Appeler eth_simulateV1 directement via client.request de viem
const simulationResult = await client.request({
  method: "eth_simulateV1" as any,
  params: [
    {
      blockStateCalls: [
        {
          calls: [
            {
              from: "0x1111111111111111111111111111111111111111",
              to: "0x2222222222222222222222222222222222222222",
              data: "0xa9059cbb00000000000000000000000033333333333333333333333333333333333333330000000000000000000000000000000000000000000000000de0b6b3a7640000",
              value: "0x0",
            },
          ],
        },
      ],
    },
    "latest",
  ],
});

console.log(simulationResult);
```


### 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` :

**Poids en CU par appel**

| Méthode | CU par appel |
| --- | --- |
| `eth_simulateV1` | 20 |
| `eth_call` | 15 |
| `eth_estimateGas` | 20 |

Pour les formules de conversion d'unités et les modalités de recharge, visitez la [page Tarifs](https://blockvectra.com/fr/pricing/).

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](https://docs.blockvectra.com/fr/guides/billing-rules/) 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 :

```json
{
  "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](https://docs.blockvectra.com/fr/guides/ai-agents/).

## Étapes suivantes

* [Consulter le forfait gratuit et les tarifs](https://blockvectra.com/fr/pricing/#free) pour vérifier ce que comprend votre compte.
* [Se connecter à la console](https://console.blockvectra.com/login/?next=%2Fkeys%2F) pour créer une API key.