EOSPark Talks: BP Voting

How to calculate the vote scores?
score_of_vote=stake_of_EOS∗2^​(current_year−2000)​​

For instance, now is 0:00 on 1st, January, 2018, I staked 100 EOS, then the score I voted for Block Producer A is: 100 * 2^18.5 =37072760

Half year later, at 0:00 on 1st, January, 2019, I staked 100 EOS, then I voted for Block Producer A again, then the total score of Block Producer A will be reduced by the score of my previous vote, 37072760. Then add my current score: 100 * 2^19=52428800, view the source code for details.

When you reduce or increase your own staked EOS, the scores of previous votes will be updated in real time, and the total score of the BP been voted will be reduced or increased accordingly. So that’s why you obviously voted for a BP, why are they still urging you to continue to vote for him, because even though the number of EOS you staked has not changed, the score for each ticket at different times is Not the same, it is increasing with time.

What is the number of voting accounts?
The number of voting accounts is a reflection of the BP’s support rate from another dimension. Indicates that there are so many EOS users voted for their favorite BPs. However, the ranking of the BPs is not based on the number of voting accounts, but is sorted by the total scores of votes in the voting mentioned above.

So you will find out that some BPs have a small amount of voting accounts, but their scores are very high. The reason is there are many EOS big households voted for them. One big ticket has a very high amount of money.

Few days ago, I found a very interesting account bpvoter.one. Under this account, I created more than 600 small accounts. Then I can click on a small account and I found that they are all staked with EOS ranging from 2000 to 5000. These small accounts don’t do anything other than voting. Lol.

What is unclaimed rewards?
The BPs worked hard to produce block, and the work done with price.(the annual server cost is still very high). In addition, EOS will burn EOS through some operations such as auctioning and buying and selling RAM. If there is no additional issuance, it will lead to deflation, so there is an EOS additional offering that does not exceed 5% per year. Then how are these issued EOS distributed?

First, 80% of this part of the EOS will be sent to an account called eosio.saving. You can see that there are more than 9 million EOSs out there. It is said that EOS in this account will be used for community building.

Then, the remaining 20% is rewarded to the BPs. This part of the reward is divided into two parts, 25% of which is used as a block reward, and the remaining 75% is the voting reward we will introduce in this article.

So what is the rule of 75% of the 20% of the annual 5% of the additional issuance to BPs?

Voting reward distribution rules before contract version 1.3.0
The previous distribution rules were simple but rude, and each of them was divided according to the proportion of the votes they obtained. In this case, the first-ranked eosuobibipool is an example. At this time, its score is 2.596%, so if it keeps the ticket rate from now on, it will remain unshakable for a hundred years, then its reward will be rewarded in one year. Is:

10000000000.050.20.750.02596=1947001000000000∗0.05∗0.2∗0.75∗0.02596=194700

The daily reward for the ticket is approximately 194700/365=533. However, this is not the only rewards for this BP. Don’t forget the rewards above-mentioned.

Voting reward distribution rules after contract version 1.3.0
We finally come to the most important part of this article, and the release notes is here. The new distribution rules are described in the New producer pay algorithm chapter. Anyway, I don't understand much. I can only read the global language in the source code.

First introduce the big background, the new version introduces a concept called votepay share. By reading the code, I understand that this new concept is a share similar to the ticket score that grows proportionally with time, followed by the share of the vote. More than to distribute voting rewards. The calculation of this vote share is roughly as follows:

Vote for shares = score of votes * time difference

This time difference is the time difference between any two operations involving the updated ticket score, such as voting for a BP, increasing/decreasing the EOS of the stake, the operation of claiming rewards for the BP, and so on.

If this is the case, it is actually not much different from the old ones. It is just a change of shells, but there is a special limitation: when the BP has not made a claimrewards operation for more than three days, it will not receive any rewards. The rewards will be taken away by other hard-working BPs in disguise.

So what impact does this particular restriction have? You may say that the current BPs are basically rewards every day. Some BPs even write a script every day, and there are very few that have not been received for more than three days. Well, for the first 21 BPs, is this the alternative BP? We know that usually the standby BP does not have the opportunity to make a block, so only the ticket is rewarded, and the reward is less than 100 EOS is not available, so it is very likely that there will be no embarrassing situation of claimrewards operation for three days. If the purpose of this new version is to filter out the garbage alternate BPs, then I can secretly tell you that this version of the system contract is a bug.

Before explaining this bug, you must first understand the logic of the new version. Explain from the two actions, one is the voteproducer that votes for the BP, and the other is the BP’s claim operation claimrewards. For the explanation of the following examples, a macro definition is given first:

voteproducer

Claimrewards
After the new version of the system contract is deployed, the BP is required to manually perform an updtrevision to start the new version of the ticket reward settlement logic. After that, the BP can be re-updated manually with regproducer, or automatically updated at the next claimrewards.

When there is no operation related to updating the ticket score between updtrevision and regproducer/claimrewards



When there is an operation related to the updated ticket score between updtrevision and regproducer/claimrewards

Sample summary
By example 1, 2, 6, and 7, you can know that if the BP does not claimrewards for more than 3 days, the reward will be cleared to 0, and the lost reward will continue to be in the reward pool. Equal to disguise increases the rewards of other BPs.
Through examples 8, 9, you can know that the BP should perform a regproducer or claimrewards operation as soon as possible after completing the updtrevision operation, otherwise the possible rewards from the user vote during this period will be lost. This is also the reason why the last sentence in the original text says that some rewards may be lost.

About bugs

Now let’s explain the bug mentioned earlier. This bug exists in determining whether the claimrewards has been more than 3 days since the last claimrewards.

[Related source code] as follows:

When it is judged that the ticket reward is less than 100 EOS, the code will go straight to p.last_claim_time = ct; this line, personally think this should be a bug, because the alternative points can write a timed script to do a claimrewards operation every day. Although they may not be able to claim any rewards, they can still successfully refresh their last_claim_time time. In this case, the new version of the judgment about not claiming for more than 3 days will not succeed.

Contact us:

Website: http://eospark.com
LinkedIn: https://www.linkedin.com/company/bloc...
Twitter: https://twitter.com/eospark_com
Telegram: https://t.me/eospark (EOSPark Official)

Tagged:
Sign In or Register to comment.
Join Telegram