Back to Blog

AI and MCP / D03

Осведомлённые о ресурсах транзакции: Как MERX автоматически оптимизирует каждую TX

Скрытая стоимость игнорирования ресурсов TRON

Каждая транзакция в сети TRON потребляет два типа ресурсов: energy и bandwidth. Energy питает выполнение смарт-контрактов - каждый опкод, каждая запись в хранилище, каждый перевод токена. Bandwidth охватывает сырые байты самой транзакции. Когда у вас нет этих ресурсов в делегировании или стейкинге, сеть сжигает ваш TRX для покрытия стоимости.

Для простого перевода USDT, это сжигание может достичь 27 TRX - примерно $7 по текущим ценам. Для свопа на DEX это может превысить 50 TRX. Большинство кошельков и SDK просто позволяют этому происходить. Они транслируют транзакцию, сеть сжигает ваш TRX, и вы платите максимально возможную комиссию, даже не узнав, что была более дешёвая опция.

MERX придерживается принципиально иного подхода. Каждая транзакция, проходящая через MCP-сервер MERX, проходит через конвейер, осведомлённый о ресурсах, который оценивает затраты, проверяет существующие ресурсы, покупает только дефицит, ожидает делегирования, и только потом подписывает и транслирует. Результатом является последовательная экономия 80-90% на каждой транзакции.

Эта статья объясняет точно, как работает этот конвейер.

Конвейер транзакций, осведомлённых о ресурсах

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

Этап 1: Оцените Energy и Bandwidth

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

Для передачи USDT в размере 100 USDT с адреса A на адрес B:

Tool: estimate_transaction_cost
Input: {
  "from": "TAddressA...",
  "to": "TAddressB...",
  "contract": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
  "function": "transfer(address,uint256)",
  "parameters": ["TAddressB...", 100000000],
  "value": 0
}

Response:
{
  "energy_required": 64895,
  "bandwidth_required": 345,
  "cost_without_resources": 27.12,
  "cost_with_resources": 3.42
}

Симуляция запускается против живого состояния блокчейна. Если получатель никогда раньше не владел USDT, затраты на energy будут выше (потому что контракту нужно создать новый слот хранилища). Если allowance отправителя требует обновления, это добавляет energy. Каждая переменная учитывается.

Для торговли SunSwap симуляция захватывает точную маршрутизацию, расчёт slippage и состояние пула ликвидности:

Simulation result for SunSwap V2:
- Energy required: 223,354
- Bandwidth required: 420
- Router path: TRX -> USDT via pool 0x...

Эта точность критична. Переоценка напрасно растрачивает деньги на неиспользованную energy. Недооценка вызывает отказ транзакции, и вы теряете как стоимость покупки energy, так и bandwidth неудачной транзакции.

Этап 2: Проверьте текущие ресурсы

Адрес агента может уже иметь некоторые ресурсы от предыдущих делегирований, стейкинга или дневного бесплатного allowance bandwidth. MERX проверяет, что уже доступно:

Tool: check_address_resources
Input: { "address": "TAddressA..." }

Response:
{
  "energy": {
    "available": 12000,
    "total": 12000,
    "used": 0
  },
  "bandwidth": {
    "available": 1400,
    "total": 1500,
    "used": 100,
    "free_available": 1400,
    "free_total": 1500
  }
}

В этом примере адрес имеет 12 000 доступной energy и 1 400 bandwidth из дневного бесплатного allowance.

Этап 3: Рассчитайте дефицит

MERX вычитает доступные ресурсы из требуемых ресурсов, чтобы определить точно, что нужно купить:

Energy needed:     64,895
Energy available:  12,000
Energy deficit:    52,895
-> Rounded up to:  65,000 (minimum order unit)

Bandwidth needed:    345
Bandwidth available: 1,400
Bandwidth deficit:     0 (sufficient)

Здесь применяются два важных правила:

Минимум energy: 65 000 единиц. Рынок делегирования energy TRON работает с минимальными блоками примерно в 65 000 energy. Если дефицит меньше 65 000, MERX округляет до 65 000. Если дефицит равен 0 (адрес уже имеет достаточно energy), покупка не совершается.

Порог bandwidth: 1 500 единиц. Если дефицит bandwidth меньше 1 500, MERX полностью пропускает покупку bandwidth. Каждый адрес TRON получает 1 500 бесплатного bandwidth в день, который непрерывно восстанавливается. Для большинства одиночных транзакций бесплатное allowance достаточно. Покупка bandwidth имеет смысл только для высокочастотных операций, которые исчерпывают дневное allowance.

Этап 4: Купите дефицит

С точно рассчитанным дефицитом MERX запрашивает все доступные поставщики energy для получения лучшей цены:

Tool: get_best_price
Input: {
  "energy_amount": 65000,
  "duration_hours": 1
}

Response:
{
  "best_price": 3.42,
  "provider": "sohu",
  "all_prices": [
    { "provider": "sohu", "price": 3.42 },
    { "provider": "catfee", "price": 3.51 },
    { "provider": "netts", "price": 3.65 },
    { "provider": "tronsave", "price": 3.78 }
  ]
}

MERX размещает заказ у самого дешёвого поставщика:

Tool: create_order
Input: {
  "energy_amount": 65000,
  "duration_hours": 1,
  "target_address": "TAddressA..."
}

Заказ размещается, и поставщик начинает процесс делегирования.

Этап 5: Опрашивайте до прихода делегирования

Это этап, который неправильно реализуют большинство реализаций. Делегирование energy на TRON не является мгновенным. После того как поставщик трансляирует транзакцию делегирования, она должна быть подтверждена сетью. Это обычно занимает 3-6 секунд, но может занять больше времени во время перегрузки сети.

MERX опрашивает баланс ресурсов целевого адреса с регулярными интервалами:

Polling cycle:
  t+0s:  check_address_resources -> energy: 12,000 (not yet)
  t+3s:  check_address_resources -> energy: 12,000 (not yet)
  t+6s:  check_address_resources -> energy: 77,000 (delegation arrived)
  -> Proceed to Stage 6

Опрос использует экспоненциальный backoff, начиная с 3 секунд, с максимальным ожиданием 60 секунд перед timeout. Если делегирование не прибывает в пределах временного окна, конвейер сообщает об ошибке, а не транслирует транзакцию, которая будет сжигать TRX.

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

Этап 6: Подпишите локально и трансляируйте

Только после подтверждения, что делегированная energy доступна в цепи, MERX подписывает и транслирует фактическую транзакцию:

1. Build transaction object with TronWeb
2. Sign with local private key (never leaves the machine)
3. Broadcast to TRON network
4. Return transaction hash

Транзакция теперь выполняется с использованием делегированной energy, потребляя примерно 65 000 единиц energy вместо сжигания 27 TRX.

Инструмент ensure_resources: конвейер в одном вызове

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

Tool: ensure_resources
Input: {
  "address": "TAddressA...",
  "energy_needed": 65000,
  "bandwidth_needed": 345
}

Этот единственный вызов инструмента внутренне выполняет этапы 2-5. Он проверяет текущие ресурсы, рассчитывает дефицит, находит лучшую цену, размещает заказ и опрашивает до прихода делегирования. Агент получает ответ только когда адрес полностью обеспечен и готов к транзакции.

Реальный пример: торговля SunSwap

Вот полный конвейер для реальной торговли SunSwap V2 - своп 0.1 TRX на USDT.

Этап 1 - Симуляция:

triggerConstantContract(
  contract: SunSwapV2Router,
  function: swapExactETHForTokens,
  parameters: [0, [WTRX, USDT], address, deadline],
  call_value: 100000  // 0.1 TRX in SUN
)

Result: energy_estimate = 223,354

Этап 2 - Проверьте ресурсы:

Address resources:
  Energy: 0
  Bandwidth: 1,420 (free)

Этап 3 - Рассчитайте дефицит:

Energy deficit: 223,354
-> Rounded to nearest order unit: 225,000
Bandwidth deficit: 0 (free allocation covers 345 needed)

Этап 4 - Купите:

Best price for 225,000 energy / 1 hour:
  Provider: catfee
  Price: 11.82 TRX

Этап 5 - Опрашивайте:

Delegation confirmed after 4.2 seconds
Address now has 225,000 energy available

Этап 6 - Выполните:

Swap transaction broadcast
TX hash: abc123...
Energy consumed: 223,354
Energy remaining: 1,646 (will expire with delegation)
Net cost: 11.82 TRX instead of ~53 TRX burned
Savings: 78%

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

Почему порядок операций имеет значение

Строгое упорядочивание конвейера предотвращает три категории отказов:

Состояние гонки: купить и сразу трансляировать

Если вы купите energy и трансляируете транзакцию в том же блоке, делегирование может ещё не быть обработано. Транзакция выполняется без делегированной energy, сжигает TRX, и вы заплатили дважды - один раз за energy (которая остаётся неиспользованной) и один раз за сжигание TRX.

MERX предотвращает это путём опроса до подтверждения делегирования в цепи перед продолжением.

Переоценка: жестко закодированные значения energy

Многие инструменты используют жестко закодированные оценки energy (например, "передачи USDT всегда стоят 65 000 energy"). Но фактическая стоимость зависит от конкретных задействованных адресов, их истории владения токеном, внутреннего состояния контракта и даже номера блока. Передача на новый адрес стоит больше, чем передача на адрес, который уже владеет токеном.

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

Недооценка: недостаточные ресурсы

Если вы недооцените требования energy и транзакция исчерпает energy во время выполнения, она не удаётся. Вы теряете bandwidth для попытки транзакции, и купленная energy напрасно тратится на неудачную транзакцию.

MERX предотвращает это путём использования triggerConstantContract для точной симуляции и добавления небольшого буфера при заказе.

Различие на практике

Без транзакций, осведомлённых о ресурсах (стандартное поведение кошелька):

USDT transfer: 27 TRX burned (~$7.00)
SunSwap trade: 53 TRX burned (~$13.75)
Approve + Swap: 68 TRX burned (~$17.65)

С конвейером MERX, осведомлённым о ресурсах:

USDT transfer: 3.42 TRX (energy purchase)
SunSwap trade: 11.82 TRX (energy purchase)
Approve + Swap: 14.93 TRX (energy purchase)

Для агента, выполняющего 100 передач USDT в день, это разница между $700/день и $342/день - более $130 000 в годовой экономии.

Интеграция для разработчиков

Если вы создаёте приложение, которое взаимодействует с TRON, интеграция конвейера MERX, осведомлённого о ресурсах, не требует никаких архитектурных изменений. MCP-сервер обрабатывает весь конвейер внутренне.

Для прямой интеграции API:

# Step 1: Get estimation
curl -X POST https://merx.exchange/api/v1/estimate \
  -H "Content-Type: application/json" \
  -d '{"from": "T...", "to": "T...", "amount": 100000000}'

# Step 2: Ensure resources
curl -X POST https://merx.exchange/api/v1/ensure-resources \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"address": "T...", "energy_needed": 65000}'

# Step 3: Broadcast your transaction (signed client-side)

Endpoint ensure-resources обрабатывает сравнение цен, размещение заказа и опрос делегирования. Ваше приложение получает ответ только когда адрес готов.

Заключение

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

MERX делает правильный подход подходом по умолчанию. Каждая транзакция проходит через конвейер. Каждый дефицит ресурсов рассчитывается точно. Каждая покупка совершается по лучшей доступной цене. Каждое делегирование подтверждается перед трансляцией транзакции.

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

Ссылки:

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

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

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

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

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

All Articles