Define and implement block rewards

[bpalaggi]

Premise

The white-paper defines a few things w.r.t. rewards: categorization, amount, randomness...
However, freezing rewards will be removed, as they are a form of passive income which would make our coin a security.
While the total amount of rewards is likely to stay the same, the distribution among the various categories will change to align incentives with the goals stated in the white-paper.

Incentive

One of the goal of the white-paper is to separate the political incentive from the economical incentive.
The direction we are heading towards is to have low rewards for simple validators, and increasingly higher rewards for L2 providers (validators with > 40k).
Since L2 liquidity cannot be slashed (that'd be double spend), we assume that every validator has exactly 40k.

Additionally we need to give incentive for validators to:

• Accept new validators in the validator set;
• Ensure that pre-images and other critical data are correctly propagated;

In the second case, the lack of propagation / cooperation (e.g. by withholding pre-images) could be used as an attempt to slash a well-behaving node.

prerequisite: #2245

[AndrejMitrovic]

Sorry just this wording is strange to me:

could be used as an attempt to slash a well-behaving node.

You mean an /otherwise/ well-behaving node? Like they were good so far except they didn't reveal preimages, they're not good anymore right?

[Geod24]

You mean an /otherwise/ well-behaving node?

I mean that no matter if a node (A) well-behave, a node B can just pretend it doesn't know / didn't hear back from A.
If there's no penalty for doing so, and it benefit B, then B is likely to attempt it at some point.

[AndrejMitrovic]

can just pretend it doesn't know

When is node B queried about knowing about A's preimages? Or in other words, how does it make a statement "I confirm A has not revealed their preimage"?

[Geod24]

So far it does not. The only moment it will make such a statement will be from nomination.

[ferencdg]

some thoughts about this ticket, please share of what you think:

1.
There was an idea that we should give the block reward based on who signed the block, and hence incentivize validators for signing the block.

I think this idea is contra-productive. It will give an incentive to validators NOT to forward other validators signature, and eventually could end up with less signature. There were some suggestions to counteract this by
1.1.
trying to decrease the total block reward non-linearly in case validators don't sign. However this would lead to non-predictible coin supply, and wouldn't conform to the white paper(apart from that it would just complicate Agora code).
1.2
Penalize every validator of a quorum where one of the validator doesn't sign. In this case the coin supply would be predictable, however it is more difficult to implement, and also the following attack is possible. One attacker might create 100 validators with 40k Boa and one validator with 1.000.000 BOA. He would just use those 100 validators to mess up all the other quorums(he still needs to make sure none of those 100 validators shares the quorum with his 1.000.000 BOA validator).

I think we should just give the block reward based on who is enrolled, and that way validators have no financial reason NOT to forward other people's signature.

Now, bad-mannered validators can try to slow down other validator's enrollment by voting with 'no' to their enrollment request. However we could combine the enrollments during voting from the current vote and from our knowledge of what we think who should enroll and vote on that 'enriched' proposal. As long as 50% of the validators are not malicious, we would have a very high chance of getting all the enrollment requests into the next block.

2.
There was an idea that we should give block reward to validators based on how many coins they stack on the flash layer, and hence incentivize stacking coins on the flash layer to achieve high liquidity.

I think people already have an incenentive for stacking on the flash layer, they can set their own fees that they charge for being an intermediate node, so we don't have to reward them from the block reward.

From what I gathered from Andrei it would be very difficult if not impossible to prove that people offered liquidity on the flash layer, hence it would be difficult to reward them from the block reward.

[AndrejMitrovic]

2. sounds right to me. You can't really reward someone on-chain by making the assumption they will perform well off-chain.

[omerfirmak]

There was an idea that we should give the block reward based on who signed the block, and hence incentivize validators for signing the block.

AFAIK, block signing can go on for a while even after the block is externalized, right? So we can't know which validators will be signing the block in the consensus phase.

There was an idea that we should give block reward to validators based on how many coins they stack on the flash layer, and hence incentivize stacking coins on the flash layer to achieve high liquidity.

This does not make sense to me in a "layered" approach. Lower layers should probably never rely on upper layers.

[ferencdg]

AFAIK, block signing can go on for a while even after the block is externalized, right? So we can't know which validators will be signing the block in the consensus phase.

There supposed to be a delay in paying out the block rewards to tackle the exact situation you mentioned. So for Block X, we wait until Block X+Y, and then we try to make a consensus of who actually signed. We would do the consensus in a very similar/strict way to how we do the consensus of which validators are slashed. (I am not suggesting here that we should give out rewards based on who signed, just mentioning the original design. I would prefer giving out rewards by who enrolled)

[omerfirmak]

I would prefer giving out rewards by who enrolled

I agree, but maybe we should have more strict slashing rules to better distribute the fees/rewards.

[ferencdg]

I would prefer giving out rewards by who enrolled

I agree, but maybe we should have more strict slashing rules to better distribute the fees/rewards.

Yes, we should make the block reward payout contingent on whether the node is slashed or not, just like you did with the transaction fees. What else would you add to the slashing policy btw. Also if we really want to base the block reward on the block signatures, it would be clearer anyway to make it part of the slashing policy/consensus algorithm, and during the block reward calculation we just look at who is slashed for missing signatures(or slashed for anything else really).

I think we already have an incentive for validators to stay online and work as expected - they will be slashed if they don't share their preimages. If they already have an incentive to stay online and work AND we don't give validators other incentives TO hide other validators signatures(as the original proposal would have given them an incentive to hide), then I think we could assume they will sign and forward the signatures.

[omerfirmak]

they will be slashed if they don't share their preimages

For a validator to be deemed active, we should check more than just preimages. A validator who just reveales preimages and does nothing else is actually not contributing to overall network stability.

Two rules come to my mind for slashing;
1- If SCP exposes this information, we should probably make sure a validator is actively participating in voting. We can maybe slash the nodes that havent participated in the majority of the last N rounds.
2- Same can be applied the block signatures as well. Slash the node that haven't signed at least some portion of the previous blocks. I am not sure if this would have the same problem of nodes hiding signatures though.

[AndrejMitrovic]

1- If SCP exposes this information, we should probably make sure a validator is actively participating in voting. We can maybe slash the nodes that haven't participated in the majority of the last N rounds.

This is extremely hard to prove. A node could vote once (with hashes nobody knows about so the vote is never accepted) and then refuse to vote again. Does that mean they're an active and well-behaved validator? Probably not. But it's hard to prove because the history of voting is not stored anywhere (and it's too much data to store on-chain).

[ferencdg]

Documenting some of the decisions that were made through offline discussions and their consequences(It is still not to late to change them)

1. We will only distribute block rewards in every X blocks as opposed to distributing it in every block. This was originally meant to reduce block chain size. However if we assume there will be a transaction fee for each block, then we are going to have a CoinBase transaction anyway that we can (and will) piggyback, so distributing block rewards in every block is still possible.
2. We will delay the distribution of the block rewards, so for blocks A .. B we will distribute the rewards at block B + Y. This is because we want to give enough time validators to share block signatures which is the basis of the block reward.
3. Each validator will be rewarded based on how many blocks they signed and the reward will NOT be propotional to how much coin they staked.
4. The total block reward for a particular height is fixed, however this doesn't mean that the validators receive all that reward. The total validator reward will be based on the total number of signatures on the blocks in question. The total validator reward will be a nonlinear function of the the total signatures, so 2 times more signatures might increase the total validator reward by 4. This is to encourage validators to share signatures. The coins remaing is 'fixed block reward at height X' - 'total validator reward' will go to the Foundation.
5. We will do very stringent checks on the Coinbase transaction during the consensus protocol and we require 50% of the validators to exactly agree on who signed which blocks. However we will do very minimal checks on the Coinbase transaction during adding the block to our chain, because we cannot expect every validator in the network to have the exact aggregated signature. Because we will merge together the block reward and the fee reward into one Coinbase transaction, this means during block addition we can no longer check the fee reward(which was possible before). In theory we could check the fee reward on blocks that do not contain block reward(as we plan to distribute rewards only in every X blocks), but it would not make Agora more secure(would also require quite a bit of refactoring). We could also agree on who signed each previous block as part of the consensus protocol, but that would require yet an other bitfield in the block header.

Let me know what you think, especially about the last point.

[hewison-chris]

The rewards are now defined but there are still more PRs coming to complete the implementation of payouts with the correct distribution and at the end of the next payout period.

[hewison-chris]

Still some more PRs coming.