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
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”.