How is the problem of orphan blocks solved in this case?

Question

All nodes are online all the time, they were not offline.

What will happen if some of my peers (blue peers) have their chains as follows:

... -> A -> B -> D  (main chain)
        \-> C

while my other peers (green peers) and I have the following:

... -> A -> B -> D  (main chain)

We can get into this situation when the blue peers are connected to some other nodes that considered at some moment chain with the block C as the main. Thus, blue peers received the given block C. However, since for them (blue peers) main chain was the one with B block, they propagated only B to me (and later D), while C was just saved locally as stale block in their stale chain.

Now imagine the following scenario:

1.first comes block E whose parent is C; chains of blue peers looks like this:

... -> A -> B -> D  (main chain)
        \-> C -> E

In this case blue peers will just increase stale chain and won't propagate E since its not a part of the main chain.

2.then comes block F whose parent is E; chains of blue peers looks like this:

... -> A -> B -> D  
        \-> C -> E -> F (main chain)

In this case blue peers will switch to chain with F and since that's their new main chain, they will propagate F (header message) to us.

The problem here is that upon receiving block F (its header through header message) we will try to validate its parent hash first and since block E is unknown us, we will consider block F as orphaned and reject it. This way we will consider all future blocks as orphaned and reject it. As a consequence of this we will remain completely isolated in the network (me and all my red peers). Even if we connect to some other networks peers now, the situation would stay the same. How is this solved?

Answer 1

The problem here is that upon receiving block F (its header through header message) we will try to validate its parent hash first and since block E is unknown us, we will consider block F as orphaned and reject it.

The behavior you describe would make no sense. Nodes obviously must be capable of catching up to chaintips across multiple blocks, e.g. when they were offline for a few hours.

When a node reorgs to a new chaintip, it calculates the forkpoint, i.e. the last shared ancestor block of the two chaintips. It uses the forkpoint to determine the blocks that other peers might be missing. Per peer it then checks against the last block that was announced from that peer and the last block itself announced to the peer, whether the peer might already have some of the blocks. The node then announces the remaining header to the peer if it’s just a few missing blocks. Otherwise, it provides an inv message, which the receiver may reply with a getheaders message to. The getheaders message includes a block locator which is a description of the requester’s best blockchain. The block locator includes the last few block hashes and then an exponentially spaced list of further block hashes that provide the other node with the ability to find a shared ancestor.