La delegación de recursos en TRON por dentro: cómo funciona realmente

El modelo de recursos, base indispensable para entender la delegación

TRON no cobra gas como lo hace Ethereum. En su lugar, cada cuenta dispone de dos reservas de recursos: Energy y bandwidth. La Energy se consume al ejecutar contratos inteligentes. El bandwidth se consume en cada transacción, independientemente de si interactúa con un contrato o no. Cuando una cuenta se queda sin alguno de estos recursos, la red quema TRX del saldo disponible para cubrir el déficit. Ese proceso de quema es lo que encarece las operaciones.

Los recursos se generan de dos formas. La primera, bloqueando TRX: al inmovilizar TRX, la red acredita en la cuenta una parte proporcional del fondo global de Energy o bandwidth, que se renueva cada 24 horas. La segunda, mediante una delegación: otra cuenta bloquea TRX y asigna los recursos generados a tu dirección. Tu cuenta utiliza esos recursos delegados exactamente igual que si los hubieras generado tú mismo. Desde la perspectiva de la máquina virtual, no existe ninguna diferencia.

Este es el pilar sobre el que descansa todo lo demás. La delegación no es un canal de pago ni una capa intermedia. Es una asignación directa de derechos sobre recursos en la cadena, de una cuenta a otra.

Qué cambió con Stake 2.0 en materia de delegación

El modelo original de staking (Stake 1.0) exigía elegir en el momento del bloqueo si el TRX generaría Energy o bandwidth, y solo permitía desbloquear la cantidad total de una vez, tras un período de espera de 3 días. La delegación existía, pero era poco flexible: bloqueabas TRX, se generaba un único tipo de recurso y, opcionalmente, lo apuntabas hacia otra dirección.

Stake 2.0, activado en la red principal a mediados de 2023, reestructuró este sistema de forma considerable. Los cambios más relevantes en cuanto a delegación son los siguientes:

• División proporcional de recursos: una sola posición de TRX bloqueado puede distribuir los recursos generados entre varias direcciones al mismo tiempo. No se envía TRX a ningún sitio, simplemente se redirige la producción de recursos.
• Desbloqueo por tramos: es posible desbloquear cantidades parciales sin afectar al resto de la posición. Esto permite a los proveedores de recursos gestionar su liquidez sin interrumpir las delegaciones activas.
• Período de espera de 14 días para el desbloqueo: tras ejecutar unstake, el TRX entra en una cola de retirada y queda bloqueado durante aproximadamente 14 días antes de poder llamar a withdrawExpireUnfreeze para recuperarlo. Durante ese período, cualquier delegación que dependiera de ese TRX se cancela de inmediato, no al cabo de los 14 días. La delegación finaliza en el momento en que se inicia el desbloqueo, no cuando se recibe el TRX.
• Eliminación del bloqueo por cambio de tipo de recurso: en la versión 1.0, pasar de Energy a bandwidth requería un ciclo completo de desbloqueo y nuevo bloqueo. En la 2.0, se puede redirigir la producción de recursos de una misma posición bloqueada hacia un tipo distinto sin necesidad de desbloquear, aunque esto sigue requiriendo una transacción independiente en la cadena.

La consecuencia práctica para quienes reciben Energy delegada es clara: el saldo de recursos puede caer a cero en cualquier momento del día si el delegante inicia un desbloqueo. En el lado receptor no existe ningún período de gracia.

La mecánica en cadena de una transacción de delegación

Cuando un delegante ejecuta delegateResource, la transacción registra tres datos: la dirección del delegante, la dirección del receptor y la cantidad de Energy (o bandwidth) que se delega. A continuación, la red ajusta los límites de recursos reflejados en el estado de la cuenta receptora.

Internamente, los nodos de TRON llevan un registro separado de los recursos delegados y los propios. Si consultas una cuenta a través de wallet/getaccount en la API HTTP, verás campos como delegated_frozenV2_balance_for_energy y acquired_delegated_frozenV2_balance_for_energy. El primero indica lo que has enviado. El segundo, lo que has recibido. Ninguno de los dos implica movimiento de TRX. El TRX real permanece en el saldo bloqueado del delegante.

El consumo de recursos durante una transacción funciona así: la máquina virtual comprueba la Energy disponible en la cuenta que ejecuta la operación, sumando la propia y la recibida por delegación. Si es suficiente, descuenta de ese fondo en este orden: primero se consume la Energy delegada recibida y después la propia bloqueada. Si el fondo se agota, se quema TRX del saldo libre de la cuenta al tipo de cambio vigente en la red. Ese tipo no es fijo: se calcula de forma dinámica según la Energy total de la red y el precio de quema establecido por los parámetros en cadena.

Cómo se recupera la Energy después de usarla

La Energy no es un crédito único. La Energy consumida se recupera de forma lineal a lo largo de un período de 24 horas. Si tu cuenta tiene un límite máximo de 100.000 de Energy y utilizas 65.000 al ejecutar un contrato, habrás recuperado el total al cabo de 24 horas. A mitad del período, es decir, a las 12 horas, tendrás disponibles aproximadamente 32.500.

Esta recuperación aplica tanto a la Energy propia bloqueada como a la delegada. La tasa de recuperación está vinculada al máximo de la cuenta, no a ningún ciclo global fijo. Por eso, dos cuentas con distintos límites de Energy se recuperan a ritmos absolutos diferentes, aunque ambas se recarguen por completo en 24 horas.

Para operaciones de alta frecuencia, este ciclo de 24 horas es el factor limitante. Una delegación calculada para una sola transferencia al día no cubrirá diez transferencias diarias, aunque el total de Energy parezca suficiente sobre el papel. Hay que tener en cuenta el ritmo de recuperación, no solo la capacidad total.

Revocar y reasignar delegaciones

La delegación no es permanente. Un delegante puede ejecutar unDelegateResource en cualquier momento para recuperar los recursos. El efecto es inmediato: la Energy disponible del receptor disminuye en la cantidad revocada a partir del siguiente bloque. No hay período de espera en el lado receptor ni ningún mecanismo de compensación a nivel de protocolo.

Reasignar una delegación, es decir, enviar la misma producción de recursos a un receptor distinto, requiere dos transacciones: revocar la delegación al receptor actual y luego delegar al nuevo. Son operaciones independientes en la cadena y consumen bandwidth por sí mismas. Con Stake 2.0 se pueden gestionar de forma más eficiente que antes, pero desde el punto de vista de una sola transacción, siguen sin ser atómicas.

Un caso particular que conviene conocer: si el TRX bloqueado de un delegante genera, por ejemplo, 200.000 de Energy y ha delegado 150.000 a la dirección A, puede delegar las 50.000 restantes a la dirección B sin tocar la delegación de A. La restricción es que la Energy total delegada no puede superar la Energy total generada. Intentar sobre-delegar fallará a nivel de transacción.

Qué implica todo esto para el alquiler de Energy

Los servicios de alquiler de Energy como tronenergyrent.com operan íntegramente dentro de este modelo de delegación. Cuando alquilas Energy, el proveedor bloquea TRX, genera Energy y ejecuta delegateResource apuntando a tu dirección. Desde la perspectiva de tu cuenta, recibes acquired_delegated_frozenV2_balance_for_energy exactamente como se ha descrito. No tienes TRX en tu poder. Tienes una asignación de recursos temporal.

La duración del alquiler corresponde al tiempo que el proveedor mantiene activa esa delegación. Un alquiler de 1 día al precio actual cuesta 8,19 TRX por 65.000 de Energy, suficiente para cubrir una transferencia estándar de USDT TRC-20 que requiere aproximadamente 65.000 de Energy y unos 345 de bandwidth. Un alquiler de 30 días cuesta 175,50 TRX para el mismo bloque de Energy. Puedes consultar los costes exactos según tu volumen de transferencias con la calculadora.

El motivo por el que los alquileres de corta duración resultan más caros por día es puramente operativo: el proveedor tiene que gestionar la cola de desbloqueos y la sobrecarga de re-delegación en ciclos frecuentes. El período de espera de 14 días para el retiro implica que el capital queda inmovilizado independientemente de lo corto que sea el alquiler.

La delegación de bandwidth funciona con el mismo modelo

Todo lo descrito anteriormente aplica igualmente al bandwidth, con una diferencia en el comportamiento por defecto. Cada cuenta recibe 600 unidades de bandwidth gratuitas al día por parte de la red, independientemente del staking. Esta asignación gratuita cubre las transferencias básicas de TRX, pero no la parte de bandwidth en transferencias frecuentes de TRC-20. Bloquear TRX o recibir bandwidth delegado incrementa tu límite por encima de esa base de 600.

Cuando delegas bandwidth a una cuenta, se suma a su capacidad existente, por encima de cualquier asignación gratuita que ya tenga. El orden de consumo es el siguiente: primero el bandwidth gratuito, luego el bandwidth delegado, después el propio bloqueado y, finalmente, la quema de TRX. Este orden importa si necesitas calcular con exactitud en qué momento empezará a producirse la quema en una cuenta determinada.

Consultar el estado de una delegación a través de la API

Si estás desarrollando herramientas o monitorizando una delegación, las llamadas a la API más relevantes son:

• wallet/getaccount: devuelve el estado completo de la cuenta, incluyendo los campos de recursos delegados y recibidos.
• wallet/getdelegatedresourcev2: devuelve el registro de delegación específico entre dos direcciones, incluyendo la cantidad exacta de Energy y la fecha de vencimiento del bloqueo si se estableció alguno.
• wallet/getcanwithdrawunfreezeamount: permite a un delegante comprobar qué parte de su desbloqueo en cola ya puede retirarse.

El endpoint getdelegatedresourcev2 resulta especialmente útil para verificar que una delegación está activa y tiene el tamaño correcto antes de ejecutar transacciones que dependan de ella. No des por sentado que una delegación sigue vigente solo porque se configuró el día anterior. Confirma siempre el estado en la cadena antes de depender de ella.