Как работает делегирование энергии на TRON

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

В этой статье подробно объясняется механизм делегирования Stake 2.0: как поставщики делегируют энергию покупателям, что происходит во время и после периода делегирования, и как MERX управляет полным жизненным циклом делегирования у нескольких поставщиков.

Основание Stake 2.0

TRON представил Stake 2.0 (также называется Stake v2) как замену оригинальному механизму блокировки ресурсов. Ключевое нововведение Stake 2.0 — это разделение стейкинга от использования ресурсов. В исходной модели (Stake 1.0) замороженный TRX производил энергию, которую мог использовать только адрес того, кто её заморозил. Stake 2.0 представил делегирование, позволяя одному адресу направлять свои залокированные ресурсы на любой другой адрес в сети.

Три операции

Делегирование Stake 2.0 включает три операции в блокчейне:

1. Stake (freezeBalanceV2)

Поставщик блокирует TRX в контракте стейкинга. Это производит энергию пропорциональную сумме залокированного и общему стейку сети. Энергия восстанавливается постоянно в течение 24-часового окна.

Поставщик стейкит 36,000 TRX
Сеть выделяет ~65,000 energy/day поставщику

2. Delegate (delegateResource)

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

{
  "owner_address": "TProviderAddress...",
  "receiver_address": "TBuyerAddress...",
  "resource": "ENERGY",
  "balance": 36000000000,
  "lock": true,
  "lock_period": 3
}

Ключевые параметры:

owner_address: адрес поставщика (делегирующий)
receiver_address: адрес покупателя (получатель)
resource: ENERGY или BANDWIDTH
balance: количество TRX (в SUN), поддерживающее это делегирование
lock: заблокировано ли делегирование на минимальный период
lock_period: длительность блокировки в днях (если lock равен true)

3. Undelegate (undelegateResource)

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

{
  "owner_address": "TProviderAddress...",
  "receiver_address": "TBuyerAddress...",
  "resource": "ENERGY",
  "balance": 36000000000
}

Жизненный цикл делегирования

Полное делегирование проходит несколько фаз. Понимание каждой фазы критично для создания надёжных систем аренды энергии.

Фаза 1: Размещение заказа

Покупатель запрашивает энергию на определённый адрес и длительность. Это происходит вне блокчейна — покупатель платит поставщику (напрямую или через агрегатор типа MERX), и поставщик ставит делегирование в очередь.

Фаза 2: Делегирование на блокчейне

Поставщик транслирует транзакцию delegateResource. Обычно это подтверждается в течение 3-6 секунд на TRON (один блок). После подтверждения энергия немедленно доступна на адресе покупателя.

Эффективная энергия покупателя = own_staked_energy + all_delegated_energy

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

Фаза 3: Период активного делегирования

Во время периода делегирования покупатель использует энергию для своих операций. Ключевое поведение в этой фазе:

Восстановление: делегированная энергия восстанавливается с той же скоростью, что и собственная залокированная энергия — постоянно в течение 24 часов.
Приоритет потребления: когда покупатель имеет и собственную, и делегированную энергию, TRON не различает их. Вся энергия объединена в пул.
Несколько делегирований: покупатель может получать делегирования от нескольких поставщиков одновременно. Количества энергии складываются.

Фаза 4: Истечение и возврат

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

Временная шкала:
  T+0:   delegateResource подтверждена (энергия активна)
  T+3d:  Период блокировки истекает
  T+3d+: Поставщик вызывает undelegateResource (энергия удаляется)

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

Фаза 5: После отмены делегирования

После подтверждения отмены делегирования TRX поставщика возвращается в их пул "не делегированных". Они могут затем делегировать их следующему клиенту. Доступная энергия покупателя снижается на отменённое количество.

Механика периода блокировки

Параметры lock и lock_period в транзакции делегирования заслуживают особого внимания.

Заблокированные делегирования

Когда lock: true, поставщик обязуется поддерживать делегирование как минимум lock_period дней. В это время поставщик не может отменить делегирование. Это даёт покупателю гарантию доступности ресурса.

lock_period = 3 дня

День 0: Делегирование создано, блокировка начинается
День 1: Поставщик НЕ МОЖЕТ отменить делегирование
День 2: Поставщик НЕ МОЖЕТ отменить делегирование
День 3: Блокировка истекает, поставщик МОЖЕТ отменить делегирование

Незаблокированные делегирования

Когда lock: false, поставщик может отменить делегирование в любой момент — даже сразу после делегирования. Это рискованно для покупателей, потому что поставщик может вернуть энергию до того, как покупатель её использует.

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

Гранулярность периода блокировки

Период блокировки TRON указывается в днях (технически в блоках, но протокол отображается в периоды примерно 24 часа). Минимальная практическая блокировка — 1 день. Распространённые длительности на рынке:

Data table
Период блокировки	Типичный сценарий использования
0 (не заблокировано)	Не рекомендуется
1 день	Краткосрочная / тестирование
3 дня	Стандартная аренда
7 дней	Еженедельные операции
14 дней	Двухнедельное покрытие
30 дней	Месячные контракты

Проверка доставки энергии

Как узнать, что делегирование действительно произошло? Есть несколько методов проверки.

Проверка на блокчейне

Запросите сеть TRON напрямую:

// Используя TronWeb
const accountResources = await tronWeb.trx.getAccountResources(buyerAddress);
console.log('Общий лимит энергии:', accountResources.EnergyLimit);
console.log('Использованная энергия:', accountResources.EnergyUsed);
console.log('Доступно:', accountResources.EnergyLimit - accountResources.EnergyUsed);

Поле EnergyLimit отражает полную энергию из всех источников: собственной и делегированной. Увеличение EnergyLimit после подтверждения делегирования подтверждает доставку.

Поиск записи делегирования

TRON предоставляет API для запроса записей делегирования адреса:

// Получить все делегирования, полученные адресом
const delegations = await tronWeb.trx.getDelegatedResourceV2(
  buyerAddress,
  providerAddress
);

Это возвращает конкретные количества делегирований и периоды блокировки от конкретного поставщика к покупателю.

Проверка MERX

MERX выполняет автоматическую проверку после каждого заказа:

Заказ размещён и оплачен.
Поставщик выполняет транзакцию делегирования.
MERX отслеживает блокчейн для подтверждения транзакции делегирования.
MERX запрашивает ресурсы аккаунта покупателя для проверки увеличения энергии.
Если проверка не удаётся (энергия не получена в течение истечения), заказ отмечается и покупателю возвращаются средства.

import { MerxClient } from 'merx-sdk';

const client = new MerxClient({ apiKey: 'your-key' });

// Разместить заказ
const order = await client.createOrder({
  energy: 65000,
  targetAddress: 'TBuyerAddress...',
  duration: '1d'
});

// Проверить статус заказа (включает проверку делегирования)
const status = await client.getOrder(order.id);
console.log(status.delegationStatus);
// 'pending' | 'confirmed' | 'verified' | 'failed'

Делегирование от нескольких поставщиков

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

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

Адрес покупателя: TBuyer123...

Делегирование 1: Поставщик A -> 200,000 энергии (65,000 x 3)
Делегирование 2: Поставщик B -> 130,000 энергии (65,000 x 2)
Делегирование 3: Поставщик C ->  65,000 энергии (65,000 x 1)

Полная делегированная энергия: 395,000/день
Плюс собственная залокированная энергия покупателя: 0
Полная доступная энергия: 395,000/день

Все делегирования независимы. Поставщик A может отменить делегирование без влияния на делегирования B и C. Полная энергия покупателя — это просто сумма всех активных делегирований плюс его собственная залокированная энергия.

Почему это важно для агрегации

Когда покупатель заказывает 500,000 энергии через MERX, ни один поставщик может не иметь столько доступной. MERX может разбить заказ:

Заказ: 500,000 энергии для TBuyer123...

Маршрутизация:
  Поставщик A: 200,000 энергии по 82 SUN/единица  = 16,400,000 SUN
  Поставщик B: 180,000 энергии по 85 SUN/единица  = 15,300,000 SUN
  Поставщик C: 120,000 энергии по 88 SUN/единица  = 10,560,000 SUN

Полная стоимость: 42,260,000 SUN
Эффективный тариф: 84.52 SUN/единица

Покупатель видит один заказ со смешанным тарифом. За кулисами на блокчейне выполняются три отдельные транзакции делегирования.

Как MERX управляет жизненным циклом делегирования

MERX управляет полным жизненным циклом каждого делегирования, от заказа до истечения, у всех интегрированных поставщиков.

Выполнение заказа

Проверка цены: Опрашивает всех поставщиков на текущую лучшую цену.
Маршрутизация: Выбирает самого дешёвого поставщика, который может заполнить заказ.
Выполнение: Отправляет заказ выбранному поставщику через их API.
Мониторинг: Следит за транзакцией делегирования на блокчейне.
Проверка: Подтверждает, что энергия прибыла на целевой адрес.
Уведомление: Уведомляет покупателя через webhook или WebSocket.

Во время активного периода

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

В момент истечения

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

Обработка ошибок

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

Распространённые граничные случаи

Энергия использована до истечения делегирования

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

Поставщик делегирует больше, чем приобретено

Иногда поставщик может делегировать больше энергии, чем покупатель заплатил (из-за внутренних различий в учёте). Покупатель получает выгоду от дополнительной энергии во время периода делегирования. MERX отслеживает точные заказанные и доставленные количества.

Несколько заказов на один адрес

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

Адрес не существует

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

Заключение

Делегирование энергии — это основание экономики ресурсов TRON. Механизм Stake 2.0 преобразует энергию из неотчуждаемого ресурса в торгуемый товар, позволяя существовать всей экосистеме поставщиков. Понимание того, как работают делегирования — механика блокировок, процесс проверки, композиция от нескольких поставщиков — необходимо для всех, кто создаёт производственные системы на TRON.

MERX абстрагирует сложность управления делегированиями у нескольких поставщиков в один вызов API, но знание того, что происходит под капотом, помогает вам принимать лучшие решения о длительности, объёме и выборе поставщика.

Исследуйте API MERX и начните управлять делегированиями программно на https://merx.exchange/docs.

Эта статья является частью серии знаний MERX об инфраструктуре TRON. MERX — первая блокчейн-биржа ресурсов. GitHub: https://github.com/Hovsteder/merx-sdk-js.

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

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

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

Спросите вашего AI-агента: "What is the cheapest TRON energy right now?" и получите живые цены от всех подключённых поставщиков.

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