[Suggestion] New BP Reward Proposal Based on Equipment Rewards - EOS NodeOne

loumloum Posts: 21 Brand New

[Suggestion] New BP Reward Proposal Based on Equipment Rewards

This is based on the ideas of Loum and Leo from EOS NodeOne. This article will later be submitted to worker proposal.

1. Purpose
We propose a new block producer(BP) reward model based on equipment rewards in order to compensate for the disadvantages of current producer pay model announced by Dawn 4.0 of block.one.

Our method can not only maintain a sufficient number of standby BPs and but also reduce the unnecessarily large revenue gap between the highest and the lowest rewarded BP.

2. Problems in the current Producer Pay Model
The producer pay model proposed by block.one in Dawn 4.0 is shown below.



Figure 1. BP reward method proposed by block.one

Top 21 active BPs divide up the 0.25% per-block rewards proportional to the number of blocks produced by them. All producer candidates also divide up the 0.75% per-vote rewards proportional to the total number of votes they receive, which makes a total of 1% inflation. In this pay model, while the top 21 active BPs receive both the per-vote rewards and the per-block rewards, but the standby BPs get only the per-vote rewards. Furthermore, block.one has set 100 EOS per day (0.48 %) as a cutoff threshold for claiming the per-vote rewards. In other words, standby BPs who got less votes than the cutoff threshold will not be rewarded at all.

Consequentially, the current producer pay model causes following problems:

  • 1) The difference in total rewards between the top rank and the lower end can be extremely huge by voting result. According to our calculation, the top 1 producer is rewarded about 20 to 30 times more than the last rewarded producer. See Figure 2.

  • 2) The total number of the rewarded producers can be quite small by the cutoff threshold. Our calculations indicate that the total number of BPs meeting the minimum reward criteria can be less than 50 or even 30. Besides, the number of standby BPs is solely determined by a voting result with the cutoff threshold.

The following table shows the BP rewards and the last rewarded producer rank by six scenarios including the Pareto distribution scenarios.


Figure 2. the BP rewards and the total number of rewarded BPs by six scenarios including three Pareto distributions scenarios.

Table link1: EOS NodeOne - BP Revenue Analysis (Version 1.1) (Only for reference)

3. Equipment Rewards and Essentials of BP rewards
We introduce the equipment reward and explain following essentials of BP rewards. We also provide an simple illustrative example of BP pay model below.

3.1 Equipment rewards
Standby BPs are literally supposed to stand by active BPs and replace them when they are in trouble. In order to make this process possible without any technical problems, they need to maintain such equipments equivalent to the active BPs.

For this reasons, we propose the equipment rewards as a new part of the producer pay model. Equipment rewards are literally to reward BPs for maintaining their equipments. Thus, with the equipment rewards, standby BPs ought to be prepared with adequate equipments for replacing active BPs in emergencies without any functional issues. Equipment rewards can be accepted as a minimum revenue guarantee for BP operation.

Since BPs receive the equipment rewards, the community have the right to ask standby BPs to have adequate equipment similar to the active BPs. Standby BPs can be required to publish their own equipments in public, which can hold them responsible for their words.

3.2 Per-Vote rewards
Now, let's look at the implications of per-vote rewards. All producers strive to get more votes from the EOS community because they are basically rewarded based on the votes they received. One of main role of active BPs is to provide appropriate computing resources for dApps. If the dApp platform is vigorously activated and so more computing resources are required, then the active BPs must scale their computing resources accordingly.

Since expanding their equipments, however, is costly, they will reluctantly do so. Therefore, they need a motivation. The per-vote rewards is exactly for that. The voting result can give a pressure on the active BPs to provide more computing resources. Otherwise, they will lose their votes which is associated directly with their revenue.

Hence, voters are supposed to use their votes intelligently to put financial pressure on all BPs to expand their equipments/infrastructure. We call this Infrastructure Growth Needs.
However, if it is the case that most votes are casted for the upper ranks of BPs, then the rest standby BPs will be faced with a difficulty in maintaining or upgrading their equipments for standy. In the Scenario 1 in Figure 2, the last rewarded BP is 29th ranked and lower ranked BPs than the rank 29th get nothing at all.

3.3 The number of standby BPs
Due to the cutoff threshold by block.one, the number of standby BPs is not fixed and can be continuously changed according to the vote results. The disadvantage of the current method is that the number of standby BPs can be very small and determined only by vote results.

One solution to this is set the total number of BPs who get paid the equipment rewards in order to fix the number of standby BPs. For example, we can set the equipment rewards for 63 BPs, three times the number of active BPs. In this case, 21 active BPs and 42 standby BPs are paid for their equipments.

3.4 Simple illustrative example of BP pay model with equipment rewards
As mentioned above, including both equipment rewards and per-vote rewards improve the current pay model in many aspects.. Here is a simple illustrative example for a BP pay model with both rewards sections.

Example: 0.5% Equipment Rewards, 0.5% Per-Vote Rewards
We divide the total 1% BP rewards by 0.5% for equipment rewards and 0.5% for per-vote rewards as shown in Figure 3. As a result, all 63 BPs receive equipment rewards and the 21 active BPs receive per-vote rewards too. In other words, active BPs will receive both rewards, while standby BPs will receive only equipment rewards.



Figure 3. Pay model consisting of both equipment rewards and per-vote rewards

However, this example has problems that the revenue difference between the active BPs and the standby BPs can become too large and the standby BPs paid equally in spite of different vote amounts they received which can demotivate lower ranked BPs to get more votes.

4. NEW BP pay model suggestion
We now propose our new practical producer pay model including equipment rewards. This model assures that a certain number of standby BPs can afford to maintain enough resources and the quality of the system for dApps. It also reduces the reward gap between the top rank and the last rewarded BPs.

Example: 0.25% Per-Block Rewards, 0.5% Per-Vote Rewards, 0.25% Equipment Rewards
This BP rewards consist of per-block rewards, per-vote rewards and equipment rewards, as shown in Figure 4. In this pay model, active BPs will receive all three rewards, while standby BPs receive per-vote rewards and equipment rewards. The only difference between this model and the current model is to add equipment rewards and reduce the total per-vote rewards percentage.

The new BP pay model can solve the problem caused by vote results which can make a huge revenue gap between BPs, and guarantee BPs to maintain their equipments properly. Therefore we think our model can solve the said drawbacks of the current method dramatically.

However, the percentages used in the above example are only for illustration. Therefore, we plan to provide the revenue analysis data tool for proper reward percentages of the new BP pay model in our next article.



Figure 4. BP rewards consisting of per-block rewards, per-vote rewards and equipment rewards.

5. Conclusion
We have proposed the new BP reward section, equipment rewards. With the equipment rewards, standby BPs are required to maintain their equipments similar to those of the active BPs. Also this can solve the drawbacks of the current pay mode dramatically, maintain a sufficient number of standby BPs, and reduce the unnecessarily huge reward gap between the highest and the lowest BPs.

However, we still leave how to qualify BPs to get equipment rewards and how to verify their equipments. These will be suggested later and also can be discussed in the community.

This is our second version of BP revenue analysis tool:
EOS NodeOne - BP Revenue Analysis (Version 2)

Tagged:

Comments

  • JuniAikoJuniAiko Posts: 1 Brand New
    edited June 19

    Perhaps a periodic auto benchmark (per hour or few hours) could be perform on a random BP, which will set and update a cap on the BP reward they are able to receive; imposed on top of the vote-based rewards.

    A list of the benchmark score and breakdown also could then be made avail. to voters.

    • BPs with a equipment benchmark score of zero will have 0% * vote-based-rewards.
    • BPs with less then ideal equipment benchmark score will only receive fractional rewards.
    • Standby BPs that exceeds their equipment benchmark scores could potentially have their rewards multiplied by a factor depending on what is taken away from the underperforming BPs.
  • unusunus Posts: 3 Brand New
    edited June 20

    there's some numbers in your proposal that came from nowhere, e.g. 63; the solution that solve current rewards problems for BPs has to include:
    1. solution for a fair distribution of rewards between stand by and active BPs; today I believe it is not, not even close
    2. solution for ensuring a standby BP is capable of taking over at any moment the job from an active BP which has problems and needs to be replaced
    3. proven number of standby BPs that can ensure the chain is bullet proof against attacks and random performance, scalability problems
    4. methods to measure the BPs performance and if a BP is missing blocks to lose rewards
    5. well explained (based on empirical evidence, and/or theory) reason for choosing a particular number of standby BPs
    6. well explained (based on empirical evidence, and/or theory) the split between rewards per vote/performance/hardware/etc.

  • leo_seoleo_seo Posts: 5 Brand New

    @JuniAiko said:
    Perhaps a periodic auto benchmark (per hour or few hours) could be perform on a random BP, which will set and update a cap on the BP reward they are able to receive; imposed on top of the vote-based rewards.

    A list of the benchmark score and breakdown also could then be made avail. to voters.

    • BPs with a equipment benchmark score of zero will have 0% * vote-based-rewards.
    • BPs with less then ideal equipment benchmark score will only receive fractional rewards.
    • Standby BPs that exceeds their equipment benchmark scores could potentially have their rewards multiplied by a factor depending on what is taken away from the underperforming BPs.

    I would like to say that you made good criteria for the equipment rewards.
    What I have been thinking is also how to qualify BPs for the rewards like check-mark criteria as we had before or verifying their nodes on a standby network.
    I guess we can discuss more about your suggestion which differs equipment rewards for BPs by more criteria.

  • leo_seoleo_seo Posts: 5 Brand New

    @unus said:
    there's some numbers in your proposal that came from nowhere, e.g. 63; the solution that solve current rewards problems for BPs has to include:
    1. solution for a fair distribution of rewards between stand by and active BPs; today I believe it is not, not even close
    2. solution for ensuring a standby BP is capable of taking over at any moment the job from an active BP which has problems and needs to be replaced
    3. proven number of standby BPs that can ensure the chain is bullet proof against attacks and random performance, scalability problems
    4. methods to measure the BPs performance and if a BP is missing blocks to lose rewards
    5. well explained (based on empirical evidence, and/or theory) reason for choosing a particular number of standby BPs
    6. well explained (based on empirical evidence, and/or theory) the split between rewards per vote/performance/hardware/etc.

    You got a very good point. By now, we have the tool below of the article to run some analyses on vote data. But as you said, we would rather have more reasonable grounds for the numbers.

    I am still researching on this. If you have any idea, please share.
    Thanks!

  • e3eeose3eeos Posts: 1 Brand New

    @JuniAiko said:
    Perhaps a periodic auto benchmark (per hour or few hours) could be perform on a random BP, which will set and update a cap on the BP reward they are able to receive; imposed on top of the vote-based rewards.

    A list of the benchmark score and breakdown also could then be made avail. to voters.

    • BPs with a equipment benchmark score of zero will have 0% * vote-based-rewards.
    • BPs with less then ideal equipment benchmark score will only receive fractional rewards.
    • Standby BPs that exceeds their equipment benchmark scores could potentially have their rewards multiplied by a factor depending on what is taken away from the underperforming BPs.

    The benchmark scores are worth exploring but need to be carefully measured and weighted. I think we should look into this.

Sign In or Register to comment.