[Proposal] Improvents to the proposal system

2개월 전

The proposal system introduced in the HF21 is a big improvement and step forward in the blockchain. Thanks to this Steem is now a bit more auto sustainable in terms of developments and contributions.

In this sense, I also want to give my contribution. The objective of the current proposal is to improve the steem code, concretely, the proposal system itself. Although the work done by @blocktrades and his team is very good and appreciated, there are still some things to fix and it also needs new features relevant to both creators and stakeholders.

Improvements

The improvements I propose to develop are:

  • Vote weight
  • Add maximum payment
  • Calculate the total paid
  • Fix scalability issues

Vote weight

Currently, when a user votes for a proposal he is voting with all of his steem power, there is no way to define a weight.

For big stakeholders this is a problem. Suppose this situation: A big stakeholder votes for a return proposal and votes for a proposal for a new development. He really wants the new development but it is not reaching the threshold. If he removes the vote from the return proposal then the development will start getting the funds, however, the return proposal lose a lot of votes and then other proposals can cross the barrier and get funds too.

This problem can be solved by giving the possibility to vote with different vests. In this case, the stakeholder could reduce the vote for return proposal a little bit in order to reduce the threshold for the development but not too much and the barrier continues for the rest.

Maximum payment

Suppose this scenario: A proposal is created to work during 15 days and asks a daily payment of 100 sbd. Then the expectation is to to receive 1500 sbd. What happens if at the end of the period the total payout is only 1000 sbd? There are some ends in the current implementation:

  1. The contributor finishes the work despite the final payout. We rely in the good will of the contributor but sometimes a reduction of the budget is not enough to finish the work.
  2. The contributor creates a new proposal asking for the remaining amount. This is a good solution, but the problem is to get the again the attention from the stakeholders, which have to vote again the new proposal.
  3. The work is not finished or it is partially finished (if applies).

One solution to these problems is the possibility to define a maximum payment. Following the example above, the contributor could create a proposal to work during 25 days, ask a daily payment of 100 sbd, but put 1500 sbd as the maximum payment. In this sense there are 10 additional days to complete the payment, but it can not increase beyond 1500 sbd.

Calculate the total paid

In the current implementation the unique way to calculate the total paid to an active proposal is by consulting all single payments using the history api.

If we implement the maximum payment described above, then the total paid must be added too, and it can be easily obtained by calling the proposal details.

Scalability issues - Total votes

Currently, each hour, all votes from all active proposals are computed in order to sort them and distribute the payments.
If a single proposal is voted by 12000 users then, each hour the blockchain will add the steem power of all of them, which is not scalable to hundred of proposals and thousands of users.

The best way to handle this issue is by calculating only the increments. If a new vote comes in, then the total is incremented. If it is removed then the total decreases. If there is a power down then the proposals voted decrease. If there is a power up the new vests are added to the proposals voted.

In this sense, after the end of the period there is no need to calculate the votes, just sort them and distribute the payments.

This part will also solve the current problem with the inactive proposals, which the total votes are not calculated because the inactive proposals are not in the schedule of payments.

Timeline and qualifications

The total payment for this work is 4800 sbd, distributed in 30 days with daily payment of 160 sbd.

The new code will be submitted as a pull request to the principal repository of steem.

Qualifications

I've been working as principal blockchain developer in a pilot project for the European Commission during almost one year. This time has helped me to get a lot of experience with respect to the core of the steem blockchain and I would like to continue doing more improvements.

I've made some minor contributions to the steem repository:

I've been contributing to the dsteem javascript library:

How to vote

To vote for this proposal follow this link.

To consult this proposal:

Acknowledgment

These ideas are the result of discussions with some users and witnesses, especially @smooth, about improvements that they would like to see implemented in a later hardfork.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
STEEMKR.COM IS SPONSORED BY
ADVERTISEMENT
Sort Order:  trending

Please address vote totals for inactive (upcoming) proposals. This is needed for stakeholders to know how to vote but the only way to calculate it currently is to retrieve all votes and add them up. This is very non-scaleable.

EDIT: After re-reading your description of how the totals will be updated I guess this will apply to inactive proposals as well, but please make that more clear in the writeup.

·

Yes. The new way to count the total votes will update both active and inactive proposals.

please make that more clear in the writeup.

Ok. I added it.

Another small improvement we could use is to put the proposal id in the account history entry for payouts. Currently it isn't there.

·

+1. I will take this into account.

I already voted for this but I would like to suggest one more addition. It would be very useful to retrieve the votes sorted by 'value' and not by name. This way it will be much easier to display them without fetching the whole list first.

·

Sure. This is a good suggestion.
By adding the vote weights we have to add a column for that in the table of votes. Then we can add the feature to sort by vote value.

Approved and Endorsed by me.

thumbsup

THIS IS AWESOME!!

SteemPeak was looking at some temporary non-hardfork solutions for some of this stuff but this would be great permanent solution!!

I personally really believe in the need for the MAX FUNDING option right now the work around is doable but not good because it requires too much trust and as we know if someone removes a proposal when it hits "max funding" then it's not "complete" and is hard to find the information.

QUESTIONS

What will it take to get this code running? HardFork? Replay?
How hard is it going to be to do?
You're editing the actual blockchain code right?
If it gets funded how long after do we think it'll be usable... just asking to see if we should forgo present work arounds for now.

Anyway my favorite proposal yet!

·

Thanks for your comment!

You're editing the actual blockchain code right?

Yes

What will it take to get this code running? HardFork? Replay?

Yes. It requires a hardfork because we are changing the consensus rules. And requires a replay.

If it gets funded how long after do we think it'll be usable...

The code is not too extensive, it can be done during the month. The final implementation depends on the witnesses (for instace, they probably will wait the SMTs to make only one hardfork)

What is your opinion on downvotes for proposals?

·

I would be against this currently as the Bitshares system (upon which SPS is based) has a track record of working fine using the return (or burn) mechanism. Introducing structural changes to a complicated voting system make it very difficult to predict what the results will be.

If it turns out, after significant experience on Steem, that we think there is a problem which downvotes would help solve, we can add them.

·

I think it is better not to introduce them to the proposal system. Not only because they are very controversial but also because they can be obtained in a different way.

Unlike the reward system for posts, the SPS does not have manabar or limit in the number of votes. So, if you want to penalize a particular proposal you can give votes to other proposals, the effect will be the same as a downvote. And, as I said, there is no restriction in the number of votes. It is like increasing the threshold for certain proposals.

·
·

Well...I can't really agree with that for the simple reason that there may be hundreds or thousands of other proposals (or even more than thousands). Theoretically, yes, you can vote for all of them without worrying about a manabar and this is equivalent to a downvote, but in practice, no not really (also one might even consider RCs at some point).

But the structure of having return/burn proposals is very much like downvotes in practice and it seems to have worked well for Bitshares so I say we should give that solid chance to work before jumping to downvotes.

I voted in 2 proposals. Still wondering how I can maximize my vote for other projects.

Posted using Partiko iOS

·

To maximize your vote buy Steem and power it up

Wow! These are very thoughtful additions to the SPS. Will resteem to help you get more attention. Great work man :)

These all seem very legit additions to the current SPS - Thanks for taking the time and brain power to write this up for us and make it possible to vote on it!

Hi @jga!

Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your UA account score is currently 5.343 which ranks you at #745 across all Steem accounts.
Your rank has dropped 7 places in the last three days (old rank 738).

In our last Algorithmic Curation Round, consisting of 130 contributions, your post is ranked at #1. Congratulations!

Evaluation of your UA score:
  • You've built up a nice network.
  • The readers appreciate your great work!
  • Great user engagement! You rock!

Feel free to join our @steem-ua Discord server

@proxy.token has upvoted for your proposal. @proxy.token hope all your efforts can contribute to the development of Steem community.

·

Thank you, and also thanks to all community behind @proxy.token for this support! I appreciate that.

Apoyando hermano por estos buenos planteamientos, esperemos sean tomados en cuenta.

You got my vote

Congratulations @jga! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :

You distributed more than 23000 upvotes. Your next target is to reach 24000 upvotes.

You can view your badges on your Steem Board and compare to others on the Steem Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Do not miss the last post from @steemitboard:

The new SteemFest⁴ badge is ready
Vote for @Steemitboard as a witness to get one more award and increased upvotes!

A bit late to answer, but still. I'd like to say that your proposal is really great. It is a good way to allow equity for smaller proposal, as this might lower the return-proposal without weakening the whole system, and allow to weight between priorities that one believes to be necessary for the blockchain.