Vote Instruction in TRON smart contract

[taihaofu]

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:

• VOTE (vote for SR)
• WITHDRAWBALANCE (withdraw rewards)

We might need several other Instructions, such as

• REWARDBALANCE (show vote reward amount)
• ISWITNESS (distinguish witness address type)

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.

[Sh11thead]

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

[taihaofu]

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.

[timothyckw]

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?

[taihaofu]

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.

[behilter]

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.

[mattopolitan]

Would this freeze operation support the selection of gaining bandwidth / energy? Could they also choose who the bandwidth / energy receiver would be?

[taihaofu]

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.

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.

[taihaofu]

Would this freeze operation support the selection of gaining bandwidth / energy? Could they also choose who the bandwidth / energy receiver would be?

Yes, I think we should provide such functionalities, one way to do this can be freeze.call(freezeAmount, day, resourceType, toAddress);

[mattopolitan]

Would this freeze operation support the selection of gaining bandwidth / energy? Could they also choose who the bandwidth / energy receiver would be?

Yes, I think we should provide such functionalities, one way to do this can be freeze.call(freezeAmount, day, resourceType, toAddress);

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.

[behilter]

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.

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, 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.

[KI5FPL]

In my opinion, it's a bad design. No one mentions "internal transaction".
Since all the OpCodes was also a System Contract call.
What do you plan to do with "internal transaction"?
As more OpCodes added, more operations will be hidden behind TVM.

[saifalmea]

Hello

[YOUSU198]

Bkdr

[yanghang8612]

This issue has been rewrite to TIP-271.
So we close this issue.