Introduce delegating resource usage right

[LuganBI]

Simple Summary

The resource usage right can be delegated.

Motivation

After Stake 2.0 is enabled, the resource delegations have been much more flexible on the TRON network. The volume of resource delegation and revoking resource delegation transactions has increased significantly. Especially in the case of asset aggregation of an account, it needs to repeatedly delegate resources to other addresses and then undelegate after the transfer transactions are done, which makes large amounts of transactions happen and the operations could be very cumbersome. In order to alleviate this situation, it is proposed to introduce a new transaction type to reduce the number of such large and frequent resource delegation and revoking resource delegation transactions.

After introducing the transaction type of delegating resource usage right, when an account has to regularly initiate large amounts of resource delegation transactions to help other addresses execute transactions, it only needs to delegate the resource usage right to every target address once and for all. It will greatly reduce the complexity of the operations.

Specifications

Adding a transaction type of resources usage right delegation, it allows account A to delegate X shares of specific resources to account B. After the transaction is completed, the X shares of resources are still in account A, and when account B needs to consume the specific type of resources, resources less than X share will be consumed directly from account A first. When the resources to be consumed are greater than X share or account A has insufficient resources, account B's own resources will then be consumed.

[GuipaiQigong111]

I am not sure about the specific functional division between it and the resource delegating, but I always feel that this move carries too much risk. Without the constraints of relevant rules, it may be abused, which will be detrimental to the healthy development of the Tron network.

[CarlChaoCarl]

The implementation involves more details, such as how to be compatible with existing logic, and it may also bring the risk of abuse.

[toolsopen]

I prefer to use multiple addresses to sign transactions at the same time and specify one of the addresses as the resource payment address.

[CooperDepp]

Hi, I think one thing we need to consider is the relationship between shares than account A can delegate(Da) and the actual shares A has(Ha):

If Da<=Ha: then this is same like this: A delegate resources to other accounts without undelegating.
If Da>Ha: then there are some risks for the chain, for example, A can delegate shares to all other accounts on chain even if A has no resources, this will bring high risk on DB and many useless datas on chain.

Maybe we can add a limitation for the list.

And for the transaction processing, if there are many things like this on chain, many transactions need to check the delegated shares first, if the list is long and many of them don’t have enough resources, the chain will spend a lot of useless time and waste chain’s resources.

[lxcmyf]

@toolsopen
Let me understand what you mean. Assuming there are multiple addresses that require resources, and only one address has enough resources, when a transaction is initiated by an address without any resources, it is possible to pay for the resources consumed by the transaction by specifying the address with sufficient resources through multiple signatures. In this way, it may be necessary to add a field for each transaction type to specify the payment address. Is that how you envision it?

[barbatos2011]

@toolsopen Let me understand what you mean. Assuming there are multiple addresses that require resources, and only one address has enough resources, when a transaction is initiated by an address without any resources, it is possible to pay for the resources consumed by the transaction by specifying the address with sufficient resources through multiple signatures. In this way, it may be necessary to add a field for each transaction type to specify the payment address. Is that how you envision it?

It's a good suggestion. maybe one thing that we could discuss is if every time we need another account to join and sign the transaction, for large number of transactions, maybe it is too inconvenient. or is there any way to handle this?