<aside> 🚧

This section will be removed once ‣ is implemented, as it eliminates the concept of orphan proofs.

Performing backfilling for each orphan proof block (as described below) is highly inefficient, considering the potential number of orphan proofs in the future and the additional backfillings triggered recursively. This happens mainly in checkpoint sync, particularly during checkpoint sync.

Once Proof of Leadership v0.2 is implemented, this complex orphan proof verification can be eliminated entirely.

</aside>

This is part of the block verification based on Proof of Leadership v0.1. A block is deemed invalid if one of its orphan proof blocks is missing from the local block tree (i.e. if it cannot be checked whether the proof was valid in its original block).

In most cases, these blocks can be treated as invalid and rejected during the synchronization process. However, if the current block tree was built by case 3: checkpoint sync, they should not be immediately rejected. Since the block tree was initialized only with a checkpoint chain and lacks sufficient historical blocks, the synchronization algorithm cannot determine whether the original block of the orphan proof actually exists.

To establish confidence in the block’s validity, a backfilling should be initiated from the missing orphan proof block. Until this backfilling is complete, the forward synchronization (or the backfilling) that triggered it must be paused, as they cannot proceed without verifying the orphan proof.

If the original block is not found from peers, or if it turns out to be invalid during the backfilling, the orphan proof is considered invalid.