The block time is 10m, which is often so much that no two blocks can be solved at the same time.
I don’t think this is true.
I think the primary purpose of the constant average block time along with the upper bound on block size is to keep the processing and storage burden on normal nodes to an acceptable level (see quotes and references at the end).
It is also impossible for a node to receive two blocks at the same time. The Ethernet interface receives packets sequentially rather than synchronously. Even on the Gigabit interface, there will be differences in the order of nanoseconds in packet completion times. Even if a node uses several independent network connections, it is trivial to arbitrarily sequence packets received concurrently from eth0 before eth1.
When someone like Solana says “at the same time” I imagine they really mean “sometime during the same period of time”. What they should have probably said was something like “with the same parent group”.
takes into account:
Real mass periods can vary from seconds to hours.
Receiving nodes do not time slots in order to allocate blocks for slots.
Block arrival time has no effect on block selection on a time scale of several actual intervals.
When miners see someone else’s block, they immediately stop working on their block with the same parent and start working on the next block. Even if that block arrives within microseconds of the previous block, leaving approximately 10 minutes remaining from the default current block interval.
It seems to me that the last of these points has the greatest effect in reducing the propagation of competing blocks with the same parent.
Some call this a big problem when a node receives two blocks at the same time
Rearranging the last block or two is not uncommon and is well catered for. So I suspect that block request is not a key factor in choosing block periods. Bitcoin’s design allows the initial order of each node to be somewhat random. Consider the effect of physical (or effective) distance etc. on the propagation times of a message from two remote miners to two other nodes of varying distances.
What did Nakamoto say in 2008?
The white paper on Bitcoin contains only one mention of “10 minutes”:
Assuming blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. Since computer systems are typically sold with 2GB of RAM as of 2008, and Moore’s Law predicts current growth of 1.2GB per year, storage shouldn’t be a problem even if block headers must be kept in memory.
So the block interval is related to the storage burden on normal nodes.
Nakamoto wrote earlier in the white paper
Nodes always consider the longer string to be the correct string and will continue to work on extending it. If two nodes simultaneously broadcast different versions of the next block, some nodes may receive one or the other first. In this case, they work on the first branch they got, but save the other branch in case it gets longer. The tie will be broken when the next working guide is found and one branch becomes longer; The nodes that were running on the other branch will switch to the longer nodes.
So this kind of activity is allowed in the design and not the so-called “big problem”.