Substrate: What prevents a misconfigured / malicious validator to create a block with bad timestamp?

[xlc]

This is the only logic I can found to validate the timestamp in a block

https://github.com/paritytech/substrate/blob/67f354f57e738fa575775f7fa0fb903e8972182b/frame/timestamp/src/lib.rs#L154-L157

So what prevents a validator produce with a block with a future time?

And how does the next validator handle such case? If it is issuing block with the correct timestamp, it may be considered invalid?

[burdges]

Block producers should build on the chain head with a timestamp they believe valid.

There is extensive design work on this in https://w3f-research.readthedocs.io/en/latest/polkadot/BABE/Babe.html#-4.-clock-adjustment--relative-time-algorithm- and https://github.com/w3f/polkadot-spec/pull/168 although @hndnklnc only added the temporary adjustment section https://w3f-research.readthedocs.io/en/latest/polkadot/BABE/Babe.html#temporarily-clock-adjustment recently.

There was code that did not work properly, never got turned on, and got removed in #4993 https://github.com/paritytech/substrate/commit/dbeebe2cbc87662cc4bdc7e948d14da2cf30e03e#diff-20230c59d1bd7ffff93b396e87d05ad3

After @sorpaas refactoring #5655 any new attempt should be sharable with other consensus engines because it'll get used by both sassafras #4600 and secondary approval checks.

We should expose and feed this clock back into parachains via cumulus too.

[arkpar]

Timestamp inhernet is checked here: https://github.com/paritytech/substrate/blob/master/frame/timestamp/src/lib.rs#L252

Additionally, BABE verifier checks the slot number here:
https://github.com/paritytech/substrate/blob/6ecbc4c45b913360878afd831bef05dddecef444/client/consensus/babe/src/lib.rs#L870

[bkchr]

Yeah, as @arkpar said that it is checked and it will fail if the the timestamp is too far in the future.

[xlc]

Followup question, up to 30s drift is allowed

https://github.com/paritytech/substrate/blob/e097348a045824572d4eda8ff521fd746fe75a15/frame/timestamp/src/lib.rs#L241

Block producer use its local time to provide inherent data

https://github.com/paritytech/substrate/blob/e097348a045824572d4eda8ff521fd746fe75a15/primitives/timestamp/src/lib.rs#L96-L97

Does this means the following attack is possible?

• Block time = 6s
• At real time 1000, block producer A created a block with timestamp of 1020
  
  
  
  • This block is valid as the draft is less than 30s
  
  
• At real time 1006, block producer B attempt to create a new block with timestamp of 1006
  
  
  
  • This block is invalid because it is less than (1020 + 3)
  
  
  • block producer B lost its block reward
  
  

[burdges]

Is there a check that inherents have increasing timestamps somewhere?

[arkpar]

At real time 1006, block producer B attempt to create a new block with timestamp of 1006
This block is invalid because it is less than (1020 + 3)

B sets new block timestamp to max(now, previous + MinimumPeriod). MinimumPeriod for kusama is 1. So the timestamp In this case will be set to 1021, which is valid.
https://github.com/paritytech/substrate/blob/master/frame/timestamp/src/lib.rs#L236

[arkpar]

@burdges Yes https://github.com/paritytech/substrate/blob/master/frame/timestamp/src/lib.rs#L254