SMT Voting Mana Deep Dive
Hello Steemians, I’m @vandeberg, Senior Blockchain Engineer at Steemit and today I want to share some exciting changes coming to how voting mana is handled with SMTs which are intended to further the progress we have made over the last several years to make voting on Steem more intuitive and fair to everyone. We want SMTs to be the most advanced protocol for tokenizing web applications, and it is technical changes like these, informed by our unrivaled experience with STEEM, that will help us deliver on that promise. Speaking of SMTs, be sure to check out our recent blockchain update in which we disclose an ETA for the SMT testnet and an update on Platform Independent State Files.
Voting is at the center of Steem's Proof of Brain algorithm, which we believe will be a core value proposition for developers launching SMTs, so we want to make sure that when that protocol goes live, the voting process is as streamlined as possible.
When Steem was first released each account had voting power between 0 and 100%. This system is still present in many interfaces and the nomenclature of Steem. During the calculation of rewards an account's voting power was multiplied by their Steem Power to get something we called a” reward share.” A reward share is an internal system that helps the blockchain keep track of author and curation rewards.
The problem of this approach is that the voting power percent only had a precision of two, meaning the smallest amount we could represent was 0.01%. As users consumed their voting power, the accuracy of these calculations became worse and worse and at small levels of voting power, the system was almost unusable. Furthermore, this system did not interact well with powering up/down STEEM and delegations and made it easy to exploit the rules to vote with more Steem Power than you would otherwise normally be able to.
Enter Voting Mana
In Hardfork 20 we changed the internal representation of voting power to voting mana which helped to eliminate certain Steem exploits. The basic principle is the same. The value still represents the same concept of remaining availability to vote on content, but does so in a more accurate and consistent manner. Voting mana is the intermediary value that was previously calculated by multiplying voting power and Steem Power. Voting power regeneration is now more precise, as are the consumed values that result in awarding reward shares to content. Along with this change, we were able to make the rules regarding Steem Power and delegations consistent and eliminate the exploits that previously riddled Steem.
Vote Directly with Mana
Even though we changed the internal structures of Steem to use voting mana, the vote operation itself still used a percentage weight. It is not nearly as bad for precision as the percentage voting power, but it is less than ideal for precision of votes. This is especially true when changing your vote. For example, if your max mana is 1,000,000 and you vote on a piece of content with 50% weight, you will use 10,000 mana.(A 100% vote is capped at 1/50th of your remaining mana). If you later go and change your vote to 100%, you will use 19,800 mana. If you had voted 100% instead originally the vote would have been worth 20,000. This subtlety is hidden through the use of the percent weight.
In the SMT hardfork we are adding a new vote operation that will vote directly with voting mana. The same max vote restrictions are enforced, but will make the impact of the vote clearer. This operation will be used for voting on all SMTs and allows users to vote with each SMT separately, each with different amounts of mana. This will allow you to upvote content with one SMT while downvoting it with a different SMT. Comments can specify up to 5 SMTs that can vote on them, for a total of 6 assets (5 SMTs plus STEEM).
There is one more oddity from the previous example. Did you notice it?
You changed your vote from 50% to 100% and in total used 29,800 mana when a 100% upvote first would have only used 20,000 mana! When you change a vote you lose out on any curation rewards you would have earned. We think this is harsh enough for changing a vote.
Being charged fully for both votes is unnecessarily punitive, which is why were are making the following changes to how votes are charged.
If the absolute reward shares assigned by the vote increase, you are only charged for the delta. You will still be fully charged for changing from a downvote to an upvote and vis-versa. Here are a few examples to help demonstrate how these rules will impact your voting.
If you change a vote from 75% to 100%, you consume mana of a 25% upvote.
If you change the 100% vote to 50%, you consume no mana.
If you change the 50% vote to -50%, you consume mana of a 50% downvote.
If you change the -50% vote to -100%, you consume mana of a 50% downvote.
If you change the -100% vote to -25%, you consume no mana.
If you change the -25% back to a 75% upvote, you consume mana of a 75% upvote.
We believe these changes will continue the progress we have already made over the last several years to make voting more intuitive and fair to everyone.
this is a bit confusing
devs, man, that's how they talk. weird, right?
What part is confusing? Perhaps I can clarify.
To be clear, this will be a new voting operation that specifies mana consumption for each vote instead of upvote percentage?
But the existing upvote operations will still work? We should be extremely cautious about deprecating any operation that hundreds of third-party tools are using.
Voting an an SMT requires using the new vote operation that votes with mana directly, but the existing vote operation will continue to work for voting with just STEEM. It already converts the percent voting power in to consumed mana and will follow these new rules.
Can you clarify this:
Do you still get curation rewards based on your new vote?
just to add to @lordbutterfly's "No" I would note that losing that curation is not a new thing.
No you dont.
No, but there are talks about making this better that it will allow curation rewards at the point of the new vote. So far it isn't scheduled to be in a specific hard fork but would be a better behavior if approved. This will allow you to get curation rewards even if changing your vote, but you lose your original position.
The reason for the loss of curation rewards is to prevent a user from voting a minimum amount on many posts to lock a curation position then changing it to a larger vote if a post starts to do well.
Great explanation and important changes. Though I still have a question: if I change my 100% vote to 50%, I'm not being charged additional mana, but the curation rewards are reset, right? It might be a good side benefit if the curation rewards wouldn't be reset afterwards. Or isn't this possible due to the vote being replaced, including timestamp?
There really should be some sort of penalty. If you vote 100% and then I downvote because I think that is excessive, and then you reduce your vote to 50%, I've still used up my downvote mana. Similarly, you might make a big vote giving someting visibility and other smaller voters might follow on expecting the post to trend, generating curation rewards. Then when you remove/reduce your vote, the chance of trending is reduced and the later voters may regret their votes (despite potentially gaining relative curation reward share).
I think the inherently sequential nature of voting is pretty important and there needs to be sufficient penalties while allowing people to change votes when actually necessary. An exception could be if there are no subsequent votes (you are still the last vote), perhaps it should be possible to change vote without any sort of penalty (a misclick exception). But that will be an edge case and even very unlikely to ever happen if the user base is large enough with many votes coming in all the time.
I was thinking that the rule I had in mind for changing to a later vote position (equivalent to unvoting and revoting with a different account) is enough of a penalty, though now that I think about it a bit, there are plenty of situations where this isn't true, especially with auction timer and large vote weight changes. But when it comes to the votes before such an adjustment, I don't see the conceptual difference between an event in which you change your vote significantly and an equivalent vote by another account that comes to shake things up.
I think complete negation of curation is too harsh of a penalty, especially in cases where one makes mistakes, which you mentioned.
I was also thinking in terms of comparisons to a multi account setup, though they are a bit hard to compare exactly. Multi account setups with the same total stake can adjust the post payout multiple times without sacrificing any curation, for example.
The point about multiple accounts is an excellent one. But with multiple accounts you can't remove the first vote at all, only add to it or subtract from it with a downvote. Not exactly the same thing as changing.
Though if one can argue that the multiaccount solution is strictly better than changing, that is an argument for allowing changing, but not to the extent that it may convey further advantage or disadvantage others. Some aspects of this may be very difficult to realize in implementation.
I believe you are talking about votes which are sequentially previous? In that case I agree, which is why I said that when your vote is last, changing it can be allowed without penalty.
But...on second thought even, that is not entirely true. Your vote might have discouraged others from following and then once you remove your vote the auction timer would be burned down. I believe the rule about allowing the last vote to change with no penalty can only strictly be applied after the penalty expires (so that mere passage of time does itself not change the state of voting).
Another rule variant I've considered aside from being the last vote as I mentioned is to allow vote changes without penalty or with reduced penalty for some time period, say one minute, even if no longer last in the stack. Subsequent voters can consider that previous votes are not yet 'final' until the timer has expired.
You can remove the first vote at the cost of curation just like the single case, but with the proposed change, the single account will get a sort of benefit by only being charged the delta for an upward adjustment. Hmm.
Yes, but I mean distinguishing between
a) account changing vote, say reduction by X rshares
b) different account coming in and downvoting the same amount of rshares
To anyone that has voted before this event, it looks the same.
Under the "set curation weight to last vote" proposal, we could still apply an adjustment penalty on top, for example. And make it so that the curation weight cannot be larger than what it was * penalty. Something like that. Maybe that's too complicated, but probably not much more than curation is already :)
That's not a benefit relative to multiple accounts. With an original vote of A and a new vote of B, the voter is charged for A+B-A. But with two accounts, the first account would vote A and be charged for A, and the second account would vote B-A and be charged for B-A, for a total cost of again A+B-A.
I think it is because I'm coming at it from the perspective that vote changing should not be normalized. There are just too many ways in which it complicates and undermines the sequential nature of voting (where voters act with knowledge of previous votes). IMO vote changing is useful in certain exceptional cases such as mistakes or new information about the content, but mostly people just just take more care in voting without expecting to be able to change it with no or low penalty.
I do agree with not incentivizing account splitting, which calls for penalties being small or zero to the extent they can be circumvented with multiple accounts (as above).
Yeah, I think you're right in that vote changing should not be a normal occurrence. Was just thinking if there is something in between the multi account (keeps CR) and single account change situation (no CR)
And yup I am not sure what I was thinking about in the multi-account scenario above, I was wrong on that point.
Posted using Partiko Android
I agree on the first point. The advantage that multiaccounting can incrementally increase votes without penalty but single accounts can't is not ideal.
Good point!
This is my understanding.
Trying to think of an example where not resetting CR could be tricky:
Here, would you want/deserve to keep your curation reward?
No. Only if weight > 0.
I think the problem of not resetting the curation rewards is how to calculate it, should it be calculated at the time of changing it to 50% or should it just make it half when the upvote changes from 100% to 50%.
We should be clear here, because to me "reset" means "as if you voted at the new time", but in reality, the current behavior is "give up curation altogether on the post". I would like to ask if we can do the "as if voted at new time" deal.
This makes the most sense to me as well.
Ah really? I didn't know that. I thought it was give up your current position (timing) for the curation rewards and replace it with the new one, for the new vote.
What's the downside about keeping the curation ratio if the vote weight is changed from 100% to 50%? The voting mana isn't returned, so there's already the downside from that. But I don't think it needs to be treated as a completely new vote.
Example:
100% vote => 40% curation effectivity
a few hours later
50% vote => 15% curation effectivity
Currently, we would use the newest curation effectivity, but why not use the first one?
Not sure, have to think on it. Is there a difference down or up?
All I know is that treating as a new vote is better than complete removal. If this other suggestion has no weird quirks it could be fine too.
Posted using Partiko Android
It should only work if the vote weight is being reduced, otherwise, you could spam very small votes (0.01%) and adjust their vote weights once the curation effectiveness is known.
A good example of my initial point is:
Let's say I'm automatically curating a specific author, but a specific post isn't as valuable as I thought, so I want to reduce the weight.
I thought of that, but if your weight doesn't change in the up direction, the rshares that you piled on top don't have curation weights associated to it. Granted, it might still be better than voting 100% at the later time to begin with, but have to work out those numbers.
But if up vs down matters, I think treating as if you only voted late is the more consistent approach.
(Btw I don't think vandeberg proposed treating as new weight. It looks like it will just be forfeited altogether, unless I misread)
Posted using Partiko Android
Re-read the post and you're right. Well, that sucks. Is there a technical limitation for that? Even if the vote would be added on top, the code could look for the newest vote from voters.
As I noted elsewhere, I think penalties, even fairly harsh, for changing votes are reasonable given the inherently sequential nature of voting. Your vote may induce others to vote after you and then when you change your vote, their votes may be hurt.
Changing is needed in some edge cases like when a post is discovered as plagiarism after people already voted on it (actually even this is debatable since the early voters could and perhaps should have been more careful in vetting, and the solution is just pile on downvotes) but it shouldn't really be normalized to too large an extent.
I think that's the explanation for curation rewards being reset. The order of voting changes.
But I believe these changes can be exploited: Vote a post with a high percentage, but if the pending payout doesn't reach the expected level, after a while change it to a much lower percent at no voting mana penalty.
So authors specify these?
Will the assets limit be set in the blockchain or can be a parameter that witnesses set?
I can't wait to see the UI for this.
There may or may not be one, or different applications may offer different aspects of it. There are already many functions on the blockchain that don't map directly to most or all UIs.
nice
nice
This will allow you to upvote content with one SMT while downvoting it with a different SMT.
It will hold true if you have same number of stake in all the SMTs.
This makes sense if you think of something analogous to tag abuse. Perhaps it is mischaracterized with respect to one community/SMT but still got votes. It should be downvoted there but perhaps upvoted in its correct one.
terrific explanation and crucial adjustments. even though i nevertheless have a query: if i change my 100% vote to 50%, i am no longer being charged extra mana, but the curation rewards are reset, right? it might be a very good side benefit if the curation rewards would not be reset afterwards. or isn't always this feasible due to the vote being changed, including timestamp?
Thanks for this very comprehensive post. Just a question: if one revotes on something, one will still lose all curation rewards. Is this correct?
I think that's correct, until and unless they change the logic which is quite tricky.
Thanks for the confirmation!