Chain MMR commitment in block headers

[bobbinth]

As pointed out by @plafer, block header cannot contain current chain MMR commitment because this would make the block header self-referential (e.g., we need MMR commitment to compute block header hash and we need block header hash to compute the current MMR commitment).

One solution to this is to say that current block header contain commitment to the chain MMR prior to this block. That is, current MMR at block height $n$ is a combination of block_header.chain_root at block $n$ and the block header itself.

Conceptually, this shouldn't break anything - but we need to be careful in several places and potentially make some updates. Specifically:

• In the transaction kernel, chain_root in the specified block header cannot be used to verify inclusion of notes created in the block. I'm not sure if this breaks anything (it might) - but if it does, there are probably a couple of ways to fix it. cc @frisitano
• The MMR data returned from various store/RPC endpoints, we may need to return not the current data but the data as of last block (this probably affects sync_state and get_block_inputs endpoints). cc @hackaugusto.

There are may be also other solutions to address this - so, any suggestions are welcome.

[frisitano]

I don't think there are any implications here for the transaction kernel. This would be relevant in the context of the block kernel when constructing new blocks. The way I see this working is in the prologue of the block kernel we read in the block hash and chain root of the previous block and insert the previous block hash into the mmr to get the new chain root.

Currently in the testing we have it structured as you described. Block header for block number 4 contains a commitment to the chain root of the mmr which includes blocks 0 - 3.