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.

My assessment:

Let's quickly discuss BTC's proof of work. Block time is 10m, and it's mostly this much so that two blocks can not be solved at the same time. Even that, there's still a chance this could happen, 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. Le's say in Bitcoin, 3 blocks were mined at the same time.

Some call this a huge problem that when node receives 2 blocks at the same time, it doesn't know which one was solved first and one block gets discarded while there's a chance that second one should have gotten discarded. So it turns out timestamp is used only for managing/calculating difficulty.

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

  • Solana describes proof of work as a problem because it allows them to assert their extremely fragile (has gone down countless times) "consensus algorithm" called proof of history which is censorship enforcing. They need to sell you on insecure consensus mechanisms in order to pump their own pre-minted coins.
    – Poseidon
    Mar 17, 2023 at 15:58

1 Answer 1


Block time is 10m, and it's mostly this much so that two blocks can not be solved at the same time.

I don't believe this is true.

I believe the primary purpose of the fixed average block time in conjunction with the upper limit on block size is to keep the processing and storage burden on ordinary nodes to an acceptable level (see quotations and references at end).

It is also impossible for a node to receive two blocks at the same time. An ethernet interface receives packets serially not concurrently. Even on a Gigabit interface, there will be differences of the order of nanoseconds in packet completion times. Even if a node uses multiple independent network connections, it is trivial to arbitrarily serialise concurrently received packets from eth0 before eth1.

When someone such as Solana say "at the same time" I imagine they really mean "sometime during the same block interval". What they probably should have said is something more like "with the same parent block".

Bear in mind:

  • Real block intervals can vary from seconds to hours.

  • Receiving nodes are not timing the intervals in order allocate blocks to intervals.

  • Block arrival time has no influence on block selection in a timescale of several actual block intervals.

  • When miners see another's block, they immediately stop work on their block with the same parent and start work on the next. Even if that block arrived within microseconds of the prior block leaving almost 10 minutes remaining of the notional current block interval.

It seems to me the last of these points has the most effect in reducing publication of competing blocks with same parent.

Some call this a huge problem that when node receives 2 blocks at the same time

Reordering the last one or two blocks is not uncommon and is well catered for. So I suspect block ordering is not a primary factor in choosing block intervals. The Bitcoin design allows for each node's initial ordering to be somewhat arbitrary. Consider the effect of physical (or effective) distance etc on message propagation times from two distant miners to two other nodes of varying distance.

What did Nakamoto say in 2008?

The Bitcoin white paper has only one mention of "10 minutes":

If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

So the block interval is associated with the storage burden on ordinary nodes.

Earlier in the whitepaper, Nakamoto writes

Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof- of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

So this kind of activity is allowed for in the design and is not the alleged "huge problem".

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .