Solana docs say:
In Proof of Work consensus, these block times need to be very large (~10 minutes) to minimize the odds of multiple validators producing a new valid block at the same time. There's no such constraint in Proof of Stake consensus, but without reliable timestamps, a validator cannot determine the order of incoming blocks. The popular workaround is to tag each block with a wallclock timestamp. Because of clock drift and variance in network latencies, the timestamp is only accurate within an hour or two. To workaround the workaround, these systems lengthen block times to provide reasonable certainty that the median timestamp on each block is always increasing.
Solana docs say:
Let's quickly discuss Ethereum's proof of work. Block time is so small(3sec).In such case, multiple blocks can be solved at the same time, if so, one of the blocks will be discarded and another one will be added. Now, chance is nodes don't know which block they should add to their chain, but I guess, whichever gets propagated first to them, they add that. So, in the nutshell, that's a problem because even though 2 blocks were mined at the same time, there would still be
milliseconds difference when they were solved, but since time can't be trusted this much, node that receives such 2 blocks can't decide which one to add to the chain, so adds the one that was very first received(it could have received a block -
blockA that was solved after
blockB, but still received
blockA due to network propagation). And that's what Solana calls a problem as it's a little bit unfair.
Q1: Am I right what I assessed and what Solana describes as a problem above ?
Q2: From the paragraph I copied/pasted above, It mentions this:
Because of clock drift and variance in network latencies, the timestamp is only accurate within an hour or two.
Why does it say
an hour or two ? ethereum doesn't let adding blocks that are more than 10sec difference from the local time of receiver's block. Any idea ?