Automatic reclaim for locked delegations

tronenergymarket commented 9 months ago

tip: <to be assigned>
title: Automatic reclaim for locked delegations
author: Tee <admin@tronenergy.market>
discussions-to: https://github.com/tronprotocol/tips/issues/632
status: Draft 
type: Standards Track 
created: 2023-12-06

Simple Summary (required)

Add a reclaim parameter in the wallet/delegateresource API in Stake 2.0, to support delegating bandwidth or energy resource with an automatic reclaim.

Abstract (required)

Besides the current API wallet/delegateresource that allows users to lockup for specific time before the resource could be undelegated, it is proposed to add a parameter reclaim in this API to support automatic reclaim in resource delegating, with boolean. When that parameter is true the resource will be automatically reclaimed to the original delegator.

Motivation (required)

Currently in Stake 2.0, each resource delegation require another reclaim transaction. Is it known that in current energy / bandwidth markets it requires to duplicate each order, one for delegating the resource and one for reclaiming it.

This makes a big waste of low-value transactions which can be saved having that parameter. The addition of the parameter will also be good to simplify the delegation between pairs, simplifying the interaction and not having to remember to claim that resource back.

Also in the current situation delegating to the same address which has an expired time makes it moves to the unlocked bag, making it very difficult to track for the energy markets in complex situations and putting energy providers in ugly situations with unclaimed delegations for that fact.

Specification (required)

Modify wallet/delegateresource API, the user can call this API to delegate bandwidth or energy resource with a reclaim parameter to make the system automatic reclaim.

Params:

owner_address - Address of transaction initiator, data type is string
receiver_address - Receiver address of resource to be delegated to, data type is string
balance - Amount of TRX staked for resources to be delegated, unit is sun, data type is unit256
resource - Resource type, "BANDWIDTH" or "ENERGY", data type is string
lock - Whether it is locked. If it is set to false, there will not be any lockup time no matter what the lock_period value is. If it is set to true, the delegating transaction will have a lockup time, and the time is decided by the lock_period value.
lock_period - The lockup period, unit is blocks, data type is int256, It indicates how many blocks the resource delegating is locked before it can be undelegated. If the lock time is not over, and the owner delegates the same type of resource with a new lockup time to the same address, the lockup time of all the resource of the same type will be reset to the new lockup time.That new lockup time cannot be less than (old lockup time + old transaction timestamp) - current time.
visible - Whether the address is in base58 format, data type is bool
reclaim -Whether it is automatic reclaimed. If it is set to false, there will not be no reclaim back after the expiration time. If it is set to true and 'locked_period' is set, the delegating resource will be back to the user automatically after expiration time.

Returns: unsigned transaction, data type is JSON string

Example:

curl -X POST https://127.0.0.1:8092/wallet/delegateresource -d \
'{
  "owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",     
  "receiver_address":"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",     
  "balance":1000000000,     
  "resource":"BANDWIDTH",     
  "lock": true,
  "lock_period": 86400,
  "visible":true,
  "reclaim": true
}'

Rationale

The design of using a boolean parameter seems the most feasable way because it simplify the backward compatibility and doesn't introduce any extra complexity in the api. There is also other alternatives for the 'reclaim' name which could be 'lock_reclaim' because it's directly related to the locked_period.

Backward Compatibility

It will not influence the existed staking and unstaking related transactions.

If the lock is set to true, and reclaim is set to false, or left blank, it will have no effect. Also if 'lock' is set to 'false' it won't have any effect.

ferdinand026 commented 9 months ago

Good suggestion, but I think it may be difficult to implement. Now we can delegate some resources to someone more times, auto-reclaim will be complicated.

tronenergymarket commented 9 months ago

Good suggestion, but I think it may be difficult to implement. Now we can delegate some resources to someone more times, auto-reclaim will be complicated.

The system would launch just whenever the lock_period expires. If an user continue delegating extending the time the system wouldn't activate.

tomatoishealthy commented 9 months ago

@tronenergymarket

Different from the traditional Internet, there is a certain complexity in implementing a scheduled task on the blockchain. The above description only lists the changes in APIs. Is it possible to provide a more detailed implementation? For example:

When to trigger reclaim operation
Whether the fees need to be adjusted
Whether it will lead to flooding attacks, and if so, how to avoid it
When will the parameters be turned on and how to ensure data consistency when switching between old and new versions

jwrct commented 9 months ago

@tronenergymarket I believe that any operation that changes account information in a blockchain system should be triggered by the account itself, which is reasonable. It is unreasonable and extremely difficult for the system to automatically trigger the withdrawal of delegation.

lxcmyf commented 9 months ago

@tronenergymarket java-tron aims to provide some basic underlying interfaces. The common ways to implement scheduled tasks on the blockchain are as follows: smart contract implementation and external scheduler. If these two methods are excessively coupled with the chain, it will increase the complexity of transaction and cost calculation. If you want to achieve automatic undelegating, you can completely control it through your own services upstream, so as not to interfere with the call and execution of the underlying interface.

tronenergymarket commented 9 months ago

I understand it and the complexities are over the improvements in this little feature.

Thank you all for your comments and time. I still think it should be great that tron blockchain could create somehow more generic schedule transactions.

CarlChaoCarl commented 8 months ago

At present, it is not possible to automatically recycle locked delegates. This can be discussed after the chain supports scheduled tasks.

lxcmyf commented 6 months ago

Due to the involvement of complex development work and potential security risks, this feature will not be supported temporarily.

tronprotocol / tips