[Bug] Truncated ARCHOR_HEIGHT leads to less coinbase_reward than expected

[feezybabee]

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

[d0cd]

Plugging in values for the above equations, we have:

which shows that supply is effectively doubled as expected.

[randomsleep]

@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.

[d0cd]

@randomsleep good point! My analysis failed to take into account the expected ratio of combined proof target given difficulty adjustment.

[d0cd]

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.

[d0cd]

Closing this issue for now, but please feel free to reopen if you have any strong concerns.