[WIP] BEP-176: Validator Reward Model 2.0

[brilliant-lx]

BEP-176: Validator Reward Model 2.0

• BEP-176: Validator Reward Model 2.0
  • 1. Summary
  • 2. Abstract
  • 3. Status
  • 4.Motivation
  • 5. Specification
    • 5.1 Mechanism & Governance
  • 6. License

1. Summary

This BEP will introduce a new validator reward model on BNB Smart Chain. As a result of this BEP, the validator staking reward policy is going to be modified such that it is more accurately representative of the validator's contribution to the overall network.

2. Abstract

The mechanism for validator income distribution will be altered when this BEP is implemented. The specifics are still being worked out, but in general, we may divide the overall rewards from gas fees into two parts:

• Network Verification Reward: will be distributed among all validators more equitably, according to their contributions to the whole network.
• Block Reward: The single producer for its work on this block.

The proportion of each part is up for debate, and validators will have the possibility to alter the value through governance.

The idea suggests that we may favor a slightly greater ratio of the Network Verification Reward vs Block Rewards, given that the primary objective is to validate the network to enable real and secure transactions. Our viewpoint is that transactions are resources shared among validators; a validator should not consider them to be their property.

3. Status

Draft

4.Motivation

Before this BEP, the validator’s reward mostly relied on the transaction gas fee it received, as their only source of rewards is the gas fee for the transaction in the blocks they produce. A validator will get more rewards if it packs more transactions into the block it produces. It was designed to encourage validators to add more transactions, but it didn’t represent the overall contribution that a validator made. In general opinion, a validator should be rewarded even if it only produces empty blocks, because it helps build the network, e.g. verify blocks, keep a copy of the latest network storage state, broadcast blocks and transactions… But validator will lose its dedicated block reward if it produces empty block, so it still encourages validator to add more transactions in its block.

The rewards logic will serve multiple objectives. In addition to transaction inclusion, it is necessary to consider efforts to validate blocks and maintain network security.

Absolute fairness is not an easy goal to accomplish, but we do our best to bring about some improvements with this BEP. We name it Validator Reward Model 2.0, it could have further revisions to keep improving it.

5. Specification

Currently, as defined by the Parlia consensus, block producers will collect the gas fee of each transaction as its reward and distribute it to a system contract temporarily.
The system contract will forward the reward information to Beacon Chain periodically to settle the reward along with the staking information kept on Beacon Chain.

The general procedure will not be changed in this BEP, but 2 steps will be added:

• For each block, part of the block reward will be put into the shared network contribution funding pool. Initially, the ratio is set to 50%, i.e. half of the rewards will be shared with the other validators.
• Before the system contracts forward the reward information to Beacon Chain, the funding pool will be distributed according to the network contribution of each validator. The contribution could be simply determined by the block number it produces.

5.1 Mechanism & Governance

A governable parameters: validatorRewardRatio will be introduced in the ValidatorSet Contract. At the end of each block, the Validator will sign a transaction to invoke the deposit function of the contract to transfer the gas fee. The validator reward model logic is implemented within the deposit function that: validatorRewardRatio * ( gasFee - burnRatio*gasFee) will be transferred to the validator contribution funding pool address;

The initial setting:

• validatorRewardRatio = 50%

This process will be carried on BNB Beacon Chain, every community member can propose a change of the params. The proposal needs to receive a minimum deposit of BNB (2000BNB on mainnet for now, refundable after the proposal has passed) so that the validators can vote for it. The validators of BSC can vote for it or against it based on their staking amount of BNB.

If the total voting power of bounded validators that votes for it reaches the quorum (50% on mainnet), the proposal will pass and the corresponding change of the params will be passed onto BSC via cross-chain communication and take effect immediately. The vote of unbounded validators will not be considered into the tally.

6. License

The content is licensed under CC0.

[48ClubIan]

No offence to person, but this proposal looks extremely stupid.

In other chain , let's take ethereum as example, miner gets reward for sealing empty block, true but miner also doesn't get slashed for not sealing in turn. More important, the real reason why miners on ethereum get reward for even empty block is there does be real block reward besides gas spending.

It also astonishes me that "It is unethical toward the other validators... to include more transactions into their own block". Then what is bnb-chain/bsc#1186 doing?

Unethical ? To include more transactions ? Seriously ? I thought it was talking about FTX.

Absolute fairness is not an easy goal to accomplish
No it's not ture. Actually I have a best idea, how about all validators split reward equally?

Simple & Easy.

[ghost]

1. Validators should be encouraged to include more transactions, to help increase the highest TPS of this chain, to make this chain more stable and stronger, not to only increase the profit of some validators, especially when these validators take advantage of the imperfect code design or system bugs.
2. What worker: enhancement of the current block generation logic. bsc#1186 does is to improve the efficiency (the highest TPS) of the chain. It is absolutely different from "utilize an excessive amount of time to include more transactions into their own block in order to increase their revenue...it would also lead to the instability of the network".

All my above opinion is based on that I heard the way some validators are being doing is not good for the network stability. If I'm wrong, please let me know.

[48ClubIan]

1. Validators should be encouraged to include more transactions, to help increase the highest TPS of this chain, to make this chain more stable and stronger, not to only increase the profit of some validators, especially when these validators take advantage of the imperfect code design or system bugs.
2. What worker: enhancement of the current block generation logic. bsc#1186 does is to improve the efficiency (the highest TPS) of the chain. It is absolutely different from "utilize an excessive amount of time to include more transactions into their own block in order to increase their revenue...it would also lead to the instability of the network".

All my above opinion is based on that I heard the way some validators are being doing is not good for the network stability. If I'm wrong, please let me know.

I suggest you review worker: enhancement of the current block generation logic. bsc#1186 better before you criticizing in your first point, because that's exactly what it is.

If you think it is take advantage of the imperfection code design or system bugs, then it is.

[brilliant-lx]

you may misunderstand what bnb-chain/bsc#1186 has done.
As a matter of fact, validator is encouraged to add more transactions as long as the timestamp in its block header is not reached.
Before this PR, most validators did not fully use its block window to add more transactions.
If all of the validators are unambitious, it is fine. But if some of the validators are ambitious, then it will impact others' interest.
So #1186 did not take the advantage of imperfection design, what #1186 has done is to try to make sure every validator can fully use the 3s block window.

[48ClubIan]

you may misunderstand what bnb-chain/bsc#1186 has done. As a matter of fact, validator is encouraged to add more transactions as long as the timestamp in its block header is not reached. Before this PR, most validators did not fully use its block window to add more transactions. If all of the validators are unambitious, it is fine. But if some of the validators are ambitious, then it will impact others' interest. So #1186 did not take the advantage of imperfection design, what #1186 has done is to try to make sure every validator can fully use the 3s block window.

Actually "fully use the 3s block" is literally just another saying of "being ambitious" as #1186 has done, exactly the same as what is done by some validators before. The only difference this time is it is merged in master branch.

Just being adopted by everyone doesn't make what's "unethical" ethical, unless it was never "unethical".

[brilliant-lx]

Actually, I agree on it, "it is not unethical", I can change the sentence to use other word.
#1186 tries to make validator "ambitious" by default, validator is allowed to gain more profit as long as it follows the consensus rules.

[galaio]

I think all matters. Let’s think of a simple scenario if all validators fulfill gas limit per block with the same gas price, all validators get the same reward.

Now, there are many reality scenes, related with compete gas price, diff txs in your txpool, package time, and Infrastructure influence. So every validator will get a different reward, the same reward just in probabilistic. By the way, BSC hasn’t coinbase reward, only the tx gas fee.

All is about fairness, BSC encourage validators to fulfill their block to reach gas limit, encourage validators to exchange txpool as much as possible, encourage broadcast block in time, and get then fairness reward back. That is to aim for a higher smooth TPS in BSC. notice: it's an encouragement only.

So BSC needs to improve client performance to keep fairness in block produce bnb-chain/bsc#1186, and redistribute part of reward #176 share high gas price or package more txs from txpool.

Validators get slashed or jailed is kill themselves, you will get nothing or little reward. The empty block will get less reward than others, and it’s possible to produce empty block in many scenarios, like txpool empty, Network delay or CPU matter. I think it will balance with eco.

[48ClubIan]

Actually, I agree on it, "it is not unethical", I can change the sentence to use other word. #1186 tries to make validator "ambitious" by default, validator is allowed to gain more profit as long as it follows the consensus rules.

Appreciate it.

However, this way the motivation of this BEP doesn't stand well any more.

We already have #1186 to balance rewards among, why do we need model 2.0 to make sure validator which produces empty block still get rewarded?

They may did part of its job, but they also failed to finish the entire job, I mean sealing txs in time. I don't see the point to compensate such disfunction.

[brilliant-lx]

Actually, I agree on it, "it is not unethical", I can change the sentence to use other word. #1186 tries to make validator "ambitious" by default, validator is allowed to gain more profit as long as it follows the consensus rules.

Appreciate it.

However, this way the motivation of this BEP doesn't stand well any more.

We already have #1186 to balance rewards among, why do we need model 2.0 to make sure validator which produces empty block still get rewarded?

They may did part of its job, but they also failed to finish the entire job, I mean sealing txs in time. I don't see the point to compensate such disfunction.

The motivation of this BEP is simple:
1.validators can be rewarded according their true contribution.
2.validators can be incentivized to build a strong network.

bnb-chain/bsc#1186 did some improvements but there is still a long way to go.

First of all, we have to make sure if we can align on the these points:
1.Empty block is also a valuable block, although it did not contain any transaction, it has contribution on security.
2.Producing block is only a part of the contribution to the network. Other contributions could be: block verification, transaction propagation... (In an even broader view, full node, light node, archive node are also important parts of the network, but we focus validator right now.)
3.Generally speaking, TxPool is a shared resource, validators share transactions in this pool.

Great appreciate for your feedback, it is important, without the majority of validators's support, this BEP would not be accepted. As you may know, currently BNB Chain does not have the vast validator size as Ethereum has. It is crucial for these validators to participate in building a stronger network.
This may be not the final edition, any constructive advices will be considered seriously.

[Jolly23]

It's hard to understand you know the contribution can make network more stable. The normal nodes play a more important part on this topic, but you only talk about validators here.
If you really want to, how do you explain "UpgradeStatusExtension.DisablePeerTxBroadcast"? That's the weirdest thing I've ever seen in the blockchain design.

[48ClubIan]

I don't feel my question answered.

Producing empty block may have some contribution on security, but that's not all the contribution it is supposed to make.
Not doing all job deserves penalty, or at least not extra compensation.
My question is, why do you suggest reward instead?

Actually, not being slashed is already some kind of reward for 0 block producer.

Also, I am curious, is empty block very common recently ? Why is this worth proposing a special BEP?

[brilliant-lx]

It's hard to understand you know the contribution can make network more stable. The normal nodes play a more important part on this topic, but you only talk about validators here. If you really want to, how do you explain "UpgradeStatusExtension.DisablePeerTxBroadcast"? That's the weirdest thing I've ever seen in the blockchain design.

well, short reply: "Rome is not built in one day", all of the current Layer1 blockchains are far from perfect, let us just keep building it.

[brilliant-lx]

1.Empty block will lost its dedicated block reward, 50% by default, the ratio can be adjusted through governance. Meanwhile, empty block may only impact its own revenue, does not impact other validator's revenue. It is not encouraged, since it is bad for the overall performance.
2.Empty block is rarely seen recently, since the bear market. Actually this BEP is not proposed for empty block, it is about fairness.

[48ClubIan]

Enough, the whole thing makes no sense to me. I will not comment further.

What is "dedicate block reward" ?
Why is current model "unfair"? How can a validator produce its own block without secure the network?
Why is the proposed formula capable to solve the "unfairness" ? Math proof ?
What are validators supposed to do different before and after this BEP ?

Lots of terms are referred to without being defined, they just bounced out.
But it doesn't matter, just like before.

The proportion... will have the possibility to alter the value through governance.
Great.

Wait, don't we even need governance to adopt it ?
We don't.

We didn't have governance about whether to adopt BEP-95
We didn't have governance about whether to adopt BEP-131

But we do have vote on its parameters.

Isn't it great?

[Jolly23]

But actually the UpgradeStatusExtension.DisablePeerTxBroadcast is not a kind of building, it's destroying.

[darren-liu]

I personally vote for the change. It is not in the name of fairness, but for the best of the network.

1. Empty block is better than no block. When validators get no incentive for empty blocks, they may skip a few as long as they don't get caught for slash. But such skipping can cause a lot of fork and re-org, which downgrades the network's performance, especially when it is busy. Liveness is quite key, especially if BSC may change the way of blocking rotation to increase the capacity as Polygon or Solana is doing.

2. Validators should be encouraged to include more transactions. This means better throughput of the whole network.

3. A balanced validator set was the design goal of BSC, described even in the first version of the white paper. A skewed APR purely based on the transaction inclusion capability will cause voting power centralization. There should be a way to trade off between efficiency and democracy.

I look forward to seeing other options but so far this is the most balanced one.

The validators who put effort into including more transactions will get hurt, but their effort will not be 100% in vain; while the other validators who don't put effort will not get the full benefits.

[thy-r]

It needs to be said that the real motivation behind this proposal is not to reward validators for empty blocks. Validators that frequently produce empty blocks are either malfunctioning or running on cheap hardware / bandwidth, and there is no reason to reward them at the expense of the other validators who perform well.

The real motivation behind this proposal is the fact that some validators are extracting MEV and accept private transactions. As a result, they earn more than the rest and consequently, attract more delegations. As they get more and more delegations, they can add more validators and potentially take control over the network.

This is a potential threat, but this proposal will not mitigate it because validators will still get to keep 50% of their individual profit, which is a large enough edge to maintain such a threat. Raising the sharing ratio to 100% might solve this, but that would be a very bad idea because in such a case validators will have no incentive to excel or improve. Instead, their optimal strategy would be to operate by doing the minimum work necessary, as cheaply as possible, and this will result in a degraded network performance.

For this reason, I strongly suggest the BNB Smart Chain community to scrap this proposal, and instead debate on whether and how to standardize MEV extraction on the BNB chain.

One possible solution is to integrate MEV-Boost built-in the BSC client, similar to the way it is done on Ethereum, to allow all validators to extract MEV. A better longer term solution might be Proposer/Builder Separation on the protocol level, similar to what is planned on Ethereum.

In the meantime, the BNB Smart Chain community should be alert that if MEV extracting validators will be prevented from adding more validators to the network, they will have no incentive to share their MEV profits with their delegators. This will result in lower APR for the delegators, which is already at all times low.

Increasing delegators APR is another reason to consider standardizing MEV as a priority, as otherwise, more and more delegators will convert their BNB to ETH as the yield for staking ETH on Ethereum is much higher than it is for staking BNB on the BNB chain, thanks in part to the built-in MEV extraction support on Ethereum.

[brilliant-lx]

It needs to be said that the real motivation behind this proposal is not to reward validators for empty blocks. Validators that frequently produce empty blocks are either malfunctioning or running on cheap hardware / bandwidth, and there is no reason to reward them at the expense of the other validators who perform well.

The real motivation behind this proposal is the fact that some validators are extracting MEV and accept private transactions. As a result, they earn more than the rest and consequently, attract more delegations. As they get more and more delegations, they can add more validators and potentially take control over the network.

This is a potential threat, but this proposal will not mitigate it because validators will still get to keep 50% of their individual profit, which is a large enough edge to maintain such a threat. Raising the sharing ratio to 100% might solve this, but that would be a very bad idea because in such a case validators will have no incentive to excel or improve. Instead, their optimal strategy would be to operate by doing the minimum work necessary, as cheaply as possible, and this will result in a degraded network performance.

For this reason, I strongly suggest the BNB Smart Chain community to scrap this proposal, and instead debate on whether and how to standardize MEV extraction on the BNB chain.

One possible solution is to integrate MEV-Boost built-in the BSC client, similar to the way it is done on Ethereum, to allow all validators to extract MEV. A better longer term solution might be Proposer/Builder Separation on the protocol level, similar to what is planned on Ethereum.

In the meantime, the BNB Smart Chain community should be alert that if MEV extracting validators will be prevented from adding more validators to the network, they will have no incentive to share their MEV profits with their delegators. This will result in lower APR for the delegators, which is already at all times low.

Increasing delegators APR is another reason to consider standardizing MEV as a priority, as otherwise, more and more delegators will convert their BNB to ETH as the yield for staking ETH on Ethereum is much higher than it is for staking BNB on the BNB chain, thanks in part to the built-in MEV extraction support on Ethereum.

Thanks for in-depth reply, I would try to explain from my side:
1.The motivation of this BEP is not for empty block, as I have said, it is about the validator reward, how to reward the validators according to their true contribution.

2.MEV is another big topic, but it is not the real intention of this BEP as well. IMO, it would be better for a third-party to provide this service, since it is not part of the consensus. Ethereum has considered PBS, but many details are not settled yet, it could take a very long time to support it officially. This BEP will not solve the MEV problems.

3.Reply to some of your concerns:
Q1: validator could save cost on hardware and reluctant to add transactions.
A1: it could loss the 50% block reward in this case. The device cost should be affordable, and this BEP would not be applied if validator could gain higher APR by not adding transactions. We will take into consideration, make sure it would not be a problem.

Q2:validator with higher APR attracts more staking and gradually take over the network
A2:it is the challenge of all the PoS based chain. Generally speaking, the big stake holder should contribute to make a better network, but it could hurt smaller holders in short term. it could be a problem, but same as MEV, it is another topic, not be covered in this BEP.

4.I will not scrap this BEP right now, but it would not be enabled in a hurry. We will do further investigation on it to address your concerns. And appreciate the feedback from you and 48ClubIan. There is a long way to go to build the 100% incentive mechanism to make sure every participant can be rewarded according to their contribution, even developer, bug reporter, P2P provider, archive node... I believe it won't be accomplished in short term, this BEP could be only a small part of it.