Ethereum block time assessment

Question

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:

My assessment:

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 ?

Answer 1

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.

The target block time in Ethereum is 13 seconds, I suppose that was a typo. I understand that one may consider such situation unfair if you know the true orderering of the blocks creation in your time frame. But no one does, as you said "time cannot be trusted". In such a situation (and assuming that both block lead to equal total difficulty and have roughly equal timestamps), there is not way of taking a "fair" decision, since you cannot accept any timestamp proof as valid, and you cannot rely on the order of reception neither due to network instability.

An interesting point, is that such decisions (pick first / pick last) can actually be used against the PoW network to conduct selfish mining attacks since it gives indication on which branch will be picked, the current selection rule for both Bitcoin and Ethereum is 50% chance for each block in case of same height / same difficulty competing blocks as you can see here (If you are curious, this is explained in this paper).

And while this solution was not intended to solve the fairness problem you are describing (it it first of all a mitigation mechanism against selfish mining), I could easily argue that when nothing can be proved / disproved with certainty, a 50 / 50 seems like the most fair decision you could make.

Q1: Am I right what I assessed and what Solana describes as a problem above ?

The problem that they are really talking about is not really about fairness, it's just about fork probability in PoW blockchains. This probability is basically linked to the block rate and block size (the larger the block the longer the propagation time). When you mix such probability with a lousy definition of time you get into situations where conflicting blocks (events) cannot be distinguished as in your example, and for a time the blockchain is in an inconsistent state.

They are just using existing difficulties in decentralized time synchronization to introduce their Proof of History, which I understand as a centralized time definition based on successive events rather than a decentralized increasing global metric of time if that makes sense.

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.

I'm very surprised by that sentence and would clearly agree with @Mikko Ohtamaa's comment. Computers sync time through NTP regularly and stay relatively close to each other, I'm also pretty sure that the sync frequency is defined so that the average clock drift becomes almost meaningless...

I hope that answers your questions.