-
Notifications
You must be signed in to change notification settings - Fork 188
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
Vote Instruction in TRON smart contract #156
Comments
The TVM does lack instructions related to voting, but perhaps we need to consider some instructions for implementing freeze and unfreeze mechanisms within the VM first. Or we can simplify the process by combining VOTE and FREEZE into one instruction. FYI: I've drafted a new Issue to discuss this. #157 |
Thanks @Sh11thead, freeze TRX is a considerable instruction and I will discuss with you in issue #157. I think there are also several tricky things for FREEZE instruction, such as delegation resource, energy payment rules. |
I have 2 questions. Firstly of all, are there any risks if user stakes their token in contract for voting? Secondly, any mechanisms to protect the asset in contract? |
As a DApp user, you need carefully go through the contract. You need to make sure the contract has an available function to retrieve your own assets. Voting is a contract operation, as long as you give your asset to the contract, the assets are belonging and controlled by the smart contract. Control here means any operation the contract can deal with your assets such as vote, freeze, unfreeze. So you need to check the logic as other DApp contract, make sure it is the same as you expected. |
In my opinion, the TRX transferred into the contract is owned by the contract account. So the rewards should not be distributed to DAPP users because these users have obtained some service provided by the contract. For example, they store some data or play a game. |
Would this freeze operation support the selection of gaining bandwidth / energy? Could they also choose who the bandwidth / energy receiver would be? |
That’s true. Block reward should belong to contract itself. But contract can have logic to distribute the reward to its user, it is all depending on the DApp developer’s business purpose. |
Yes, I think we should provide such functionalities, one way to do this can be |
I'm glad to hear that. On the other hand though, when the overall freezing TRX increases, the amount of energy & bandwidth everyone gets from freezing TRX would decrease. Would you afraid normal DApp users complain about it? Since even though most contracts' energy fee is paid by the developers themselves, it is not uncommon to see contract owners ran out of juice & charges normal user energy. |
yes, that is very nice. DAPP developers will be inspired to develop much more popular applications. I think this is a good feature for the blockchain. But some things need to be carefully evaluated, for example, the DAPP developer will vote for the SR that may help him cheat, or maybe the SR is controlled by himself. The popular DAPP just.game will give the most rewards to the last user who buys the lift. So, the SR may reject others' transactions but receive the developer's transaction. |
In my opinion, it's a bad design. No one mentions "internal transaction". |
Hello |
Bkdr |
This issue has been rewrite to TIP-271. |
Background
TRON is a DPOS blockchain and supports staking reward for all users as long as they vote for activity SRs. But assets locked in smart contract are not fully used for staking purpose. To build a fair mechanism and support DApp developers to share a better ecosystem, we need to have instructions for voting and collect related rewards in smart contract.
Implementation
Basically we need at least 2 Instructions:
We might need several other Instructions, such as
Make staking reward happened in smart contract can give DApp developers more motivation to build their DApps and increase their income. I highly recommend to implement this.
The text was updated successfully, but these errors were encountered: