search

tronprotocol / tips

TRON Improvement Proposals
221 stars 187 forks source link

Stake 2.0 - A new TRON stake model #467

Closed lxcmyf closed 1 year ago

lxcmyf commented 1 year ago 
tip: 467
title: Stake 2.0 - A new TRON staking model 
author: lxcmyf@gmail.com
discussions-to: https://github.com/tronprotocol/tips/issues/467
status: Final
type: Standards Track 
category : Core
created: 2022-09-28

Simple Summary

This TIP aims to establish a more flexible stake model, called Stake 2.0, Stake 2.0 can improve the utilization of network resources, and at the same time enhance the stability of the TRON stake system.

Motivation

At present, by staking TRX on the TRON network, you can obtain voting rights called TRON Power, as well as bandwidth or energy as resources. The users need to choose whether to obtain whether energy or bandwidth during the stake operation. The obtained resources can also be delegated to other addresses only if they are specified when staking. Once the staking is completed, it is not allowed to unstake within 3 days. Then, the users can perform the unstake operation and immediately obtain the staked TRX.

The delegating of resources under the current stake mechanism is hardly flexible, resulting in low resource utilization and complicated user operations. The stake and delegating operation are bound together at present. If you want to alter your resource delegating object, you need to perform unstaking first, then make another staking and designate a new delegating object. Additionally, the unstake operation must wait for 3 days after staking, which means that the resources obtained cannot be re-delegated to others within 3 days. If the user has already voted before unstaking, the unstake operation will also result in the automatic cancellation of the vote. Hence, all these rules greatly reduce the efficiency of resource allocation and incur extremely complicated user operations to stake and delegate at will.

Since the TVM does not support stake, vote, or delegate commands, the developers are not able to implement related operations in a smart contract, which limits the applications involved staking and delegating, like tokenization and decentralized resource exchange. In addition, the principal will arrive immediately after the stake is released, when the TRX market fluctuates violently, a large number of staking or unstaking operations will be triggered, which will also have a certain impact on the overall stake model.

Therefore, we need a new stake mechanism to solve these problems, separate low-frequency staking operations and high-frequency resource delegating operations, support resource re-delegating without unstaking, and improve resource utilization. Add stake, delegate, vote, and related commands should be added in the TVM, meanwhile, the new mechanism should implement the delayed arrival of unstaking TRX, improve the stability of the stake model under extreme market conditions, and help network participants to form more stable expectations for the total circulation of the entire network.

Specifications

Based on the description above, a newly designed staking model is shown as below, seven new APIs should be added to the java-tron client:

and six new opcodes should be added to TVM: FREEZEBALANCEV2, UNFREEZEBALANCEV2, DELEGATERESOURCE, UNDELEGATERESOURCE, CANCELALLUNFREEZEV2, WITHDRAWEXPIREUNFREEZE

Mechanism

The mechanism of Stake 2.0 is shown as follows:

Specification in undelegateresource

If the recipient has consumed a part of the resource, after undelegating, this part of resources will still be not available status in the owner account, and needs some time to recover. The owner can only delegate the available resources to others.

Example：

Specification in unstake

TRX partial unstaking is supported, but a maximum of 32 partial unstaking operations is allowed simultaneously, in other words, there should be no more than 32 delay arrivals of the unstaking assets in progress at the same time.

Example,

Unstaking will first reclaim the idle TRON Power, then the TRON Power that has been used. For the reclaiming of TRON Power that has been used, if vote for multiple SRs, it will revoke votes in proportion.

Example：

Specification of HTTP APIs

/wallet/freezebalancev2

Description: stake TRX to obtain TRON Power (voting rights) and bandwidth or energy.

Params:

  1. owner_address - Address of transaction initiator, data type is string
  2. frozen_balance - Amount of TRX to be staked, unit is sun, data type is uint256
  3. resource - Resource type, "BANDWIDTH" or "ENERGY", data type is string
  4. visible - Whether the address is in Base58 format, data type is bool

Returns - unsigned transaction, data type is json string

Example:

curl -X POST  http://127.0.0.1:8092/wallet/freezebalancev2 -d  \
'{"owner_address":"TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
 "frozen_balance":1000000,
 "resource":"BANDWIDTH",
 "visible":true
}'

/wallet/unfreezebalancev2

Description: Unstake TRX to release bandwidth and energy and at the same time TRON Power will be reduced and all corresponding votes will be canceled.

Params:

  1. owner_address - Address of transaction initiator, data type is string
  2. unfreeze_balance - Amount of TRX to be unstaked, unit is sun, data type is uint256
  3. resource - Resource type, "BANDWIDTH" or "ENERGY", data type is string
  4. visible - Whether the address is in base58 format, data type is bool

Returns - unsigned transaction, data type is json string

Example:

curl -X POST  http://127.0.0.1:8092/wallet/unfreezebalancev2 -d  \
'{"owner_address":"TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
 "unfreeze_balance":1000000,
 "resource":"BANDWIDTH",
 "visible":true
}'

/wallet/delegateresource

Description: delegate resource

Params:

  1. owner_address - Address of transaction initiator, data type is string
  2. receiver_address - Receiver address of resource to be delegated to
  3. balance - Amount of TRX staked for resource to be delegated, unit is sun, data type is unit256
  4. resource - Resource type, "BANDWIDTH" or "ENERGY", data type is string
  5. lock - Whether it is locked, if it is set to true, the delegated resources cannot be undelegated within 3 days.When the lock time is not over, if the owner delegates the same resources using the lock to the same address, the lock time will be reset to 3 days
  6. visible - Whether the address is in base58 format, data type is bool

Returns - unsigned transaction, data type is json string

Example:

curl -X POST  http://127.0.0.1:8092/wallet/delegateresource -d  \
'{"owner_address":"TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
 "receiver_address":"TQ4gjjpAjLNnE67UFbmK5wVt5fzLfyEVs3",
 "balance":1000000,
 "resource":"BANDWIDTH",
 "lock": true,
 "visible":true
}'

/wallet/undelegateresource

Description: undelegate API

Params:

  1. owner_address - Address of transaction initiator, data type is string
  2. receiver_address - Receiver address of resource to be delegated to
  3. balance - Amount of TRX staked for resource to be undelegated, unit is sun, data type is unit256
  4. resource - Resource type, "BANDWIDTH" or "ENERGY", data type is string
  5. visible - Whether the address is in base58 format, data type is bool

Returns - unsigned transaction, data type is json string

Example:

curl -X POST  http://127.0.0.1:8092/wallet/undelegateresource -d  \
'{"owner_address":"TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
 "receiver_address":"TQ4gjjpAjLNnE67UFbmK5wVt5fzLfyEVs3",
 "balance":1000000,
 "resource":"BANDWIDTH",
 "visible":true
}'

/wallet/withdrawexpireunfreeze

Description: withdraw unfrozen balance API

Params:

  1. owner_address - Address of transaction initiator, data type is string
  2. visible - Whether the address is in base58 format, data type is bool

Returns - unsigned transaction, data type is json string

Example:

curl -X POST  http://127.0.0.1:8092/wallet/withdrawexpireunfreeze -d  \
'{
  "owner_address":"TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
  "visible":true
 }'

/wallet/getavailableunfreezecount

Description: remaining times of available unstaking API

Params:

  1. owner_address - account address, data type is string.
  2. visible - whether the address is in base58 format, data type is bool

Returns - Remaining times of available unstaking, data type is number.

Example:

curl -X POST  http://127.0.0.1:8092/wallet/getavailableunfreezecount -d  \
'{
  "owner_address":"TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
  "visible":true
 }'

/wallet/getcanwithdrawunfreezeamount Description: query the withdrawable balance at the specified timestamp

Params:

  1. owner_address - account address, data type is string.
  2. timestamp - query cutoff timestamp, in millisecond.
  3. visible - Whether the address is in Base58 format, data type is bool

Returns - withdrawable balance，unit is sun.

Example:

curl -X POST  http://127.0.0.1:8092/wallet/getcanwithdrawunfreezeamount -d  \
'{
  "owner_address":"TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
  "timestamp": 1667977444000
  "visible":true
 }'

/wallet/getcandelegatedmaxsize Description: query the amount of delegatable resources of the specified resource Type for target address, unit is sun.

Params:

  1. owner_address - account address, data type is string.
  2. type - resource type，data type is number, 0 is bandwidth, 1 is energy
  3. visible - whether the address is in base58 format, data type is bool

Returns - the amount of delegatable resource, unit is sun.

Note: The interface indicates the return of the maximum amount of delegated resources for normal transactions, but there are some special transactions in actual situations, such as multi-signature, memo and other transactions that will deduct a part of the resource usage. At this time, the maximum value of specific resources that can be used may be smaller than the recommended value returned through this interface.

Example:

curl -X POST  http://127.0.0.1:8092/wallet/getcandelegatedmaxsize -d  \
'{
  "owner_address": "TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
  "type": 1,
  "visible": true
 }'

/wallet/getdelegatedresourcev2

Description: query the amount of resources detail delegated by fromAddress to toAddress

Params:

  1. fromAddress - resource from address, data type is string.
  2. toAddress - resource to address, data type is string.
  3. visible - whether the address is in base58 format, data type is bool

Returns - Resource delegation information

Example:

curl -X POST  http://127.0.0.1:8092/wallet/getdelegatedresourcev2 -d  \
'{
  "fromAddress": "TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
  "toAddress": "TQ4gjjpAjLNnE67UFbmK5wVt5fzLfyEVs3",
  "visible": true
 }'

/wallet/getdelegatedresourceaccountindexv2

Description: query the resource delegation index by an account

Params:

  1. value - account ddress, data type is string.
  2. visible - whether the address is in base58 format, data type is bool

Returns - Resource delegation index

Example:

curl -X POST  http://127.0.0.1:8092/wallet/getdelegatedresourceaccountindexv2 -d  \
'{
  "value":"TJAVcszse667FmSNCwU2fm6DmfM5D4AyDh",
  "visible": true
 }'

Specification of TVM instructions

0xda: FREEZEBALANCEV2

The FREEZEBALANCEV2 takes 2 operands pop up from stack:

If operation succeed, push 1 to stack, otherwise push 0 to stack.

0xdb: UNFREEZEBALANCEV2

The UNFREEZEBALANCEV2 takes 2 operands pop up from stack.

If operation succeed, push 1 to stack, otherwise push 0 to stack.

0xdc: CANCELALLUNFREEZEV2

The CANCELALLUNFREEZEV2 takes no operand pop up from stack.

If operation succeed, push 1 to stack, otherwise push 0 to stack.

0xdd: WITHDRAWEXPIREUNFREEZE

The WITHDRAWEXPIREUNFREEZE takes no operand pop up from stack.

If operation succeed, push the actual withdrawal amount to stack, otherwise push 0 to stack.

0xde: DELEGATERESOURCE

The DELEGATERESOURCE takes 3 operands pop up from stack:

If operation succeed, push 1 to stack, otherwise push 0 to stack.

0xdf: UNDELEGATERESOURCE

The UNDELEGATERESOURCE takes 3 operands pop up from stack:

If operation succeed, push 1 to stack, otherwise push 0 to stack.

Specification of precompile contracts

0x100000b: GetChainParameter

The GetChainParameter takes 1 parameters:

index: index of the parameter to be queried.

Query the specific chain parameters, and push the query result to stack. The solidity syntax is shown below.

0x100000c: AvailableUnfreezeV2Size

The AvailableUnfreezeV2Size takes 1 parameters:

target: target account address.

Query the size of the available unfreeze queue for target address, and push the query result to stack.

0x100000d: UnfreezableBalanceV2

The UnfreezableBalanceV2 takes 2 parameters:

target: target account address.

resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.

Query the unfreezable balance of a specified resourceType for target address, and push the query result to stack.

0x100000e: ExpireUnfreezeBalanceV2

The ExpireUnfreezeBalanceV2 takes 2 parameters:

target: target account address.

timestamp: query cutoff timestamp.

Query the withdrawal balance at the specified timestamp for target address, and push the query result to stack.

0x100000f: DelegatableResource

The DelegatableResource takes 2 parameters:

target: target account address.

resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.

Query the amount of delegatable resources(unit: SUN) of the specified resourceType for target address, and push the query result to stack.

0x1000010: ResourceV2

The ResourceV2 takes 3 parameters:

target: target account address.

from: from account address.

resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.

Query the amount of resources(unit: SUN) of a specific resourceType delegated by from address to target address

0x1000011: CheckUnDelegateResource

The CheckUnDelegateResource takes 3 parameters:

target: target account address.

amount: resource amount to undelegate in SUN.

resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.

Check whether the contract can recycle the specified amount of resources of a specific resourceType that have been delegated to target address, and push the amount of clean resource(unit: SUN), the amount of dirty resource(unit: SUN) and the restore time to stack.

0x1000012: ResourceUsage

The ResourceUsage takes 2 parametes:

target: target account address.

resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.

Query the usage of a specific resourceType of resources for target address, and push the amount of usage(unit: SUN) and the restore time to stack.

0x1000013: TotalResource

The TotalResource takes 2 parameters:

target: target account address.

resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.

Query the total amount of available resources(unit: SUN) of a specific resourceType for target address, and push the query reslut to stack.

0x1000014: TotalDelegatedResource

The TotalDelegatedResource takes 2 parameters:

target: target account address.

resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.

Query the amount of delegated resources of a specific resourceType for target address, and push the query reslut to stack.

0x1000015: TotalAcquiredResource

The TotalAcquiredResource takes 2 parameters:

target: target account address.

resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.

Query the amount of acquired resources(unit: SUN) of a specific resourceType for tareget address, and push the query reslut to stack.

Solidity example

Here is an example showing how to call the above TVM instructions in solidity：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

contract FreezeV2Example {

    event BalanceFreezedV2(uint, uint);
    event BalanceUnfreezedV2(uint, uint);
    event AllUnFreezeV2Canceled();
    event ExpireUnfreezeWithdrew(uint);
    event ResourceDelegated(uint, uint, address);
    event ResourceUnDelegated(uint, uint, address);

    constructor() payable {}

    fallback() payable external {}

    receive() payable external {}

    function freezeBalanceV2(uint amount, uint resourceType) external {
        freezebalancev2(amount, resourceType);
        emit BalanceFreezedV2(amount, resourceType);
    }

    function unfreezeBalanceV2(uint amount, uint resourceType) external {
        unfreezebalancev2(amount, resourceType);
        emit BalanceUnfreezedV2(amount, resourceType);
    }

    function cancelAllUnfreezeV2() external {
        cancelallunfreezev2();
        emit AllUnFreezeV2Canceled();
    }

    function withdrawExpireUnfreeze() external returns(uint amount) {
        amount = withdrawexpireunfreeze();
        emit ExpireUnfreezeWithdrew(amount);
    }

    function delegateResource(uint amount, uint resourceType, address payable receiver) external {
        receiver.delegateResource(amount, resourceType);
        emit ResourceDelegated(amount, resourceType, receiver);
    }

    function unDelegateResource(uint amount, uint resourceType, address payable receiver) external {
        receiver.unDelegateResource(amount, resourceType);
        emit ResourceUnDelegated(amount, resourceType, receiver);
    }

    function getChainParameters() view public returns(uint, uint, uint, uint, uint) {
        return (chain.totalNetLimit, chain.totalNetWeight,
                chain.totalEnergyCurrentLimit, chain.totalEnergyWeight,
                chain.unfreezeDelayDays);
    }

    function getAvailableUnfreezeV2Size(address target) view public returns(uint) {
        return target.availableUnfreezeV2Size();
    }

    function getUnfreezableBalanceV2(address target, uint resourceType) view public returns(uint) {
        return target.unfreezableBalanceV2(resourceType);
    }

    function getExpireUnfreezeBalanceV2(address target, uint timestamp) view public returns(uint) {
        return target.expireUnfreezeBalanceV2(timestamp);
    }

    function getDelegatableResource(address target, uint resourceType) view public returns(uint, uint) {
        return (target.delegatableResource(resourceType), block.number);
    }

    function getResourceV2(address target, address from, uint resourceType) view public returns(uint) {
        return target.resourceV2(from, resourceType);
    }

    function checkUnDelegateResource(address target, uint amount, uint resourceType) view public returns(uint, uint, uint, uint) {
        (uint clean, uint dirty, uint restoreTime) = target.checkUnDelegateResource(amount, resourceType);
        return (clean, dirty, restoreTime, block.number);
    }

    function getResourceUsage(address target, uint resourceType) view public returns(uint, uint, uint) {
        (uint dirty, uint restoreTime) = target.resourceUsage(resourceType);
        return (dirty, restoreTime, block.number);
    }

    function getTotalResource(address target, uint resourceType) view public returns(uint) {
        return target.totalResource(resourceType);
    }

    function getTotalDelegatedResource(address from, uint resourceType) view public returns(uint) {
        return from.totalDelegatedResource(resourceType);
    }

    function getTotalAcquiredResource(address target, uint resourceType) view public returns(uint) {
        return target.totalAcquiredResource(resourceType);
    }

    function killme(address payable target) external {
        selfdestruct(target);
    }
}

Backward Compatibility

After the proposal of the new mechanism is opened, it will not affect the previously frozen TRX. For those TRX frozen through the old mechanism, it can be redeemed using the old unstake interface. If needed, the only way to stake in the future is through the new mechanism.

BlueSkyXN commented 1 year ago

GOOD

clarklee186 commented 1 year ago

Great thought.

CryptoRhinoGH commented 1 year ago

It sounds like not such a bad idea, however the implementation is not clear at all. In tron currently, there is a huge market for selling energy. In that sense, the current model provides stability and security to these buyers who are expecting to receive the energy for at least 3 days with the current model. I believe, due to this reason, redelegating should just be implemented with the current time frame(min freeze time). Apart from this, the max freeze time should be increased allowing users to freeze for more number of days as set while freezing. Once the amount is frozen, the redelegation should not be until The unfreeze time has been reached as set in the freeze/redelegation transaction. This would ensure protection of buyers of energy, apart from it having an inclination towards lesser unfreezes (for improved TRX stability which might be very less, but could also be pretty effective) as well.

The redelgation of resources would be a wonderful idea if/when implemented, as it would reduce bandwidth costs of having to vote, unfreeze and refreeze, which could just be written over with a simple method of changing the address the resources are delegated to.

On the other hand, as a developer, I can see this having a slight number of issues with choosing the best lath for implementation. One such main issue that immediately comes to mind is the amount which you're redelgating. What if someone wants to redelegate a larger amount than that frozen for one account? Would you allow them to input a larger for TRX staked and use another frozen amount from another account (from lowest to highest unfreeze time that has passed)?

To make this question more clear, let's stake an example. For example addr x had 3000 TRX staked, addr y (with a larger unfreeze time than x which has also passed) has 3000 TRX staked. You redelegate 4000 TRX. In terms of efficiency, would it be better to use 3000 from addr x and 1000 from addr y? Or to limit the usage to 3000 and redelagting from just addr x and then redelgating 1000 from addr y? Even in this case, does the remaining 2000 for addr y have a new unfreeze time or not?

There are plenty of ways to implement this. Although I would love to hear more about specifically how redelgation would help in times of market fluctuations to keep TRX stable? And what implications (as mentioned by you) does it have on the stake model currently?

caohuiboss commented 1 year ago

I agree with this proposal, which is conducive to the efficient use of tron's resources, but I still have the following questions

  1. Do I need to wait for three days to transfer the resources that I have frozen to user a's address directly to user b's address without unfreezing?
  2. Will the voting change after the transfer?
  3. Will unfreezeBalance in tronweb be canceled directly in the future, or is it only used when I need to recover all the resources in the end?
  4. If there is no freeze time limit, does it mean that we can flexibly choose the freeze time? What is the time interval?
  5. Suppose my address has a trx of 2w resources. Now I have frozen 10,000 resources for user a, and I will freeze 2w resources for user b in the next two days. Will there be a dynamic merge operation, such as automatically merging the resources of user a? Should I freeze b with my remaining resources, or can I only do it step by step?
  6. Assuming the proposal is implemented, will it affect me if I still use the previous model?
lxcmyf commented 1 year ago

@CryptoRhinoGH My expectation is that after upgrading, unstaking can only be released from the available resources. The resources that have been delegated can not be released from the unstaking, and there is no longer time to unfreeze them. Instead, the assets will be retrieved in a way of delayed receipt. I am thinking about how to specify this scheme, which will be updated later.

Binulaj commented 1 year ago

I suggest we need a function to stake our Tron for a customized unstake period, like 1 week or 2 months or 2 years with minimum 3 days mandatory unstake period, this will further improve longer period tron staking in the tron network and it also helps the tron energy and bandwidth renting market

Phoenix-Fragrant commented 1 year ago

@Binulaj

I think the problem is not the unstake period, but how to make full use of the mortgage resources to make them better used

joker-gdb commented 1 year ago

I suggest we need a function to stake our Tron for a customized unstake period, like 1 week or 2 months or 2 years with minimum 3 days mandatory unstake period, this will further improve longer period tron staking in the tron network and it also helps the tron energy and bandwidth renting market

Chain itself should not implement this, it is generally implemented through smart contracts, but requires EVM/TVM to support staking-related instructions.

lxcmyf commented 1 year ago

@caohuiboss Thanks,

  1. In my expectation, there should be no 3 day limit before unstaking. In my opinion, we can retrieve delegated resource and transfer to another one without unstaking.
  2. If without unstaking, voting would not change a bit.
  3. Not sure about that. There might be new commands for the new mechanism.
  4. As I state above, I hope the 3 day limit should be revoked, staked TRX can be released at any time, but the arrival of TRX could be delayed to the account, to play a similar part of the 3 day limit, in which the delay period is configurable.
  5. Step by step I think.
  6. No, the upgrade will be compatible
Binulaj commented 1 year ago

@Phoenix-Fragrant

To clear my idea again, The issue is about the unstake period because if we implement a customised unstake period then this gives energy/bandwidth buyers a guarantee, this will be highly positive for the energy/bandwidth renting market and also improve long period unstakeble tron on the network, we can publicly shill this information on Twitter or social media

fbsobreira commented 1 year ago

Great news! IMO this TIP is a great opportunity to enhance the stake/resources system! Would love to see this implementation

Binulaj commented 1 year ago

This proposal will lead to stop the deflation of tron if the majority of srs start to sell energy at cheap

dmf3030 commented 1 year ago

This feels like a way for very large wallets to be able to sell energy into the market without having to worry about missing voting rewards or potentially shifting SR rankings. The energy market is a solid part of the Tron community now, and lets not forget that a bit of energy scarcity is a good thing, it drives users to buy TRX to the point where they then can freeze to offset their cost. I'm not convinced that this is a good idea. It feels like it would take a system that is running relatively well and introduce a good bit of uncertainty.

I predict the first thing that happens if you can redelegate energy without restaking is that all the large wallets that are frozen to bandwidth will then freeze for energy. This will reduce network energy for everyone else. Then those large wallets will sit on that energy, without missing any voter rewards, they can then sell it at the leisure, those controlling the energy market and driving more money into the very top wallets. Currently the energy market is serviced by mid range holders and even small holders who fill energy orders. I see this going away and many of those smaller and mid range holders who have been accruing TRX to continue to rent it would then likely return to selling daily rewards.

In short I see this potentially creating an energy cartel of the topmost whales at the expense of the smaller more open energy market that exists today.

DmytroShalaiev commented 1 year ago

Good idea but I think we can face problems with redelegating resources from the account when it already used resources And resource owner wants to re-delegate these resources to the second account.

Problem: how the first account should repair resources, they will be in minus after re-delegating by the owner?

Solution: allow redelegation of resources from the first account to the second only when the first account repairs all used delegated resources

otakuinny commented 1 year ago

This proposal is short on clear details. But if I understand it right, it is proposing the following main things

  1. Resources can be delegated to different addresses without having to perform unstake operation
  2. It says "the new mechanism should implement the delayed arrival of unstaking TRX" but doesn't explain exactly how

First of all, it proposes too many changes. Second, it says several times that the current resource utilization is in-efficient and this proposal will improve it but I just don't see how. How would being able to delegate resources whenever you want be beneficial to anyone other than those with big TRX bags. This sounds like it is only helpful to those that want to delegate their energy for a fees without having to wait for 3 days. So, in this case, they'd be able to delegate energy for 1 day instead of 3 days. This would help big whales corner the resource renting market and hurt smaller holders

Another TIP that is disguised as something that benefits the whole TRON community when it actually only benefits those with large TRX accounts to sell their energy resources. There is already too many TRX in circulation which is one of the factors affecting the price. Like someone above said, this will burn fewer TRX everyday as people would just rent energy instead of burning TRX for their transactions. This will be very bad for the price of TRX as there will be more and more TRX everyday.

For me, this proposal is a big NO because it doesn't solve any current problems, but creates a few new problems, the most glaringly obvious one being that it stops TRX from being deflationary.

Jakevsky commented 1 year ago

@otakuinny It is motivation, not a solution bro, no need to show how at this step. I think the "delayed arrival of unstaking TRX", is the answer to the revoke of the 3-day limit to unstake TRX. I learned that it does not mean you can stake for resources, then unstake the next day, so that you may keep the resources and your TRX in the meantime, it does not make sense. Once unstaked, voting and benefits will be gone. Second, you confused me with your point. If, as you said, it is bad for the price of TRX, how could it benefit those with large TRX accounts? They lose the most.

lxcmyf commented 1 year ago

@otakuinny In fact, this can solve some problems in the existing mechanism. In my expectation, staking, unstaking, delegate resource and other operations are independent. After staking, you can unstake at any time. However, for the rational use of resources, the TRX with unstaking and postponement needs to be delayed to the account, and the length of the delay can be discussed separately. Resources can be entrusted to other accounts after being staked, but only the resources currently available in the staking account can be entrusted. After being entrusted to other accounts, I would like to propose the concept of usage. When recycling resources, the usage of resources should also be brought back to prevent the resources from being reused by the lender. The usage of resources should be recycled according to the proportion of resources

Also, you mentioned that it is not conducive to deflation. I think the final result will not tend to inflation. Leasing resources also needs to pledge TRX to support this behavior, which will not lead to reduced use of TRX.

joker-gdb commented 1 year ago

This TIP will spawn a huge energy market. About 1 year ago, I also considered putting some of my TRX into the energy market to gain income, but then I gave up. Now the energy market is too small, it is difficult for my TRX to go out at one time. Because if someone needs to rent, I need to unfreeze and then freeze and delegrate the energy to him, but I can't get income by freezing my remaining TRX. Once I freeze to get voting income, I will not be able to rent for the next 3 days.

I think TVM should add staking-related instructions, so that a liquidity mining pool can be realized through smart contracts. The income of this pool comes from voting and lease . This is a major progress, because some decentralized energy markets will be created, these energy markets are not just a place to trade energy, but a decentralized liquidity mining pool.

lxcmyf commented 1 year ago

@joker-gdb I'm not sure whether the current TRON ecosystem supports this, but I think it's a good suggestion. Maybe it's helpful to add these instructions as you said.

kunlunxuejue11 commented 1 year ago

Sounds good, unstaking and getting the funds immediately, it seems to be invisible on other chains, such as EOS, DOT, COSMOS, maybe you guys can learn from these implementations.

otakuinny commented 1 year ago

@otakuinny It is motivation, not a solution bro, no need to show how at this step. I think the "delayed arrival of unstaking TRX", is the answer to the revoke of the 3-day limit to unstake TRX. I learned that it does not mean you can stake for resources, then unstake the next day, so that you may keep the resources and your TRX in the meantime, it does not make sense. Once unstaked, voting and benefits will be gone. Second, you confused me with your point. If, as you said, it is bad for the price of TRX, how could it benefit those with large TRX accounts? They lose the most.

@Jakevsky, this TIPs section is not for half-baked ideas with no real details. If you have half an idea, you need to fully think through on how exactly it is supposed to work and then post your proposal. Take a look at all the other proposals. They all explain exactly what they want to happen and how. This proposal basically says, there needs to be a better resources model but doesn't explain anything else.

As for your question about large TRX accounts, the commissions they can earn by renting out their TRX will more than make up for any changes in the TRX prices that are caused by the Inflation this proposal creates so they don't care cos they still make money.

otakuinny commented 1 year ago

@otakuinny In fact, this can solve some problems in the existing mechanism. In my expectation, staking, unstaking, delegate resource and other operations are independent. After staking, you can unstake at any time. However, for the rational use of resources, the TRX with unstaking and postponement needs to be delayed to the account, and the length of the delay can be discussed separately. Resources can be entrusted to other accounts after being staked, but only the resources currently available in the staking account can be entrusted. After being entrusted to other accounts, I would like to propose the concept of usage. When recycling resources, the usage of resources should also be brought back to prevent the resources from being reused by the lender. The usage of resources should be recycled according to the proportion of resources

Also, you mentioned that it is not conducive to deflation. I think the final result will not tend to inflation. Leasing resources also needs to pledge TRX to support this behavior, which will not lead to reduced use of TRX.

@lxcmyf, my main concern is not about the unstaking but with the disruption in the energy market this creates as this is only beneficial for large TRX holders and hurts small holders.

The accounts that are staking and not doing anything with the resources they are receiving are already locking their TRX up. In your new scheme, those trx will still be locked except now they can delegate resources without unstaking and within the mandatory 3 day period. So, the only thing that changes is that whales are gonna make more money at the expense of small trx bag holders. And, it will definitely lead to inflation as more people will just rent energy and not burn any TRX for transactions.

I just have a simple question for everybody. Who does this proposal benefit? Think about the answer and you'll realize this is not good for the TRON community in general.

otakuinny commented 1 year ago

This TIP will spawn a huge energy market. About 1 year ago, I also considered putting some of my TRX into the energy market to gain income, but then I gave up. Now the energy market is too small, it is difficult for my TRX to go out at one time. Because if someone needs to rent, I need to unfreeze and then freeze and delegrate the energy to him, but I can't get income by freezing my remaining TRX. Once I freeze to get voting income, I will not be able to rent for the next 3 days.

I think TVM should add staking-related instructions, so that a liquidity mining pool can be realized through smart contracts. The income of this pool comes from voting and lease . This is a major progress, because some decentralized energy markets will be created, these energy markets are not just a place to trade energy, but a decentralized liquidity mining pool.

What you said proves this proposal is no good. This only benefits those that can use their TRX to sell resources all at the expense of those that can't and it also leads to massive Inflation of TRX supply which will negatively affect the price.

The current resources model works just fine. If anything the only thing that can make it better is if the user can freeze their TRX for more than 3 days.

dmf3030 commented 1 year ago

This proposal is short on clear details. But if I understand it right, it is proposing the following main things

  1. Resources can be delegated to different addresses without having to perform unstake operation
  2. It says "the new mechanism should implement the delayed arrival of unstaking TRX" but doesn't explain exactly how

First of all, it proposes too many changes. Second, it says several times that the current resource utilization is in-efficient and this proposal will improve it but I just don't see how. How would being able to delegate resources whenever you want be beneficial to anyone other than those with big TRX bags. This sounds like it is only helpful to those that want to delegate their energy for a fees without having to wait for 3 days. So, in this case, they'd be able to delegate energy for 1 day instead of 3 days. This would help big whales corner the resource renting market and hurt smaller holders

Another TIP that is disguised as something that benefits the whole TRON community when it actually only benefits those with large TRX accounts to sell their energy resources. There is already too many TRX in circulation which is one of the factors affecting the price. Like someone above said, this will burn fewer TRX everyday as people would just rent energy instead of burning TRX for their transactions. This will be very bad for the price of TRX as there will be more and more TRX everyday.

For me, this proposal is a big NO because it doesn't solve any current problems, but creates a few new problems, the most glaringly obvious one being that it stops TRX from being deflationary.

We've both been around since the beginning and I know both have a clear idea how these TIPS and chain changes get pushed through and also who typically benefits. But even if we look past the obvious point that this is for the benefit of whales and potentially TronDAO itself, you also keyed on a very important point. These are big changes, and complicated changes, this is not just raising the energy price or setting a longer timeout on the TVM. This is tinkering with the very delicate balance that is resources, something thats been relatively successful for years now. It is like you said, half baked at best and way to complicated and large a thing to just brashly change.

On top of this, we are rapidly approaching the time when USDD was supposed to have its burn mechanism cut into javatron, something that is also a big change and very delicate. I see very little reason to risk changing the resource system that has worked so well for so long and I think it points to big players once again steam rolling changes on the chain for their own benefit.

dmf3030 commented 1 year ago

Again people need to think about how this would play out. TronDAO and other very large players have billions of TRX frozen for bandwidth because those TRX are voting for their SRs. The reason those large wallets don't sell energy is because they can't risk SR positions and staking rewards by leaving TRX unfrozen waiting for energy orders. They can't practically sell the energy from their billions of TRX, so they don't currently sell.

Now if they can freeze one time and then redelegate as they wish, heres what will happen: The large large wallets will freeze for energy and just like when binance accidentally froze for energy a while back, the amount of available energy for everyone else will dramatically decrease. So the first result will be a sudden loss of energy for most small and middle users. This of course creates scarcity and will force those people to now look to buy energy, where previously they may have accrued enough TRX to freeze and cover their usage. So now they go looking for energy and the massive wallets will become the main sellers because they can undercut the market due to huge supply. So basically it will both hurt small users while benefitting many huge wallets that already collect staking rewards and do little else in terms of contributing.

I fail to see the upside to this proposal and this is without considering the details of implementation, which if flawed, could cause havoc on the chain.

otakuinny commented 1 year ago

@otakuinny If the large TRX accounts with their delegated resources swarm into the delegating market, what I can see is a cheaper price for ordinary users. The commission and TRX inflation are bold guesses of yours. And the large accounts utilize their TRX in this way is much better for the whole community rather than throwing TRX into ex/dex. What do you think?

@Jakevsky, you are saying large accounts benefitting at the expense of smaller energy sellers is a good thing. When you say "large accounts utilize their TRX in this way is much better for the whole community", are you serious?? Do you know any whales that did anything for the betterment of any community? Whales aren't that magnanimous. Their singular goal is profit which involves screwing smaller holders every time. Whales cornering energy market making TRX inflationary is not a "bold guess". Let's play out a hypothetical scenario. Let's say a few whales with a few Billion TRX started selling energy at a very cheap price. The following things will happen...

People burning TRX for energy for some of their transactions is a good thing. There has been a balance between people burning trx for fees and people renting energy. If that balance is disrupted either way, it'll lead to lower transaction volume and creates negative outlook on the whole TRON chain as a whole.

otakuinny commented 1 year ago

Again people need to think about how this would play out. TronDAO and other very large players have billions of TRX frozen for bandwidth because those TRX are voting for their SRs. The reason those large wallets don't sell energy is because they can't risk SR positions and staking rewards by leaving TRX unfrozen waiting for energy orders. They can't practically sell the energy from their billions of TRX, so they don't currently sell.

Now if they can freeze one time and then redelegate as they wish, heres what will happen: The large large wallets will freeze for energy and just like when binance accidentally froze for energy a while back, the amount of available energy for everyone else will dramatically decrease. So the first result will be a sudden loss of energy for most small and middle users. This of course creates scarcity and will force those people to now look to buy energy, where previously they may have accrued enough TRX to freeze and cover their usage. So now they go looking for energy and the massive wallets will become the main sellers because they can undercut the market due to huge supply. So basically it will both hurt small users while benefitting many huge wallets that already collect staking rewards and do little else in terms of contributing.

I fail to see the upside to this proposal and this is without considering the details of implementation, which if flawed, could cause havoc on the chain.

@dmf3030, you have hit several nails on their head with your points. You are exactly right! Even if we were to set aside the fact that this isn't really a proposal but just someone throwing out a plea to the TRON DAO devs asking them to somehow change the current resources model to benefit the wallets with billions of TRX, it still fails to clearly explain how this benefits the average TRON user. Like you said, the current resources model has been working reasonably well and messing with it to benefit whales, or even just for the heck of it sounds like a terrible idea, if not a dangerous one. Especially, since TRON and Justin have been working their asses off lately to hawk USDD to the larger crypto community, it becomes more important that the security and the reliability of the TRON blockchain is not threatened by trying to fix things that are not broken in the first place.

lxcmyf commented 1 year ago

@dmf3030 This improvement is very beneficial to the decentralized energy market. If TRX whale holders find it profitable, they will definitely change the bandwidth pledge to energy pledge, but I don't think it will hurt small users, why? Let me explain, if whale users change bandwidth pledge to energy pledge, it will inevitably increase the cost of obtaining energy from freezing, but now the proportion of energy obtained by consuming pledge on the TRON network is very small, and there are more small users, even big whales. All are consuming trx to pay for energy. On the contrary, the large amount of energy of whales flowing into the market will inevitably lead to a decrease in the price of energy leasing, which will in turn cause the cost of energy leasing to be much lower than the cost of consuming trx to pay for energy.

Of course, if a large number of users choose to rent energy instead of burning trx to pay for energy, this will hinder deflation, but in fact it will not have a particularly big impact, because, in tronscan, I see almost all whales (especially exchanges) in Burn trx to pay for token transfers, they can pledge trx to get free energy, but they don't, so the new mechanism won't make whales give up trx burning.

joker-gdb commented 1 year ago

I suggest we need a function to stake our Tron for a customized unstake period, like 1 week or 2 months or 2 years with minimum 3 days mandatory unstake period, this will further improve longer period tron staking in the tron network and it also helps the tron energy and bandwidth renting market

@Binulaj I found that I made a mistake. If TVM supports delegate-related instructions, it would not solve the problem. Although the smart contract can control the time limit of the resource delegation and prevent the energy lender from maliciously canceling the delegation, but the lender can completely cancel the agent through the HTTP API, this is a loophole.

So the resource delegation should support the time limit. For example, A agent 100 energy to B, the lease period is 10 days, B pays lease fee to A, and A cannot release the delegation within 10 days, this can protect B's rights and interests.

Also the resources in the delegation state , the corresponding TRX cannot be unstaked.

otakuinny commented 1 year ago

I suggest we need a function to stake our Tron for a customized unstake period, like 1 week or 2 months or 2 years with minimum 3 days mandatory unstake period, this will further improve longer period tron staking in the tron network and it also helps the tron energy and bandwidth renting market

@Binulaj I found that I made a mistake. If TVM supports delegate-related instructions, it would not solve the problem. Although the smart contract can control the time limit of the resource delegation and prevent the energy lender from maliciously canceling the delegation, but the lender can completely cancel the agent through the HTTP API, this is a loophole.

So the resource delegation should support the time limit. For example, A agent 100 energy to B, the lease period is 10 days, B pays lease fee to A, and A cannot release the delegation within 10 days, this can protect B's rights and interests.

Also the resources in the delegation state , the corresponding TRX cannot be unstaked.

@joker-gdb, increasing the TRX stake period from 3 days to a higher number of days is beneficial for energy renting market. But, providing the stake from smart contracts is a dangerous idea as there are tons of scam contracts with hundreds of millions of TRX that will now benefit by selling energy, receiving voter rewards which will reduce rewards for everyone else, and in the end run away with all the TRX when their scam ends. So, in essence, being able to stake trx and delegate resources from smart contracts is not a great idea.

otakuinny commented 1 year ago

@dmf3030 This improvement is very beneficial to the decentralized energy market. If TRX whale holders find it profitable, they will definitely change the bandwidth pledge to energy pledge, but I don't think it will hurt small users, why? Let me explain, if whale users change bandwidth pledge to energy pledge, it will inevitably increase the cost of obtaining energy from freezing, but now the proportion of energy obtained by consuming pledge on the TRON network is very small, and there are more small users, even big whales. All are consuming trx to pay for energy. On the contrary, the large amount of energy of whales flowing into the market will inevitably lead to a decrease in the price of energy leasing, which will in turn cause the cost of energy leasing to be much lower than the cost of consuming trx to pay for energy.

Of course, if a large number of users choose to rent energy instead of burning trx to pay for energy, this will hinder deflation, but in fact it will not have a particularly big impact, because, in tronscan, I see almost all whales (especially exchanges) in Burn trx to pay for token transfers, they can pledge trx to get free energy, but they don't, so the new mechanism won't make whales give up trx burning.

@lxcmyf, the very first sentence you said is wrong "This improvement is very beneficial to the decentralized energy market". When a handful of whales control the energy market, it is NOT A DECENTRALIZED energy market anymore. It is very centralized. I'm not sure why you are pushing so hard for this. In your example where there are a large number of whales selling energy, you have failed to see the most obvious outcome. When a bunch of whales compete with each other and sell energy for cheap, it'll bring down the energy free rate per trx, which is at around 28 energy per 1 trx frozen right now. When billions of TRX is frozen for energy thru selling this rate will decrease day by day eventually reaching 1, just like bandwidth.

This would screw over literally every individual TRON user, every dapp owner that is freezing their own TRX to get free energy for themselves and for their contracts and forces them to rent energy. So, in effect, you will be forcing EVERYONE, even those with enough TRX to get their free energy to rent from whales, making the whales richer. This is completely unacceptable as people with enough TRX to freeze to get their own free energy should not be forced to pay for something they can get for free.

It feels like this whole proposal's aim is to create a monopoly over the TRON resources and force every single TRON user to pay for their transactions by renting resources from whales, even when they have enough trx to get enough energy they need. NOT GOOD!!

joker-gdb commented 1 year ago

I think not only the contract needs to support staking and delegation-related commands, also need to support tokenization. After staking trx, user can also get LP tokens. However, tokenization seems to be a bit difficult, because after staking, will get 2 kinds of resources, so need 2 kinds of tokens to support it

Binulaj commented 1 year ago

https://github.com/tronprotocol/tips/issues/467#issuecomment-1263149090

So we have to believe a smart contract coded by someone for the customizable unstake period

joker-gdb commented 1 year ago

#467 (comment)

So we have to believe a smart contract coded by someone for the customizable unstake period

@Binulaj The contract owner need to open source the code to gain the trust of others, if the delegation supports time-limit, it is entirely up to the mechanism of the chain to ensure the rights of energy buyers

Binulaj commented 1 year ago

#467 (comment) So we have to believe a smart contract coded by someone for the customizable unstake period

@Binulaj The contract owner need to open source the code to gain the trust of others, if the delegation supports time-limit, it is entirely up to the mechanism of the chain to ensure the rights of energy buyers

I believe, if we ever have a plan to implement on customise unstake period then we need the customise unstake period function should be on the wallet interface, so it will have more visible to people than a smart contract website, and it more convenient

joker-gdb commented 1 year ago

#467 (comment) So we have to believe a smart contract coded by someone for the customizable unstake period

@Binulaj The contract owner need to open source the code to gain the trust of others, if the delegation supports time-limit, it is entirely up to the mechanism of the chain to ensure the rights of energy buyers

I believe, if we ever have a plan to implement on customise unstake period then we need the customise unstake period function should be on the wallet interface, so it will have more visible to people than a smart contract website, and it more convenient

Yeah, it is friendlier

dmf3030 commented 1 year ago

@dmf3030 This improvement is very beneficial to the decentralized energy market. If TRX whale holders find it profitable, they will definitely change the bandwidth pledge to energy pledge, but I don't think it will hurt small users, why? Let me explain, if whale users change bandwidth pledge to energy pledge, it will inevitably increase the cost of obtaining energy from freezing, but now the proportion of energy obtained by consuming pledge on the TRON network is very small, and there are more small users, even big whales. All are consuming trx to pay for energy. On the contrary, the large amount of energy of whales flowing into the market will inevitably lead to a decrease in the price of energy leasing, which will in turn cause the cost of energy leasing to be much lower than the cost of consuming trx to pay for energy.

Of course, if a large number of users choose to rent energy instead of burning trx to pay for energy, this will hinder deflation, but in fact it will not have a particularly big impact, because, in tronscan, I see almost all whales (especially exchanges) in Burn trx to pay for token transfers, they can pledge trx to get free energy, but they don't, so the new mechanism won't make whales give up trx burning.

@otakuinny already answered this better than I could, but I will reiterate - large wallets deciding to move to freezing for energy would hurt all users, especially smaller uses who have accumulate TRX to pay for a few daily transactions. It would be moving the goal post for those users and for dapps who have based their model on possibly offsetting user fees by freezing for energy. Its just a needless change that has one result, letting large wallets enter into the energy selling market. Let that sink in, this would drastically complicate the resource model, add all sorts of unforeseen edge cases and primarily just to allow large wallets to start freezing for energy so that they can sell it.

We shouldn't even be having this conversation without much more specific information, it is way to delicate a change for someone to just say "no it will be good for things" without being able to analyze it or even look for loopholes or implementation issues.

otakuinny commented 1 year ago

@dmf3030 This improvement is very beneficial to the decentralized energy market. If TRX whale holders find it profitable, they will definitely change the bandwidth pledge to energy pledge, but I don't think it will hurt small users, why? Let me explain, if whale users change bandwidth pledge to energy pledge, it will inevitably increase the cost of obtaining energy from freezing, but now the proportion of energy obtained by consuming pledge on the TRON network is very small, and there are more small users, even big whales. All are consuming trx to pay for energy. On the contrary, the large amount of energy of whales flowing into the market will inevitably lead to a decrease in the price of energy leasing, which will in turn cause the cost of energy leasing to be much lower than the cost of consuming trx to pay for energy. Of course, if a large number of users choose to rent energy instead of burning trx to pay for energy, this will hinder deflation, but in fact it will not have a particularly big impact, because, in tronscan, I see almost all whales (especially exchanges) in Burn trx to pay for token transfers, they can pledge trx to get free energy, but they don't, so the new mechanism won't make whales give up trx burning.

@otakuinny already answered this better than I could, but I will reiterate - large wallets deciding to move to freezing for energy would hurt all users, especially smaller uses who have accumulate TRX to pay for a few daily transactions. It would be moving the goal post for those users and for dapps who have based their model on possibly offsetting user fees by freezing for energy. Its just a needless change that has one result, letting large wallets enter into the energy selling market. Let that sink in, this would drastically complicate the resource model, add all sorts of unforeseen edge cases and primarily just to allow large wallets to start freezing for energy so that they can sell it.

We shouldn't even be having this conversation without much more specific information, it is way to delicate a change for someone to just say "no it will be good for things" without being able to analyze it or even look for loopholes or implementation issues.

Exactly! If anything, the only thing I'd propose changing in the resources model is to let users stake their TRX for longer than 3 days. I think increasing the upper limit for the days of the freeze transaction, which is currently only fixed to 3 days, to 30 days would be a good idea so users can decide to stake between 3 and 30 days. Not sure why this hasn't been the case since the beginning.

otakuinny commented 1 year ago

To be honest, the biggest app of TRON is USDT. The main energy consumption is the transfer of these tokens, so the biggest consumer is the exchange. The fluctuation of energy price will not make these users give up burning, no matter how the mechanism changes, the high probability exchange will not change the way energy is paid, they do not need to consider the cost, anyway, the user pays the fee, the deflation model will not change.

Wrong on so many levels. First, USDT is not an app, but a trc20 token. It takes between 16 and 20k energy to do one transfer. Whether I am initiating these transfers inside a dapp or in the sunswap exchange, I have never paid for the energy fees as I always freeze enough of my trx to receive free energy. usdt transfers account for a tiny fraction of the smart contract transactions that consume energy. Saying no matter how we change the resources model, it'll not have an effect cos all the energy is consumed by usdt transactions is ignorant at best and a lie at worst.

dmf3030 commented 1 year ago

Stop the whales from entering the energy market, it seems very ridiculous and selfish, like the poor guys are shouting: hi, rich guys, you don't come, don't grab the cake with me. The rich say: No, I'll make energy cheaper to your advantage. The poor guys said: No, I don't need cheaper energy, I just keep the status quo.

It's ridiculous.

Lets be clear, I'm not proposing some half baked, zero detail, change to one of the core mechanics of the chain. Thats what this TIP is doing and I guess you support flailing about in the inner workings of Javatron just to make the life of a few big wallets easier.

Furthermore, there is nothing stopping whales from selling energy, they can do it the same way everyone else does. If your a whale with 100m TRX wallet propping up a zombie SR, then just move 10m TRX to a second wallet and fill energy orders or figure out a solution to automate it. That is what everyone else has done for the last few years and any whale can do it too. What is not fair is whales deciding they want to put a thumb on the scale to totally change the core protocol just so they can avoid making a few transactions a day or because they dont want to have to manage the finer points of selling energy.

This proposal calls out a problem that doesnt exist and offers a nebulous solution that benefits few. If the core problem is needing cheaper energy then just make it so wallets can freeze and opt out of getting resources. Or maybe look at increasing the max energy available on chain slightly. Both of those could help put more energy on chain, and once is just a vote away.

This chain is already largely under the influence of rich wallets and big interests, the more we set a precedent that they can alter things to make their lives easier at the expense of chain stability or small users the more likely this chain will be a USDT layer with few dapps and fewer users.

dmf3030 commented 1 year ago

Im gonna say this one more time so its not lost:

There is nothing stopping whales entering the energy market in its current state.

The TIP says its too complicated in its current state, which is silly, crypto and defi are complicated by nature and plenty of solutions are found to extract value. The current energy market is working just fine with multiple solutions for larger wallets to sell energy.

Again, there is nothing stopping whales entering the market now and becoming the cheap energy saviors some of you think they will be. Please if someone can propose a clear reason why large wallets can not sell for energy then add it here so we can discuss it.

otakuinny commented 1 year ago

Stop the whales from entering the energy market, it seems very ridiculous and selfish, like the poor guys are shouting: hi, rich guys, you don't come, don't grab the cake with me. The rich say: No, I'll make energy cheaper to your advantage. The poor guys said: No, I don't need cheaper energy, I just keep the status quo.

It's ridiculous.

Lol, this guy 🤦. He thinks the rich whales want to help out the poor small holders by making energy cheaper 🤣. And he just casually says people freezing their own trx to get free energy is "not good idea". Bro, what??? So, basically, you are suggesting EVERY USER should just pay whales to rent energy or burn their trx for transactions. If this isn't something that'll kill the TRON ecosystem, I don't know what will.

Also, you give too much credit to whales and their generosity (do you by chance have 100s millions of trx 😄). Let's forget for a moment that everybody having to pay to rent energy is already a collasslly bad idea, and talk about the idea of whales providing energy to everybody. The assumption that when there are competing entities vying to provide the same service to a group of people, it will bring down the cost of said service, is a faulty one. This is what's taught in textbooks, but not what happens in reality. In the real world, the whales would form a cartel and would have an unspoken pact to fix the lowest price for energy. Why? Because, this is good for business than them competing with each other and eating into each other's profits. A prime example of this is the oil cartel OPEC. There are dozens of countries in the world that has oil reserves who instead of undercutting each other on the price, formed a cartel that fixes the production which effects the price. Like I said before, you either don't know enough to see the whole picture or you do and deliberately trying to make this happen cos it'd benefit you.

In any case, like several others have said, there are no details in this "proposal", just a wish for the current resources model to be better. In my humble opinion, it is already better. There is a flourishing energy market on telegram where users are trading energy with each other and more energy markets, telegram bots are popping up almost every week. Changing the resources model to benefit a handful of whales where they could keep their voter rewards and sell energy at the expense of everyone else will very likely bring the whole tron eco system down. As it is, whales exert an undue influence in TRON which makes the optics look bad to the rest of the crypto community. Remember, the ethos of crypto is decentralization. Cheering for whales to form cartels and making each tron user a slave that must rent energy to do anything in TRON is anything but decentralization.

vovan87 commented 1 year ago

.

Ocea91 commented 1 year ago

@dmf3030 I see only one third in TRON use energy from staked TRX, so I am not going to say it is successfully market based on its original purpose. And there are not many big whales sell energy in the market. So you think that is all because of the present state of stake? And once it changes due to this proposal, the big whales are going to play a big part in this game? As long as most of the user burn TRX for energy, that is not happening, except that energy in the market are cheaper than burning TRX. That is the bottom line.

Ocea91 commented 1 year ago

@asawhit1 I can see a point from the the 'dmfxxx' and 'otakutiny' guys. They did not involve and contribute in the community but say crappy things and conjecture about so called 'big whales' are gonna fuck them. What do you expect from those guys? Nothing graceful would ever come out of their mind.

otakuinny commented 1 year ago

@dmf3030 I see only one third in TRON use energy from staked TRX, so I am not going to say it is successfully market based on its original purpose. And there are not many big whales sell energy in the market. So you think that is all because of the present state of stake? And once it changes due to this proposal, the big whales are going to play a big part in this game? As long as most of the user burn TRX for energy, that is not happening, except that energy in the market are cheaper than burning TRX. That is the bottom line.

@Ocea91, I'm not entirely sure I understand what you are saying. You say only one third of transactions use energy that come from staked trx. You say that like it's a bad thing. It's a good thing. This way a lot of trx get burned and the supply is decreased. If nobody burns trx for energy, your trx will be worthless. Don't know why you say what I said is based on conjecture when I offered as clear an examples as anyone can. Maybe you didn't, or couldn't, understand the dynamics and the complex interplay that exist between the different elements in the tron ecosystem.

Also, son, I have been heavily involved in tron since September 2017 and have seen everything.

otakuinny commented 1 year ago

The change to the resources model I support is what @Binulaj had proposed above about increasing the freezing period from 3 days to whatever days. This is a good proposal because it is clear and definite. Unlike the original vague description of this TIP.

lxcmyf commented 1 year ago

@asawhit1 @dmf3030 @otakuinny I think we should be rational. We should not hinder the healthy and orderly development of the TRON ecology because of the uncertain impact. The existing staking mechanism is too simple, which is not conducive to the stable and efficient development of the entire staking market. Perhaps the question you raised is objective, but is it always conducive to the progress of the TRON ecology to maintain the status quo? No, that's not the case. Standing still will never make a difference. We should learn to embrace change and look at the changes it brings with a more intelligent and rational view.

dmf3030 commented 1 year ago

@asawhit1 I can see a point from the the 'dmfxxx' and 'otakutiny' guys. They did not involve and contribute in the community but say crappy things and conjecture about so called 'big whales' are gonna fuck them. What do you expect from those guys? Nothing graceful would ever come out of their mind.

Come on now, I've been here since Tron's very first epoch. I've spent more hours than I care to admit supporting and discussing Tron projects. I help people nearly every day either avoid scams or see how they happen. I run nodes, I deploy smart contracts, I've made tens of thousands of transactions and burned my share of TRX. I know the network and I've been vocal in my support of it and vocal when I think its being pushed in the wrong direction. Thats what an independent thinking community member looks like. My goal is to protect the network and voice concerns I have, especially when TIPS like this are tossed out. Without dissent the network is just a centralized echo chamber.

dmf3030 commented 1 year ago

@dmf3030 I see only one third in TRON use energy from staked TRX, so I am not going to say it is successfully market based on its original purpose. And there are not many big whales sell energy in the market. So you think that is all because of the present state of stake? And once it changes due to this proposal, the big whales are going to play a big part in this game? As long as most of the user burn TRX for energy, that is not happening, except that energy in the market are cheaper than burning TRX. That is the bottom line.

You don't want every single person using energy, then there would be no burn. The energy system is a finely balanced tool that both reduces cost for users who take advantage of it, but also acts as an incentive for people to buy more TRX to offset their fees. There needs to be some demand and value to energy or else it doesnt act as the carrot that people strive for.

If I am making transactions everyday and renting energy, I am offsetting the network fees by some 80%. Now that means a renter is clearly making money, so if I look at it that way then I would want to buy enough TRX to no longer rent. Suddenly that TRX is worth not only staking rewards but also the extra TRX I'm not paying in renters fees. The renters fees going away is a huge incentive to buy in, we should keep that element.

If everyone used energy we would be inflationary and the true winners would be the large energy selling wallets. If they all froze for energy they could force many more users to need to rent, effectively "taxing" the network by creating an energy scarcity where there wasn't one before.