Back to Blog

AI and MCP / D04

Точная симуляция энергии: как MERX знает, сколько точно стоит своп

Проблема с угадыванием

Большинство инструментов и кошельков TRON используют жёсткие оценки энергии. Перевод USDT? Выделите 65 000 энергии. Своп на SunSwap? Может быть, 200 000. Одобрение? Примерно 50 000. Эти цифры хранятся как константы где-то в коде, и каждая транзакция использует их независимо от фактических условий.

Такой подход имеет два способа отказа, и оба стоят вам денег.

Если оценка слишком низкая, транзакция исчерпает энергию во время выполнения. Вся транзакция не срабатывает, но вы всё равно платите за пропускную способность, потреблённую попыткой. Энергия, которую вы купили, расходуется впустую на транзакцию, которая не дала результата. Вам нужно купить больше энергии и попробовать снова.

Если оценка слишком высокая, вы покупаете энергию, которую никогда не используете. Делегированная энергия имеет минимальный период аренды — обычно один час. Всё, что остаётся, когда делегирование истекает, просто теряется. Если вы перейдёте на 30% выше при каждой транзакции, то со временем и при тысячах транзакций, потери накапливаются в серьёзные деньги.

MERX полностью исключает угадывание. Каждая оценка энергии производится путём симуляции точной транзакции для текущего состояния блокчейна. Результат — это не приблизительное значение и не диапазон, а точное количество единиц энергии, которое потребит транзакция.

Как работает triggerConstantContract

Сеть TRON предоставляет конечную точку симуляции только для чтения под названием triggerConstantContract. Эта конечная точка выполняет вызов смарт-контракта в виртуальной среде, которая отражает текущее состояние блокчейна, но не изменяет его. Не транслируется никаких транзакций. Не потребляются никакие ресурсы. Никакие изменения состояния не фиксируются.

Симуляция выполняет точно такой же байт-код, который исполнялся бы в реальной транзакции. Она использует те же ячейки хранилища, те же остатки на счётах, ту же логику контракта. Единственное отличие в том, что результаты отбрасываются вместо того, чтобы быть записанными в блокчейн.

Ключевой результат — energy_used — точное количество единиц энергии, потреблённых смоделированным выполнением.

Вызов API

const result = await tronWeb.transactionBuilder.triggerConstantContract(
  contractAddress,       // Вызываемый контракт
  functionSelector,      // например, "transfer(address,uint256)"
  { callValue: 0 },     // Параметры, включая любое отправленное значение TRX
  [                      // Параметры функции
    { type: 'address', value: recipientAddress },
    { type: 'uint256', value: amount }
  ],
  senderAddress          // Адрес, с которого будет отправлена транзакция
);

const energyUsed = result.energy_used;

Это не эвристика оценки газа, как Ethereum eth_estimateGas, который возвращает верхний предел с запасом безопасности. triggerConstantContract возвращает точную энергию, потреблённую трассировкой выполнения. Когда MERX симулирует своп, который возвращает 223 354 энергии, выполнение на цепи потребит 223 354 энергии.

Почему адрес отправителя имеет значение

Тонкая, но критическая деталь: адрес отправителя влияет на результат симуляции.

Рассмотрим перевод USDT. Если отправитель никогда раньше не взаимодействовал с контрактом USDT, контракт должен выделить новую ячейку хранилища для баланса отправителя. Это выделение стоит энергию. Если у отправителя уже есть запись баланса, контракту нужно только обновить существующую ячейку — на тысячи единиц энергии дешевле.

Аналогично, адрес получателя имеет значение. Перевод USDT на адрес, который никогда не держал USDT, вызывает создание ячейки хранилища для получателя. Перевод на адрес, который уже имеет баланс USDT, не вызывает.

Эти различия могут сдвинуть стоимость энергии на 10 000–20 000 единиц для простого перевода. Для сложных операций DeFi с несколькими внутренними вызовами и изменениями хранилища дисперсия ещё больше.

Вот почему MERX симулирует с реальными адресами отправителя и получателя для каждой транзакции. Общая симуляция с заполнителями вернула бы другое значение энергии, чем фактическое выполнение.

Жёсткие оценки в сравнении с точной симуляцией

Вот конкретное сравнение с использованием реальных данных из основной сети TRON.

Сценарии передачи USDT

Data table
СценарийЖёсткая оценкаТочная симуляция
Отправитель имеет USDT, получатель имеет USDT65 00029 631
Отправитель имеет USDT, получатель никогда не держал USDT65 00064 895
Отправитель никогда не одобрял, получатель новый65 00064 895
Передача на адрес контракта65 00047 222

Жёсткий подход использует 65 000 для всех случаев. Точная симуляция выявляет диапазон в 2 раза в фактических затратах. В первом сценарии жёсткая оценка заставляет вас купить более чем в два раза больше энергии, чем фактически необходимо.

Своп SunSwap V2

Data table
СценарийЖёсткая оценкаТочная симуляция
TRX -> USDT, прямой пул200 000223 354
USDT -> TRX, прямой пул200 000218 847
Токен A -> Токен B, многоскачковый250 000312 668
Небольшая сумма, тот же пул200 000223 354

Для прямого свопа TRX -> USDT жёсткая оценка в 200 000 недооценивает на 23 354 единицы. Эта транзакция не сработает. Альтернатива — увеличить жёсткую оценку до 250 000 для безопасности — расходует 26 646 единиц энергии на каждый отдельный своп.

Как MERX использует точную симуляцию

Сервер MCP MERX предоставляет симуляцию через два инструмента, которые работают на разных уровнях абстракции.

Низкий уровень: estimate_contract_call

Этот инструмент позволяет вам симулировать любой произвольный вызов контракта:

Инструмент: estimate_contract_call
Входные данные: {
  "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
  "function_selector": "transfer(address,uint256)",
  "parameters": [
    { "type": "address", "value": "TRecipient..." },
    { "type": "uint256", "value": "100000000" }
  ],
  "from_address": "TSender...",
  "call_value": 0
}

Ответ:
{
  "energy_used": 64895,
  "result": "0x0000...0001",
  "success": true
}

Ответ включает как стоимость энергии, так и возвращаемое значение смоделированного вызова. Для перевода возвращаемое значение указывает, будет ли перевод успешным. Для свопа он возвращает выходное количество.

Высокий уровень: get_swap_quote

Для операций DEX MERX предоставляет специализированный инструмент, который объединяет симуляцию с котированием цен:

Инструмент: get_swap_quote
Входные данные: {
  "from_token": "TRX",
  "to_token": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
  "amount": "100000",
  "from_address": "TSender..."
}

Ответ:
{
  "output_amount": "0.032847",
  "output_token": "USDT",
  "energy_required": 223354,
  "price_impact": "0.001%",
  "route": ["WTRX", "USDT"],
  "minimum_received": "0.032519"
}

Поле energy_required происходит из точной симуляции свопа с реальными параметрами. output_amount также происходит из симуляции, так что котировка отражает фактический результат, который произведёт своп в текущем блоке.

Реальные данные: симуляция в сравнении с выполнением на цепи

Вот реальный своп, выполненный через сервер MERX MCP на основной сети TRON.

Транзакция: Своп 0.1 TRX на USDT через SunSwap V2

Симуляция до выполнения:

triggerConstantContract(
  contract: TKzxdSv2FZKQrEkFPRQi4qeCokAFkrntVM,  // SunSwap V2 Router
  function: swapExactETHForTokens(uint256,address[],address,uint256),
  parameters: [
    0,                                              // amountOutMin
    ["WTRX_address", "USDT_address"],              // path
    "TSender...",                                    // to
    1711814400                                       // deadline
  ],
  call_value: 100000,                               // 0.1 TRX в SUN
  from: "TSender..."
)

Результат:
  energy_used: 223,354
  return_value: [32847]  // 0.032847 USDT

Выполнение на цепи (после делегирования энергии):

Транзакция: abc123...
  Статус: SUCCESS
  Потреблено энергии: 223,354
  Потреблено пропускной способности: 420
  Результат: получено 0.032847 USDT

Симуляция вернула 223 354 энергии. Выполнение на цепи потребило 223 354 энергии. Точное совпадение. Не приблизительное значение. Не диапазон. То же самое число.

Граничные случаи и как MERX их обрабатывает

Изменения состояния между симуляцией и выполнением

Состояние блокчейна может измениться между временем симуляции и временем трансляции. Другая транзакция может изменить то же хранилище контракта, изменив стоимость энергии. MERX снижает риск тремя способами:

  1. Минимизация разрыва. Конвейер симулирует, покупает энергию, опрашивает делегирование и транслирует в самой плотной возможной последовательности. Типичный разрыв: 5–10 секунд.
  1. Добавление небольшого буфера для нестабильных операций. Для свопов DEX, где состояние пула ликвидности часто меняется, MERX добавляет 5% буфер к закупке энергии. Этот буфер покрывает незначительные вариации состояния без значительного увеличения затрат.
  1. Безопасный отказ. Если транзакция исчерпает энергию несмотря на буфер, она сбивается перед изменением состояния. Энергия потребляется, но никакие токены не передаются неправильно. Агент может повторить попытку с новой симуляцией.

Отменённые симуляции

Иногда triggerConstantContract возвращает отмену. Это означает, что транзакция не пройдёт на цепи. Распространённые причины:

MERX выводит эти отмены до того, как будет куплена любая энергия:

Ответ:
{
  "success": false,
  "revert_reason": "INSUFFICIENT_OUTPUT_AMOUNT",
  "energy_used": 0,
  "message": "Своп не сработает: результат ниже минимума. Отрегулируйте проскальзывание или сумму."
}

Это предотвращает самый дорогостоящий тип отказа: покупку энергии для транзакции, которой никогда не было суждено сработать.

Транзакции одобрения

Свопы токена TRC20 на SunSwap требуют транзакцию одобрения перед свопом. Это отдельный вызов контракта со своей собственной стоимостью энергии. MERX обнаруживает, когда одобрение необходимо, и симулирует обе транзакции:

Результаты симуляции:
  1. approve(router, MAX_UINT256): 46,312 энергии
  2. swapExactTokensForTokens(...): 223,354 энергии
  Итого: 269,666 энергии

Агент может затем купить энергию для обеих операций в одном порядке, избежав накладных расходов двух отдельных взаимодействий с энергетическим рынком.

Интеграция симуляции в ваш рабочий процесс

Если вы разрабатываете на TRON и не используете точную симуляцию, вы оставляете деньги на столе или подвергаете себя сбоям транзакций. Вот как это интегрировать:

Для разработчиков агентов MCP

Используйте сервер MERX MCP. Инструменты ensure_resources и execute_swap автоматически запускают симуляцию. Вам не нужно отдельно вызывать estimate_contract_call, если только вы не хотите проверить результаты.

Для интеграторов API

Вызывайте конечную точку оценки MERX перед каждой транзакцией:

curl -X POST https://merx.exchange/api/v1/estimate \
  -H "Content-Type: application/json" \
  -d '{
    "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
    "function_selector": "transfer(address,uint256)",
    "parameters": ["TRecipient...", 100000000],
    "from_address": "TSender...",
    "call_value": 0
  }'

Для прямых пользователей TronWeb

Вызывайте triggerConstantContract сами перед каждым взаимодействием со смарт-контрактом:

const simulation = await tronWeb.transactionBuilder.triggerConstantContract(
  contractAddress,
  functionSelector,
  options,
  parameters,
  senderAddress
);

if (!simulation.result.result) {
  console.error('Транзакция не сработает:', simulation.result.message);
  return;
}

const energyNeeded = simulation.energy_used;
// Теперь купите ровно столько энергии перед трансляцией

Экономика точности

Рассмотрим приложение, обрабатывающее 1 000 переводов USDT в день.

С жёсткими оценками (65 000 энергии за перевод):

Ежедневно купленная энергия: 65 000 000
Среднее фактическое использование: 47 000 000  (варьируется в зависимости от сценария)
Ежедневные потери: 18 000 000 энергии
Стоимость ежедневных потерь: ~94 TRX (~$24)
Годовые потери: ~$8 760

С точной симуляцией:

Ежедневно купленная энергия: 47 200 000  (фактическая + 0.4% округление)
Ежедневные потери: 200 000  (округление до минимальных единиц заказа)
Стоимость ежедневных потерь: ~1 TRX (~$0.26)
Годовые потери: ~$95

Разница составляет $8 665 в год для одного типа операции. Для приложений, которые запускают несколько типов транзакций при более высоких объёмах, экономия масштабируется линейно.

Заключение

Точная симуляция энергии — это не функция. Это требование для любого серьёзного приложения TRON. Разница между жёсткой оценкой и точной симуляцией — это разница между угадыванием и знанием. MERX выбирает знание.

Каждая транзакция смоделирована. Каждая единица энергии учтена. Каждый своп процитирован точно. Симуляция говорит 223 354, и цепь подтверждает 223 354.

Это не приблизительное значение. Это инженерия.


Ссылки:

Попробуйте сейчас с ИИ

Добавьте MERX в Claude Desktop или любого другого совместимого с MCP клиента — без установки, без API ключа для инструментов только для чтения:

{
  "mcpServers": {
    "merx": {
      "url": "https://merx.exchange/mcp/sse"
    }
  }
}

Попросите своего ИИ-агента: «Какова самая дешёвая энергия TRON прямо сейчас?» и получите живые цены от всех подключённых поставщиков.

Полная документация MCP: merx.exchange/docs/tools/mcp-server


All Articles