[ARC-0042] Adjust reward algorithms to utilize timestamps

[raychu86]

Motivation

This PR is intended to implement and address the concerns highlighted in ARC-0042.

The gist is that the current block times are not aligned with our current algorithms and causing the following:

1. block_reward is emitting at a higher inflation rate than the expected 5%
2. coinbase_reward is reducing too quickly and not over the expected 10 year timeline.

This PR addresses the problem by using timestamps as the peg rather than block_height. Both the inflation rate and the coinbase_reward reduction-over-time are on human timescales; it makes sense for us to align the formulas to the human timescale with timestamps rather than relying on block_heights, which are on a network timescale.

block_reward:

• Rename original to block_reward_v1
• Implement block_reward_v2
• Use time_since_last_block to determine how much reward to emit for that particular block in relation to how much inflation that time_since_last_block seconds should cause.
• This time_since_last_block is bound by a block interval of 60 seconds to prevent the block reward from becoming too large in the event of a long block interval such as a network outage or network upgrade.

coinbase_reward:

• Rename original to coinbase_reward_v1
• Implement coinbase_reward_v2
• Use anchor_block_reward_at_timestamp instead of anchor_block_reward_at_height
• Uses the number of seconds the block is to the 10 year mark to determine the reward. The closer we are, the less reward.

Some emission analysis can be seen in the comments below - #2569 (comment)

Migration:

• Introduce N::CONSENSUS_V2_HEIGHT to Network trait
  • This is the height for each network that snarkVM will swap from the v1 reward impls to the v2 reward impls.
• SnarkOS will require nodes to swap to the new version before height N::CONSENSUS_V2_HEIGHT, otherwise there may be some issues.
  • Validators need to change to the new version or risk possible forking
  • Clients need to change to the new version or risk sync halting

The migration and reward logic change will occur at the following block heights (These heights are subject to change):

Canary - Block 2,900,000 (~Nov 15, 2024 at the current 3.3s block times)

Testnet - Block 2,950,000 (~Nov 22, 2024 at the current 3.3s block times)

Mainnet - Block 2,800,000 (~Dec 10, 2024 at the current 3.0s block times)

These numbers were calculated by determining the planned release schedule and backing into the block height using the current block speeds and including a buffer between release and consensus change. This buffer is intended to give leeway for nodes to upgrade before the consensus change. The following table is the approximate timeline and buffers for the networks:

Network	Release Date	Buffer	Consensus V2
Canary	Nov 12, 2024	3 days	Nov 15, 2024
Testnet	Nov 19, 2024	3 days	Nov 22, 2024
Mainnet	Dec 3, 2024	7 days	Dec 10, 2024

Test Plan

Tests have been added to ensure that the V2 block_reward and coinbase_reward implementations match the expected behavior.

CI can be found here.

[vicsn]

Just nits today, will review the tests and ideas for testcases tomorrow

Since the code is the defacto documentation on the reward mechanisms at the moment, do you mind adding slightly more detail:

• In the docblock for fn puzzle_reward what the conceptual meaning is compared to e.g. the coinbase_reward
• In the docblock for fn anchor_block_reward_at_timestamp what the conceptual meaning is compared to e.g. the coinbase_reward (namely, it is an upper bound, ultimate payout depends on the target of the solutions)

[d0cd]

We simulated the block rewards without coinbase rewards and observed the following results.
The y-axis is the block rewards and the x-axis is the UNIX timestamp in seconds.
Note that the end of the x-axis is 2030-09-04 23:59:59.
Each of the plots represent an assumed a "fixed" block time.

Plot Name	Block Time (s)
Rewards No Solutions-0-0	3
Rewards No Solutions-1-0	5
Rewards No Solutions-2-0	10
Rewards No Solutions-3-0	15
Rewards No Solutions-4-0	30
Rewards No Solutions-5-0	45
Rewards No Solutions-6-0	60
Rewards No Solutions-7-0	90
Rewards No Solutions-8-0	120

These results are consistent with desired goals of this PR.
While each of the plots start with a different block reward emission rate, they all have the same rate after block 2M.
This indicates that after the CONSENSUS_V2_HEIGHT is reached, the base block reward emission rate will be steady regardless of block time.

Below is a plot of anchor block rewards over time for the same set of block times.
As expected, we see that after block 2M, the anchor block reward rate converges to the desired decay function.

[iamalwaysuncomfortable]

These results are consistent with desired goals of this PR

@d0cd I think they're consistent with the goals of this PR and are a faithful prototype of ARC-0042, but perhaps the numbers actually suggested in the ARC itself are inconsistent with the stated goals of the ARC to reduce inflation if block times go beyond 10 seconds.

The monte-carlo simulation shows the emission rate increasing (sometimes with quite a significant slope increase) for block times beyond 10 seconds. This doesn't reduce inflation if block times increase with the addition of further validators or more traffic.

The discussion should be brought to ARC-0042 about reducing the V2_MAX_BLOCK_INTERVAL from 60 to perhaps a lower number like 20. @HarukaMa do you have any thoughts on this?

[HarukaMa]

@iamalwaysuncomfortable Are you calculating the emission rate against timestamp for block time >10s? For per-block reward it's expected to increase because the block did cover more time, so it should have emitted more credits. If you plot it against the actual time though, the emission rate should remain the same. (EDIT: remember that we are trying to address the issue that credits emission is too high relative to time, as the design is 5% block reward per year regardless of how many blocks we have generated over the year. If the block interval is longer than the max block interval, the emission rate will actually decrease as the exceeded time won't be rewarded. This in turn could actually become an incentive to make validators push out blocks faster.)

EDIT: also thanks for mentioning me, wasn't aware there is already a PR for this.

[raychu86]

@iamalwaysuncomfortable @HarukaMa

The algorithm will have a block_reward emission rate of 5% as long as the block times are consistently within the V2_MAX_BLOCK_INTERVAL. Even if block times are consistently 60 seconds exactly, the emission rate should remain 5%. If the blocktime is consistently larger than V2_MAX_BLOCK_INTERVAL (because of network load or too many validators), then the emission rate will be lower than expected for the year and be less than 5% because we are capping the amount of rewards.

However, I do see your point that reducing this would incentivize block times that are always lower than V2_MAX_BLOCK_INTERVAL, because validators want to ensure maximum payout. Definitely worth considering, but it is a balance we need to make to help guarantee steady inflation and keep block times low enough.

I would suggest keeping at 60 seconds to be conservative or 30 seconds if we want to be a bit more aggressive.

[vicsn]

L G T M

[ljedrz]

LGTM 👍

[iamalwaysuncomfortable]

Even if block times are consistently 60 seconds exactly, the emission rate should remain 5%. If the blocktime is consistently larger than V2_MAX_BLOCK_INTERVAL (because of network load or too many validators), then the emission rate will be lower than expected for the year and be less than 5% because we are capping the amount of rewards.

The tradeoff of block time vs. rewards emission rate is something all the members of the Aleo community should do some deeper analysis of ultimately. However, if the community is currently staunchly committed to the 5% inflation rate 60 seconds likely provides reasonable statistical guarantees that this rate will be preserved.

[zkxuerb]

LGTM