BitShares Forum
Main => General Discussion => Topic started by: bytemaster on January 04, 2016, 10:05:13 pm
-
The purpose of this BSIP is to minimize the cost incurred by the network doing unnecessary operations every maitenance interval.
Every hour votes are tallied and 99% of the time there is no meaningful change. Under this proposal, votes would only be tallied when requested by a user and at most once per maintenance interval. The fee for tallying votes would be around $5.
Users of the system can determine whether or not there is a $5 difference in votes that would justify a re-tally. A worker, witness, or committee member who got voted in would pay $5 to have the vote counted.
The side effect of this behavior would be to greatly improve reindexing performance, the vast majority of which is spent tallying votes that never change.
Witnesses producing blocks on the maintenance interval can pre-tally the votes and compare them to the last value. They can then indicate whether or not anything changed significantly in the block they produce.
If there is no one who stands to benefit by more than $5 then chances are it is an unnecessary update to the voting totals.
-
Cool idea.. approx what % of time in maintenance is spent tallying votes?
-
The purpose of this BSIP is to minimize the cost incurred by the network doing unnecessary operations every maitenance interval.
Can that cost be represented in time/money so we have an idea of how this would improve BitShares' blockchain? How much money/time does it save / can it potentially save in the future?
-
The purpose of this BSIP is to minimize the cost incurred by the network doing unnecessary operations every maitenance interval.
Every hour votes are tallied and 99% of the time there is no meaningful change. Under this proposal, votes would only be tallied when requested by a user and at most once per maintenance interval. The fee for tallying votes would be around $5.
Users of the system can determine whether or not there is a $5 difference in votes that would justify a re-tally. A worker, witness, or committee member who got voted in would pay $5 to have the vote counted.
The side effect of this behavior would be to greatly improve reindexing performance, the vast majority of which is spent tallying votes that never change.
Witnesses producing blocks on the maintenance interval can pre-tally the votes and compare them to the last value. They can then indicate whether or not anything changed significantly in the block they produce.
If there is no one who stands to benefit by more than $5 then chances are it is an unnecessary update to the voting totals.
Ideas to improve performance are always good.
However, to implement this BSIP, it's needed to implement "Maintain Proxy Voting Totals ($3000)" (https://github.com/cryptonomex/graphene/issues/454) first, otherwise a common user may have no way to check who would be voted in on next maintenance interval, then she would perhaps trigger that every hour.
-
Sounds good.
Can this be done in a way that makes crowdfunding possible? Something like an account, that is checked once every maintenance interval, and if it has enough funds, tallying will be done.
We have still very few committee members and it's not going to help if they have to pay to become one. If crowdfunding was possible they could just ask donations to the tallying fund account until there's enough.
-
I support this idea.
-
I think I can automate this in the witnesses so no fee for tallying votes is necessary nor manual intervention required.
-
If I understand your automation idea correctly, just make sure the ability the vote to correct a problem quickly isn't impaired. In 1.0 it was tough to vote out poorly performing witnesses (for several reasons), but in 2.0 that situation is made worse through the introduction of the maintenance interval.
I understand the tradeoff you made and the need for the maintenance interval in 2.0, not arguing against that.
Just making sure you consider the impact on ability to take corrective action through voting. This should be included under the PROs and CONs as a CON in the BSIP.
If the result of implementing this BSIP increases the time to make important changes (like removal of bad actors), it may still be worth it but that impact needs to be fully disclosed by providing a few use cases of how the BSIP will alter current operation.
-
If I understand your automation idea correctly, just make sure the ability the vote to correct a problem quickly isn't impaired. In 1.0 it was tough to vote out poorly performing witnesses (for several reasons), but in 2.0 that situation is made worse through the introduction of the maintenance interval.
I understand the tradeoff you made and the need for the maintenance interval in 2.0, not arguing against that.
Just making sure you consider the impact on ability to take corrective action through voting. This should be included under the PROs and CONs as a CON in the BSIP.
If the result of implementing this BSIP increases the time to make important changes (like removal of bad actors), it may still be worth it but that impact needs to be fully disclosed by providing a few use cases of how the BSIP will alter current operation.
My approach should not have any negative impacts.