Enable Conversion between Energy and Bandwidth in Stake 2.0

Simple Summary

In order to improve user experience and resource flexibility on the TRON network, it is recommended to introduce a new transaction type that allows direct conversion between Energy and Bandwidth resources in Stake 2.0, without the need for unstaking and re-staking TRX.

Motivation

Following the implementation of Stake 2.0, the demand for resources on the TRON network has been continuously increasing.

Under the current Stake 2.0 mechanism, users can only perform staking and unstaking operations. According to proposal #70, the lock-up period for unstaked assets is set to 14 days. This means that if a user wants to change their resource type (e.g., from bandwidth to energy), they must first unstake the TRX, wait through the 14-day lock-up period, and then re-stake the TRX to obtain energy. This process is highly inconvenient for users and leads to inefficient resource allocation on the network.

Therefore, we need to introduce a new transaction type that allows users to directly exchange between Energy and Bandwidth resources without going through the unstaking process, making resource management more convenient and flexible for all users.

Background

Here is the daily transaction volume for staking and unstaking operations on the TRON network:

As shown in the chart above, the TRON network processes approximately 3,000 to 5,000 staking and unstaking transactions daily. With each unstaking operation requiring a 14-day waiting period, a lot of TRX remains locked in this transition state.
This inefficiency creates several problems:

• Resource Underutilization
• Poor User Experience
• Network Contribution Loss

By implementing the proposed direct exchange mechanism between Energy and Bandwidth, TRX could be converted to another active resource rather than sitting idle in the unstaking queue.

Specification

Propose to add a new transaction type and a new opcode that enable direct resource exchange.

• Add a new transaction type ExchangeResourceContract.
• Add a new opcode EXCHANGERESOURCE to TVM.

Compatibility

This proposal is fully compatible with the existing Stake 2.0 system and does not require any changes to it.

The issue names Stake 2.0, proposal #70, the ExchangeResourceContract transaction type, and the EXCHANGERESOURCE TVM opcode. Start by tracing existing Stake 2.0 resource operations and TVM transaction and opcode definitions, then establish the conversion behavior and compatibility requirements. Done means both additions are implemented and verified by the project's tests.