FIP 008: Adjusting Validator Block Reward

[leonprou]

[WIP] FIP8: Adjusting Validator Block Reward

Problem

The current consensus mechanism has two constraints:

1. Maximum stake per validator account is 100K
2. Maximum number of validator accounts is 100

The following constraints, introduce a number of disadvantages:

• Validators have to own multiple validator accounts and run multiple nodes to stake more than the maximum amount for account.
• When both Maximum stake and maximum number of validators capped, maximum total stake is capped as well to 10M. It’s impossible to use for staking more than this.

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:

1. Do not change the inflation of the token over time.
2. Splitting or combining the validator’s stake to multiple accounts should not affect the validator's reward over time. Meaning that a validator with the total stake of 1M can run one machine with 1M staked, two machines with 500K on each, or 10 machines with 100K. All these options should give to the validator the same block reward.

I suggest the following formula for Ra, the block reward of validator A:

Ra = (Sa / S) n R

Where:

_Sa - the stake of validator A_

_S - total stake of top 100 validators_

_n - number of validators_

_R - current reward with adjustment to the inflation planed_

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

Validator	Stake	# of nodes	Blocks validated	Reward per block	Validator’s reward
A	100K	1	10 (=Ba)	R	10R (=Va)
B	900K	9	90 (=Bb)	R	90R (=Rb)
Total	1M	10	100	X (Average)	100R

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:

Validator	Stake	# of nodes	Block validated	Reward per block	Validator’s reward
A	100K	1	50	0.2R (=Ra)	10R (=Va)
B	900K	1	50	1.8R (=Rb)	90R (=Vb)
Total	1M	10	100	R	100R

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

Validator	Stake	# of nodes	Block validated	Reward per block	Validator’s reward
A	100K	1	25	0.2R (=Ra)	10R (=Va)
B1	500K	1	25	2R (=Rb1)	50R (=Vb1)
B2	200K	1	25	0.8R (=Rb2)	20R (=Vb2)
B3	200K	1	25	0.8R (=Rb3)	20R (=Vb3)
Total	1M	10	100	R	100X

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

• One validator account and one node per validator
• All fuse tokens can be delegated, giving revenue for all the holders
• Voting should be easier, because validator need to vote only once
• (Implementation is rather fast and not much changes are required)

Cons

• As suggested, the small stake validators will validate the same amount of blocks as high stake validators. This can make network attacks possible when many small validators refuse to validate the blocks. For example if there’s 5 validators with stake: 100M, 100K, 100K, 100K, 100K. And the 4 small validators stop to validate blocks, only 1 of 5 blocks will be validated, reducing the network TPS by 5.

[Andrew-Pohl]

Sounds great! I have a couple of points: 1: I take it the minimum required to run a node will still be 100k?

2. Is it possible to have a lower limit on validation fee to avoid "land grabs" of nodes setting fees to 0% getting a lot of delegation then raising them (without delegates knowing). Maybe we could have a fee of 10/20%
3. Kind of relays into point 2, there probably needs to be a mechanism to limit the rate and amount a validator can change his/her fee. i.e there is currently nothing stopping a node setting the fee to 0% then when they have a large amount of delegations bumping that up significantly (delgators may miss this). Maybe we could limit nodes to only updating fees every week (X cycles) and only by increments up to 5%?

[CrackerHax]

Agree with Andy on all points.

[fileflume]

1) Typo here: Va = 50 0.8R = 10R ✅ Should it be 50 1.8R = 90R?

2) "One validator account and one node per validator" With increased tx fees it may become profitable to run multiple validating nodes.

3) Certainly need to stop validators being able to change their delegation fees whenever they choose. I think there's a better way where network inflation, validator fees and tx fees are set at the network level and voted upon, or determined by the governance body.

4) Voting - only validators can vote? And weighted based on the total number of tokens staked and delegated to that node.

[leonprou]

Thanks for the feedback guys 👍

@fileflume

1. you're right about this, also it's for Vb = 50 * 1.8R = 90R.
2. Good point about the fees. Yep that's a definitely a drawback of the FIP8.
3. Need to discuss this separately, We've opened a discourse I think it's a good place for discussions: https://fuseforum.trydiscourse.com/. I prefer to keep the github for technical comments and specs.
4. Yeah, only the validators can vote. But delegators are voting by selecting the validators. it's like choosing the parliament. Yep the votes should be weighted, but we still consider if this gonna be part of this FIP or a the next one.

@Andrew-Pohl

1. We are discussing the max and min limits. I think we can open a separate discussion for this on https://fuseforum.trydiscourse.com/. And on 2 as well.
2. I think it's a good idea to specify all the exploitation and attacks so we can decide on what to implement. So I'll write this down for me.