Mismatch in initial block heights at genesis

[brentstone]

The initial block height of the chain according to request::InitChain from tower ABCI is 1 (see code here), which does not match the initial block height of the chain in the namada protocol, which is 0.

The initial block height of 1 from tower ABCI is used to determine when the next epoch begins right here, so possibly epoch 1 (the second epoch) starts a block later than intended.

[james-chf]

Related: #377

We should look to remove BlockHeight(0) in general from our code since it doesn't exist (and change BlockHeight::default() to be BlockHeight(1) instead of BlockHeight(0))

[tzemanovic]

Good catch! Looks like we should be setting our block height from the initial_height we receive on init chain.

There's one place where BlockHeight(0) is used - in ABCI queries, where it's used as a special meaning for "last committed height"

[tzemanovic]

Additionally, we should initialize storage.block.pre_epochs with empty first_block_heights and write it from init-chain too

[tzemanovic]

thanks @james-chf for clearing this up in another discussion. There is no genesis block, InitChain initializes state to be used for the first block, which will have the BlockHeight(1) - the confusing part for me was that InitChain request comes with height = 1, which really means "prepare the genesis state for the first block, which will have height 1".

The issue with storage.block.pre_epochs is actually wrong though - we should use the InitChain height to initialize its value.

[cwgoes]

@tzemanovic What still needs to be done here - just the block height type fix?

[tzemanovic]

@tzemanovic What still needs to be done here - just the block height type fix?

the default value for pred_epochs.first_block_heights is incorrect - we're using 0 height, but it should be set from the value received in init_chain (typically 1)