-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIP 008: Adjusting Validator Block Reward #11
Comments
Sounds great! I have a couple of points: |
Agree with Andy on all points. |
|
Thanks for the feedback guys 👍
|
[WIP] FIP8: Adjusting Validator Block Reward
Problem
The current consensus mechanism has two constraints:
The following constraints, introduce a number of disadvantages:
Goals
The goals of this FIP are:
(a) removing the maximum stake per validator limit (constain 1)
(b) changing the current validator selection process. Top 100 accounts with the highest amount of tokens staked are going to be chosen as network validators.(b) introducing a new block reward function, so validators will receive block rewards in accordance to their stake.
Why is a new block reward function required?
By Aura consensus which we are using, all validators get to validate the same amount of blocks, and receive the same block reward. So all validators, without considering their stake expected to receive the same rewards. The block reward function is needed to take validator’s stake into account, so the validators would lower the number of the nodes they are running.
Another important property of Aura consensus, is that the time is partitioned into time slots that are divided between the validators, when each validator is allowed to validate only his time slots.
Block reward function
The new block reward formula should have the following properties:
I suggest the following formula for Ra, the block reward of validator A:
Ra = (Sa / S) * n * R
Where:
Meaning that the new block reward will be proportional to the ratio of validator’s stake. We will see in a while why multiplying by the number of validators is needed.
Examples
Let’s look at a simple example of two validators A and B, with the stake of 100K and1M.
We are going to inspect a certain amount of time that ‘s sufficient to validate 100 blocks. With the current block time of time seconds it is 500s, but every time period can be used.
Without the proposal
Va = 100 /
Validator reward is number of blocks A validated multiply the block reward
Va = Ba * R = 10R
vb = Bb * R = 90R
With the proposal, validator B can combine his 9 accounts into one:
Using the new formula, the reward should be:
Ra = (Sa / S) * n * R
Ra = (100k / 1rM) * 2 * R= 0.2R
Rb = (900k / 1M) * 2 * R= 1.8R
Va = 50 * 0.2R = 10R ✅
Vb = 50 * 1.8R = 90R ✅
We can see that the Validator reward over time didn’t change, fulfilling (1) property of the formula.
Now, Assuming that B wants to split his stake to 3 nodes
Ra = (100k / 1M) * 4 * R= 0.4R
Rb1 = (500k / 1M) * 4 * R= 2R
Rb2 = (200k / 1M) * 4 * R= 0.8R
Rb3 = (200k / 1M) * 4 * R= 0.8R
Va = 25 * 0.4R = 10R ✅
Vb1 = 25 * 2R = 50R
Vb2 = 25 * 0.8R = 20R
Vb3 = 25 * 0.8R = 20R
Vb = Vb1 + Vb2 + Vb3 = 90R ✅
We can see that splitting the funds for Validator B, didn’t change his reward over time, fulfilling (2) property of the formula
Proof
Mathematical proof that suggested block reward formula is sounds
_Work in Progress _🏗👷♂️
What happens when the validator misses blocks?
When the validator misses his time slot to validate the block, no block reward is generated in this time slot. Then the next validator is allowed to validate the new block is the new time slot. Meaning that, missing blocks is not affecting the reward of other validators, and can only reduce the inflation (because less block rewards are generated)
Governance
Governance is an integral part of the network. With the current voting mechanism, the validator’s votes are equal as all validator accounts have the same amount of tokens staked.
We propose that the weight of validator’s vote, going to be proportional to the amount of tokens staked. Getting back to example 1: validator A with 100K fuse is going to have 1 vote, while validator B with 900K will have 9 votes (or other amounts that keep that ratio). We will expand this subject further if needed.
Pros and Cons
Let’s do a quick evaluation of pros and cons of the proposal and its consequences:
Pros
Cons
The text was updated successfully, but these errors were encountered: