Proposal: Enable usage optimization for Stake 2.0

[lxcmyf]

Simple Summary

In order to further improve the flexibility of Stake 2.0, it is proposed that after the mainnet is upgraded to the Periander version, the Stake 2.0 extension will be enabled, please refer to TIP-541 and TIP-542.

Motivation

Stake 2.0 is a new milestone of the TRON network, which has fully upgraded the staking mechanism. Compared with Stake 1.0, Stake 2.0 is more flexible, efficient and intelligent, it significantly improves the flexibility of TRON network resources and voting management.

Since Stake 2.0 was enabled on the mainnet for more than two months, the community has put forward some suggestions for improvement:

• There is a waiting period of 14 days after unstaking in Stake 2.0, if users misoperate the unstaking transaction, or they change their mind during the waiting period and want to restake the TRX for earnings, for now, they can do nothing but wait for 14 days.

• Currently when users initiate a resource delegating transaction, if the lock parameter is set to true, the resource can not be undelegated within 3 days. However, the solid lockup time of 3 days can not meet all the scenarios and is not conducive to the two parties to agree on a lease time in advance. Making the lockup time a customizable time will enhance the flexibility in delegation transactions.

Therefore, GreatVoyage-v4.7.2(Periander) introduces TIP-541 and TIP-542. TIP-541 added a new governance proposal to allow users to cancel the unstaking that has been initiated but not yet completed, and TIP-542 added a new governance proposal to allow users to specify the resource delegating lockup time according to their needs.

Specification

Propose to modify the No.77 and No.78 TRON Network Parameters to enable the Stake 2.0 extension,

• getAllowCancelAllUnfreezeV2 (No.77) The No. 77 network parameter is set to 1, it means that the function of allowing cancellation of unstakings is enabled.

• getMaxDelegateLockPeriod (No.78) The No. 78 network parameter is set to a value larger than 86400, it means that the function of allowing specification of resource delegating lockup time is enabled. The value indicates the maximum value of the lock time that can be set, unit is block interval (3 seconds). So setting the value as 144000 means maximum locking time is 5 days (144000*3/24/60/60).

How to initiate the voting request

Enable the usage optimization for Stake 2.0,

• createProposal 77 1 78 864000

Analysis

After it is enabled, the nodes will support a new transaction type, and users can use the wallet/cancelallunfreezev2 API to create an unstaking canceling transaction:

curl -X POST http://127.0.0.1:8090/wallet/cancelallunfreezev2 -d \
'{
  "owner_address": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
  "visible": true
}'

The return value in the above example is an unsigned transaction, it should be signed and broadcasted then.

After the above transaction is successfully on chain, you can use wallet/gettransactioninfobyid to query the amount of unstaking TRX that canceled and the amount of unstaked TRX withdrawn to the account:

curl -X POST http://127.0.0.1:8090/wallet/gettransactioninfobyid -d \
'{"value":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
  "visible":true
}'

{
    ...
    "cancel_unfreezeV2_amount":[
        {
            "key": "BANDWIDTH",
            "value": 2000000000
        },
        {
            "key": "ENERGY",
            "value": 3000000000
        },
        {
            "key": "TRON_POWER",
            "value": 0
        }
    ],
    "withdraw_expire_amount": 1000000000
}

• cancel_unfreezeV2_amount: the amount of unstaking TRX that canceled, the unit is sun

  • BANDWIDTH: cancel_unfreezeV2_amount[0].value is the amount of TRX re-staked to obtain bandwidth, the unit is sun
  • ENERGY: cancel_unfreezeV2_amount[1].value is the amount of TRX re-staked to obtain energy, the unit is sun

• withdraw_expire_amount: the amount of unstaked TRX withdrawn to the account, the unit is sun

When enabling the proposal, a time parameter needs to be specified, indicating the maximum value of the lock time that can be set. Once enabled, a new parameter, lock_period, will be added to wallet/delegateresource API:

curl -X POST http://127.0.0.1:8090/wallet/delegateresource -d \
'{
  "owner_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
  "receiver_address": "TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1",
  "balance": 1000000,
  "resource": "ENERGY",
  "lock": true,
  "lock_period": 86400,
  "visible": true
}'

• lock: whether to lock the delegating
• lock_period: lock time, only when lock is true, this field is valid. The owner cannot cancel the delegating before the lock time is up. The unit of lock_period is block interval(3 seconds). This field indicates the time of how many blocks will be produced from the moment the transaction is executed. So the above 86400 means locking for 259200 seconds (3 days). lock_period cannot exceed the maximum lock period (value of the No.78 network parameter).

The default value of lock_period is 86400, which is 3 days. That is, when lock is true, if lock_period is not specified or set to 0, lock_period will be set to 86400 by default, which will ensure the compatibility before and after TIP-542 takes effect.

In addition, the minimum value of lock_period cannot be lower than the remaining lock time of this type of resource that was previously delegated to the same recipient address，and the value will overwrite the remaining lock time of the previous delegating.

For example, user A delegates 100 energy shares to B, and lock_period is set to 57600 (2 days), and the remaining lock time after 1 day is 28800. At this time, when A delegates energy to B again, if choose to lock,lock_period should be set to at least 28800 (1 day), otherwise, an exception error will be thrown when creating the delegating transaction: The lock period for ENERGY this time cannot be less will be thrown when creating a proxy transaction than the remaining time[9600000ms] of the last lock period for ENERGY!. If A choose to lock 86400, this will overwrite the remaining lock time from 1 day to 3 days.

Compatibility

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

[Jamestepfoward]

This is what we need, #542 will definitely make resource renting more easy. When will it be on mainnet, please leave some time for adopting these new features.

[Jackmrshen]

Good job, and TIP-541 will decrease the influence of 14 days waiting period, it provides with another option for users when they meets emergency during unstakings, that is cancel the unstaking, unstake it in just lend, and get the strx immediately.

[hitlxy]

Cancelling unstakes will indeed bring us a lot of convenience, users do not have to wait 14 days to reuse the unstaked funds. After re-stake the funds, voting for super representatives still needs to be re-voted manually, maybe that cannot be automated.

[lxcmyf]

@hitlxy Yes, this will make the functionality of the interface and voting function overly coupled, increasing complexity.

[LauraYH]

The 3-day lock setup impacts and limits the energy rental market so much, finally a solution is brought up. The unit of the parameter is bizarre, needs a little math.

[souppopnix]

I like these proposed features, cancel unstaking will allow us to reuse our resource/asset faster if needed. Being able to specify a custom locking period for delegations will give delegators and receivers more flexibility to agree on a lease time that suits their needs, sounds great to the energy market. I hope these features can be enabled soon to benefit the community.

[lxcmyf]

@souppopnix Yes, it's coming soon.

[L-Reid]

Custom locking period improves the resource allocation efficiency. But I think It is better that the unit of the lock-up period is the number of days, Because after the energy or bandwidth consumption, it needs almost one day to recover, so if the delegating period is very shot, a few blocks or minutes, even if the resources are recycled, they cannot be delegated again because they have been used.

[lxcmyf]

@L-Reid Some users have usage scenarios with lockdown periods of hours or even seconds. After resource consumption, it is dynamically restored, and can be restored even if it is less than a day, but cannot be fully restored. It is only a partial recovery of resources based on time.

[ferdinand026]

It is more reasonable for lock period to have a larger range and small unit, expected this proposal takes into effect.

[brooklynn1212]

What's the upper limit of getMaxDelegateLockPeriod, could it be as long as 30 days?

[lxcmyf]

@brooklynn1212 Yes, it is possible. The range of values for getMaxDelegateLockPeriod is (86400, 10512000], in blocks. The minimum is the number of blocks corresponding to 3 days, and the maximum is the number of blocks corresponding to 1 year. This will be determined through proposal voting.

[Jamestepfoward]

30 days is fine.

And a bit more suggestion, for the lock time, it needs some math, and it would be misleading for users cause the unit of block number is never seen in other field. And the parameter name lock_period will easily remind of time. Could it be made something like lock_block_intervals, otherwise some conspicuous remarks should be added somewhere to guide developers.

[MannGates]

I also noticed in #542 someone suggests to make the lock time 365 days. As it is only a limit parameter, why not make it larger? Maybe there is business involved in long-term resource delegating. It won't influence the short term delegating transactions right?

[Jamestepfoward]

I also noticed in #542 someone suggests to make the lock time 365 days. As it is only a limit parameter, why not make it larger? Maybe there is business involved in long-term resource delegating. It won't influence the short term delegating transactions right?

@MannGates There is an compatibility issue you should know that the upper limit parameter can only be adjusted larger in the future, it can not be smaller because otherwise the previous transactions of long lock time will be denied by nodes. That's why we should be cautious setting this value. I think 30 days meets the most requirement, if there is such situation that need lock time of 1 year, please name some, or we can discuss later.

[MannGates]

I also noticed in #542 someone suggests to make the lock time 365 days. As it is only a limit parameter, why not make it larger? Maybe there is business involved in long-term resource delegating. It won't influence the short term delegating transactions right?

@MannGates There is an compatibility issue you should know that the upper limit parameter can only be adjusted larger in the future, it can not be smaller because otherwise the previous transactions of long lock time will be denied by nodes. That's why we should be cautious setting this value. I think 30 days meets the most requirement, if there is such situation that need lock time of 1 year, please name some, or we can discuss later.

I see, then 30 days is fine. I never see long-term renting scenarios indeed for now.

[Jackmrshen]

It seems only nile network and wallet cli supports this proposal, when will tronweb includes this?

And a bit more suggestion, for the lock time, it needs some math, and it would be misleading for users cause the unit of block number is never seen in other field. And the parameter name lock_period will easily remind of time. Could it be made something like lock_block_intervals, otherwise some conspicuous remarks should be added somewhere to guide developers.

It would not be a serious problem, since dapps will not use this this unit, probably I will use unit of second on user interface, and input the corresponding block numbers calling the API, users won't be sensitive for several seconds.

[brooklynn1212]

Good to know, and it provides users with more control over their staking process, they can more easily move their funds to other projects or save their funds without having to wait until their staking period has ended. This also helps to reduce the risk of a funds being locked up for too long if the user decides to switch projects or opt out of a project altogether.

[KrisdiaPaul]

Last time the implementation of Stake 2.0 makes resource delegating more easily and flexible, which also leads to increase of low-value transactions. If this is to make it more flexible, I'm afraid that the volume of low-value transactions will increase more.

[Jackmrshen]

Last time the implementation of Stake 2.0 makes resource delegating more easily and flexible, which also leads to increase of low-value transactions. If this is to make it more flexible, I'm afraid that the volume of low-value transactions will increase more.

Some low-value transactions utilize delegated resources indeed, but the main reason was free bandwidth. The modification in this proposal add no convenience for saving resources. I do not think these changes will promote the low-value transactions.

[lxcmyf]

Thanks to all your discussion on this proposal. This issue will be closed as it has already taken effect, please check it here: https://tronscan.org/#/proposal/88