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?

[lxcmyf]

Here are the advantages and disadvantages of the two solutions I have summarized：

Option 1: Resource Usage Authorization

Advantages:

Simplified operation: By granting resource usage rights at once, the complexity of frequent delegation and revocation of delegation is reduced, making the whole process simpler.
Flexibility: Allowing one account (authorizing account) to authorize resources (usage rights actually) to multiple accounts with no need to repeat operations for each transaction, improves the flexibility of resource utilization.
Security: Resources remain in the authorizing account and are only consumed when needed by the authorized accounts, reducing the risk of resource theft.

Disadvantages:

Resource locking: Once authorized, resources are locked and cannot be used for other purposes, affecting their liquidity.
Management complexity: It is necessary to track and manage multiple authorization relationships, especially when there are a large number of authorized accounts, which increases the complexity of management.
Dependency: The authorized accounts rely on the authorizing account for resource consumption. If there is a problem with the authorizing account (such as account being frozen), it may affect the authorized account's transactions.

Option 2: Multi-signature Payment with Designated Address

Advantage:

instantaneousness: No prior authorization of resources is required, and the payment address can be specified immediately when the transaction occurs, improving the immediacy of the transaction.
Flexibility: The payment address is designated dynamically based on the needs of each transaction, providing higher flexibility.
Resource utilization efficiency: Resources are not locked for periods and will only be used when actual transactions occur, improving the efficiency of resource utilization.
Payer control: Payers have more control over whether to pay resources for particular transactions, as they need to explicitly agree on the resource consumption for each transaction.

Disadvantages:

Security issue: It is necessary to ensure the security of the multi-signature mechanism and prevent unauthorized resource consumption.
Complexity: It is necessary to add fields or handle unknown fields for each transaction type (if using protobuf's unknown field), which increases the complexity of the system.
Performance issue: The multi-signature mechanism may increase transaction processing time, especially when multi-signature verifications are required, which may affect overall performance.
Dependency: Although dependency is immediate, if the designated payment address has insufficient resources or rejects payment, the transaction may not be completed.

Both options have their unique advantages and disadvantages:

Option one is more suitable for long-term stable resource authorization relationships, while option two provides higher flexibility and immediacy, meanwhile, brings higher complexity and potential security risks.

[toolsopen]

Here are the advantages and disadvantages of the two solutions I have summarized：

Option 1: Resource Usage Authorization

Advantages:

Simplified operation: By granting resource usage rights at once, the complexity of frequent delegation and revocation of delegation is reduced, making the whole process simpler. Flexibility: Allowing one account (authorizing account) to authorize resources (usage rights actually) to multiple accounts with no need to repeat operations for each transaction, improves the flexibility of resource utilization. Security: Resources remain in the authorizing account and are only consumed when needed by the authorized accounts, reducing the risk of resource theft.

Disadvantages:

Resource locking: Once authorized, resources are locked and cannot be used for other purposes, affecting their liquidity. Management complexity: It is necessary to track and manage multiple authorization relationships, especially when there are a large number of authorized accounts, which increases the complexity of management. Dependency: The authorized accounts rely on the authorizing account for resource consumption. If there is a problem with the authorizing account (such as account being frozen), it may affect the authorized account's transactions.

Option 2: Multi-signature Payment with Designated Address

Advantage:

instantaneousness: No prior authorization of resources is required, and the payment address can be specified immediately when the transaction occurs, improving the immediacy of the transaction. Flexibility: The payment address is designated dynamically based on the needs of each transaction, providing higher flexibility. Resource utilization efficiency: Resources are not locked for periods and will only be used when actual transactions occur, improving the efficiency of resource utilization. Payer control: Payers have more control over whether to pay resources for particular transactions, as they need to explicitly agree on the resource consumption for each transaction.

Disadvantages:

Security issue: It is necessary to ensure the security of the multi-signature mechanism and prevent unauthorized resource consumption. Complexity: It is necessary to add fields or handle unknown fields for each transaction type (if using protobuf's unknown field), which increases the complexity of the system. Performance issue: The multi-signature mechanism may increase transaction processing time, especially when multi-signature verifications are required, which may affect overall performance. Dependency: Although dependency is immediate, if the designated payment address has insufficient resources or rejects payment, the transaction may not be completed.

Both options have their unique advantages and disadvantages:

Option one is more suitable for long-term stable resource authorization relationships, while option two provides higher flexibility and immediacy, meanwhile, brings higher complexity and potential security risks.

I prefer the second option, it is more flexible and does not need to worry about resource recycling.

[troncommons]

Here are the advantages and disadvantages of the two solutions I have summarized：

Option 1: Resource Usage Authorization

Advantages:

Simplified operation: By granting resource usage rights at once, the complexity of frequent delegation and revocation of delegation is reduced, making the whole process simpler. Flexibility: Allowing one account (authorizing account) to authorize resources (usage rights actually) to multiple accounts with no need to repeat operations for each transaction, improves the flexibility of resource utilization. Security: Resources remain in the authorizing account and are only consumed when needed by the authorized accounts, reducing the risk of resource theft.

Disadvantages:

Resource locking: Once authorized, resources are locked and cannot be used for other purposes, affecting their liquidity. Management complexity: It is necessary to track and manage multiple authorization relationships, especially when there are a large number of authorized accounts, which increases the complexity of management. Dependency: The authorized accounts rely on the authorizing account for resource consumption. If there is a problem with the authorizing account (such as account being frozen), it may affect the authorized account's transactions.

Option 2: Multi-signature Payment with Designated Address

Advantage:

instantaneousness: No prior authorization of resources is required, and the payment address can be specified immediately when the transaction occurs, improving the immediacy of the transaction. Flexibility: The payment address is designated dynamically based on the needs of each transaction, providing higher flexibility. Resource utilization efficiency: Resources are not locked for periods and will only be used when actual transactions occur, improving the efficiency of resource utilization. Payer control: Payers have more control over whether to pay resources for particular transactions, as they need to explicitly agree on the resource consumption for each transaction.

Disadvantages:

Security issue: It is necessary to ensure the security of the multi-signature mechanism and prevent unauthorized resource consumption. Complexity: It is necessary to add fields or handle unknown fields for each transaction type (if using protobuf's unknown field), which increases the complexity of the system. Performance issue: The multi-signature mechanism may increase transaction processing time, especially when multi-signature verifications are required, which may affect overall performance. Dependency: Although dependency is immediate, if the designated payment address has insufficient resources or rejects payment, the transaction may not be completed.

Both options have their unique advantages and disadvantages:

Option one is more suitable for long-term stable resource authorization relationships, while option two provides higher flexibility and immediacy, meanwhile, brings higher complexity and potential security risks.

Great analysis, and I also prefer option 2. One thing that need to be considered is the fee for this kind of transaction, like multi-signature transaction now, because it needs more resource than normal ones.
Hi guys, any suggestion for this?

[lxcmyf]

@toolsopen @abc-x-t
There are still some issues with

Multi signature Payment with Designated Address

that need further analysis and improvement. For example, if an account that requires proxy payment initiates a smart contract transaction, and the transaction involves energy consumption, there may be the following hidden dangers:

• Lack of transaction transparency:

The payment agent cannot directly see the actual consumption of the smart contract, which may lead to misjudgment of resource allocation, resulting in resource abuse or shortage.

• Internal consumption within the contract:

If the smart contract consumes energy internally and the payment agent is not informed or recorded in the contract logic, the payment agent may not be able to estimate or control the payment fee.

[317787106]

Hi guys, I have another soultion. Let me specify it.

Add a new system contract to implement the following functionality:

Account A can transfer x units of resources (resource type can be specified as bandwidth or energy) to Account B, converted into sun based on the real-time price and stored in two newly added fields in B's account. This transfer process is irreversible, and A's resources will recover within 24 hours.

The x units of resources received by B are for personal use only, cannot be transferred to other accounts, and are non-recoverable once used. When B initiates a transaction, the x units of received resources will be consumed first. Any remaining unused resources can be used for subsequent transactions. If the resources are insufficient, the standard resource consumption method will apply. A can transfer different amounts of resources to multiple accounts in a single operation.

To simplify storage and operational logic, A does not need to keep detailed records of each resource transfer, and B does not need to track the origin of transferred resources. B only needs to accumulate the same type of resources in the corresponding fields.

To prevent A from abusing the resource transfer function or causing database inflation, a minimum resource transfer threshold should be set for batch resource transfers, along with a special fee mechanism to ensure the system operates efficiently and fairly.

[King31T]

Hi guys, I have another soultion. Let me specify it.

Add a new system contract to implement the following functionality:

Account A can transfer x units of resources (resource type can be specified as bandwidth or energy) to Account B, converted into sun based on the real-time price and stored in two newly added fields in B's account. This transfer process is irreversible, and A's resources will recover within 24 hours.

The x units of resources received by B are for personal use only, cannot be transferred to other accounts, and are non-recoverable once used. When B initiates a transaction, the x units of received resources will be consumed first. Any remaining unused resources can be used for subsequent transactions. If the resources are insufficient, the standard resource consumption method will apply. A can transfer different amounts of resources to multiple accounts in a single operation.

To simplify storage and operational logic, A does not need to keep detailed records of each resource transfer, and B does not need to track the origin of transferred resources. B only needs to accumulate the same type of resources in the corresponding fields.

To prevent A from abusing the resource transfer function or causing database inflation, a minimum resource transfer threshold should be set for batch resource transfers, along with a special fee mechanism to ensure the system operates efficiently and fairly.

Firstly, Sounds complex. Secondly, I have two questions about 'converted into sun based on the real-time price and stored in two newly added fields in B's account'

1. What is the meaning of conversion to sun?
2. If we make this conversion, why do we still need two fields?

[angrynurd]

@317787106
I understand that the author's requirement in this issue is to implement flexible delegation of resource usage rights, hoping to maintain unchanged resource ownership while only delegating usage rights. However, your proposal appears to be a resource transfer mechanism that is irreversible and actually changes the ownership of resources (by converting to sun and transferring). Is this correct?