Qué se rompe en tu integración si TRON cambia el precio de la energía o los parámetros de la red
En TRON, el precio de la energía (getEnergyFee, actualmente 100 sun) y el techo de fee_limit (15 000 TRX) son parámetros de red que se cambian mediante propuestas on-chain del comité de SR, sin necesidad de hard fork. Si están fijados en el código, cualquier cambio rompe la conversión de Energy a sun: fee_limit queda demasiado bajo (las transacciones fallan con OUT_OF_ENERGY) o excesivo, y tu cálculo del coste de transferencia se aleja de la realidad. La solución es consultar wallet/getchainparameters y recalcular el presupuesto antes de enviar.
Respuesta corta
En TRON, el precio de la energía no es un gas dirigido por el mercado, sino un parámetro de red: getEnergyFee (parámetro #11), actualmente 100 sun = 0,0001 TRX por unidad de Energy. Igual que el techo getMaxFeeLimit (15 000 TRX) o el límite de CPU por transacción (80 ms), lo cambia el comité de SR mediante una propuesta on-chain: sin hard fork, sin migrar a un nodo nuevo. Así que lo que se rompe en tu integración no es ni la firma ni el formato de transacción, sino la aritmética del presupuesto: la conversión Energy → sun, el valor de fee_limit, las estimaciones en caché y los cálculos de coste unitario. Todo ello suele estar incrustado como constantes.
El parámetro ya ha cambiado muchas veces: distintas versiones de la documentación de TRON mencionan 10, 100, 280 y 420 sun por unidad de Energy. Cualquiera de esos números fijado en tu código produce una discrepancia de varias veces.
Qué deja exactamente de funcionar
1. Un fee_limit fijado en el código
Recibes energy_required en Energy, pero pasas fee_limit en sun: fee_limit (sun) = energy_required × getEnergyFee. Si el precio de la energía ha subido mientras tu multiplicador es una constante, el presupuesto se queda corto: la transacción se revierte con OUT_OF_ENERGY, y la Energy ya consumida se cobra y nunca se reembolsa. Si el precio ha bajado, simplemente estás inmovilizando TRX de más en tus wallets hot. Otro clásico es la confusión de unidades: fee_limit = 100 pensado como «100 TRX» en realidad autoriza 0,0001 TRX, y la llamada falla de inmediato. La documentación califica expresamente de error típico de producción el fijar en el código «15 000 TRX» y «100 sun».
2. Calcular el coste de una transferencia de USDT TRC-20
Una transferencia de USDT cuesta alrededor de 64 000 de Energy si el destinatario tiene un saldo del token distinto de cero, y alrededor de 130 000 de Energy si el saldo es cero (la diferencia proviene del coste de SSTORE cuando un slot deja de valer cero). No se puede multiplicar esto por un precio de energía constante: cambian tanto el precio como el consumo. Mainnet ejecuta el Dynamic Energy Model: una vez superado un umbral de carga, el coste efectivo de Energy de un contrato popular se multiplica por un factor de 1× a 4,4×, y el factor se recalcula en cada ciclo de mantenimiento (6 horas). El coste de opcodes individuales de la TVM también ha estado sujeto a votación: una propuesta así apareció en la versión Cleobulus.
En resumen: el coste de una transferencia es una función de tres variables (consumo, energy_factor, getEnergyFee), no un número en una tabla de precios.
3. Estimaciones de energía en caché
estimateenergy refleja el estado del nodo en el momento de la consulta y no garantiza que la transacción posterior tenga éxito. Una caché que sobrevive al ciclo de mantenimiento pierde todo valor en el límite del ciclo junto con energy_factor, y un cambio en el estado del contrato o en los parámetros de la llamada la invalida incluso antes. Los números de Shasta no son válidos para producción: la misma llamada puede costar 31 000 de Energy en testnet y 90 000 en Mainnet.
4. Parámetros del lado del contrato
No son parámetros de red, pero rompen tu economía igual de silenciosamente. consume_user_resource_percent es la parte del coste que paga quien llama; quien desplegó el contrato puede cambiarla tras el despliegue mediante wallet/updatesetting, y el nuevo valor se aplica a todas las llamadas posteriores. Si a quien desplegó se le acaba la Energy en staking, la parte no pagada pasa silenciosamente a quemar los TRX del usuario. origin_energy_limit reside en el registro on-chain del contrato: tras UpdateEnergyLimitContract, todo el que llama adopta el nuevo valor desde el siguiente bloque sin ver el cambio.
5. Puertas de fork y el límite de 80 ms
Las nuevas funciones de la TVM se activan mediante puertas de parámetros de red; hasta que se abre una puerta, el opcode correspondiente se trata como ILLEGAL_OPERATION, y el despliegue en Mainnet, Nile y Shasta es independiente. El límite getMaxCpuTimeOfOneTx (80 ms, parámetro #13) también se cambia por votación: superarlo produce OUT_OF_TIME y se cobra todo el fee_limit. Si la complejidad de tu llamada está cerca del umbral crítico, fallará de forma intermitente.
Qué cambiar de tu lado
| Dónde | Qué hacer |
|---|---|
| Configuración | Elimina las constantes energyPrice y maxFeeLimit; lee wallet/getchainparameters al arrancar y de forma periódica |
| Cálculo de fee_limit | energy_required × getEnergyFee + un margen para DEM (hasta 4,4×), o un presupuesto conservador basado en el factor máximo |
| Estimación | Vuelve a estimar justo antes de enviar; no reutilices una caché a través del límite del ciclo de 6 horas |
| Gestión de errores | Separa OUT_OF_ENERGY (presupuesto insuficiente) de OUT_OF_TIME (se cobra todo el límite): la lógica de reintento es distinta para cada uno |
| Coste unitario | Calcúlalo a partir del consumo real en el recibo de la transacción, no de una lista de precios; contempla el escenario «el destinatario tiene saldo de USDT cero» |
El historial del precio de la energía está disponible en wallet/getenergyprices, y la lista de IDs de parámetros y sus valores actuales está en el glosario.
Conclusión
TRON no tiene EIP-1559 ni comisiones de prioridad: todos pagan la misma tarifa, y por eso mismo se cambia mediante una propuesta del comité. Una integración que lee los parámetros de red de la cadena y calcula su presupuesto de forma dinámica sobrevive a un cambio así sin necesidad de un despliegue. Una integración construida sobre constantes se entera a través de una oleada de errores OUT_OF_ENERGY y de una discrepancia en su informe de costes.