Симуляція перед відправленням: тестове виконання транзакцій за допомогою eth_simulateV1

Перед трансляцією транзакцій у блокчейн-мережу їхнє тестове виконання (dry-run) дозволяє розробникам заздалегідь перевірити результати виконання, верифікувати переходи стану контрактів та спостерігати логи подій, уникаючи зайвих витрат на газ через скасування (revert) контрактів.

Рівень виконання Ethereum надає кілька способів оцінки транзакцій перед їх відправленням:

• eth_call: виконує окремий виклик повідомлення лише для читання без збереження стану між послідовними викликами.
• eth_estimateGas: обчислює ліміт газу, необхідний для виконання, але не забезпечує послідовних переходів стану для кількох транзакцій або повних логів подій.
• eth_simulateV1: визначений у стандартній специфікації Ethereum Execution APIs, цей метод дозволяє послідовно симулювати кілька транзакцій між блоками, акумулює зміни стану між транзакціями та підтримує перевизначення параметрів блоку і стану акаунта.

Підтримувані мережі та політика методів

Можливості мереж публікуються динамічно через GET /v1/chains. Прочитайте methods.allow із цієї відповіді, щоб дізнатися, які мережі дозволяють eth_simulateV1; мережа, де його немає у списку, відхиляє виклик із помилкою JSON-RPC -32601 (method not available, не тарифікується).

Умови стану вузла

eth_simulateV1 є методом запиту стану:

• Шлюз синхронізації (-32010): коли вузол цільової мережі синхронізується і ще не готовий, виклик повертає -32010 (node is syncing, не тарифікується).
• Вікно стану (-32011): у Robinhood Chain запити, спрямовані на блоки, старіші за state_window_blocks мережі (GET /v1/chains), або з тегами блоків safe, finalized чи earliest, повертають -32011 (не тарифікується). Тег блоку за замовчуванням — latest.

Структура запиту та базовий приклад

Відповідно до специфікації рівня виконання (визначення eth_simulateV1 в Ethereum Execution APIs), eth_simulateV1 приймає два позиційні параметри:

1. Об'єкт корисного навантаження (payload):
   • blockStateCalls (обов'язковий масив): масив об'єктів симульованих блоків. Кожен об'єкт містить масив викликів транзакцій calls, необов'язкові перевизначення заголовка блоку blockOverrides та необов'язкові перевизначення стану акаунтів stateOverrides.
   • validation (необов'язковий булевий прапорець, за замовчуванням false): якщо false, поводиться подібно до eth_call; якщо true, запускає повну валідацію EVM, крім перевірки підписів.
   • traceTransfers (необов'язковий булевий прапорець): якщо true, повертає логи подій для переказів нативних токенів.
2. Тег блоку (необов'язковий рядок, за замовчуванням 'latest'): номер блоку, хеш блоку або тег блоку.

Базовий приклад: тестове виконання переказу ERC-20

Наведений нижче приклад виконує тестовий виклик ERC-20 transfer(address,uint256) у Robinhood Chain. Замініть $BLOCKVECTRA_API_KEY на ваш реальний 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"
    ]
  }'

Аналіз структури відповіді

Згідно зі специфікацією виконання Ethereum, поле result містить масив результатів симульованих блоків із такою схемою:

Поля рівня блоку

• number: номер симульованого блоку (шістнадцятковий рядок).
• hash: хеш симульованого блоку (32-байтний шістнадцятковий рядок).
• parentHash: хеш батьківського блоку.
• timestamp: часова мітка блоку (шістнадцятковий рядок).
• gasLimit: ліміт газу блоку.
• gasUsed: загальний обсяг газу, витрачений усіма симульованими викликами в цьому блоці.
• baseFeePerGas: базова комісія за одиницю газу для блоку.
• miner: адреса coinbase, яка отримує комісії блоку.
• calls: масив результатів виконання для кожного симульованого виклику.

Поля рівня виклику (елементи масиву calls)

• status: статус виклику у вигляді шістнадцяткового рядка. 0x1 вказує на успіх, тоді як 0x0 вказує на збій або revert.
• gasUsed: фактичний обсяг газу, витрачений цим викликом (шістнадцятковий рядок).
• maxUsedGas (необов'язково): піковий обсяг газу, використаний під час виконання до повернень.
• returnData: дані, що повертаються, у шістнадцятковому кодуванні. У разі успішного переказу ERC-20 містить булеве значення true; у разі revert містить селектор помилки або дані revert.
• logs: масив логів подій, згенерованих викликом. У разі успіху містить логи подій, такі як Transfer:
  • address: адреса контракту, що згенерував подію.
  • topics: масив 32-байтних хешів топіків (topics[0] — це хеш сигнатури події, такий як сигнатура події Transfer).
  • data: неіндексовані дані події у шістнадцятковому кодуванні.
  • blockNumber, blockHash, transactionHash, transactionIndex, logIndex, removed.
• error (присутнє в разі збою): об'єкт, що містить code (3 для revert, -32015 для помилки віртуальної машини VM) і message (наприклад, execution reverted).

Ціноутворення та ваги CU

BlockVectra вимірює споживання в Compute Units (CU). Вага для кожного методу JSON-RPC динамічно публікується через GET /v1/plans:

Формули конвертації одиниць та інформацію про поповнення балансу дивіться на сторінці Ціни.

Відхилені запити — включно із синхронізацією вузла (-32010), перебуванням за межами вікна стану (-32011) або недоступністю методу (-32601) — не тарифікуються. Повні правила білінгу дивіться у розділі Які запити є безкоштовними.

Використання з AI-агентами та MCP

Автономні AI-агенти можуть викликати eth_simulateV1 безпосередньо через сервер Model Context Protocol (MCP) від BlockVectra.

Автентифікований інструмент rpc_call дозволяє виконувати методи JSON-RPC у підтримуваних мережах. API key має бути налаштований в HTTP-заголовках MCP-клієнта (x-api-key: {api_key} або Authorization: Bearer {api_key}), і ніколи не повинен передаватися всередині параметрів інструмента чи підказок розмови.

Приклад корисного навантаження для виклику інструмента rpc_call у Robinhood Chain:

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

Агенти можуть перевіряти status === "0x1", щоб верифікувати коректність взаємодії з контрактом та оцінити споживання газу перед надсиланням необроблених транзакцій. Інструкції з налаштування та використання дивіться у посібнику з інтеграції AI-агентів.

Наступні кроки

• Перегляньте безкоштовний план і ціни, щоб дізнатися, що включено у ваш акаунт.
• Увійдіть до консолі, щоб створити API key.