Do not pre-vote for blocks generated in the past or future

[sgkim126]

Because the block proposer can cheat the block generation time, the validators should not sign the very old block or the block generated in the future.

It's on the basic assumption that all nodes try to sync the time and the time error between the server is not that big. However, synchronizing the time of all nodes is impossible so the validator should be tolerant to some time error. The tolerance is how much the time error is allowed.

The degree of acceptance of future generated time error and the past generated time error must be treated differently. If the node keeps trying to synchronize the machine time, it is very rare to receive a proposal block generated in the future, and the error will be little. But time error of the block created at the past could be relatively large due to the network propagation time.

To handle this issue, you should make

• the tendermint module doesn't send a pre-vote if the block was generated over 30 seconds ago or 5 seconds later from the machine time.
• Make the above 30 seconds and 5 seconds configurable.
  • They should be the machine property, not the chain property.

[HoOngEe]

I understood that the chain property in codechain is given by such as mainnet.json, corgi.json etc. And the machine properties are more flexibly customized when one wants to run a node like the properties in config.prod.toml. Am I right?

[sgkim126]

Yes, you are right.
And you'd better add a CLI option when you add a field to config.prod.toml.