# Simula antes de enviar: simulación de transacciones con eth_simulateV1

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

Antes de transmitir transacciones a una red blockchain, simularlas permite a los desarrolladores inspeccionar los resultados de ejecución, verificar las transiciones de estado de los contratos y observar los logs de eventos con antelación, evitando costos de gas innecesarios causados por reversiones de contratos.

La capa de ejecución de Ethereum ofrece varias formas de evaluar las transacciones antes de enviarlas:

* `eth_call`: Ejecuta una sola llamada de mensaje de solo lectura sin conservar el estado entre llamadas sucesivas.
* `eth_estimateGas`: Calcula el límite de gas necesario para la ejecución, pero no proporciona transiciones de estado secuenciales entre varias transacciones ni logs de eventos completos.
* `eth_simulateV1`: Definido en la especificación estándar Ethereum Execution APIs, este método permite simular secuencialmente varias transacciones entre bloques, acumula los cambios de estado entre transacciones y admite la sobrescritura de parámetros de bloque y del estado de las cuentas.

## Cadenas compatibles y política de métodos

Las capacidades de la red se publican dinámicamente mediante `GET /v1/chains`. Lee `methods.allow` en esa respuesta para saber qué cadenas permiten `eth_simulateV1`; una cadena que no lo incluya rechaza la llamada con el error JSON-RPC `-32601` (`method not available`, sin facturación).

### Condiciones del estado del nodo

`eth_simulateV1` es un método de consulta de estado:

* **Control de sincronización (`-32010`)**: Cuando el nodo de la cadena de destino se está sincronizando y aún no está listo, la llamada devuelve `-32010` (`node is syncing`, sin facturación).
* **Ventana de estado (`-32011`)**: En Robinhood Chain, las solicitudes dirigidas a bloques anteriores a la ventana `state_window_blocks` de la cadena (`GET /v1/chains`), o que especifiquen las etiquetas de bloque `safe`, `finalized` o `earliest`, devuelven `-32011` (sin facturación). La etiqueta de bloque predeterminada es `latest`.

## Estructura de la solicitud y ejemplo básico

Según la especificación de la capa de ejecución ([definición de eth\_simulateV1 en Ethereum Execution APIs](https://ethereum.github.io/execution-apis/api/methods/eth_simulateV1)), `eth_simulateV1` acepta dos parámetros posicionales:

1. **Objeto de parámetros**:
   * `blockStateCalls` (matriz obligatoria): Una matriz de objetos de bloques simulados. Cada objeto contiene una matriz de llamadas de transacción `calls`, sobrescrituras opcionales de cabeceras de bloque `blockOverrides` y sobrescrituras opcionales del estado de las cuentas `stateOverrides`.
   * `validation` (booleano opcional, predeterminado `false`): Cuando es `false`, se comporta como `eth_call`; cuando es `true`, realiza todas las validaciones de la EVM excepto las comprobaciones de firmas.
   * `traceTransfers` (booleano opcional): Cuando es `true`, devuelve logs de eventos de transferencias del token nativo.
2. **Etiqueta de bloque** (cadena opcional, predeterminada `'latest'`): Número de bloque, hash de bloque o etiqueta de bloque.

### Ejemplo básico: simular una transferencia ERC-20

El siguiente ejemplo simula una llamada ERC-20 `transfer(address,uint256)` en Robinhood Chain. Sustituye `$BLOCKVECTRA_API_KEY` por tu API key real:

**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}`),
});

// Call eth_simulateV1 directly via viem's client.request
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);
```


### Inspección de la estructura de la respuesta

Según la especificación de ejecución de Ethereum, el campo `result` contiene una matriz de resultados de bloques simulados con el siguiente esquema:

#### Campos de bloque

* `number`: Número del bloque simulado (cadena hexadecimal).
* `hash`: Hash del bloque simulado (cadena hexadecimal de 32 bytes).
* `parentHash`: Hash del bloque padre.
* `timestamp`: Marca de tiempo del bloque (cadena hexadecimal).
* `gasLimit`: Límite de gas del bloque.
* `gasUsed`: Gas total consumido por todas las llamadas simuladas en este bloque.
* `baseFeePerGas`: Tarifa base por unidad de gas del bloque.
* `miner`: Dirección coinbase que recibe las tarifas del bloque.
* `calls`: Matriz de resultados de ejecución de cada llamada simulada.

#### Campos de llamada (elementos de la matriz `calls`)

* `status`: Estado de la llamada como cadena hexadecimal. `0x1` indica éxito, mientras que `0x0` indica fallo o reversión.
* `gasUsed`: Gas real consumido por esta llamada (cadena hexadecimal).
* `maxUsedGas` (opcional): Máximo gas utilizado durante la ejecución antes de los reembolsos.
* `returnData`: Datos devueltos con codificación hexadecimal. En una transferencia ERC-20 correcta, contiene el booleano `true`; en una reversión, contiene el selector del error o los datos de reversión.
* `logs`: Matriz de logs de eventos emitidos por la llamada. En caso de éxito, contiene logs de eventos como `Transfer`:
  * `address`: Dirección del contrato que emitió el evento.
  * `topics`: Matriz de hashes de temas de 32 bytes (`topics[0]` es el hash de la firma del evento, como la firma del evento `Transfer`).
  * `data`: Datos de evento no indexados con codificación hexadecimal.
  * `blockNumber`, `blockHash`, `transactionHash`, `transactionIndex`, `logIndex`, `removed`.
* `error` (presente en caso de fallo): Objeto que contiene `code` (`3` para una reversión, `-32015` para un error de la VM) y `message` (como `execution reverted`).

## Precios y pesos de CU

BlockVectra mide el consumo en Compute Units (CU). El peso de cada método JSON-RPC se publica dinámicamente mediante `GET /v1/plans`:

**Peso en CU por llamada**

| Método | CU por llamada |
| --- | --- |
| `eth_simulateV1` | 20 |
| `eth_call` | 15 |
| `eth_estimateGas` | 20 |

Consulta las fórmulas de conversión de unidades y los detalles de las recargas en la [página de precios](https://blockvectra.com/es/pricing/).

Las solicitudes rechazadas —incluidas las debidas a sincronización del nodo (`-32010`), a quedar fuera de la ventana de estado (`-32011`) o a un método no disponible (`-32601`)— no se facturan. Consulta [qué solicitudes son gratuitas](https://docs.blockvectra.com/en/guides/billing-rules/) para ver las reglas de facturación completas.

## Uso con agentes de IA y MCP

Los agentes de IA autónomos pueden invocar `eth_simulateV1` directamente mediante el servidor Model Context Protocol (MCP) de BlockVectra.

La herramienta `rpc_call` con API key permite ejecutar métodos JSON-RPC en las cadenas compatibles. La API key debe configurarse en las cabeceras HTTP del cliente MCP (`x-api-key: {api_key}` o `Authorization: Bearer {api_key}`), y nunca enviarse dentro de los parámetros de la herramienta ni en mensajes de conversación.

Ejemplo de parámetros de invocación de la herramienta `rpc_call` en Robinhood Chain:

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

Los agentes pueden comprobar `status === "0x1"` para verificar la validez de la interacción con el contrato y evaluar el consumo de gas antes de enviar transacciones en bruto. Consulta las instrucciones de configuración y uso en la [guía de integración de agentes de IA](https://docs.blockvectra.com/es/guides/ai-agents/).

## Próximos pasos

* [Consulta el Plan gratuito y los precios](https://blockvectra.com/es/pricing/#free) para comprobar qué incluye tu cuenta.
* [Inicia sesión en la consola](https://console.blockvectra.com/login/?next=%2Fkeys%2F) para crear una API key.