what is the mapBlocksUnknownParent variable?

Question

I was reviewing this pull request. It was an attempt to remove the global variable mapBlocksUnknownParent. I found the definition here. In the CChainState::LoadExternalBlockFile function.

    // Map of disk positions for blocks with unknown parent (only used for reindex)
    static std::multimap<uint256, FlatFilePos> mapBlocksUnknownParent;

Questions:

1. What is the mapBlocksUnknownParent variable? Where is it useful?

2. What does LoadExternalBlockFile function do? (by its name I deduce that it reads blk???.dat files and load them into the memory at the start up, but I'm not sure)

3. When it is possible to have blocks with unknown parents? While AFAIK we always reach blocks through their ancestors, not descendants. So in which situation we have a block with unknown parent?

4. Why this variable is considered global while it is defined inside of a function scope? Is this because the variable is static?

Answer 1

1. What is the mapBlocksUnknownParent variable? Where is it useful?

It keeps a map of blocks in the blk*.dat files whose parent is unknown, indexed by the block hash of that parent.

2. What does LoadExternalBlockFile function do? (by its name I deduce that it reads blk???.dat files and load them into the memory at the start up. But I'm not sure)

It deals with importing blocks from external files. This means not from the network, and not blocks already in our block database. It happens in two contexts:

• When a file is specified on the command line using -loadblock=<FILE>; this can be used to import blocks e.g. given to you on portable media (say, a USB stick).
• When running with -reindex, in which case the block database is wiped, but the blk*.dat files are kept, and then this "importing" operation is run on these still existing blk*.dat files.

3. When is it possible to have blocks with unknown parents? While AFAIK we always reach blocks through their ancestors, not descendants. So in which situation we have a block with unknown parent?

When requesting blocks from the network, we only ask for blocks whose parents are known (at least the headers must be known), so indeed, this variable isn't useful in that context. But the blocks are not downloaded in order, and the blk*.dat files contain blocks in the order they were received.

This means that when using -reindex to rebuild the database, some blocks will be encountered out-of-order, meaning blocks will be read whose parent isn't known yet. To deal with this situation, LoadExternalBlockFile keeps track of these blocks without known parent. When the parent is encountered and processed, the children will be processed too.

4. Why this variable is considered global while it is defined inside of a function scope? Is this because the variable is static?

Exactly. static variables in function scopes are effectively globals that can only be accessed from that function. Only one instance of the variable exists, shared between all invocations of that function.