[Bug] Truncated `ARCHOR_HEIGHT` leads to less `coinbase_reward` than expected
https://hackerone.com/reports/2315255
Summary:
ARCHOR_HEIGHT is truncated and is less than the real real_archor_height. This leads to coinbase_reward being only 80% of expected.
Proof-of-Concept (PoC)
ANCHOR_HEIGHT is defined as:
/// The anchor height, defined as the expected number of blocks to reach the coinbase target.
const ANCHOR_HEIGHT: u32 = Self::ANCHOR_TIME as u32 / Self::BLOCK_TIME as u32;
/// The anchor time in seconds.
const ANCHOR_TIME: u16 = 25;
/// The expected time per block in seconds.
const BLOCK_TIME: u16 = 10;
This means ANCHOR_HEIGHT is 2 and the underlying real real_archor_height should be 2.5.
While calculating coinbase_reward in anchor_block_reward_at_height function, the anchor_block_reward is calculated as:
R_anchor = floor((2 * S * ANCHOR_HEIGHT* H_R) / (H_Y10 * (H_Y10 + 1)))
This formula is designed to double STARTING_SUPPLY in 10 years. As ANCHOR_HEIGHT is less than the real value, anchor_block_reward_at_height is also less. This will cause the coinbase_reward to be only 80% of the expected reward.
Summary:
Truncated ARCHOR_HEIGHT leads to less coinbase_reward than expected
Plugging in values for the above equations, we have:
~which shows that supply is effectively doubled as expected.~
@d0cd The sum in the figure is not the final reward.
f(h) is anchor_block_reward_at_height. We need to multiply f(h) with combined_proof_target/coinbase_target to get the coinbase_reward of block h.
let reward = anchor_block_reward.saturating_mul(remaining_proof_target).saturating_div(coinbase_target as u128);
As ANCHOR_TIME is 25, the coinbase_target is set to achieve at expected 2.5 blocks. At each block, the expected combined_proof_target/coinbase_target value is block_time/ANCHOR_TIME = 0.4. Therefore, the expected total coinbase reward is
That is 80% of STARTING_SUPPLY.
@randomsleep good point! My analysis failed to take into account the expected ratio of combined proof target given difficulty adjustment.
While the observation is correct, this is not a bug. After mainnet launch and if the need arises, the validators/governance process can revisit adjusting these values to achieve the desired emissions.
Closing this issue for now, but please feel free to reopen if you have any strong concerns.