Делегування ресурсів у TRON: як це працює насправді

Модель ресурсів як основа делегування

У TRON немає газу в розумінні Ethereum. Натомість кожен акаунт має два пули ресурсів: Energy та bandwidth. Energy витрачається на виконання смарт-контрактів. bandwidth споживається кожною транзакцією, незалежно від того, чи задіяний контракт. Коли один із ресурсів вичерпується, мережа спалює TRX з балансу акаунта, щоб покрити нестачу. Саме це спалювання і робить операції дорогими.

Ресурси поповнюються двома способами. Перший: стейкінг TRX, коли ви блокуєте монети, а мережа нараховує вашому акаунту пропорційну частку глобального пулу Energy або bandwidth, що оновлюється щодня. Другий: отримання делегування, коли інший акаунт стейкає TRX і передає вам відповідні ресурси. Ваш акаунт використовує делеговані ресурси так само, ніби ви самостійно їх застейкали. З точки зору віртуальної машини жодної різниці немає.

Це фундамент, на якому тримається все інше. Делегування не є платіжним каналом чи обгорткою. Це пряме призначення права на ресурси в мережі від одного акаунта до іншого.

Що змінив Stake 2.0 у делегуванні

Оригінальна модель стейкінгу (Stake 1.0) вимагала під час стейкінгу одразу обирати, що генеруватиме TRX: Energy чи bandwidth. Розблокувати можна було лише всю суму після трьох днів блокування. Делегування існувало, але було досить негнучким: ви стейкали TRX, він генерував один тип ресурсів, і ви за бажанням спрямовували ці ресурси на іншу адресу.

Stake 2.0, запущений у мережі в середині 2023 року, суттєво переробив цю систему. Ключові зміни, що стосуються делегування:

• Розподіл ресурсів між отримувачами: Один застейканий обсяг TRX може одночасно генерувати ресурси, розподілені між кількома адресами. Ви не переміщуєте TRX, а лише розподіляєте потік ресурсів.
• Частковий анстейкінг: Можна розблокувати частину застейканих коштів, не чіпаючи решту. Це дає постачальникам ресурсів змогу керувати ліквідністю без шкоди для активних делегувань.
• Затримка виведення 14 днів: Після виклику unstake TRX потрапляє до черги виведення і залишається заблокованим приблизно 14 днів, після чого можна викликати withdrawExpireUnfreeze. При цьому будь-яке делегування, що спиралося на ці TRX, скасовується негайно, а не через 14 днів. Делегування припиняється в момент ініціювання анстейкінгу, а не в момент отримання TRX.
• Без блокування при зміні типу ресурсу: У версії 1.0 перемикання з Energy на bandwidth потребувало повного анстейкінгу і повторного стейкінгу. У версії 2.0 можна перепризначити вихід ресурсів з тієї самої застейканої позиції на інший тип без анстейкінгу, хоча це все одно вимагає окремої транзакції в мережі.

Практичний висновок для тих, хто отримує делеговану Energy: ваш баланс ресурсів може впасти до нуля в будь-який момент, якщо делегатор ініціює анстейкінг. Жодного буферного часу для отримувача не передбачено.

Як влаштована транзакція делегування на рівні мережі

Коли делегатор викликає delegateResource, транзакція фіксує три речі: адресу делегатора, адресу отримувача та обсяг Energy (або bandwidth), що делегується. Після цього мережа коригує відображення лімітів ресурсів у стані акаунта отримувача.

Всередині вузли TRON відстежують делеговані ресурси окремо від власних. Якщо запитати акаунт через wallet/getaccount у HTTP API, ви побачите поля на кшталт delegated_frozenV2_balance_for_energy та acquired_delegated_frozenV2_balance_for_energy. Перше відображає те, що ви відіслали. Друге, те, що отримали. Жодний TRX при цьому не переміщується. Реальні TRX залишаються на застейканому балансі делегатора.

Споживання ресурсів під час транзакції відбувається так: віртуальна машина перевіряє доступну Energy акаунта (власний стейкінг плюс отримані делегування). Якщо її достатньо, відбувається списання у такому порядку: спочатку витрачаються делеговані ресурси, потім власні застейкані. Якщо пул вичерпано, TRX спалюється з вільного балансу акаунта за поточним курсом мережі. Цей курс не є фіксованим, він розраховується динамічно на основі загального обсягу Energy в мережі та поточної ціни спалення, визначеної параметрами мережі.

Як Energy відновлюється після використання

Energy не є одноразовим кредитом. Використана Energy відновлюється рівномірно протягом 24 годин. Якщо максимальний ліміт Energy вашого акаунта становить 100 000 і ви витратили 65 000 на виконання контракту, через 24 години ліміт відновиться повністю. Через 12 годин буде доступно приблизно 32 500.

Це відновлення стосується як власної застейканої, так і делегованої Energy. Швидкість відновлення прив'язана до максимального ліміту акаунта, а не до якогось єдиного глобального лічильника. Тобто два акаунти з різними лімітами Energy відновлюються з різною абсолютною швидкістю, хоча обидва заповнюються повністю за 24 години.

Для частих операцій цей добовий цикл є головним обмежувальним фактором. Одне делегування, розраховане на один переказ на день, не покриє десять переказів на день, навіть якщо загальний обсяг Energy виглядає достатньо на папері. Потрібно враховувати ритм відновлення, а не лише загальну ємність.

Відкликання та перепризначення делегувань

Делегування не є постійним. Делегатор може в будь-який момент викликати unDelegateResource, щоб повернути ресурси. Ефект миттєвий: доступна Energy отримувача зменшується на відкликаний обсяг вже в наступному блоці. Жодного буферного часу для отримувача і жодного компенсаційного механізму на рівні протоколу не існує.

Щоб перепризначити делегування, тобто спрямувати той самий потік ресурсів іншому отримувачу, потрібні дві транзакції: відкликати від поточного отримувача, потім делегувати новому. Це окремі операції в мережі, які самі по собі споживають bandwidth. У Stake 2.0 їх можна виконати ефективніше, ніж раніше, проте з точки зору однієї транзакції вони все одно не є атомарними.

Є один корисний крайній випадок: якщо застейкані TRX делегатора генерують, наприклад, 200 000 Energy і він вже делегував 150 000 на адресу A, то решту 50 000 можна делегувати адресі B, не торкаючись делегування A. Обмеження одне: загальний обсяг делегованої Energy не може перевищувати загальний обсяг згенерованої. Спроба перевищити цей ліміт завершиться помилкою на рівні транзакції.

Що це означає для оренди Energy

Сервіси оренди Energy, як-от tronenergyrent.com, повністю працюють у межах цієї моделі делегування. Коли ви орендуєте Energy, постачальник стейкає TRX, генерує Energy і викликає delegateResource, вказуючи вашу адресу. З точки зору вашого акаунта ви отримуєте acquired_delegated_frozenV2_balance_for_energy саме так, як описано вище. Ви не тримаєте TRX. Ви тримаєте тимчасовий розподіл ресурсів.

Тривалість оренди відповідає тому, скільки часу постачальник підтримує це делегування активним. Оренда на 1 день за поточними цінами коштує 8,19 TRX за 65 000 Energy, цього вистачає для одного стандартного переказу TRC-20 USDT, який потребує близько 65 000 Energy та 345 bandwidth. Оренда на 30 днів для того самого обсягу Energy обійдеться в 175,50 TRX. Точну вартість для вашого конкретного обсягу переказів можна розрахувати за допомогою калькулятора.

Причина, чому короткострокова оренда коштує дорожче за добу, суто механічна: постачальнику доводиться керувати чергою анстейкінгу та накладними витратами на повторне делегування при частих циклах. Через 14-денну затримку виведення капітал заблокований незалежно від того, наскільки короткою є оренда.

Делегування bandwidth працює за тією самою схемою

Усе описане вище однаково стосується bandwidth, з однією відмінністю у стандартній поведінці. Кожен акаунт щодня отримує 600 безкоштовних одиниць bandwidth від мережі незалежно від стейкінгу. Цього безкоштовного ліміту вистачає для базових переказів TRX, але не для bandwidth-частини частих TRC-20 переказів. Стейкінг або отримання делегованого bandwidth збільшує ваш ліміт понад цей безкоштовний мінімум у 600 одиниць.

Коли ви делегуєте bandwidth на акаунт, ви додаєте до його можливостей понад будь-який безкоштовний ліміт, який він вже має. Порядок споживання такий: спочатку безкоштовний bandwidth, потім делегований, далі власний застейканий, і нарешті спалення TRX. Цей порядок важливий, якщо ви хочете точно розрахувати, коли для конкретного акаунта почнеться спалення.

Як читати стан делегування через API

Якщо ви розробляєте інструментарій або відстежуєте делегування, вам знадобляться такі API-запити:

• wallet/getaccount: повертає повний стан акаунта, включаючи поля делегованих та отриманих ресурсів
• wallet/getdelegatedresourcev2: повертає конкретний запис делегування між двома адресами, включаючи точний обсяг Energy та термін дії блокування, якщо воно було встановлене
• wallet/getcanwithdrawunfreezeamount: дає змогу делегатору перевірити, яка частина з черги анстейкінгу вже доступна для виведення

Ендпоінт getdelegatedresourcev2 особливо корисний для перевірки того, що делегування активне і правильно розраховане перед виконанням транзакцій, які від нього залежать. Не варто розраховувати на делегування лише тому, що воно було налаштоване вчора. Завжди перевіряйте актуальний стан у мережі перед тим, як покладатися на нього.