Точная симуляция энергии: как 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
| Сценарий | Жёсткая оценка | Точная симуляция |
|---|---|---|
| Отправитель имеет USDT, получатель имеет USDT | 65 000 | 29 631 |
| Отправитель имеет USDT, получатель никогда не держал USDT | 65 000 | 64 895 |
| Отправитель никогда не одобрял, получатель новый | 65 000 | 64 895 |
| Передача на адрес контракта | 65 000 | 47 222 |
Жёсткий подход использует 65 000 для всех случаев. Точная симуляция выявляет диапазон в 2 раза в фактических затратах. В первом сценарии жёсткая оценка заставляет вас купить более чем в два раза больше энергии, чем фактически необходимо.
Своп SunSwap V2
| Сценарий | Жёсткая оценка | Точная симуляция |
|---|---|---|
| TRX -> USDT, прямой пул | 200 000 | 223 354 |
| USDT -> TRX, прямой пул | 200 000 | 218 847 |
| Токен A -> Токен B, многоскачковый | 250 000 | 312 668 |
| Небольшая сумма, тот же пул | 200 000 | 223 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 снижает риск тремя способами:
- Минимизация разрыва. Конвейер симулирует, покупает энергию, опрашивает делегирование и транслирует в самой плотной возможной последовательности. Типичный разрыв: 5–10 секунд.
- Добавление небольшого буфера для нестабильных операций. Для свопов DEX, где состояние пула ликвидности часто меняется, MERX добавляет 5% буфер к закупке энергии. Этот буфер покрывает незначительные вариации состояния без значительного увеличения затрат.
- Безопасный отказ. Если транзакция исчерпает энергию несмотря на буфер, она сбивается перед изменением состояния. Энергия потребляется, но никакие токены не передаются неправильно. Агент может повторить попытку с новой симуляцией.
Отменённые симуляции
Иногда 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: https://merx.exchange
- Сервер MCP (GitHub): https://github.com/Hovsteder/merx-mcp
- Сервер MCP (npm): https://www.npmjs.com/package/merx-mcp
Попробуйте сейчас с ИИ
Добавьте MERX в Claude Desktop или любого другого совместимого с MCP клиента — без установки, без API ключа для инструментов только для чтения:
{
"mcpServers": {
"merx": {
"url": "https://merx.exchange/mcp/sse"
}
}
}
Попросите своего ИИ-агента: «Какова самая дешёвая энергия TRON прямо сейчас?» и получите живые цены от всех подключённых поставщиков.
Полная документация MCP: merx.exchange/docs/tools/mcp-server