You are viewing a single comment's thread from:
RE: A simple, radical change to Steem that could fix most of our problems.
Thinking this through a little more, the system could be set to deliver all rewards when at 100% voting power as Steem. That should enforce the par between rewards types and might be an even easier way to accomplish the whole thing.
Perhaps, I was going to ask how you propose the choice be technically implemented. That makes me think of this:
Votes will probably decrease, but other costs will rise up to replace them, and back of the napkin guesswork tells me it'd be a net increase in cost.
Votes are active actions which nodes respond to on demand. From my understanding (as a former backup witness and active 3rd party developer) the computation strategy is to respond to events as much as possible and have as few "implied events", what are called "virtual operations" (check out the end of information on this block on steemd.com).
The blockchain nodes don't actually keep track of VP regeneration, it is only calculated again when another vote is cast. Blockchain users (by which I mean any front end or app) must manually recalculate this if it's something they're interested in before voting. There is no regeneration operation, not even virtual, and the blockchain doesn't care until another vote is cast, saving on computation.
Adding total system-wide payouts periodically (should be ever X minutes or hours I guess) for all accounts at 100% VP would (a) require VP regeneration to be actively calculated by nodes, and (b) calculate how much to pay them, and then pay them, periodically. Depending on the amount of account which reach or maintain 100% VP the compute cost could be a very significant increase.
As an optimisation, VP calculations could at least stop when VP reaches 100% if there is no further voting operations. However (b) would still cost.
My original thought was there would simply be an account flag that users could set to a number between 0 and 10000 (since we like that number) for how much of their rewards to get in each system. Then there should be less computation because all of the pool payouts come with very complex computations already anyway, and the new ones would be much simpler.
I can see that the 100% cap might be harder to do though.
I'm not sure it saves computation so much as outsourcing it, since we're all looking at our live voting power all the time anyway. But I guess if the witnesses don't have to do it that's something. Still, it should be possible to set a 100% signal somehow even if we aren't doing it granularly.
Not sure how Voting Mana is going to change all that anyway.
That removes cost (a), but increases cost (b). I'll have to dig into the code but I think you're very much understating the burden this would have on nodes, their complex computations not withstanding. You're proposing additional account operations for every account that selects this (not proportional to the sliding scale, of course) or every account at 100%, every X time period. I would like to see an actual reckoning with this fact, or at least a good rebuttal if you think I'm wrong.
Saves computation for witnesses obviously. Not doing it on nodes is likely to increase total universe size work to do because lots of other computers are needlessly calculating it, but that's just being pedantic. When we talk of computational cost, we're of course talking about witnesses, that is a given.
I think I'm going to have to see Voting Mana in action before I can do that for the 100% idea. For the flag, I'll see what I can come up with. Nobody's going to implement this this week anyway.
For real. I'll stay tuned and contribute if I can, at least to thrash it out.