0

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 ?

3
  • "Because of clock drift and variance in network latencies, the timestamp is only accurate within an hour or two." I do not know what sources you are reading, but they are completely bullshit. Stop reading garbage. Feb 19 at 20:00
  • @MikkoOhtamaa its here docs.solana.com/cluster/synchronization . WDYT ? Feb 19 at 20:19
  • Still garbage. I suggest you open a bug in Solana issue tracker. Feb 19 at 21:20

1 Answer 1

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.

8
  • Thanks a lot for such a detailed explanation. Appreciated so much. I will just ask one more thing to confirm my thoughts. So idea is that in Eth, if blocks are mined at the same time, we have many different chains on different nodes and That's what solana calls it a problem, right ? i guess I call it a problem as well, but that's what it is. And we say that solana solves it in a way that when nodes receive blocks, they already know the order in which they came, so blockchain is always in consistent, same state everywhere. Correct ? Feb 19 at 22:36
  • as for the 2nd question, it's really strange they mention 1h or 2h. I mean, ethereum allows 10sec difference, so we are talking about 10sec problem here and not 1 or 2h which doesn't make much sense. WDYT ? Feb 19 at 22:37
  • btw, address is wrong on your about page ! two 0x appear there :) Feb 19 at 23:01
  • 1
    wow nice catch >< thanks for pointing it out :) For your first question : I wouldn't say "many" different chains on different nodes, a fork is usually 2 possibilities to two candidate chains, technically you may have forks with 3 or more candidate but the probability is very low. Solana can fork, they don't solve that issue, they solve the time synchronization in the network trough PoH and VDF given some compromises on security and decentralization allowing for very quick ordering and provable ordering of events, which pure timestamps don't allow.
    – hroussille
    Feb 19 at 23:32
  • 1
    For your second question : as I said, I think that @Mikko Ohtamaa is right. This 1 or 2h bound is far too great imo... Now take what I tell you about Solana with a grain of Salt, i'm mostly focusing on Ethereum for now and didn't spend nearly as much time on Solana. You will easily find much more knowledgeable people than me on that subject. I'll get the occasion to dive deeper into it later on, I'll edit my answer if needed.
    – hroussille
    Feb 19 at 23:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.