Draft Proposal for Limit on bandwidth spend within Permission Model / for Resource Delegation/Reclaim transactions

[corytam]

Background

I was trying to understand about energy rental and the permission model , and thought that as a seller of energy , the permission model could be improved to enhance security of user's accounts when delegating resources to external accounts.

Simply , a feature within the permission model to prevent spending beyond available bandwidth/energy natively.

I see that some energy platforms give energy sellers an option to set a minimum energy/bandwidth limit to maintain and if this was native , it would be a great feature.

Rationale

I understand for multisig accounts , this issue can be avoided since all/enough parties (with the appropriate weightage) need to sign and approve transactions.
But in pursuit of efficiency and a solution for a non-multisig solution (in regards to energy selling/ resource delegation) which is more easily automated/executed due to simplicity , I believe these features will not only make delegation of resources fully trustless , but simplify and enhance the energy rental process . It could lead to lower overhead/ reduction in middle man costs on energy rental and hence may even lower energy costs for end-users as it becomes safer to delegate resources.

Scenario

Account A gives permission to Account B for delegating/reclaiming resource , Account B delegates Account A energy/bandwidth to Account C , spending bandwidth of Account A

The issue I see is that , correct me if I'm wrong , bandwidth spent to execute delegating /reclaiming resources is on the main account (Account A) when the external account (Account B) is the one executing the transaction.

From what I can see, this could lead to malicious draining of accounts through spam transactions at worse and at best unintentional burning of TRX.

*Note it seems like all permissions for transactions e.g transfer TRX, staking , voting will face this issue. Obviously "transfer TRX" permission gives basically control of the TRX assets in an address , but for other use cases for giving permission of staking or voting , these transactions would cost bandwidth and it is spent from Account A and you may not want to give permission away to "spend" TRX through transaction fees.

Important

This leads to a issue of trust when delegating resources and we should always aim for a trustless solution.

Right now , delegators (energy sellers) need to trust platforms that they will not burn TRX in order to execute delegation and reclaim transactions should the account run out of bandwidth.

What are the use-cases?

-Resource delegators/energy sellers providing resources to energy platforms/third parties without having to trust them that their TRX will not be burned without permissions / limits prevent accidental or nefarious attacks.

-End-users want to prevent accidental burn of TRX by accident when they run out of bandwidth/energy.

-Enabling Managed Staking service (permissions - stake , unstake , vote) without the risk of burning of TRX

Specification

Test Specification

Scope Of Impact

-Permission model
-Transaction payment overhaul

Implementation

One or more of the following options ( there may be alternatives as well)

Option 1) Transaction resource payer permission
A permission setting to make all accounts that have given away resource delegation permissions ( delegate and reclaim) will make the caller/transaction executor (external accounts given the permission) pay the bandwidth.

If permissioned tenant (Account B) is given this permission , Account B will pay for bandwidth ( technically could reverse the logic of this permission e.g pay for transaction cost if lacking the permission)
For backwards compatibility , maybe it will have to be Account B paying for bandwidth when given the permission.

Option 2) -TRX Burn for transaction resource permission
A permission / setting to prevent the account from burning tron for energy/bandwidth and only use bandwidth/energy from staked TRX

If an account does not have this permission e.g resourceBurnController , only available/staked energy and bandwidth can be used for transactions.

Option 3) Limit to minimum bandwidth/energy required in account
A setting to set a threshold on minimum bandwidth to maintain ( and no TRX will be burned for energy /bandwidth)
This option can be useful for even non energy-sellers, who either run out of bandwidth by accident after executing too many transactions and forget to check that they are out.
If limit is hit , error occurs when trying to sign transaction

For this, value of -1 could mean no minimum bandwidth and any number above will set the minimum bandwidth to maintain.

Disclaimer

Please excuse my misunderstandings if any and let me know how to improve this.

EDITTED: Updated some terms to clarify example cases ( in particular the naming of Account B as a tenant instead of delegatee) and added more comments

[lxcmyf]

@corytam
In the Tron network, if the account initiating a transaction lacks its own resources, it will burn TRX to offset the transaction fee. This is a common feature of all transactions, and it is not limited to transactions involving delegating resources and undelegating resources. For option 1 you mentioned, when the delegator initiates or cancels a transaction involving delegating resources, the tenant pays the transaction fee. Why is this done? Who initiated the transaction and who pays the transaction fee. Regarding option 2, I understand that it is actually setting an optional parameter for the transaction to determine whether to burn trx when the account resources are insufficient. Does that mean that all types of transactions can have this optional parameter set, which may affect the efficiency of the transaction being uploaded to the chain? Finally, for option 3, resources are continuously restored over time, and setting this threshold may not be meaningful. Tron actually provides a getaccount or getaccountresource interface to query the available resources of the account, which can be used to customize the interception of transactions that may be burned with trx. This question is worth discussing and thinking about, and perhaps a better solution is on the way.

[corytam]

@lxcmyf Oh let me clarify after having a better understanding now with permissions which technically is multisig.

For option 1 , I assume the "tenant"/delegatee/tx caller is signing a transaction since the resource and tron belongs to the account (Account A), the account still pays the bandwidth and not the delegatee(Account B) (and Account B is delegating resource to Account C which gets the resources)

In this case i meant delegator and delegatee refers to permissions. Maybe I should be saying Owner and permission holder ?

Interestingly , the tx caller (Account B) should be the one signing the transaction to (delegate to account C) , I assume it is treated like Account B is signing a transaction on behalf of Account A and hence Account A has to pay for the bandwidth.

This would seem like option 1 is not feasible UNLESS a similar option /permission is given where when given , permission (Account B) will sponsor/ pay bandwidth on behalf of the owner ( Account A.)

P.S
Sorry i missed clicked closing the issue

[lxcmyf]

@corytam
Has the above reply answered your question? If you have any new confusion, please feel free to ask at any time.

[lxcmyf]

@corytam
The current problem lies in the granting of multi signature permission to another account for delegating resource usage. For example, account A grants account B multi signature permission for delegating resource usage. However, when account A sets the multi signature threshold to 1, this means that either account A or B can control the resource usage of account A, and account B can initiate multi signature transactions without any hesitation, consuming a's resources. The core point is that this is actually a risk exposed by the A account itself when setting multiple signing authorization limits.

[corytam]

@lxcmyf Yes I understand your point and as it stands today , giving any permission to external accounts (Account B) runs the risk of consumption of TRX via burning for energy/bandwidth. Realized this during the Core Dev community call and I think someone brought it up.

However ,that defeats the purpose of a permission model similar to attribute based access control (ABAC) since there is 1 permission that is not implemented which is the "spending" of TRX for burning for transactions which would affect the point of the permission model to limit access to certain actions , since all transactions (that are governed by the "active permissions" features like staking , reclaim resource , voting for SR) use bandwidth and TRX may be burned for transactions.

---

Quote:

The core point is that this is actually a risk exposed by the A account itself when setting multiple signing authorization limits.

Response:
This is precisely my point to improve the current permission model , this risk shouldnt be built into the permission model in the first place and should be solved by the permission model itself.

---

There is a permission for transfer of TRX which gives accounts who have the permissions to transfer TRX and basically control of the TRX of the account, but there is this edge case that is not covered that technically allows access to TRX in some way.

Hence , my proposal is to cover for this edge case , which seems to be a attack vector for malicious dapps / actors or even an possible mistake when accounts are controlled/managed by API.

So just like a permission to transfer TRX or to stake TRX , a permission should be made to "spend" TRX for resource burn for transactions when not enough energy/bandwidth available.
If there is no permission for this , transaction cannot be signed and will fail if insufficient energy/bandwidth ( Account will need to have staked trx for energy / bandwidth)

[lxcmyf]

@corytam
Yes, I understand your suggestion. In this way, any type of transaction can autonomously choose whether to burn TRX to offset the resources consumed by the transaction when resources are insufficient, not just limited to delegating resource and undelegating. It is still recommended that accounts assess risks and operate with caution when granting multi-signature permissions. Such high-risk edge scenarios are not suitable for frequent use in this way.

[vivian1912]

@corytam Thanks for your contribution to java-tron. May I ask if the above answer your question?

Because this issue has no update for a long time, if there is no other comments, it will be closed later, and please feel free to re-open it if you still see the issue, thanks.