4

Geth and Parity nodes differ in a fundamental way when they validate block headers.

Background

According to the yellow paper

4.3 timestamp: A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally Hs
4.4 Hs is the timestamp of block H and must fulfil the relation: Hs > P(H)

Both implementations require that the machine running the node to resolve it's NTP protocol to pool.ntp.org for no more than 10 seconds

Conclusion

But, they differ when it comes time to validate the block. Geth and parity will check if that timestamp is greater than the parent's timestamp, but geth will outright reject any block that has its current time set in the future

Question

Given the fact that parity allows for a looser interpretation of timestamp validity, how do these protocols resolve on different blocks being proposed, does the stricter protocol win in the end? Additionally, is there a way to quantify this variation of timestamps?

Phillip Goldberg
  • 41
  • 3

2 Answers2

3

I doubt there has ever been an actual case of this happening (don't quote me on that unless you also quote that I said not to quote me on it). In order for a block to be valid by Parity and not valid for Geth, a miner would have to knowingly create a block with a time sufficiently in the future, and this is against their best interest since nodes will converge on Geth-valid blocks (because Geth is by far the largest by node count) and the miners would lose their rewards from the orphaned blocks. A problematic scenario would be if Parity nodes became the majority. If that happened, a miner could create one of these Geth-invalid but Parity-valid blocks and the majority of the network would be Parity, but the Geth nodes would be on a fork.

natewelch_
  • 12,021
  • 1
  • 29
  • 43
2

Just brainstorming here but I guess the reason block times are accurate is for the same reason the miners agree on all of the other parameters a block must have.

Eg they agree that they pay 3 Eth, at time of writing, for each new block. If a miner tries to award themselves more than the block reward their block is rejected. Similarly if a miner submits a block with a time that is different from the real time, their block is rejected. It isn't in the interest of the network as a whole to have inaccurate block times.

willjgriff
  • 1,658
  • 8
  • 13