Review block timestamps

[geigerzaehler]

To ensure that the network is working properly we want block time stamps close to the time when there are mined. Otherwise other nodes will reject the blocks because they are two far in the past.

We want to verify that block timestamps are set properly or come up with a solution how we can ensure this.

[CodeSandwich]

The result: it's complicated. On one hand the PoW mining loop doesn't adjust the time after preparing a header. If mining takes an hour, the header will have timestamp from one hour ago. On the other I've cranked up the target mining time to 10 minutes and started a local devnet. After some time the blocks started appearing only once a few minutes, the highest time was 12 minutes. The network had no problem with that, everything just worked. I think that we're pretty safe with our 1 minute target.

[CodeSandwich]

I've tracked the inherents validation down to substrate/frame/timestamp/src/lib.rs:214 (<Module as ProvideInherent>::check_inherent). It looks like we're only protecting ourselves from blocks with timestamps in the future. If you mine a block for a month and keep its original timestamp, Substrate is fine with this.

I'm not entirely sure what this function is supposed to do. It looks like call is taken from the block and data is constructed from the same calls stored in the same block.

[geigerzaehler]

Thanks for the insights, @CodeSandwich. Given what we know we should think about whether this can be gamed. For example, would a node that treats timestamp differently gain an advantage over our implementation? We should look at how other PoW chains are doing this.

I don’t think this is critical for the FFnet though. Let’s remove the issue from the milestone.