Assuming that more future blocks are refer to A as a predecessor, A will be part of the longest chain, while B is referred to as an
orphan block. I was trying to figure out how often such a scenario takes place.
I found this graph on blockchain.com:
https://www.blockchain.com/charts/n-orphaned-blocks (select
All Time and
Raw Values)
It's a stale block. They are not orphaned blocks as the preceding block is known. Stale blocks are often referred to as orphan blocks but that'll be the wrong term to use.
Can someone verify the correctness of this chart?
You can't. Stale blocks are often poorly propagated as nodes do not propagate competing blocks at the same height once they have seen either of them. To answer your question; it's not accurate, BitMex just recorded a stale block yesterday and it isn't reflected on the chart.
If it is correct, why do such micro forks only occur between 2014-2018?
I thought such a scenario would happen way more often.. Why not?
The spike that you see in 2015 is mainly due to the SPV mining fiasco that happened around that time, where an invalid block was mined and miners continued to build on that chain due to the fact that they didn't validate the block before mining on it and thus accounting for that spike in stale blocks. The reason why the stale blocks happens much less often, but still happens occasionally is due to the implementation of compact block[1] which relays the blocks way faster than before and it was introduced a Core version in late 2016, IIRC[2]. If the mining pools are well connected to each other, as they should, they could avoid mining on the wrong chain and losing their block rewards. Selfish mining could contribute to stale blocks but I'm not sure if that has happened yet.
I'm operating a full node. Can I verify the numer of orphan blocks by myself? (Are they stored by my node)?
You have to be running a node for the entire duration to record down any stale blocks that has been relayed to you. You'll find it hard to record the accurate number of stales without quite a few nodes and/or a well connected node. You can probably run quite a few nodes and just issue getchaintip to each of them from a central server and note any discrepancy between the responses. That's probably how forkmonitor.info is doing it as well, but at a more refined level probably.
[1]
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki[2]
https://github.com/bitcoin/bitcoin/blob/c7ad94428ab6f54661d7a5441e1fdd0ebf034903/doc/release-notes/release-notes-0.13.0.md