-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: Add freeze/unfreeze instructions for TVM and Solidity compilers #157
Comments
Several situation need to be discussed:
|
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). |
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. |
System contract seems that is one of methods to freeze/unfreeze token. But, any other options for developer except system contract that mentioned before? |
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. |
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 |
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. |
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. |
Is this leaves "internal transaction" unchanged? See-also: #156 (comment) |
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. |
contracts are a mess, nobody understands them. What about tronish? they are fooling people. |
Developers implement these instructions in GreatVoyage_v4.2. |
Close this issue as it is already implemented in GreatVoyage-v4.2.0(Plato) |
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
andUnfreezeBalanceContract
.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 risksThe text was updated successfully, but these errors were encountered: