Делегирование ресурсов TRON изнутри: как это работает на самом деле

Модель ресурсов как основа для понимания делегирования

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

Ресурсы пополняются двумя способами. Первый – стейкинг TRX: заморозьте монеты, и сеть начислит вашему аккаунту пропорциональную долю от глобального пула Energy или bandwidth, которая обновляется каждые 24 часа. Второй – получение делегирования: другой аккаунт замораживает TRX и направляет полученные ресурсы на ваш адрес. Делегированные ресурсы работают точно так же, как если бы вы застейкали TRX самостоятельно. С точки зрения виртуальной машины между ними нет никакой разницы.

Это фундамент, на котором строится всё остальное. Делегирование – не платёжный канал и не обёртка. Это прямое присвоение права на сетевые ресурсы от одного аккаунта другому.

Что изменил Stake 2.0 в модели делегирования

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

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

• Пропорциональное распределение ресурсов: одна позиция застейканного TRX может одновременно генерировать ресурсы и делить их между несколькими адресами. Вы не отправляете TRX никуда – вы просто направляете поток ресурсов.
• Частичная разморозка: теперь можно размораживать часть позиции, не трогая остаток. Это позволяет провайдерам ресурсов управлять ликвидностью, не нарушая активные делегирования.
• Задержка разморозки 14 дней: после вызова unstake TRX попадает в очередь на вывод и блокируется примерно на 14 дней, после чего можно вызвать withdrawExpireUnfreeze. При этом любое делегирование, связанное с этим TRX, отменяется немедленно – не через 14 дней, а в момент инициирования разморозки. Делегирование прекращается тогда, когда вы запускаете процесс, а не когда получаете монеты обратно.
• Нет блокировки при смене типа ресурса: в версии 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 при этом не происходит. Реальные монеты остаются в замороженном балансе делегирующего.

Расход ресурсов при выполнении транзакции происходит следующим образом: виртуальная машина проверяет доступную Energy аккаунта (собственная застейканная плюс полученные делегирования). Если её достаточно, она списывается в определённом порядке: сначала делегированная, потом собственная застейканная. Если пул исчерпан, TRX сжигается со свободного баланса аккаунта по текущему курсу сети. Курс не фиксированный – он рассчитывается динамически на основе суммарной Energy в сети и текущей цены сжигания, заданной параметрами блокчейна.

Как Energy восстанавливается после использования

Energy – это не разовый кредит. Использованная Energy восстанавливается равномерно в течение 24 часов. Если максимальный лимит Energy вашего аккаунта составляет 100 000 и вы потратили 65 000 на выполнение контракта, то через 24 часа баланс полностью восстановится. Через 12 часов у вас снова будет около 32 500.

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

При высокочастотных операциях именно этот 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 – позволяет делегирующему проверить, какая часть из поставленного в очередь на разморозку TRX уже доступна для вывода

Метод getdelegatedresourcev2 особенно полезен для проверки того, что делегирование активно и имеет нужный объём перед выполнением транзакций, которые на него опираются. Не стоит считать делегирование активным только потому, что оно было настроено вчера. Всегда проверяйте актуальное состояние в блокчейне, прежде чем на него полагаться.