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

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), 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:

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

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:

Consulta las fórmulas de conversión de unidades y los detalles de las recargas en la página de precios.

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

{
  "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.

Próximos pasos

• Consulta el Plan gratuito y los precios para comprobar qué incluye tu cuenta.
• Inicia sesión en la consola para crear una API key.