ARC-0042: Adjust block reward algorithm to make sure inflation is stable

[HarukaMa]

---

arc: 0042
title: Adjust block reward algorithm to make sure inflation is stable
authors: Haruka Ma
discussion: self
topic: Protocol
status: Draft
created: 2024-09-09

Abstract

The AleoBFT consensus doesn't guarantee a stable block interval, but the current block reward algorithm assumes the block interval is fixed at 10 seconds, and is emitting rewards regardless of actual block intervals. This makes the 5% annual reward target almost unattainable: shorter block intervals causes higher reward frequency and higher annual reward, and vice versa.

As an example, if the block interval is 3 seconds throughout a full year, the effective inflation rate from base block reward would be 16.67% instead of 5%.

This ARC proposes changes to the block reward algorithm so it could adjust the per-block reward according to the actual block interval, therefore achieving the 5% annual target without being affected by fluctuations of the validator network.

Specification

Proposed new block reward algorithm and implementation:

/// Calculate the block reward, given the total supply, block interval, coinbase reward, and transaction fees.
///     R_staking = floor((0.05 * S) * min(I, 60) / S_Y) + CR / 3 + TX_F.
///     S = Total supply.
///     I = Seconds since last block.
///     S_Y = Seconds in a year (31536000).
///     CR = Coinbase reward.
///     TX_F = Transaction fees.
pub fn block_reward(
    total_supply: u64,
    secs_since_last_block: i64,
    coinbase_reward: u64,
    transaction_fees: u64,
) -> u64 {
    // Compute the annual reward: (0.05 * S).
    let annual_reward = total_supply / 20;
    // Compute the block reward: (0.05 * S) * min(I, 60) / S_Y.
    let block_reward = annual_reward * secs_since_last_block.min(60) as u64 / 31536000;
    // Return the sum of the block reward, coinbase reward, and transaction fees.
    block_reward + (coinbase_reward / 3) + transaction_fees
}

The proposed algorithm takes the actual block interval into account, emitting less reward if block interval is short, and vice versa.

Note the block interval is capped to 60 seconds in the calculation; this is set mainly to remedy situations like chain halts or the gap between genesis timestamp and first block (only applicable to future chain resets for testnets) so there won't be a sudden large sum of credits being rewarded in one block. The 60 seconds here is just an arbitrary number; actual interval cap should be discussed further.

Also note the block interval is guaranteed to be greater than zero on the consensus level.

Test Cases

Tested with the above code on local devnet:

Dependencies

snarkVM. Potentially other products that relies on the implementation.

Backwards Compatibility

Implementing this ARC requires the snarkVM and snarkOS to have a proper soft fork mechanism.

Security & Compliance

The proposed algorithm affects the tokenomics, albeit it's trying to bring the chain back to the intended state.

Conflict of interests among validators

This section lists some situations the author could think of.

1. As the block reward linearly increases with the block interval, validators might want to hold the block generation until the interval cap is reached. The only incentive here could be to save some CPU cycles related to block generation, as in the end the total block rewards will be the same regardless of the blocks generated in a given period. Plus, holding back the blocks might cause additional puzzle solutions to abort, as there could be at most 4 solutions in a block, and considering puzzle rewards contributes to the block reward as well, doing this could actually harm the income of validators.
2. Validators might collude to generate blocks with fake timestamps in order to inflate the rewards. In short-term, this might give validators more rewards. However, by being dishonest, validators will be harming the credibility of the chain; therefore in the long run, this would harm the investment done by validators considering the entry barrier of becoming one. Setting the interval cap to the previously intended block interval (10 seconds) might deter this as well.

References

N/A

[Fatman13]

... the effective inflation rate from base block reward would be 16.67% instead of 5%.

Is the "base block reward" here referring to coinbase rewards in the graph at the bottom here? Does it mean that coinbase reward targets 5% and staking rewards targets 7% thus a combined 12% inflation rate?

[HarukaMa]

Stake reward should be fixed 5% per year, where coinbase reward is from puzzles (a third goes to block reward, two thirds go to puzzle reward)

[mwyatt896]

Put this in discord and also putting here:

some interesting numbers for you from our end over at Puzzle.
TLDR;
looks like for every 10k we add to our Arcade WAU numbers, we add 50k txns and increase consensus block times by ~0.5s. Because of this fact -- in our opinion -- this ARC should be held off until November when we have more data from Coinbase Quest full launch and it's effects on consensus block times to see if they are in line with what we see.

Background on data below:
October 2nd -- we thought most mainnet kinks were worked out so we kicked off Puzzle Arcade campaigns with communities we've been working with for past few months
Oct 2 & Oct 3rd our costs blew up from paymaster and oct 4th we had to ask communities to stop using/chill out -- was costing us too much and validator rewards wouldn't have chance of covering at current delegation
see here: https://x.com/lets_puzzle/status/1842360983605637450

so in light of adjusting block reward algorithm we ran numbers to see how this increase in activity effected consensus and run quick analysis on projections of what it will do to consensus times/block rewards down road

October 2nd:
25,568 Puzzle txns
3.04 s/block
start block: https://aleoscan.io/block?h=798610
end block: https://aleoscan.io/block?h=827030

October 3rd: ~11k Arcade WAUs
50,726 Puzzle txns
3.41 s/block
start block: https://aleoscan.io/block?h=827030
end block: https://aleoscan.io/block?h=852349

Back of napkin projections:
20k Arcade WAUs
100k Puzzle txns
~4 s/block

30k Arcade WAUs
150k Puzzle Txns
~4.5 s/block

40k Arcade WAUs
200k Puzzle Txns
~5 s/block

Based on this quick analysis -- we think it's best to wait and see how this is effected with the coinbase ramp with Leo Wallet, Pondo, Verulink, and Arcane during this month.

If their numbers lineup with ours and based on number of transactions we expect coinbase to see alone, we are likely to hit 5s/block in November. And that is not counting what we are trying to grow to in November at Puzzle as well. There is a chance we get to 10s/block based on activity alone -- not even counting increasing validator set.

That being said about the near term, I do like this as a direction to continue to pursue as I imagine pushing validator sets + increasing usage might have us greater than 10s/block given our own internal targets lol. I believe this could be a good solution for both near and long term.

I do worry about whether this block reward calculation would work given that secs_since_last_block might be different between each node though.

Any idea on if this would be an issue or any solutions to this potential issue?

[vicsn]

Big +1 from me for fixing the inflation issue.

I'm afraid block reward can't easily be made a function of blocktime.

The validator rewards is something which all validators need to have equal view and opinion on. Right now that's trivially the case, because its a constant. But if reward becomes a function of blocktime, then how are we sure all validators observe the exact same blocktime? There is no such thing as a single canonical block timestamp. One thing which might be possible is to use the BatchCertificate time instead, which per definition have been signed by a quorum of validators. They contain a timestamp, so in theory the reward could be adjusted based on the speed of certificate generation. But it would still be only a very imperfect proxy of actual blocktimes. Making rewards depending on any condition introduces a forking risk and requires lots of resources to vet its security.

In contrast, making a node's local minimum batch delay a function of its local view of either batch/certificate/block does not introduce forking risk.

UPDATE: actually maybe the timestamp is deterministic: https://github.com/AleoNet/snarkVM/tree/mainnet/ledger/narwhal/subdag/src/lib.rs#L191

[HarukaMa]

Why the block timestamp in the header can't be considered "canonical"? AFAIU it should be derived from batches that all validators agreed with, thus should be deterministic?

[apruden2008]

While I support the approach outlined in ARC-0042 for dynamic blocktime adjustments as a medium-term solution, I think we need an immediate band-aid to address the current issue of skewed reward distribution. By increasing blocktimes to around 8 seconds (buffered to 10 seconds under heavy load), we can better align rewards with Aleo’s original tokenomics model.

The implementation can be found here: AleoNet/snarkOS#3412

This interim fix ensures rewards are balanced more evenly between validators and provers, while allowing time to implement the more comprehensive dynamic solution proposed above.

Therefore I propose merging PR #3412 and test in Canary Net, testnet beta according to the same test plan we ran for our mainnet roadmap.

[WietzeSlagman]

Getting a quick fix in to allign the economics better asap should be a good plan, getting close to the publicly shared tokenomics model should be a high priority.

However, this change and increasing the validator could lead to an undesirably high block time (more than 10s) and is something we should test for thoroughly on Canary and Testnet Beta. Potentially leading to pushing the increased validator set to after/with this ARC implementation go live or reverting/updating this change.

[dylanschultzie]

I generally support this proposal.

One outstanding question I have, following Matt's comment, is what effect adding the 9 additional validators will have on block time. This isn't a "blocking" question, but it does make me wonder how pertinent this ARC will be in the coming months.

Does it make sense to add the 9 new validators to canarynet to get a feel for how that'll change the network speed?

[HarukaMa]

This ARC aims to decouple rewards from block time, and should work with any network condition (if the block interval is less than 60s).

[apruden2008]

Yes, I think that it would make the most sense to add the 9 validators AND push this change at the same time.

[Meshiest]

I was initially skeptical about the reliance on timestamps as they are notoriously untrustworthy, but the weighted median timestamp calculation from the certificates should mitigate validator collusion attacks. I would trust timestamps more if the delta times between timestamps were guaranteed to be statistically consistent across validators, but for now this looks like a decent approach.

[OzielLa]

I generally support this proposal.
We need to consider the calculation of coinbase_reward, where anchor_block_reward_at_height is also related to BLOCK_TIME and ANCHOR_TIME. Given the current block generation speed of around 3 seconds, by the end of the third year, we will reach a height of 28382400. The coinbase_reward is decreasing too rapidly.

[HarukaMa]

Yep, that needs to be addressed as well, but not sure if it should be included in this ARC right now

[howardwu]

I support @HarukaMa's proposal for a dynamic adjustment to the block reward.

As this ARC is intended to re-align the network's rewards with the published inflation schedule, I agree with @OzielLa's point that the BLOCK_TIME needs to be modified from 10 to 3 seconds. As this proposal will anchor the current block time at 3 seconds (rather than 10 seconds), making the fix to BLOCK_TIME will ensure the puzzle reward schedule does not de-accelerate at 3x the expected rate. By combining these modifications, this achieves the intended goal of adhering to the published inflation schedule.

@HarukaMa's points about potential collusion risks are correct. From my understanding, if a subset of validators collude, the network runs into the risk that forking is a possible concern. If at least 2/3rds of validators (by stake weight) collude, then the network runs into both a forking and a deviation from the anticipated inflation rate. Before rolling in these changes, adequate testing of these edge cases should be done to understand the complexity of pulling off such an attack, which in my opinion, also introduces more fundamental concerns to the sanctity of the network (CC @vicsn).

This change will require validators to update to a new version of snarkOS/VM with this ARC applied. The good news is that it does not require a coordinated synchronous update. Validators should be able to asynchronously update in advance of the target block height with which the rule change would occur. At least 2/3rds of all validators (by stake weight) will need to update to this version for the change to be effective on the network.

[HarukaMa]

I strongly believe the original ARC is written to specifically address the 5% issue.

[raychu86]

The original ARC proposal is meant to address the 5% inflation rate from block_rewards only. In other words, this 5% inflation is with regards to block_rewards and not coinbase_rewards.

Solution 3 uses the proposed changes for block_rewards to also stabilize coinbase_rewards to follow the intentional design. There is not a fixed 5% inflation rate for coinbase rewards. Coinbase rewards are an additional emission that is designed to hit some equilibrium based on the retargetting algorithm and the solutions that make it on chain.

[raychu86]

So if block_time is replaced with block_timestamp, this should not have much impact, right?

As Haruka mentioned -

block_time is the fixed interval that was set in the code (currently set to 10 seconds) that all of the reward calculations are based on. So no matter what the block time was, the reward calculation is based on the 10 seconds.

block_timestamp is the actual timestamp of blocks, which gives us granularity and the ability to adjust the rewards based on the actual block time rather than the fixed 10 seconds.

[LoiusZK]

Doing the same with coinbase_reward and using block_timestamp will allow us to determine where along the 10 year time horizon we are and select the price based on timestamp.

@raychu86 Yes, but as you mentioned in solution 3, the same operation should be performed on coinbase_reward. I understand that it is also necessary to solve the problem that the block height increases too quickly due to the short block time, and the PoW reward is reduced too quickly. That is to say, the reward of the 9th year will be reached by the end of the third year. How do you solve this problem?

[raychu86]

As I mentioned above, solution 3 already adjusts coinbase_reward to be based on timestamp to align the coinbase reward to match the 9 year timeline and will not be affected by fast or slow block times.

To be extra clear: Coinbase rewards will reach the 9 year mark in 9 years from the genesis block. Even if block times are 1 second or 100 seconds, this will not affect the timeline of coinbase rewards.

[howardwu]

For those who are new to this thread and/or following this ARC proposal, I recommend reviewing the technical implementation as proposed by @raychu86 in this PR: AleoNet/snarkVM#2569

It provides a detailed implementation of the transition to the new emission curve as iterated upon from the above ARC discussion threads.