Discussion: Add freeze/unfreeze instructions for TVM and Solidity compilers

[Sh11thead]

Background

As mentioned in #156, there is still a lack of voting in the TVM in relation to DPos and instructions for receiving benefits. The premise of implementing these instructions, while following existing mechanisms, is to achieve an effective set of mechanisms for freezing/unfreezing within the TVM. This would require additional new freeze/unfreeze instructions.

Implementation

To implement Freeze/unfreeze within a virtual machine, one can refer to the existing system contracts, FreezeBalanceContract and UnfreezeBalanceContract.
Therefore, the following two instructions inside the virtual machine can be considered.

• FREEZEBALANCE, specifying the number of TRXs frozen, the address of the recipient and the type of resource obtained, returns a success or failure flag.

• UNFREEZEBALANCE, specifying the address and resource type of the unfreeze, the system will recover the resource and unfreeze it, returning a flag of success or failure.

The basic principle that needs to be followed to achieve these two directives is to be consistent with FreezeBalanceContract/UnfreezeBalanceContract to avoid unnecessary risks

[taihaofu]

Several situation need to be discussed:

1. What if the contract called SUICIDE instruction and the TRX is still being freezed at that moment?
2. Can we unfreeze part of the freezing amount for a specific delegated address? Let’s say we want to implement an energy bank. The contract can freeze TRX and delegate it to some specific address. But as long as you unfreeze some energy for a specific address, you have to unfreeze all of the energy for the contract. We might need to change it to unfreeze for a single address.

[Sh11thead]

Several situation need to be discussed:

1. What if the contract called SUICIDE instruction and the TRX is still being freezed at that moment?
2. Can we unfreeze part of the freezing amount for a specific delegated address? Let’s say we want to implement an energy bank. The contract can freeze TRX and delegate it to some specific address. But as long as you unfreeze some energy for a specific address, you have to unfreeze all of the energy for the contract. We might need to change it to unfreeze for a single address.

For the first question, it is possible to unfreeze assets while the virtual machine is implementing the suicide command (whether this disregards the minimum freeze time remains to be discussed).
For the second question, I think it would be better to have a mechanism that is consistent with the chain, and this kind of energy banking can be done by way of subcontracts.

[timothyckw]

How about the reward for smart contract? Could you provide more detail description about benefit? Most of developers may need to consider the advantages before implementation.

[timothyckw]

System contract seems that is one of methods to freeze/unfreeze token. But, any other options for developer except system contract that mentioned before?

[taihaofu]

How about the reward for smart contract? Could you provide more detail description about benefit? Most of developers may need to consider the advantages before implementation.

It’s more related to VOTE and WITHDRAWBALANCE instructions. People freeze their asset in smart contract and vote for some SRs. Then they can collect rewards every 6 hours.

[taihaofu]

System contract seems that is one of methods to freeze/unfreeze token. But, any other options for developer except system contract that mentioned before?

I think for now we are using freeze and unfreeze system contract only. No other options. New instructions can be a new way for this purpose

[taihaofu]

Several situation need to be discussed:

1. What if the contract called SUICIDE instruction and the TRX is still being freezed at that moment?
2. Can we unfreeze part of the freezing amount for a specific delegated address? Let’s say we want to implement an energy bank. The contract can freeze TRX and delegate it to some specific address. But as long as you unfreeze some energy for a specific address, you have to unfreeze all of the energy for the contract. We might need to change it to unfreeze for a single address.

For the first question, it is possible to unfreeze assets while the virtual machine is implementing the suicide command (whether this disregards the minimum freeze time remains to be discussed).
For the second question, I think it would be better to have a mechanism that is consistent with the chain, and this kind of energy banking can be done by way of subcontracts.

I see. For Q1, we have to change some codes, and inject freeze logic in TVM. For Q2, one safe way is let DApp developer to decide how to implement it using instructions. Only concern here is the subcontract solution might lead address grow very fast in some specific situation. Might be a problem.

[mattopolitan]

Several situation need to be discussed:

1. What if the contract called SUICIDE instruction and the TRX is still being freezed at that moment?
2. Can we unfreeze part of the freezing amount for a specific delegated address? Let’s say we want to implement an energy bank. The contract can freeze TRX and delegate it to some specific address. But as long as you unfreeze some energy for a specific address, you have to unfreeze all of the energy for the contract. We might need to change it to unfreeze for a single address.

For the first question, it is possible to unfreeze assets while the virtual machine is implementing the suicide command (whether this disregards the minimum freeze time remains to be discussed).
For the second question, I think it would be better to have a mechanism that is consistent with the chain, and this kind of energy banking can be done by way of subcontracts.

For Q2, I do agree with the point that the mechanism has to be consistent. Yet isn't this "unfreeze some energy for a specific address" feature also something the community is asking for? And I do see there are comments very often in Telegram / Discord group, which provides energy renting to others. So why not implement this on the chain for normal users as well?

[taihaofu]

Several situation need to be discussed:

1. What if the contract called SUICIDE instruction and the TRX is still being freezed at that moment?
2. Can we unfreeze part of the freezing amount for a specific delegated address? Let’s say we want to implement an energy bank. The contract can freeze TRX and delegate it to some specific address. But as long as you unfreeze some energy for a specific address, you have to unfreeze all of the energy for the contract. We might need to change it to unfreeze for a single address.

For the first question, it is possible to unfreeze assets while the virtual machine is implementing the suicide command (whether this disregards the minimum freeze time remains to be discussed).
For the second question, I think it would be better to have a mechanism that is consistent with the chain, and this kind of energy banking can be done by way of subcontracts.

For Q2, I do agree with the point that the mechanism has to be consistent. Yet isn't this "unfreeze some energy for a specific address" feature also something the community is asking for? And I do see there are comments very often in Telegram / Discord group, which provides energy renting to others. So why not implement this on the chain for normal users as well

Partially unfreeze is a new functionality we can implement next step. For instruction perspective, as you mentioned, it may just keep the same as current implementation. We can do a upgrade after TRON fully support partially unfreeze.

[KI5FPL]

Is this leaves "internal transaction" unchanged?

See-also: #156 (comment)

[otakuinny]

The unfortunate truth is that more than half of the contracts in TRON belong to shady ROI dapps who accumulate huge amounts of TRX from gullible TRON users in a short amount of time. Not sure if giving these dapps the ability to freeze the TRX in their contracts and receive voter rewards is a good idea. This might have negative consequences on SRs and their ability to use the voting rewards to fund their operations as it might dilute their share of votes.

The freeze/unfreeze operation locks the TRX for at-least 3 days and renders them unable to use. If someone wants to freeze their TRX and vote, they can just do that without sending TRX to a contract. TRX sent to a smart contract are normally meant to be put to some use, and not intended to be locked. Dapp owners should not be able to use users' TRX to enrich themselves and there's no guarantee they'll share the voter rewards with their users. This is just like Binance running as an SR and voting for themselves just because they have 12 Billion TRX that belongs to their users.

A vote in TRON, just like it is in the real world, is a sacred thing and people should always be in control of who their vote goes to. This TIP has potential to have a lot of negative consequences on voting rewards/SRs/TRON resource consumption. Ultimately, it is a feature that no one asked for, that solves nothing, but might introduce several problems which can create an unfavorable climate for users in the TRON eco-system.

[TrimeGeld]

contracts are a mess, nobody understands them. What about tronish? they are fooling people.

[Lredhdx]

Developers implement these instructions in GreatVoyage_v4.2.
A new proposal will be created and approved.

[Benson0224]

Close this issue as it is already implemented in GreatVoyage-v4.2.0(Plato)
Check detail TIP at TIP-157